Re: Method combination and ASDF

On Thu, Apr 25, 2024 at 9:11 PM Faré wrote: > > Funny, but ASDF 1 at some point (commit aa52ad22 1.128 to 1.636) up was > defining its own method combination, so users could write their own methods > without overwriting ASDF's (but still overwriting each other's). > > In pr

Re: Method combination and ASDF

Funny, but ASDF 1 at some point (commit aa52ad22 1.128 to 1.636) up was defining its own method combination, so users could write their own methods without overwriting ASDF's (but still overwriting each other's). In practice it was only used for two :around methods for perform, with one being

Re: Method combination and ASDF

1. I once implemented a more general mechanism for binding syntax variables around compilation, which must be part of the syntax-control branch (that probably needs a lot of love rebasing it on top of the latest ASDF). Syntax variables include *readtable*, *read-base*, *read-default-float-format*,

Re: Method combination and ASDF

What are the methods defined by asdf-flv? IIRC, POIU also has a few :around methods (it also doesn't properly support ASDF 3.3 phases). -#f On Tue, Apr 23, 2024, 17:24 Robert Goldman wrote: > An issue that came up discussing ASDF-FLV with Didier has to do with > outside modification to

Re: Loading only fasl files

You may be interested in deliver-asd-op to create a system that consists in a fasl that you load. On Sun, Apr 21, 2024, 13:42 Greg Bennett wrote: > Hello from Greg Bennett who is trying to debug some compilation issues > in Allegro. > > I have what I believe to be a completely compiled project,

Re: Readtable not bound to standard around compilation

rpg:>> Given that Quicklisp and SBCL already refuse to update their bundled ASDF versions, because of warnings about deprecated behavior, I'm reluctant to donate any of my unpaid time to fixing this: it's a strong disincentive to making any improvements to ASDF, as opposed to just fixing bugs

Re: Readtable not bound to standard around compilation

. In the end you can only protect the developer from himself so much, when you can't change the semantics of CL itself across twenty implementations many unmaintained. On Thu, Feb 22, 2024, 11:16 Faré wrote: > In the past, to introduce changes a fraction as compatibility-breaking > (e.g. maki

Re: Readtable not bound to standard around compilation

ert Goldman wrote: > I think this is still true, but... we cannot be discussing ASDF 3.2.1 > here. It was released almost 7 years ago, and for whatever reason Zach > refuses to update. The current version is 3.3.7 > > Please get a more recent ASDF and try again. I *believe* that thi

Re: historical question

On Thu, Feb 1, 2024 at 12:35 PM Robert Goldman wrote: > I'm open to an ASDF history section being added to the manual, or a separate > ASDF history web page being added that would be linked from index.html. > > But I'm not open to doing this myself! I would accept a PR. > > Actually, isn't this

Re: historical question

I think we should add this link, as well as a link to the original README in git (which I suppose subsumes the original defsystem proposal link in the archived email) somewhere in doc/index.html. Looking at said doc/index.html, I see that a lot of references to historical ASDF alternatives were

Re: historical question

•Reflection• http://fare.tunes.org “The only difference between a military and a terrorist often is that the former lives off taxes taken by force from the population, whereas the latter only aspires to it.” On Wed, Jan 31, 2024 at 12:08 PM Faré wrote: > > The initial commit in git is: >

Re: historical question

The initial commit in git is: commit c58257d94bfae7d5a2f527fc1f2d587a0fef8222 Author: Daniel Barlow <> Date: Wed Aug 1 17:52:49 2001 + Initial revision If you want to find out when he actually started working on it, you should ask Daniel which day he started working on it—or maybe dig

Re: Request for assistance: GitLab actions

Would it be that the images were created with the exact same Dockerfile recipe in different environments? Docker could be doing the caching wrong because it ignores the environment when caching. A solution is to modify at least one byte in the Dockerfile—when I generate Dockerfile's, I include a

Re: Past discussion on ASDF loading

Do you have multiple versions of ASDF installed? e.g. one from Allegro and another from your source-registry or system-registry ? ASDF always upgrades itself first thing to avoid Big Problems otherwise. If that's what you're experiencing, I recommend the right after you (require "asdf") and

Re: Removal of feature from UIOP library

That's probably my bad for never completing and testing this feature. IIRC, it was originally meant to ensure that the optimization settings used by ASDF should not be affected by those used outside of it, nor affect them, so as to avoid weird side-effects wherein the behavior of a system depends

Re: ASDF config file under Windows

ork colleagues were doing something in > their CL init files that must have loaded some ASDF systems, because they > were seeing configuration happen before they got into interactive contact > with the REPL. > > Thank you very much for clarifying, Faré! > > > On 4 Jun 2023, at

Max version constraints

Dear Robert & asdf-develers, I was discussing max version constraints and the havoc they wroke on Haskell land, yet the legitimate use they have in toplevel projects integrating many libraries, and figured that maybe the solution could be a difference in treatment between max version constraints

Re: ADG: handling functions defined after a reference

IIRC, at ITA we loaded all the source code of QPX as source code in a first pass before we compiled it, to get all the functions resolved (happily, there weren't any macro-defining macros requiring more than one level of such loading), due to the code having been defined without such a clean build

Re: asdf-dependency-grovel tests mostly passing now

Congratulations for resurrecting ADG. > I wonder why the appropriate dependency wasn't detected, but I'm not > too worried about it. ADG is still useful even if it misses these. > There is no guarantee when the types defined by deftype are or aren't going to be expanded and checked, unless you

Re: progress on asdf-dependency-grovel

> I tried it again with ASDF 3.3 + SBCL 2.1.1, and I can load adg > successfully, with a couple of (push "path/to/adg/" > asdf:*central-registry*) to help it along. I strongly recommend using the ASDF2-era source-registry instead. > However, when I try to run > the unit tests, I get an error from

Re: progress on asdf-dependency-grovel

> I tried a later version (3.2 or 3.3, I forget which) and adg fails to > load. I think I'll stick w/ the last known working version until I > sort out getting it to run ... > It loads perfectly for me: sbcl --eval "'(#.(require :asdf) #.(in-package :asdf) #.(upgrade-asdf) #.(load-system

Re: progress on asdf-dependency-grovel

ening, which is encouraging. > Faré, can you say anything about what one should expect to see in the > debug output if stuff is working correctly? Can you see anything amiss > in the output shown below? > This output doesn't help me. Are the files now visited by the perform me

Fwd: Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel

-- Forwarded message - From: Faré Date: Thu, Dec 15, 2022, 04:02 Subject: Re: Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel To: Robert Dodier asdf-dependency-grovel predates asdf 2, and probably bitrotted with asdf 3. My guess is that its

Re: Define a Simple Echo-Op

> > > ASDF as it exists now is not capable of running anything in parallel. > Faré has an experimental project to do this, called POIU, but I > > can't speak for its status. Until very recently, SBCL was incapable of > compiling files in parallel, and still today, lots of cod

Not watching asdf anymore

Dear ASDF developers, just writing this email to tell you that I'm no longer watching ASDF's gitlab, and at some point I may stop reading this mailing list. I'm happy to see that ASDF is in good hands, but the current activity is already too much for me. Between running a company and having

Re: Rejiggering the branches

On Tue, Jul 13, 2021 at 9:34 AM Attila Lendvai wrote: >> >> >> Would the "stable" branch be any different from the "release" branch? >> If it's actually a not-so-stable development branch for 3.3 while a >> separate branch contains development for 3.4, then maybe indeed >> calling branches v3.3

Re: Rejiggering the branches

Would the "stable" branch be any different from the "release" branch? If it's actually a not-so-stable development branch for 3.3 while a separate branch contains development for 3.4, then maybe indeed calling branches v3.3 and v3.4 make more sense. —♯ƒ • François-René ÐVB Rideau •Reflection•

Re: System cleanup

Considering that SBCL upgraded to 3.1.5 in July 2015, I think you should be pretty safe assuming that your users' ASDF is more recent than 3.1.4. What more, even Xach seems to have miraculously seen the light: one months and one week ago, he updated the fallback ASDF in Quicklisp from 2.26 to

Re: A CFFI -ASDF integration bug

I suppose this is what the previous setup was trying to avoid, but the perform method on load-source-op could compile the .so file if needed. —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Corollaries to the Law of Bitur-Camember: The political process destroys the value of all

Re: A CFFI -ASDF integration bug

On Tue, Aug 4, 2020 at 6:13 PM Ilya Perminov wrote: > The files are the same. compile-op does not touch them at all. They > are just its fake output-files. Is it a good idea to compile a .c to > .o/.so in a compile-op? Its doc string says ""Operation for compiling > a Lisp file to a FASL". I

Re: A CFFI -ASDF integration bug

On Fri, Jul 31, 2020 at 1:18 PM Ilya Perminov wrote: > As a result inputs and outputs of the ops look like this: > process-op: > input: wrapper-file > output: bindings-file.lisp file.c FILE.O FILE.SO > > compile-op: > input: bindings-file.lisp > output: bindings-file.fasl FILE.O FILE.SO >

Re: A CFFI -ASDF integration bug

On Tue, Aug 4, 2020 at 1:03 PM Ilya Perminov wrote: > > I think protobuf and CFFI structure their operations in a very similar way - > process-op is analogous to proto-to-lisp, it takes a "specification" file and > generates a lisp file and some other files. protobuf generates lisp(fasl) >

Re: A CFFI -ASDF integration bug

I'm not developing ASDF anymore (unless for hire) but I believe the CFFI toolchain has a new maintainer, who might be willing to devote cycles to that (or at least to merging a patch to CFFI). Note that if the code that builds stuff and the code that tracks the dependencies disagree, the right

Re: How to tell if we're being loaded by ASDF?

One hacky way is to check whether *asdf-session* is nil or not. For more precision, check the top of the visiting-action-list of the *asdf-session* and see if its component has the pathname of your lisp file (from (uiop:current-lisp-file-pathname) —♯ƒ • François-René ÐVB Rideau •Reflection•

Re: I should know this... finding INPUT-FILES

1. output-translations is for output-files, not for input-files—except of course that input-files often will in turn call output-files on a previous operation that it depends on. 2. as to output-files, it is the outermost method that applies the output translations—when the second value is NIL;

Re: ASDF dependency graph or complexity score

Jay wrote: > > Thanks. > > I will follow up with Rob later. > > Anyway, thanks for help in the past. I will liaise with Rob to figure out > the best way forward. > > Jay > > Faré > 6:52 PM (14 minutes ago) > to me > > I guess, I will have to step up at some point

Re: PATCH: SIGNAL a condition on test failures, for use with ASDF:TEST-SYSTEM

> > Note that my recommended solution is for a test library to create a > > report file with a test-report-op (that always succeeds at creating a > > report file, but the report file may indicate failure), and the > > test-op just depends on the test-report-op, and signals and error if > > it

Re: long-description

On Tue, Feb 26, 2019 at 8:30 AM Will Mengarini wrote: > > * Robert Goldman [19-02/25=Mo 15:37 -0600]: > > Even if so, why not just add `:documentation-pathname`, > > and then no one will have to worry about type errors? > > +1 > Because adding a new slot means a new ASDF version with its own

long-description

I've seen the pattern of using :long-description #.(uiop:read-file-string (uiop:subpathname *load-pathname* "README.md")) spread among CL libraries. I see it only as a waste of kilobytes of data (quadrupled on 32-bit unicode lisps such as SBCL). I'm told it's because Quickdocs likes it

Re: ASDF upgrade script fails on cmucl/Linux

I believe this is an issue with ASDF upgrade not working on CMUCL due to CLOS issues. The workaround is to use the install-asdf.lisp script to overwrite CMUCL's builtin ASDF with a newer one. — Although I'm not sure whether the script will work if ASDF can't upgrade itself. —♯ƒ • François-René

Re: clisp testing on linux

n the same test, because I am not seeing > this error, and maybe it's causing the segmentation fault. Would you post the > context of the error? > > Thanks! > R > > On 18 Dec 2018, at 17:43, Faré wrote: > > Well, CLISP is known for its deterministic but chaotic se

Re: wild-package-inferred-system

system > (My motivation is to eliminate the need for manually creating > `foo/.../all'-type subsystems that exist only to use-reexport all > .lisp files.) > I'm not convinced this is a good idea, but then again I don't understand your use case. > In accordance with the ASDF Best Practi

Re: clisp testing on linux

Well, CLISP is known for its deterministic but chaotic segfaults (i.e. sensitive to the slightest perturbation in input), probably due to some GC bug somewhere, which would explain your failure. Interestingly, I experience a different failure using GNU CLISP 2.49.60+ (2017-06-25) on NixOS

Re: why does ASDF ask to please only define system/test?

On Tue, Dec 11, 2018 at 2:09 PM Mark H. David wrote: > It seems that any system Y associated with a name X must have its name be of > the form X/Y. For example, when you build "cl-ppcre", you get this warning: > > Please only define "cl-ppcre" and secondary systems with a name starting with >

Re: Timing compilation

> Hello, > > I would like to collect information about the time it takes to compile > an ASDF system (possibly also load it), dependencies excluded. I'm > thinking there's probably a way to do this by :around'ing compile-op, or > something like that, but if someone already has a clear view on

Re: Extracting a UIOP's manual

This looks very helpful indeed. Can you submit a MR on gitlab.common-lisp.net/asdf/asdf ? —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Fraud is the homage that force pays to reason. — Charles Curtis On Thu, Aug 16, 2018 at 3:23 AM Hugo Ishimaru wrote: > > Hi all, > > I

Re: bootstrapping asdf

> I think we should probably clear out all the MRs except the syntax > rationalization, then release bug fix 3.3.3, and then move to get the syntax > branch integrated as a release candidate for 3.4. > > I think the syntax isolation is a big enough change in behavior that it > merits being 3.4

Re: Is anyone actually using the deferred warnings code?

On Wed, May 30, 2018 at 6:01 PM Robert Goldman wrote: > > AFAICT, it is disabled by default, and it is not documented in the ASDF > manual. > > So is this code even live, except for in the test scripts? > > It was pretty painful to get this to work because it relies on unexported > (and hence

bootstrapping asdf

In case anyone takes over maintenance of ASDF in the future, I wrote this mind dump on some of its more stuble "magic" behavior: https://fare.livejournal.com/190738.html Thanks to Eric Timmons for the prompting... PS: there are relatedly a few bug fixes in 3.3.2.5 — thanks and congratulations

Re: POIU is bitrotten

. — Rudyard Kipling On Tue, Jul 24, 2018 at 6:14 PM Robert Goldman wrote: > > Hi, Faré -- > > I had a look at POIU, because I thought it would be interesting to fix > this. I got pretty badly bogged down, though, because there's a really > high barrier to entry in tryin

Re: A thing I should know myself....

Sorry for a late reply. UIOP has these utilities that can help you: (uiop:find-symbol* :unimplemented-stub :foo nil) (uiop:match-condition-p #(unimplemented-stub foo) (make-condition 'simple-warning)) (setf uiop:*uninteresting-conditions* '(#(unimplemented-stub foo))) Also, ASDF has the

Re: Deferred warnings broken on SBCL 1.4.7

> again later. But for now, I think it's fixed. > > > > Comments welcome -- especially comments involving a nicer rewrite of > > what I wrote. > > > > Best, > > R > > > > On 30 May 2018, at 12:13, Faré wrote: > > > >

Re: Deferred warnings broken on SBCL 1.4.7

On Wed, May 30, 2018 at 12:53 PM Eric Timmons wrote: > Somewhat related, I was curious why ASDF doesn't use Gitlab CI to > automatically run tests. It probably wouldn't have helped in this > particular case since the root cause was a change outside ASDF, but > it's still nice for things like

Re: Deferred warnings broken on SBCL 1.4.7

Oops. Can you provide a patch? If possible one that uses #. to test what symbols are present and does the right thing? There are a few examples of #+sbcl #.( in filesystem.lisp and image.lisp. —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Government — If you think the problems

Re: asdf-announce post from nim...@gentoo.org requires approval

Chema Alonso asked: > Where can I download the 3.3.2 tarball? > > Normally I get it from here: > > https://common-lisp.net/project/asdf/archives/ > > But I can't find it right now. > > Thanks. > I took the liberty of running "make archive publish-archive" from the release branch. The tarballs

Re: Problems with DEFSYSTEM-DEPENDS-ON

On Mon, Apr 9, 2018 at 12:22 PM, Robert Goldman wrote: > On 9 Apr 2018, at 11:17, Attila Lendvai wrote: > >>> A cheesy fix would simply be to wrap it in IGNORE-ERRORS. But it might >>> cause >>> errors in its present form. >> >> >> >> i've learned, painfully, that

Re: Building from clean on Allegro Windows

I couldn't reproduce with AllegroExpress 10.1 on Linux amd64. So I gave a closer look on the Windows VM, rm'ing all the files in build/results/ before I retried, and looked at the minimal logs for the issue. The warnings were a false lead: Allegro does issue them, but they are actually caught by

Re: "deprecated recursive use" warning

On Wed, Mar 21, 2018 at 7:25 AM, Attila Lendvai wrote: > yeah, it feels like a lot of pain. it would be nice if there was a > fork-like API in ASDF for implementing such exec'd compilation, but > then i guess ASDF itself has no clue which /foo/bin/ directory has the >

Re: follow-up about handling .info file and index

Dear Robert and Robert, here is a complement to Robert Goldman's excellent response. It includes some style hints for the future of ASDF and its extensions. >: Robert Dodier > What I finally settled on is this. When the operation is COMPILE-OP, > the .info file is copied to same location where

Re: Testing for ASDF 3.3.2 and beyond?

On Sat, Mar 17, 2018 at 2:52 PM, Robert Goldman wrote: > Thank you very much, Anton. Question: is the inner-conditional-test failure > on SBCL 1.3.21 not a regression? I just loaded this system and tested it on > my mac with SBCL 1.4.3, and it worked fine, so I'm inclined to

Re: Testing for ASDF 3.3.2 and beyond?

Dear Anton, can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes). Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default? —♯ƒ • François-René

Re: Best Practice for an ASDF Variable Like *compile-file-failure-behaviour*

On Fri, Mar 9, 2018 at 7:32 PM, Mark H. David wrote: > Actually, I see these lines in the file asdf.lisp in my sbcl distribution > (SBCL 1.4): > > (defmethod operate :around (operation component keys >verbose >

Re: Best Practice for an ASDF Variable Like *compile-file-failure-behaviour*

On Fri, Mar 9, 2018 at 5:34 PM, Robert Goldman wrote: > Are you just using this for yourself? If so, a simple > > (let ((asdf:*compile-file-failure-behaviour* :warn)) > (asdf:load-system "my system")) > > will suffice. > Yup. > Alternatively, you could put something like

Re: Testing for ASDF 3.3.2 and beyond?

On Fri, Mar 2, 2018 at 1:05 PM, Robert Goldman wrote: > So as I see it we have three options for the *shared-readtable* > > Your original option -- the "initial-ish" readtable (since we can't control > when ASDF is loaded) Usually ASDF is loaded before any significant other

Re: Testing for ASDF 3.3.2 and beyond?

>> Maybe it's an artefact of SBCL using too much memory *while compiling* >> and would go away if you used e.g. POIU to compile inside forks. > > How? > "Just" load POIU right after you load ASDF, and before you load anything else. https://gitlab.common-lisp.net/qitab/poiu > The test order is

Re: Patch: Add support for Mezzano

On Thu, Mar 1, 2018 at 1:33 AM, Peter Housel wrote: > Enclosed is a patch (which can be applied using git am) that adds ASDF > support for the Mezzano Common Lisp operating system. > Please make it a merge request on gitlab.common-lisp.net/asdf/asdf —♯ƒ • François-René ÐVB

Re: package-inferred-systems and primary-system-name

Dear Eric, Robert, >:Eric > If a have a package-inferred-systems "a" and "a/b/c", the following > code used to return "a": > > (primary-system-name (find-system "a/b/c")) > > But after commit 069cd2a6 it returns nil. > Thanks for finding that bug. Sorry we didn't have regression tests for that.

Re: test-bundle

> (defmethod mark-operation-done :after ((o load-bundle-op) (c system)) > (mark-operation-done (find-operation o 'load-op) c))) > > Thanks for explaining that. That said, can you explain why we do this, > instead of marking load-bundle-op as done? I guess because loading the > bundle is intended

Re: test-bundle

ing other people's persons. We have every duty to respect even persons we think are stupid. — Faré

Re: Issues with package location information on SBCL

On Tue, Feb 20, 2018 at 3:35 PM, Robert Goldman wrote: > This does seem to illustrate an issue with the current "export everything > that's in UIOP" strategy. > > Should we consider changing this policy? > 1- UIOP reexports everything that individual subpackages of UIOP

Re: Test-multiple

> ;;; Warning: Computing just-done stamp in plan NIL for action > (PREPARE-SOURCE-OP > > "test-multiple-too" >"file2"), but > dependency (LOAD-SOURCE-OP > > "test-multiple-too" > > "file1") wasn't done yet! > > Note the warning --

Re: Issues with package location information on SBCL

On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons wrote: > Glad to help! I've also opened the following bug on SBCL to let them know > about it: https://bugs.launchpad.net/sbcl/+bug/1750466. > Thanks! > Also, I checked that nothing else in ASDF uses `parse-define-package-form`, >

Re: Test-multiple

. — E.W. Howe, "Country Town Sayings", p.7 On Mon, Feb 19, 2018 at 5:21 PM, Robert Goldman <rpgold...@sift.info> wrote: > Faré --- > > Would you please add some comments to test-multiple? I got a failure on > that with MKCL under jenkins on linux, but cannot repl

Re: Issues with package location information on SBCL

Thanks a lot for fixing this issue! I opened a MR based on it: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/92 —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org To be an anarchist only means that you believe that aggression is not justified, and that states necessarily

Re: Testing for ASDF 3.3.2 and beyond?

he all the tests there, if you want... —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Pain is inevitable. Suffering is optional. On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman <rpgold...@sift.net> wrote: > Thanks for sending that. Had a quick look. One nice thin

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

>: Attila > what if i make the .spec generation a standalone operation that needs > to be explicitly run by the library author? > I think that's indeed the right thing to do. > it's a bit more burden for > the lib author because he needs to keep track of changes to the > configuration and/or the

Testing for ASDF 3.3.2 and beyond?

Dear Anton, can you run the below tests, in order or priority? 1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users. 2- Can you test what is currently in

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

One solution is to create a new file with the correct timestamp, that is either a copy of the existing spec file or a new generated one. —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org For followers of most ideologies (openly religious or not), toleration is a concession of

Re: Multiple processing compiling the same file

> I suspect this would be one binary for each permutation of the optimization > settings used times the number of top-level entry points. Right? That > number is > much larger than the number of /tmp directories I need just to automatically > compile before running. > No, use cl-launch/dispatch

Re: Multiple processing compiling the same file

>: Jim Newton > One difficulty about your build-then-deliver suggestion is that my local > machine is running mac-os, and the cluster is > running linux. I don’t think I can build linux executables on my mac. > Your build does not have to be "local": pick one random Linux machine, have it do

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 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

Re: Including uiop and not asdf in a built application

> :Robert > Am I correct in thinking that Dave's way of building monolithic bundles of > either fasls or source code are, at least potentially, a baby version of > cross-compilation? It seems like these are interesting specifically because > they could be loaded into different images (otherwise,

Re: Syntax control code

On Sun, Jan 7, 2018 at 6:56 AM, Erik Huelsmann wrote: > gitlab is back up now. > Thanks a lot, Erik! Congrats for drive-by bugfixing! So the official URLs are: Syntax control merge request: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 Current version of the

Re: Syntax control code

It's in doc/syntax-control.md in the syntax-control branch (MR !86 on gitlab). Unhappily, gitlab.common-lisp.net seems to be down right now: https://gitlab.common-lisp.net/asdf/asdf If symptom persists, you may have to use my github backup in the meantime.

One bug down, one bug up

Dear future maintainers of ASDF, I have great news for you if you were looking for an opportunity to learn about the guts of ASDF: a new bug that will cover a lot of ground, yet is relatively well-understood, and isn't urgent at all. I wouldn't make it anyone's first bug, but once you have some

Re: ASDF debugging on Hangouts?

://fare.tunes.org When it comes to giving, some men stop at nothing. — Saul Gorn On Wed, Dec 27, 2017 at 6:06 PM, Faré <fah...@gmail.com> wrote: > On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman <rpgold...@sift.info> wrote: >> On 4 Dec 2017, at 21:56, Faré wrote: >>> https:

Re: ASDF debugging on Hangouts?

On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman <rpgold...@sift.info> wrote: > On 4 Dec 2017, at 21:56, Faré wrote: > >> Fixing the same potential issue with the (more stable but still >> evolvable) code in the core of ASDF will require applying the same >> sol

Re: ASDF debugging on Hangouts?

indows laptop >> under ccl64. Maybe the asdf AllegroCL provides is getting in the way? I will >> look also at tossing cffi just to get a fresh start. >> >> -kt >> >> On Tue, Dec 26, 2017 at 1:55 PM, Faré <fah...@gmail.com> wrote: >>> >>> >&g

Re: ASDF debugging on Hangouts?

>> Error: OPERATION instances must only be created through MAKE-OPERATION. >> >> [condition type: FORMATTED-SYSTEM-DEFINITION-ERROR] > > > Is that an ASDF issue? Ceramic? ACL? cffi-grovel (the system being built > when the error is thrown)? > You need a fresher version of cffi-grovel. Update your

Re: Relativising FASL Cache Paths

On Sun, Dec 17, 2017, 06:08 Nicolas Hafner wrote: > On 17/12/17 12:02, 73budden . wrote: > > Nicolas, can you resolve source locations at SWANK level? E.g. > functions like SWANK/SBCL::SOURCE-FILE-SOURCE-LOCATION might be > appropriate for patching: you take the location that

Re: Relativising FASL Cache Paths

, if the Lisp files were compiled using a logical pathname, logical > pathname translations could be used to fix that up as required. > > Is there a way to transform the input/output files to logical pathnames to > facilitate this, or would that be too much to ask for? > > On 15/12/17

Re: Relativising FASL Cache Paths

The design of ASDF is that you should properly initialize the output-translations. The usual way is to use ~/.config/common-lisp/asdf-output-translations.conf, but since in your case you support the directory moving from one instantiation to the next, it is probably better to call

Re: ASDF + QL maintenance needed.

On Mon, Dec 11, 2017 at 2:13 PM, Faré <fah...@gmail.com> wrote: > ASDF needs volunteers to replace its retiring maintainers. > > One easy way to start, and a good filter for people non ready for the > job, is the simple and boring yet essential task of looking at > Qui

ASDF + QL maintenance needed.

ASDF needs volunteers to replace its retiring maintainers. One easy way to start, and a good filter for people non ready for the job, is the simple and boring yet essential task of looking at Quicklisp build failures and either fixing other people's build files, or fixing ASDF, depending on who

Re: ASDF debugging on Hangouts?

nough For Love" On Mon, Dec 4, 2017 at 11:29 AM, Faré <fah...@gmail.com> wrote: > Well, after realizing one hour into the debugging session that I > needed to click on a button "Start Broadcast" to go live, I'm going to > reschedule the event, starting at 14:00 EST (19:00 UTC

Re: ASDF debugging on Hangouts?

that human hearts endure That part which laws or kings can cause or cure! — Samuel Johnson On Wed, Nov 29, 2017 at 7:24 PM, Faré <fah...@gmail.com> wrote: > After a kernel downgrade, I have painfully managed to get streaming to > Youtube Live Events working. > https://www.youtube.c

Re: ASDF debugging on Hangouts?

After a kernel downgrade, I have painfully managed to get streaming to Youtube Live Events working. https://www.youtube.com/my_live_events I'm tentatively scheduled an event at 10:00 EST (15:00 UTC) on next Monday December 4th 2017. https://www.youtube.com/watch?v=1kq-73Cjn08 I'll be using

  1   2   3   4   5   6   7   8   9   10   >