freenode/#lisp - IRC Chatlog
Search
18:59:57
dieggsy
have any of you seen an issue with sly and ACL where it says polling ... infinitely
19:02:47
splittist
lotuseater: you need (from github) the nuddyco/McClim cloned into your quicklisp/local-projects/ (or wherever you put those things), then the nuddyco/slime somewhere in your emacs load-path, remembering to use the slime-clime contrib.
19:04:31
dieggsy
Xach: what OS are you on? i wonder if it's some weird macOS thing. normally i run linux
19:14:25
lukego
okay, sorry a bit late at night to backport that. maybe just load this file https://github.com/emacs-mirror/emacs/blob/master/lisp/emacs-lisp/text-property-search.el
19:16:02
lukego
weird. the function is in the manual anyway so I'm not sure whassap. https://www.gnu.org/software/emacs/manual/html_node/elisp/Property-Search.html
19:17:40
splittist
lukego: requiring text-property-search, and fixing a 'first' (-> car) and it works!
19:25:52
dieggsy
oh, i'm seeing an error in the inferior-lisp buffer: Error: Symbol "PACKAGE-LOCAL-NICKNAMES" not found in EXCL package.
20:40:23
lotuseater
pjb: and i once got the impression of lispworks by reading on their website it has also good support on mac for building "apps"
21:09:02
lotuseater
or the lectures on his youtube channel (mostly in german) are also very interesting
21:12:44
pjb
lotuseater: indeed, but it's a commercial implementation. freenode is for discussion of free(dom) software ;-)
21:37:34
luis
splittist: are there any bits that could be used by slime without clim for visualizing things? E.g., it’d be nice to draw class hierarchies in the inspector (or a new class browser, bits of which I’ve got in the works)
21:47:46
phoe
luis: or even better - have a slime contrib that follows some sort of swank-ish protocol on the CL side
21:48:40
phoe
this way you become clim-agnostic with a thin layer of intermediate stuff in the middle
21:49:27
phoe
this way you can load it independently of clim, you just won't be able to display anything by default until clim or some other client is loaded
21:51:00
luis
phoe: right, there are a couple of ways to customize the inspector and things like that but is
23:19:14
nij
Is there any tendency among the #lisp community to move toward a nix/guix-like package (or called systems in CL's term) management strategy, if tools are available?
23:20:20
tychoish
I think a lot of scheme folks use guix because the package manager is written in guile (maybe? I think?)
23:21:40
nij
Yeah.. but none of the CL's platform is close to guix/nix afaik, in the sense of reproducibility.
23:25:11
nij
tychoish: Umm I guess so, haven't really tried them seriously. But what they promise seems great.
23:26:12
tychoish
and "as long as everything runs in guix/nix" and "as long as you don't dynamically link anything"
23:26:23
tychoish
and there are ways that guix/nix assume a compilation model that doesn't really apply to CL? and there are ways to sort of get a lot of the same benefit?
23:29:49
tychoish
I think there are definitely buildsystem and compilation improvements to be made: like it'd be nice to be able to cross compile things, or be able to have per-project quicklisp dependencies/etc.
23:57:21
fiddlerwoaroof
nij: my main issue with nix/guix for CL is that I would then have to restart my REPL to install new dependencies
0:00:15
nij
fiddlerwoaroof: Hmm.. I'm not sure what you mean. Isn't guix only in charge of getting the dependencies? We can then load the dependencies in a running repl like we usually do, without turning the repl off.
0:01:36
nij
The problem is, guix can get you many different "versions" (written in hash) of CL-systems with the same name. So whatever function you used to "load" (e.g. asdf:load, ql:quickload) should be aware of that. But I don't think it's terribly hard to make that "load" function behave accordingly.
0:02:55
nij
I'm really just trying to change the usual version to hash. So instead of hello-2.10, I think it's better to have 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i-hello-2.10.
3:49:20
fiddlerwoaroof
nij: my hope is to come up with a way to specify a set of git repositories to clone and generate an ASDF configuration from, all within lisp
3:53:50
fiddlerwoaroof
Something like line 75 here: https://git.fiddlerwoaroof.com/u/edwlan/git-systems.git/blob/master/git-systems.lisp#L75
3:54:54
nij
I hope so too, that'd be the first step without using hash. Emacs has this too - https://github.com/raxod502/straight.el
3:56:36
lukego
splittist: I hopefully pressed the right button to give you commit bit. welcome to push directly :)
3:56:50
pjb
fiddlerwoaroof: have a look at: https://github.com/informatimago/lisp/blob/master/tools/make-depends.lisp
4:00:50
nij
pjb: Would you mind explaining a bit how it reltaes? And if you think it makes sense to merge this into asdf?
4:04:11
pjb
nij: oh, you mean a configuration for asdf, not an asd file? I thought you meant the later. That code reads lisp sources (notably defpackage forms), and generate file dependencies. This could be used to generate asd files.
4:06:38
pjb
I thought you wanted com.informatimago.common-lisp.make-depends.make-depends:generate-asd
4:07:54
pjb
I still find that asdf:*central-registry* is perfectly good… https://github.com/informatimago/lisp/blob/master/tools/asdf-tools.lisp#L126
4:11:49
lukego
luis: If CLIM feels heavyweight maybe an alternative solution could be a slimmed down CLIM? Maybe it even already exists e.g. an ASDF system within McCLIM that loads what we need for Emacs but not other parts e.g. X11 and PDF backends. The more I play with McCLIM lately the more it feels like the core APIs don't require /that/ much machinery.
4:28:03
fiddlerwoaroof
pjb: the code I shared clones the specified git repositories and generates and ASDF configuration that makes them loadable with load-systems, I think it's slightly different from what you're sharing
4:28:31
fiddlerwoaroof
lukego: isn't part of the issue with SLIME just that it has to be careful about depending on libraries that might conflict with the user's projects?
4:29:30
fiddlerwoaroof
I wonder if there's some-way to use the mechanism it has for picking sbcl/ccl/lispworks backends to also allow us to use mcclim if it's already been loaded
4:36:13
engblom
Is it possible to compile a standalone binary? (asdf:make :my-project) is not standalone, as it still requires that all dependencies are installed.
4:38:18
pjb
engblom: you can save an executable image that contains all the dependencies, so standalone.
4:39:30
pjb
engblom: in the case of ecl, it's different, since it generate elf binaries. But you can do essentially the same, for lisp dependencies.
4:42:12
splittist
I seem to remember that refactoring the clim asd/loading mechanism was on a roadmap somewhere (possibly even as 'done'). If you don't need the font/CLX stuff then it's already pretty lightweight. And it's virtually nothing compared to the giant piles of js every tab in your browser is loading for no apparent reason.
4:44:06
engblom
fiddlerwoaroof: Lets say you have a project that got dependencies on a few library. When doing (ql:quickload :my-project), quickload will pull down all dependencines. If you then do (asdf:make) you get a binary, but it does not contain those libraries so if you move it to another computer it will not run
4:47:10
lukego
luis: current state of "nested presentations" in CLIME: Emacs sees just one image, but the mouse-sensitive presentation regions form a tree, with the innermost ones overriding the outer ones. for now those regions are all rectangles (bounding boxes) but Emacs can do polygons/circles too. if you (accept TYPE) then the non-matching presentations go away and don't occlude the acceptable ones
4:55:36
White_Flame
lukego: regarding heavyweight, GUIs really should be heavyweight. Good text support, complex layout, hardware acceleration, nice antialiasing, caching, etc can all be pretty large features that give good quality and offload work from the user. I think it's a resonable tradeoff
4:56:18
White_Flame
and IMO making a heavyweight GUI layer is the only way for complex things to run fast
4:56:57
White_Flame
(in a general programming sense, not a hpc/gaming sense which tends to seek fixed pipelines for everything)
4:58:54
lukego
White_Flame: Fine but in this context Lisp doesn't do that work anyway: it's outputting SVG and Emacs/imagemagick is doing that heavy lifting stuff.
5:08:25
lukego
more reuse potential would be to port the little bit of Elisp code to Javascript and then have browser-based CLIM too. but that's not really my wheelhouse.
5:09:48
fiddlerwoaroof
What you're probably running into is shared libraries not being present: there's workarounds here (e.g. bundling the .so files with your executable or providing a shell script to install them with apt or various static linking mechanisms) in most cases I find that I can just cut the problematic dependency (osicat is one thing I try to avoid depending on, for example)
5:28:28
White_Flame
lukego: yeah, I've been threatening to do something like that for a long time, although I'd likely not go clim
5:29:03
White_Flame
the browser languages have a ton of cruft, but also great features & quality of rendering
5:42:05
nij
fiddlerwoaroof: Oh yes that's quite neat. That would solved my issue for system fetching.
5:43:59
fiddlerwoaroof
But, the idea would be to define a specific commit with something like this: (:git "fwoar-lisputils" "https://github.com/fiddlerwoaroof/fwoar.lisputils.git" "751faf8a933f1a7a023945b544f0f1b563964391")
5:44:54
fiddlerwoaroof
the :git bit at the beginning lets you also pull down tarballs from an HTTP server or something, the next component is a directory name, then a source url and the commit hash
5:47:45
fiddlerwoaroof
I think it's basically a good idea to separate the system definition facility from the facility that resolves the systems to urls
5:48:30
fiddlerwoaroof
e.g. if I fork CFFI, I should just be able to change the system -> url mapping without having to mess with ASDs or anything
5:49:35
fiddlerwoaroof
So, all the code I have does is clone the git repositories to a project-specific directory and configures ASDF's source registry
5:50:55
fiddlerwoaroof
I haven't thought this through entirely, but I like how ASDF just specifies a list of system names as dependencies
5:52:08
fiddlerwoaroof
I also generally just dislike the idea of version pinning: my experience with NPM and Maven has basically convinced me that version pinning just sort of enables dependency churn
5:53:00
nij
If we can specify which dependency to use by the hash of the system, that would be a huge leap.
5:53:49
nij
fiddlerwoaroof: yeah, I agree too, so let's use this instead: 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i-hello-2.10.
5:53:54
fiddlerwoaroof
If you're forced to upgrade to the most recent release of all your dependencies every time they update, you'll just stop using third party libraries that are inconsiderate about breaking changes
5:55:30
fiddlerwoaroof
The problem I have with version pinning is that it encourages you to not upgrade your code to the new version
5:55:41
nij
Another way is accretion, but that requires the whole community to acknowledge.. so I think hash pinning is one of the best practical ways so far.
5:56:35
fiddlerwoaroof
I just have a rule: if a library makes too many breaking changes, I either fork it or I write my own version of the library
5:57:56
fiddlerwoaroof
It makes it easier because they don't have to deal with a maintainer that is inconsiderate of the library's users
5:59:08
nij
With hash-pinning, a build either works or not works. If it works, people can rebuild it with confidence.
6:00:34
no-defun-allowed
I am mostly unaware of any dependency pinning techniques, as libraries I use don't make breaking changes apparently. But it seems like you would have to pin everything in the general case.
6:00:58
no-defun-allowed
Say, if a kernel changed the syscall interface, then code might not work. Or do you pin the kernel version?
6:03:49
fiddlerwoaroof
no-defun-allowed: a nice thing about Linux is that Linus is pretty adament of not breaking syscalls, iiuc
6:04:09
moon-child
most userspace libraries break all the time, making the kernel policy not _super_ useful
6:04:51
no-defun-allowed
fiddlerwoaroof: Yes, my argument rests on unlikely circumstances. Though using *BSD or some other weirdo not-macOS-or-Linux Unix clone is an unlikely circumstance that some #lisp participants take part in.
6:04:56
fiddlerwoaroof
but, the stable syscall API means that containers are usually sufficient as opposed to VMs
6:04:59
moon-child
java/npm practice is to pin major version, but allow updates to minor versions. The theory being that minor versions will not break compatibility but major versions may. From what I can tell this works out ~~alright in practice
6:05:38
fiddlerwoaroof
moon-child: however, everyone ends up using package-lock.json which forces dependencies to have the correct hash
6:06:17
fiddlerwoaroof
maven's version conflict resolution algorithm is "pick an arbitrary version and hope it works"
6:06:55
fiddlerwoaroof
Which works surprisingly well, until you run into something like a transitive dependency on five different incompatible versions of Guava
6:08:45
nij
no-defun-allowed: uh I think hash pinning can only guarantee reproducibility in terms of building.
6:08:49
fiddlerwoaroof
My experience with npm and java/clojure has lead me to think that _not_ pinning and just fixing breakage as it comes up ends up being better
6:09:52
nij
fiddlerwoaroof how do java/clojure community do? They explicitly ban any sort of pinning?
6:11:37
nij
I've heard of Hicky's idea on accretion. But I don't know how they force people to use that method.
6:12:19
fiddlerwoaroof
You end up with million-line codebases stuck on a 10 year old version of hibernate because it would take a week to upgrade
6:13:22
fiddlerwoaroof
And, the solution is generally to use CI tooling (e.g. Dependabot on Github) that automatically bumps the version whenever a new version of a dependency is released
6:14:42
fiddlerwoaroof
Clojure is a bit more like CL, though: most Clojure libraries I used are safe to upgrade and even go years without active maintenance because they're considered "done"