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"
6:31:40
moon-child
the erlang creator once proposed--not entirely seriously--I think--but who knows-- a scheme where libraries would be obviated and functions would be identified exclusively by hash
6:35:15
fiddlerwoaroof
I have generally started to come around to a similar conclusion: https://gbracha.blogspot.com/2009/06/ban-on-imports.html
6:37:16
fiddlerwoaroof
Nix does this, a module is basically just a function (although you can use imports to specify default argument values), and I think this sort of parameterized module system solves a lot of problems
6:38:37
moon-child
I thought nix operates on the level of whole libraries, not individual functions?
6:39:00
moon-child
(and indeed, I don't know how you could do the latter unless the language were built for it, in the face of e.g. global variables)
6:39:47
fiddlerwoaroof
All the expression's dependencies get passed as arguments like this: https://github.com/coq/coq/blob/master/default.nix#L24-L33
6:40:41
engblom
I saw Clojure and libraries being mentioned and there is one thing I think Clojure does better: When creating a new project all dependencies are pulled into the project folder and you specify exactly what version of the libraries you want to use. Like that you can ensure your application will compile even if the upstream library would be completely rewritten. But of course it put some responsibility on the
6:44:15
beach
engblom: How does it handle the situation where two applications need different versions of the same library, and the two versions can't coexist in the same image?
6:44:58
fiddlerwoaroof
Unless you're doing fancy classloader stuff that few people actually does, Maven has a rule for resolving the conflict
6:46:33
beach
I can't see how you can simultaneously respect the exact version that has been specified, and resolve the conflict by picking a different version.
6:48:23
fiddlerwoaroof
The way modules work, a single module can be included multiple times with multiple versions
6:51:17
fiddlerwoaroof
I think Racket/various Schemes might also have a solution here, but I've never used them enough to find out
6:52:26
engblom
beach: You probably mean "one application need different versions of the same library". I have never tested that, so I do not know how that works. If two separate applications need the different versions that is no problem.
6:53:35
fiddlerwoaroof
engblom: I'm a bit surprised you haven't run into this. I've never worked on a substantial Clojure project that didn't have issues with version conflicts among the transitive dependencies
6:55:31
engblom
fiddlerwoaroof: The projects I have done in clojure are smaller, and often raspberry pi related, or some other small tools. I am the author of https://github.com/engblom/gpio which is a gpio library written in Clojure.
6:55:40
luis
lukego: slim-clim could work! re presentations, I have an optimisation that I want to commit (dropping overlays) that I might need to coordinate with you
6:56:29
engblom
fiddlerwoaroof: I have plans to make a gpio libary in CL, once I get time. The better startup time of CL is the motivation. Clojure takes a lot of time to start up on rpi.
6:57:08
luis
moon-child: if Linux didn't commit to not breaking user-space containers would be much less reliable wouldn't they since they share the host kernel
6:58:16
engblom
The Clojure library I wrote is using /sys for handing gpio. As it is on its way to get deprecated, I will make the CL library using some kind of ffi instead.