libera/#commonlisp - IRC Chatlog
Search
15:35:56
NotThatRPG
hexology: You should be able to host your projects on cl.net's GitLab -- I forget the actual means to do this, but it's on (or near) their home page
15:38:26
morganw
If the cost was legitimately a problem I think sourcehut are open to giving financial help: https://sourcehut.org/pricing/
15:40:06
NotThatRPG
Shinmera: Looking at redist, I'm wondering why you scan the ASDF files instead of loading them. You might miss some dependencies that way. Hm.... The obvious technique would be to load up an ASDF system definition in a subsidiary Lisp, but CL invoking a new image is really hard because CL doesn't have any equivalent to `sys.executable` in python
15:43:37
NotThatRPG
Shinmera: There are some things that `defsystem-depends-on` still does not handle. As I said, the best thing would be to fire up a new lisp process, load the system in there, and interrogate that lisp process. But that's not possible in portable CL. :-(
15:44:28
NotThatRPG
I guess that's non-trivial, because you would also need to know what, if any, core is loaded
15:44:40
Shinmera
Anyway, not sure what you mean by "things that defsystem-depends-on does not handle".
15:45:31
NotThatRPG
Some ASDF extensions have issues because by the time they are loaded, ASDF can fail to parse the defsystem containing them (because that defsystem contains extensions that must be loaded prior to parsing)
15:47:19
NotThatRPG
Anyway, it would be great if CL offered a way to open up a new lisp process with the same characteristics as the invoking process.
15:48:29
NotThatRPG
oh, yes, we can fork, but you can't do the trivial python thing of using `sys.executable` to find what to fork.
15:49:48
NotThatRPG
Fare tried to do this in a library for testing, but it's quite cumbersome, and it relies on populating a lot of environment variables. I wonder if we could enhance UIOP/launch-process to make this easier...?
15:51:40
NotThatRPG
White_Flame: Yes, that's why UIOP would be a good place for this. UIOP could probably also give a portable "loaded core," but that might be a little unpleasant to manage. Just a lot of drudgery to cover all of the implementations.
15:54:00
NotThatRPG
OK then.... I should add a GL issue for this. But first I need to get on my bicycle and head downtown...
16:01:14
Shinmera
But also, I actually *can't* simply load the ASD in another process and read out the deps. That would *miss* dependencies that are feature-test-excluded.
16:49:46
Shinmera
Comparing with the quicklisp systems.txt that lists dependencies the differences seem to be down to: quicklisp including asdf as a dependency on a lot of systems? even if that system does not list the dependency explicitly. quicklisp including dependencies that seem transitive, but only on some systems and not others. and quicklisp missing a bunch of dependencies that are under feature flags.
16:50:50
Shinmera
The diff is a pain in the ass to look at as a consequence, but so far I have not spotted an occurrence where my system misses a dependency.
17:19:18
Shinmera
Okey, I now also deal correctly with folks that do asdf:load-system (or any variant thereof) in their .asds.
18:23:58
NotThatRPG
Shinmera: I haven't had time to check, but I do think there are still places where defsystem-depends-on does not work.
18:27:26
NotThatRPG
I don't think it's necessarily a "boo" to the people still hand-loading dependencies.
18:35:39
pjb
NotThatRPG: (uiop:raw-command-line-arguments) #| --> ("/usr/local/src/ccl/dx86cl64") |#
18:36:23
pjb
NotThatRPG: so the executable path would be: (first (uiop:raw-command-line-arguments)) #| --> "/usr/local/src/ccl/dx86cl64" |#
18:36:59
pjb
NotThatRPG: you'd have to know the options of each CL executable and how it finds the image, either from arguments or by default.