Re: Multiple processing compiling the same file

Sorry for the late response. What you have seems like it will work, but couldn't you just as easily use the ASDF output translations configuration facility that is described here:

Re: Multiple processing compiling the same file

On 23 Jan 2018, at 5:47, Pascal Bourguignon wrote: > On 23 Jan 2018, at 12:00, Jim Newton wrote: If I run several sbcl processes on different nodes in my compute cluster, it might happen that two different runs notice the same file needs to be recompiled (via asdf),

Re: Multiple processing compiling the same file

(Sorry for delayed response) >>>: Jim Newton >>> If I run several sbcl processes on different nodes in my compute cluster, >>> it might happen that >>> two different runs notice the same file needs to be recompiled (via asdf), >>> and they might try to compile it at the same time. What is the

Re: spurious reloads with systems not following the foo/bar naming convention?

On Tue, Jan 30, 2018 at 1:18 PM, Attila Lendvai wrote: >> I believe this is the bug that was fixed in 3.3.1.3. > > FYI, there's no such tag pushed into the official repo. > https://gitlab.common-lisp.net/asdf/asdf/tags > Robert and I failed to push the 3.3.1.2 and 3.3.1.3

Re: "deprecated recursive use" warning

On 30 Jan 2018, at 15:53, Attila Lendvai wrote: I haven't used CFFI in a while. TL;DR: is this a sane fix? https://github.com/cffi/cffi/commit/4b9b06f15912e823581b1aeb8a0d5c2ef11f702d -- and here follows the elaborate email that led me to find the above solution: a bit of

Re: "deprecated recursive use" warning

On Tue, Jan 30, 2018 at 4:53 PM, Attila Lendvai wrote: >> I haven't used CFFI in a while. > > TL;DR: is this a sane fix? > > https://github.com/cffi/cffi/commit/4b9b06f15912e823581b1aeb8a0d5c2ef11f702d > (the (not null) ...) is redundant around find-system without the nil

Re: hu.dwim.zlib broke; broken operation-done-p

On Tue, Jan 30, 2018 at 5:01 PM, Attila Lendvai wrote: > if you issue the following (available in quicklisp): > > (asdf:load-system :hu.dwim.zlib) > > then for the first time it should generate a lisp file, which then gets > compiled and loaded. > > issuing it for the second

hu.dwim.zlib broke; broken operation-done-p

if you issue the following (available in quicklisp): (asdf:load-system :hu.dwim.zlib) then for the first time it should generate a lisp file, which then gets compiled and loaded. issuing it for the second time shouldn't do anything, but since some revisions it regenerates the lisp file every

Re: "deprecated recursive use" warning

> I haven't used CFFI in a while. TL;DR: is this a sane fix? https://github.com/cffi/cffi/commit/4b9b06f15912e823581b1aeb8a0d5c2ef11f702d -- and here follows the elaborate email that led me to find the above solution: a bit of background: it's a subsystem of CFFI that generates the

Re: "deprecated recursive use" warning

I haven't used CFFI in a while. Can I ask why this needs to be here instead of there being a ``` :depends-on ((generate-lisp-op (load-op "cffi/c2ffi-generator"))) ``` ? Thanks, r On 30 Jan 2018, at 12:20, Attila Lendvai wrote: dear list, shall i be concerned about this? WARNING:

"deprecated recursive use" warning

dear list, shall i be concerned about this? WARNING: Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP '("cffi/c2ffi-generator")) while visiting (CFFI/C2FFI::GENERATE-LISP-OP "hu.dwim.zlib" "c2ffi-spec" "zlib.h") - please use proper dependencies instead it

Re: spurious reloads with systems not following the foo/bar naming convention?

> I believe this is the bug that was fixed in 3.3.1.3. FYI, there's no such tag pushed into the official repo. https://gitlab.common-lisp.net/asdf/asdf/tags using HEAD, the test case i sent doesn't fail anymore, but our own issue still prevails. it's a large environment with many systems, but