Would it be some ASDF extension you use that tries to instantiate OPERATION without going through MAKE-OPERATION?

I tried to run your script, but it expects me to setup a DWIM_WORKSPACE in a way that seems to be undocumented.

I tried to build projectured with its build script, and that works fine for me... until it tries to find .so's in /usr and such, which doesn't work with NixOS. :-( [Previously worked fine in Ubuntu.]

Also, after loading ASDF, your scripts could do this: --eval "(ignore-errors (load (uiop:subpathname (user-homedir-pathname) "quicklisp/setup.lisp")))" \

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To distinguish the real from the unreal, one must experience both. — Saul Gorn

On Wed, Nov 16, 2016 at 6:49 AM, Attila Lendvai attila@lendvai.name wrote:

...

Please try it out. Working towards a release of ASDF soon, so anything you could do to help iron out bugs would be very much appreciated!

i did a thoughtless git checkout and rebuild, and i got the attached backtrace.

the issue is with the new ban on operation instances. note that it seems to happen during an upgrade of ASDF itself, which may or may not be relevant.

maybe for a while it should only be a full warning?

my script is basically a build script for an executable SBCL image that loads all dependencies of our projects except our projects themselves. the dependencies come from the a mixture of the latest of quicklisp and my workspace.

hope this helps,

-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Nobody in the world, nobody in history, has ever gotten their freedom by appealing to the moral sense of the people who were oppressing them.” — Assata Shakur (1947–)

On 11/16/16 Nov 16 -10:31 AM, Attila Lendvai wrote:

another data point:

it was caused by asdf-system-connections. i thought i got rid of that long ago, but it's included in ql, and it got installed on my system somehow.

after

(ql:uninstall :asdf-system-connections)

my script continues, but then fails later on with iolib's IOLIB/GROVEL::PROCESS-OP.

Thanks, filed https://github.com/sionescu/iolib/issues/40

Best, r

I think we wait for iolib, but probably not ASDF system connections. Its github site shows no commits for four years, so that might be a long wait....

Sent from my iPad

On Nov 16, 2016, at 23:49, Faré fahree@gmail.com wrote:

I sent these pull requests to fix the issues: https://github.com/gwkkwg/asdf-system-connections/pull/2 https://github.com/sionescu/iolib/pull/41

Grepping Quicklisp, it appears that two more projects needed fixes, but it's actually an example in cl-graph (of extracting a graph of ASDF dependencies, which was broken, and which I fixed, leveraging POIU's graph representation), and a trivial fix for asdf-dependency-grovel, which I could push since I'm maintainer.

https://github.com/gwkkwg/cl-graph/pull/11 https://gitlab.common-lisp.net/xcvb/asdf-dependency-grovel/commit/07e3ff57a5...

I hope that's all. I would refrain from releasing an ASDF with this restriction until both asdf-system-connections and iolib have been fixed.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The difference between a programmer and a user, is that the programmer knows there is no difference between using and programming. — Faré

...

On Wed, Nov 16, 2016 at 8:36 PM, Robert Goldman rpgoldman@sift.net wrote:

...

On 11/16/16 Nov 16 -10:31 AM, Attila Lendvai wrote: another data point:

it was caused by asdf-system-connections. i thought i got rid of that long ago, but it's included in ql, and it got installed on my system somehow.

after

(ql:uninstall :asdf-system-connections)

my script continues, but then fails later on with iolib's IOLIB/GROVEL::PROCESS-OP.

Thanks, filed https://github.com/sionescu/iolib/issues/40

Best, r