freenode/#lisp - IRC Chatlog
Search
17:01:04
splittist
lukego: I can't seem to make with-output-as-presentation work. I get 'error in process filter: Symbol's function definition is void: assert'
18:05:00
splittist
Also, if you produce a giant image (by, for example, doing a format-graph-from-roots for all the subclasses of clim:design, emacs really doesn't like it ...
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.