Version specifiers and constraints

Attached is a patch to ASDF's documentation that describes what I plan to implement to allow ASDF to have both customizable version specifiers and more expressive version constraints. I would appreciate concrete feedback on this proposal. Additionally, this diff exists on MR !169 if you would

Re: Next steps

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 digits). Whatever we choose will allow a superse

Re: Versioning

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, Nov 17, 2021 at 10:45 AM Robert Goldman rpgold...@sift.info <mailto:rpg

Re: Next steps

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 wrote: I favor something like this because it would be nice to have prerelease ve

Re: Next steps

On 11/17/21 10:55 AM, Eric Timmons 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. Sorry all, I didn't mean for this to descend into chaos. I'll pu

Re: Next steps

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 fine-grained version constraints would be a big mista

Re: Next steps

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. Another 3.3 release might be in order to get !189 out (although maybe it's not that important; I'm honestly surprised by how few

Re: Rejiggering the branches

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 easily cherry pick or backport fixes into >

Re: Build Debian release file?

"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 CI? Yeah, that should be possible. How is it built? I saw a de

Re: ASDF components are brittle for backwards compatibility

"Robert Goldman" writes: > 2. Add a new `defsystem` parsing error class that is > `unknown-component-property`, raise it when an unknown property is > encountered and allow the user to continue, discarding the initarg and > accompanying value. How practical is this one actually? The initarg c

Re: Pushed 3.3.4.11 and then 3.3.4.12

"Robert Goldman" writes: > I plan to release ASDF 3.3.5 next weekend, assuming no one finds any > real stinkers in the meantime, or if anyone has a high priority fix that > needs to go in ASAP. Awesome, I'm looking forward to having the package local nicknames support released! Looking at the

Re: Where is my executable?

This should give you what you want: (asdf:output-files 'asdf:program-op "my-system") -Eric Didier Verna writes: > Hi, > > what's the proper way to find out where a dumped executable (resulting > from a program-op) has landed? I would like to it to literally > :move-here #p"./", to speak in M

Re: Upgrading/Installation Instructions Clarification

"Robert Goldman" writes: > This is true, but it causes just the kind of problems I have alluded to > -- your ASDF configuration is now smeared all over your system, and > debugging it becomes essentially impossible. You're right that understanding what the source registry is doing is extreme

Re: Upgrading/Installation Instructions Clarification

> On 18 Jan 2021, at 17:37, Wilfredo Velazquez wrote: > >> To reiterate, I believe that the instructions in >> https://common-lisp.net/project/asdf/asdf/Upgrading-ASDF.html >> 'Upgrading >> ASDF' could use some clarification. >> >> I am attempting to run a newer version of ASDF than that provid

Re: Jenkins expertise?

Mark Evenson writes: > The CLF advocates a merge of [!146][] as we then we can adjust runners as > needed for capacity and capability. The default runners are Linux. Eric > Timmons is setting up a macOS runner which can be used. Windows runners are > further in the future. asdf!

Re: Jenkins expertise?

"Robert Goldman" writes: > In mine, I simply set the environment variables `ASDF_TEST_LISPS` and > the variables that point to the lisp implementations. Then I call `make > test-all-no-upgrades-no-stop`. Just to clarify, it sounds from this that you don't actually care if the upgrade tests ar

Re: Jenkins expertise?

"Robert Goldman" writes: > On 15 Oct 2020, at 12:19, Mark Evenson wrote: > >> @Robert: would it be satisfactory to have the output of the ASDF >> tests >> available in a non-Jenkins environment? Do we need to run the ADSF >> tests under >> OSs other than Linux, that is do you current test oth

Re: Jenkins expertise?

Erik Huelsmann writes: > Hi, > > On Wed, Oct 14, 2020 at 5:51 PM Eric Timmons wrote: > >> https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/146 uses >> cl.net's shared Gitlab CI runners. It appears that the shared runner can >> only run one job

Re: Jenkins expertise?

kins job? I believe that this > is possible, because I am working on a large program (hosted on someone > else's site) where the code is hosted on GitLab, but the tests are run > on a separate Jenkins server, and the two are integrated using Gitlab's > pipelines.

Re: Jenkins expertise?

https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/146 uses cl.net's shared Gitlab CI runners. It appears that the shared runner can only run one job at a time, so the pipeline that MR introduces takes close to an hour to run (and that's only testing with four implementations). I also suspec

Re: Deferred warnings broken on SBCL 1.4.7

On Wed, May 30, 2018 at 10:47 AM, Robert Goldman wrote: > Does anyone have any suggestions about testing against multiple versions of > SBCL? This brings to a head a problem that has been pending for a long time > -- how should I be keeping around old versions of lisp implementations so > that I c

Deferred warnings broken on SBCL 1.4.7

Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script`

Re: Issues with package location information on SBCL

On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons wrote: > I've also opened the following bug on SBCL to let them know about it: > https://bugs.launchpad.net/sbcl/+bug/1750466. This bug has been fixed upstream and should probably appear in SBCL 1.4.7. Since they got that fixed before ASD

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

MR sent. I took the approach of setting the source-file. The etypecase approach would have either introduced a circular dependency between system.lisp and package-inferred-system.lisp or would have required the package-inferred-system symbol to be exported from system.lisp which felt wrong. -Eric

package-inferred-systems and primary-system-name

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. Happy to patch it, but I wanted to check how to do it before starting. The root cause right now is that system-source

Issues with package location information on SBCL

I didn't test this on anything earlier than SBCL 1.4.4, but I don't believe this behavior is version dependent. -Eric From 79baf14021d8940ef2a969359fa335e72d8fad57 Mon Sep 17 00:00:00 2001 From: Eric Timmons Date: Fri, 16 Feb 2018 23:59:49 -0500 Subject: [PATCH 1/2] Evaluate sb-c:source-locat

Re: Operations on package-inferred-system

On Thu, Jul 28, 2016 at 11:54 PM, Faré wrote: > On Thu, Jul 28, 2016 at 12:48 PM, Eric Timmons wrote: >> I *really* like using package-inferred-system for defining systems, >> but I often find it doesn't behave as I expect when performing >> operations on it. I'm

Re: Another follow-up from yesterday's doc reviews

On Thu, Sep 22, 2016 at 4:44 PM, Robert P. Goldman wrote: > Actually now LOAD-ASD controls syntax, sets the readtable, controls the > pretty-printer, sets up a cache, and a handler. And who knows what it will do > tomorrow? Oooph, didn't realize that was in there as well. At least those effects

Re: Another follow-up from yesterday's doc reviews

On Thu, Sep 22, 2016 at 4:18 PM, Eric Timmons wrote: > As I understand it, the issue isn't really with the DEFSYSTEM form > itself. Instead, the issue is with all the *other* code that could be > in the .asd file as the manual states that symbols from CL, ASDF, and > UIOP will

Re: Another follow-up from yesterday's doc reviews

On Thu, Sep 22, 2016 at 3:04 PM, Robert Goldman wrote: > It would be trivial to bind a special variable around the body of > LOAD-ASD, and put something in DEFSYSTEM that will raise an INTELLIGIBLE > error if that variable is not so bound > > (error "Do not load an ASDF system definition outside o

Operations on package-inferred-system

I *really* like using package-inferred-system for defining systems, but I often find it doesn't behave as I expect when performing operations on it. I'm curious if these behaviors are intended or if the implementation is just incomplete. I approach package-inferred-system as a way of automatically

Re: A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]

On Tue, Feb 16, 2016 at 3:14 PM, Robert Goldman wrote: > On 2/16/16 Feb 16 -10:12 AM, Eric Timmons wrote: >> On Mon, Feb 15, 2016 at 3:34 PM, Robert Goldman wrote: >>> >>> Sorry, I'm not trying to be difficult, but that solution is unacceptable >>> to

Re: A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]

On Mon, Feb 15, 2016 at 3:34 PM, Robert Goldman wrote: > > Sorry, I'm not trying to be difficult, but that solution is unacceptable > to me. From my POV as maintainer, it seems like the worst of all > worlds. We would be introducing yet more moving parts -- a new package, > ASDF-EXTENSIONS, that

Re: A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]

On Mon, Feb 15, 2016 at 3:48 PM, Robert Goldman wrote: > Trying again: > > Can someone please state what it is that Quicklisp needs? Quicklisp needs some way to determine all the direct dependencies required to load a system and its definition. It currently does this by direct inspection of the d

Re: package-inferred-system and :around-compile

not sure what makes the most sense. Maybe: + :homepage + :bug-tracker + :mailto + :source-control + :version ? -Eric >From 79e2255b16ced362a9471e680440238a1b256288 Mon Sep 17 00:00:00 2001 From: Eric Timmons Date: Tue, 1 Dec 2015 12:44:07 -0500 Subject: [PATCH] Package inferred systems and

package-inferred-system and :around-compile

I'd really like to use :around-compile (for use with local-package-aliases), but I can't seem to combine it with package-inferred-system as the inferred systems don't inherit the around-compile slot from the top level system. I'd happily supply a patch to enable it. But I'm not sure if it would ma