Re: Method combination and ASDF

On 24 Apr 2024, at 3:39, Didier Verna wrote: > François-René ÐVB Rideau écrivait: > >> What are the methods defined by asdf-flv? > > In order to support file local variables, ASDF-FLV does this: > > (defmethod asdf:perform :around > ((operation asdf:load-op) (file asdf:cl-source-file)) >

Method combination and ASDF

An issue that came up discussing ASDF-FLV with Didier has to do with outside modification to exported ASDF generic functions. I think it's unambiguously reasonable to say "if you mess with unexported functions, generic or otherwise, you're on your own, and could break things arbitrarily."

Re: Loading only fasl files

This should be what happens "naturally" when you use ASDF, *unless* some source file (or depended-on source file) is newer than the corresponding fasl file. Note that ASDF may be looking for your fasl files in a cache instead of in the same directory as the source files (see the manual for

Re: Documentation "The defsystem form"

No, the version component is not required. There is something else going wrong here. I can't tell what might be going wrong, because I can't tell: 1. What version of ASDF are you using? What does `(asdf:asdf-version)` report? 2. What is the error and backtrace? This isn't a

Re: Readtable not bound to standard around compilation

(and the community!) are ready to pay the price for the transition, and multiple times so if they don't get it right on the first try. Oh, and once you take on the job, you'll be hated by some part of the community whether you subsequently make the change or don't. Good luck! On Thu, Feb

Re: Readtable not bound to standard around compilation

t. Good luck! On Thu, Feb 22, 2024, 10:15 Robert 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

Re: Readtable not bound to standard around compilation

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 this behavior is still in place: Faré

Re: historical question

On 1 Feb 2024, at 12:30, Faré wrote: 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

Re: historical question

On 1 Feb 2024, at 11:13, Faré wrote: Looking at said doc/index.html, I see that a lot of references to historical ASDF alternatives were commented out—why not keep them, if only in a separate paragraph or section? Or move them somewhere deep in the manual? I believe they have historical

Announcing ASDF 3.3.7 Release

Today we release ASDF 3.3.7, "Robbie Burns Night 2024 (belated)," the seventh bugfix release for the 3.3 release series. I had hoped that this would be the last bugfix release, but "the best laid schemes o' Mice an' Men Gang aft agley." We urge implementations that are currently bundling

Plan to release ASDF 3.3.7

I am planning to release the current version of ASDF, 3.3.6.7, as 3.3.7, most likely tomorrow or Monday. This version has a number of miscellaneous bug-fixes, but most significantly has been fixed to be compatible with the recent release of Allegro Common Lisp version 11.0. By releasing an

Re: Request for assistance: GitLab actions

a "job keyword", and thus >> cannot be directly set in the matrix. >> >> https://docs.gitlab.com/ee/ci/yaml/?query=image >>> Keyword type: Job keyword. You can use it only as part of a job or in the >>> default section. >> >> Best regards, >>

Request for assistance: GitLab actions

I have created a new docker image for Allegro CL version 11.0 (express/free), and put it on DockerHub: https://hub.docker.com/repository/docker/rpgoldman/allegro11express/general I have tried to add regression and upgrade tests using this Docker Image -- see [Regression

Re: ASDF: could use some help with ECL issue

"Be the change that you wish to see in the world." - Mahatma Gandhi On Tuesday, January 9th, 2024 at 16:48, Robert Goldman wrote: In the regression test results for a bug fix to ASDF (https://gitlab.common-lisp.net/asdf/asdf/-/jobs/63801), I see this error which I don't underst

Request for information: Implementation-specific DEFPACKAGE extensions

@gefjon has proposed ASDF MR [!226](https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/226) that extends ASDF's package inferred system dependency groveler to handle SBCL's extension to the set of `defpackage` options, addressing [Issue

Re: Past discussion on ASDF loading

I have posted [Issue 150](https://gitlab.common-lisp.net/asdf/asdf/-/issues/150) on ASDF, with a shell script for replicating the issue. On 4 Jan 2024, at 9:16, Robert Goldman wrote: Maybe there's an issue with using `(asdf:load-system "asdf")` instead of using `(asdf:up

Re: Past discussion on ASDF loading

d explicitly (asdf:upgrade-asdf) with whatever warning need be muffled, and then you'll be good. If there's more than that, please send instructions to reproduce the issue. -#f On Tue, Jan 2, 2024, 16:47 Robert Goldman wrote: I am finding that ASDF loads itself multiple times, unnecessari

Past discussion on ASDF loading

I am finding that ASDF loads itself multiple times, unnecessarily, at least on Allegro 11. E.g., it reloads when I simply invoke `(asdf:component-pathname (asdf:find-system "foo"))` for one of my systems. This is annoying because I get redefinition style warnings every time I do this, which

Re: Removal of feature from UIOP library

yet). —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org “The real danger is that one day machines *will* become intelligent, but we’ll lack the mental equipment to notice.” — Tiresias, in J.-P. Petit, “Run, Robot, Run” On Tue, Dec 12, 2023 at 11:44 AM Robert Goldman wrot

Removal of feature from UIOP library

[Issue 48](https://gitlab.common-lisp.net/asdf/asdf/-/commits/iss148) on the ASDF GitLab repo concerns a bug in the `with-optimization-settings` macro in UIOP's lisp-build.lisp I did some investigation and as far as I can tell: 1. There's no clear description of what this is supposed to do 2.

Re: How to use the current directory?

FWIW, ANSI Common Lisp does not *have* a current directory, only a current value of `*default-pathname-defaults*`. ANSI CL is happy to run on systems that have no notion of a process having a current directory. So that accounts for why Quicklisp and ASDF don't support a notion of current

Question about UIOP:ENSURE-DIRECTORY-PATHNAME

While addressing ASDF [issue #140](https://gitlab.common-lisp.net/asdf/asdf/-/issues/140) I stumbled on what seems to me to be an error. That is that (ensure-directory-pathname "") at least on SBCL, returns a `pathname` that has `NIL` in all its slots except `HOST`. To me, this seemed

Re: ASDF config file under Windows

of what should be loaded when. CLAD does not need ASDF or UIOP. It just has a .asd file because Quicklisp asks for it. Cheers MA On Sun, Jun 4, 2023 at 9:00 PM Robert Goldman wrote: TBQH, I am not as sure as I should be. I try to avoid all the configuration that happens while ASDF

Re: ASDF config file under Windows

, at 14:11, Faré wrote: ASDF configuration is lazy. It doesn't happen during load, but the first time ASDF is invoked, if not done by the user after loading ASDF. On Sun, Jun 4, 2023, 15:00 Robert Goldman wrote: TBQH, I am not as sure as I should be. I try to avoid all the configuration

Re: ASDF config file under Windows

. Cheers MA On Sat, 3 Jun 2023 at 23:10, Robert Goldman wrote: I do like the idea of CLAD, but in this case isn't there a Catch-22? You need to configure ASDF in order to load CLAD, so you can't use CLAD to configure ASDF, can you? On 3 Jun 2023, at 10:57, Marco Antoniotti wrote: Ahem

Re: ASDF config file under Windows

Cheers MA On Sat, Jun 3, 2023 at 5:28 PM Robert Goldman wrote: Dear Greg, Thanks for the kind words! I am not sure why I didn't see your post on ASDF-devel, but I didn't. And I have seen several requests for moderation, so the list seems live. In case my response is interesting

Re: ASDF config file under Windows

Dear Greg, Thanks for the kind words! I am not sure why I didn't see your post on ASDF-devel, but I didn't. And I have seen several requests for moderation, so the list seems live. In case my response is interesting to the group, I am responding to the list as well. A couple of

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

On 15 Dec 2022, at 14:48, Robert Dodier wrote: Robert, thanks for your reply. I have made some progress. Just performed compiling # but failed to mark it done It would help to get a backtrace here. I can't tell from this if the error is happening in ASDF or in ASDF-DEPENDENCY-GROVEL (which

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

On 15 Dec 2022, at 1:07, Robert Dodier wrote: Hi, I'm interested in analyzing dependencies among a collection of Lisp files, or analyzing dependencies stated in a .asd file, or both. (1) Towards the goal of analyzing dependencies among Lisp files, I'm trying to load asdf-dependency-grovel, and

Re: Wrong release version in front page

On 16 Nov 2022, at 2:11, Nikolaos Chatzikonstantinou wrote: > Hello, > > I noticed that the front page in > claims that the latest version is 3.3.5 but the release tarball > unpacks to > asdf-3.3.6. > >

Re: Change to allow loading linked asd files

What is the lisp implementation you are using that you need this modification, and on what OS? There are some subtle distinctions between different implementations in how they treat symbolic links. On 16 Nov 2022, at 11:38, Stelian Ionescu wrote: Hi, ASDF already allows that, so it's not

Re: Handling of readme and license files

On 21 Oct 2022, at 15:53, Russell Sim wrote: Robert Goldman writes: I have been out of town and away from my email for a while. Sorry for the late response. Checked ASDF code and I think you are right: it would make sense to make `:read-file-form` more generally usable than just

Re: Handling of readme and license files

On 16 Oct 2022, at 1:58, Russell Sim wrote: Mirko Vukovic writes: somewhat off-topic to the original question: Can :static-file be used for files part of unit tests? Such as unit tests for log-parsers. My understanding is that :static-file components are used to specify any non-lisp

Re: Handling of readme and license files

On 15 Oct 2022, at 3:00, Russell Sim wrote: But regarding the readme file being loaded at read time in the ASD file. This dependency is not track but it's required to build the package. This could be caught if the builds were hermetical, and this would also help with issues related other

Re: Handling of readme and license files

I have been out of town and away from my email for a while. Sorry for the late response. Checked ASDF code and I think you are right: it would make sense to make `:read-file-form` more generally usable than just in the `:version` property. Unfortunately, if we were to do this, it would cause

ASDF 3.3.6 is released

Today we release ASDF 3.3.6, the sixth bugfix release for the 3.3 release series, and -- it is devoutly to be hoped -- the final one. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 through 3.3.5 -- to upgrade to 3.3.6 at

Closed the last of the issues on the 3.3.6 milestone

So I am definitely moving towards a release real soon now. So please test the new ASDF as you can, and report any issues you see.

Trying once more to get 3.3.6 out the door

I have poked all the merge requests that were tagged for 3.3.6 If these are close to working, I will get them merged, otherwise I will drop them from the milestone, with an eye to getting 3.3.6 out soon. If you get a chance to test your systems against the current version 3.3.5.10 looking

Re: [RFC] subsystems vs. modules

This discussion makes me worried that `if-feature` dependencies may not function properly in ASDF. AFAIK ASDF still relies only on the file system to determine whether a file needs recompilation. But changing feature values are not, in general, visible in the file system. So I believe that

Re: Define a Simple Echo-Op

On 27 Apr 2022, at 11:15, phoebe Goldman wrote: >> According to the docs, most operations inherit from self ward-operation, >> which would take the component-pathname as an input file (and might take >> others). > > I think input file sets are orthogonal to dependency direction. >

Re: Define a Simple Echo-Op

A quick note to point everyone at the doc fixes: https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/207 signature.asc Description: OpenPGP digital signature

Re: Define a Simple Echo-Op

On 27 Apr 2022, at 10:26, Robert Goldman wrote: > Phoebe Goldman writes (but can't post): > >> I'm following the manual: "If the action of performing the operation on a >> component has >> dependencies, you must define a method on component-depends-on." >

Re: Define a Simple Echo-Op

Phoebe Goldman writes (but can't post): For some frustrating reason I can't email the asdf-devel list, so cc'ing rpgoldman & he can forward. > Why can't I subclass ASDF:OPERATION? This is unexpected since > ASDF:OPERATION is the base class for all operations. The various UPWARD- DOWNWARD- etc

can't reply to asdf list Fwd: Undelivered Mail Returned to Sender

Response from Phoebe Goldman hand-forwarded because of problems with common-lisp.net's email server: A few things. 1. ECHO-OP should not be selfward. SELFWARD-OPERATION is for (OPERATION COMPONENT) pairs which depend on (DIFFERENT-OPERATION COMPONENT) for the same COMPONENT. For example,

Quick note

I have a crush of things going on in the next week, so -- although I regret it, because there are a number of very interesting issues to see to right now! -- I will be largely unresponsive for up to a week. Sorry about that, but it's unavoidable. Best, R

Earlier posting

I have received some nice emails, and I appreciate them very much. However, in other fora there have been discussions about ASDF and Flexi-streams. That may be interesting, but it misses the key point -- or perhaps it reinforces the key point: this community seems to think it's normal for

Considering resignation as maintainer

I have discovered that Stas Bokuraev is continuing to refuse to update Edi packages to modern ASDF system-naming. This would not be bad in and of itself, because these are open source systems, and they can be forked. What *is* bad is that he has publicly stated that he is doing this hoping

Re: Need to call asdf:load-system (or equivalent) from asdf:test-system

On 29 Dec 2021, at 9:32, Wilfredo Velazquez wrote: FYI mostly unrelated 2c - Opening issues for questions is not overkill IMO. In fact it serves as a great knowledge base with discussion that is easily searchable. Just close the issue when the question is resolved . That would be fine. I

Re: Need to call asdf:load-system (or equivalent) from asdf:test-system

On 28 Dec 2021, at 21:51, Albus Matt Piroglu wrote: Note I have opened an issue on gitlab, but I know it's an overkill to open issues for questions. I couldn't find an appropriate channel until I found this mailing list. I'll close the issue, and here is my question for your consideration:

Re: :initform vs. :default-initargs

Yes, that is right. `parse-defsystem` calls `change-class`. I will set up an issue for this, and put you on the cc list. On 22 Dec 2021, at 10:49, Attila Lendvai wrote: i think i know why this is happening. i have attached a test that has the two versions that i have talked about. the

Re: ASDF tools/release.lisp and PGP keys

Thanks for the note! I'm not sure what to do about this, since I don't use the "asdf/tools" myself. I never figured out how to debug the lisp scripts there, so I have stuck to the old code that is based on bash and make. That looks like code that is probably related to the creation of Debian

Re: Versioning

On 19 Nov 2021, at 15:43, Stelian Ionescu wrote: In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's

Re: Versioning

On 19 Nov 2021, at 15:25, Jason Miller wrote: On Fri, 19 Nov 2021 22:02:11 +0100 Erik Huelsmann wrote: On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov wrote: - etimmons@, rpgoldman@ "Erik Huelsmann" : Could you elaborate a bit on "As semver does not work for Common Lisp"? I've opened

Re: Next steps

ince October *fifteenth* 2020. On 18 Nov 2021, at 10:53, Marco Antoniotti wrote: Why would ASDF not understand "version later than 20201015"? I am perfectly fine with using the full 8 digit timestamp. MA On Thu, Nov 18, 2021 at 4:24 PM Robert Goldman wrote: On 18 Nov 2021, at

Re: Next steps

On 18 Nov 2021, at 7:35, Eric Timmons wrote: On 11/18/21 3:45 AM, Marco Antoniotti wrote: Sorry but I am missing something. It was said in this thread (don't remember who, apologies) that MMDD would work.  Will it? Yes. MMDD is currently a valid version string (assuming it's all

Re: Versioning

That sounds like a great solution. On 17 Nov 2021, at 16:33, Eric Timmons wrote: On 11/17/21 4:55 PM, Robert Goldman wrote: On 17 Nov 2021, at 15:12, Eric Timmons wrote: On 11/17/21 2:38 PM, Robert Goldman wrote: On 17 Nov 2021, at 13:31, Robert Dodier wrote: On Wed

Versioning

On 17 Nov 2021, at 15:12, Eric Timmons wrote: On 11/17/21 2:38 PM, Robert Goldman wrote: On 17 Nov 2021, at 13:31, Robert Dodier wrote: On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman rpgold...@sift.info <mailto:rpgold...@sift.info> wrote: I favor somethin

Re: Next steps

On 17 Nov 2021, at 14:03, Stelian Ionescu wrote: On 17 Nov 2021, at 12:32, Stelian Ionescu wrote: You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way. That only works if you are

Re: Next steps

On 17 Nov 2021, at 13:31, Robert Dodier wrote: On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman wrote: I favor something like this because it would be nice to have prerelease versions of ASDF that perform version checks properly. What I mean is, if we are going to add a feature in version

Re: Next steps

On 17 Nov 2021, at 12:32, Stelian Ionescu wrote: You don't have to use the Quicklisp client to load dependencies, just to fetch them (as a package manager). And for that, I think it should be always used this way. That only works if you are using the QL libraries unchanged. If you need to

ASDF and versioning [was Re: Next steps]

ould still work. Marco On Wed, Nov 17, 2021 at 7:19 PM Robert Goldman wrote: Not sure what the syntax is, but I agree that holding to a fixed number of arguments will be best, particularly for filtering out syntax errors. On 17 Nov 2021, at 11:51, phoebe Goldman wrote: On Nov 17, 2021, a

Re: Next steps

On 17 Nov 2021, at 12:36, Eric Timmons wrote: On 11/17/21 12:24 PM, Didier Verna wrote: Stelian Ionescu wrote: Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner. Adding

Re: Next steps

On 17 Nov 2021, at 12:26, Stelian Ionescu wrote: To guarantee an old working configuration you can simply point to the version of the Quicklisp distribution that it was last tested with. We should make it easy to specify that as metadata, and it would be much more useful than version

Re: Next steps

Not sure what the syntax is, but I agree that holding to a fixed number of arguments will be best, particularly for filtering out syntax errors. On 17 Nov 2021, at 11:51, phoebe Goldman wrote: > On Nov 17, 2021, at 12:37 PM, Robert Goldman wrote: version constraints like (:version

Re: Next steps

`version-satisfies` is *already* a generic function. We will add some more capabilities to the built-in version in ASDF 3.4, but library authors will continue to be able to implement their own extensions. On 17 Nov 2021, at 11:24, Didier Verna wrote: Stelian Ionescu wrote: Mostly sounds

Re: Next steps

On 17 Nov 2021, at 11:08, Stelian Ionescu wrote: 2. I *desperately* want to add version upper bounds. There is a real problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build

Re: Next steps

On 17 Nov 2021, at 10:35, Stelian Ionescu wrote: Mostly sounds good to me. Assuming you're still interested in more expressive version numbers and constraints for 3.4, I'll work on moving that off the back burner. Adding fine-grained version constraints would be a big mistake. Where

Next steps

The next item to merge is Alberto's !192. This is new functionality, rather than a bug fix, so I am considering adding a `main` branch, retiring `master`, and moving most activity there, with an eye to getting the first 3.4 release underway. That would permit me to start merging a number of

Re: Rejiggering the branches

On 14 Jul 2021, at 16:58, Raymond Toy wrote: If there are tags (or branches) to indicate when the release is done, then a stable branch is ok with me.  I just want a way to get to a release somehow.  (Not that I've had to debug an issue in asdf.  But if I did, I want to be able to extract

Re: Rejiggering the branches

On 13 Jul 2021, at 10:20, Eric Timmons wrote: Attila Lendvai writes: what i would do: - one branch that holds the bleeding edge. i'd call it main, just to go with the flow. - branches for ASDF versions (down to the desired resolution, probably major.minor), so that you can

Re: Rejiggering the branches

2021 19:52:01 +0200, Rudolf Schlatte said: Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8= "Robert Goldman" writes: If stable seems bad, is there another name we could use to avoid renaming? Like maint for "maintenance"? I don't love maint, because it's too close to m

Re: Rejiggering the branches

something better than `stable`, it seems like the least-worst alternative. But there's all week to come up with something better! Cheers, R On 12 Jul 2021, at 11:13, Martin Simmons wrote: On Mon, 12 Jul 2021 08:59:16 -0500, Robert Goldman said: As we move forward, and try to add some new

Rejiggering the branches

As we move forward, and try to add some new facilities to ASDF, this seems like a good time to revise the branching structure that we use. In particular, I would like to add a `stable` branch that will permit continuation of the 3.3 release series, the need for which is illustrated by Mark

Re: Build Debian release file?

On 3 Jul 2021, at 12:46, Robert Goldman wrote: On 3 Jul 2021, at 11:56, Eric Timmons wrote: "Robert Goldman" writes: Is anyone out there willing and able to build the Debian library for 3.3.5? It's not something I am able to do myself. Eric T -- is there any chance we

Re: Build Debian release file?

On 3 Jul 2021, at 11:56, Eric Timmons wrote: "Robert Goldman" writes: Is anyone out there willing and able to build the Debian library for 3.3.5? It's not something I am able to do myself. Eric T -- is there any chance we could put the Debian build process into the

Implementor emails

My email to the Corman Lisp address bounced, so I am dropping Corman Lisp from the mailing list, unless someone can point me at a working contact email. Also -- my emails to the various implementation development mailing lists are all on hold waiting for moderator approval (CCL, ABCL, clasp,

Build Debian release file?

Is anyone out there willing and able to build the Debian library for 3.3.5? It's not something I am able to do myself. Eric T -- is there any chance we could put the Debian build process into the CI? That would be a big part of a solution, but would not be a *complete* solution, which

ASDF 3.3.5 is released!

Today we release ASDF 3.3.5, the fifth bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.5 at their earliest convenience. In addition to fixes that are

Last call before 3.3.5 bug fix release

I'm going to release 3.3.5, which I *hope* will be the last bug fix release in the 3.3 series, either this afternoon or tomorrow. So this is the last call for bug fixes that should get in under the wire. I have reviewed the issues and the merge requests, and I don't see anything that can't be

Re: (Lack of) Inheritance of in-order-to dependencies

This problem is happening because of a (common) misunderstanding about what it means to apply an operator to a parent component. If you have a parent component, P, and serial children C1, C2, C3, then a simple downward-operation O will generate this plan: ``` (O . C1) (O . C2) (O . C3) (O .

Re: Upcoming bug fix release

Thanks for the update! That's great news. Best, R On 6 Jun 2021, at 0:24, Raymond Toy wrote: > FWIW, I ran 3.3.4.19 with cmucl 2021-01 using "make CMUCL=cmulisp -l cmucl > test" and all tests passed. > > On Thu, Jun 3, 2021 at 8:10 PM Robert Goldman wrote: > >&g

Upcoming bug fix release

I have just updated the ASDF repository to version 3.3.4.19 I plan for this to turn into the bug fix release 3.3.5 very soon, so please, if you have the opportunity, test it with your libraries, your hardware, your lisp implementations, etc. I am particularly excited to get this out there,

Re: ASDF components are brittle for backwards compatibility

On 29 Apr 2021, at 19:42, Stelian Ionescu wrote: On Thu, 2021-04-29 at 18:58 -0500, Robert Goldman wrote: On 29 Apr 2021, at 13:38, Marco Antoniotti wrote: Robert, it was you who suggested to use it if I remember correctly. How would it be different from what you just proposed? My

Re: ASDF components are brittle for backwards compatibility

generate a warning. Marco On Thu, Apr 29, 2021 at 8:07 PM Robert Goldman wrote: That slot *is* there, but it is specifically noted as being for ASDF 2 compatibility only, and not to be used. So you are using this at your own risk. Having a :plist slot might be a good addition, as well (i.e

Re: ASDF components are brittle for backwards compatibility

a charm once I got the hang of it and it seals the general ASDF machinery from random stuff. Marco On Thu, Apr 29, 2021 at 6:13 PM Robert Goldman wrote: ASDF checks to make sure all of the initargs are defined when parsing a defsystem. This is good for catching errors, but is terrible

Re: ASDF components are brittle for backwards compatibility

On 29 Apr 2021, at 11:42, Stelian Ionescu wrote: How can ASDF or a developer determine that the unknown property doesn't change the semantics of the DEFSYSTEM, and therefore discarding it would have an effect that's contrary to the author's intention ? ASDF has no syntactic distinction

ASDF components are brittle for backwards compatibility

ASDF checks to make sure all of the initargs are defined when parsing a `defsystem`. This is good for catching errors, but is terrible for extensibility. This means that any attempt to add additional metadata will be backwards incompatible. I can think of two ways to fix this: 1. Add a

Re: only perfom when the output is missing

On 17 Apr 2021, at 17:09, Faré wrote: One way to avoid unneeded regeneration in the future without lying about the dependency would be to modify the script to: 1. Remember in the output the hash of the input. 2. In the regeneration script, have a shortcut that leaves the output unchanged if the

Re: only perfom when the output is missing

On 14 Apr 2021, at 18:38, Attila Lendvai wrote: FTR, i have managed to solve it with this: (defclass generate-lisp-op (selfward-operation) ((selfward-operation :initform '( ; we will specify it in our own COMPONENT-DEPENDS-ON (defmethod component-depends-on ((op generate-lisp-op) (c

Pushed 3.3.4.11 and then 3.3.4.12

The first has a fix for the incorrect argument handling in `launch-program`, and the second has two fixes for feature handling from Eric Timmons. At 4.12 it seems to me that we have a bunch of bug fixes that should be released into the wild, and there seems little cost to doing so, since

Re: "How-to" request

to specialize OPERATE, how do you pass arguments to PERFORM? MA On Fri, Mar 19, 2021 at 7:45 PM Robert Goldman wrote: P.S. I don't recommend writing your own OPERATE methods -- OPERATE is quite complicated and messing with it could lead you into very deep water. I don't believe you should ever

Re: "How-to" request

P.S. I don't recommend writing your own `OPERATE` methods -- `OPERATE` is quite complicated and messing with it could lead you into very deep water. I don't believe you should ever need to. On 19 Mar 2021, at 13:42, Robert Goldman wrote: Hi. I'm happy to help you work through this, but so

Re: "How-to" request

Hi. I'm happy to help you work through this, but so that it doesn't recur as a problem, I'd appreciate it if you would help me fix the manual's discussion of this. First, have you read this page https://common-lisp.net/project/asdf/asdf.html#Creating-new-operations ? Please have a look at

Re: System cleanup

Didier, would you mind posting a GitLab issue for this? It's feasible, but I'm so overloaded right now that there's no chance I will get to it before I forget. Thanks On 19 Mar 2021, at 8:34, Didier Verna wrote: François-René ÐVB Rideau écrivait: Before it can be ignored, it must be

Re: System cleanup

On 18 Mar 2021, at 11:59, Didier Verna wrote: Hi, I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around? The relevant parts are as follows: :defsystem-depends-on

Re: Fighting with the CI....

On 16 Feb 2021, at 13:34, Robert Goldman wrote: There was an oddball thing in the Makefile, and changing it broke the CI. I'm just fixing it up now, but please don't pull from master until you get further notice. If you *have* pulled from master today, please backup to 3.3.4.8 until

Fighting with the CI....

There was an oddball thing in the Makefile, and changing it broke the CI. I'm just fixing it up now, but please don't pull from master until you get further notice. If you *have* pulled from master today, please backup to 3.3.4.8 until further notice. Sorry for any inconvenience.

Re: Upgrading/Installation Instructions Clarification

;asdf.asd" -- rather than the merged single file in "asdf.lisp". On 19 Jan 2021, at 9:05, Wilfredo Velazquez wrote: Can I upgrade ASDF by simply placing the built asdf.lisp file in ~/common-lisp/asdf/asdf.lisp and omitting everything else? Will ASDF find it? On Tue, Jan 19

Re: Upgrading/Installation Instructions Clarification

` extension. I'd have to look at the code (I'm not able to do this right now), but there would have to be a special case for files named "asdf.lisp". But I could be wrong. On Tue, Jan 19, 2021 at 9:44 AM Robert Goldman wrote: *Warning -- opinionated rant follows!* On 18 Jan 2021

Re: Upgrading/Installation Instructions Clarification

**Warning -- opinionated rant follows!** On 18 Jan 2021, at 20:50, Eric Timmons wrote: That's not quite right. It could definitely be more friendly, but there are a few ways to better control it. To completely prevent ~/common-lisp/ from being traversed you could put an

  1   2   3   4   5   6   7   8   9   10   >