- asdf-devel - mailman3.common-lisp.net

[Openmcl-devel] My asdf problem
by Paul Krueger 05 Apr '22

05 Apr '22

I am pretty much certain that I now understand what happened to cause my asdf problem. At the end of this I have a few final questions that maybe somebody can answer definitively for me. If you are curious about the details, read on. Here are some background facts: What I was seeing is a failure of asdf to locate a new system in my ~/common-lisp directory as it should. This problem only occurred in the CCL IDE, not when running CCL from the command line. There is an asdf internal variable called asdf/source-registry:*source-registry* which contains a list of all the .asd files it can find as a result of searching all of the directories where asdf thinks they might be. In my case that was my ~/common-lisp/ directory. In asdf itself. That variable is only initialized when a file is searched for. That might happen either via an explicit asdf call (e.g.(asdf::find-system <something>) or indirectly via a quickload call such as (ql::quickload <something>). Just loading asdf will not cause the *source-registry* to be initialized However, it turns out that just loading quickload WILL cause the asdf *source-registry* variable to be initialized. Once that variable is initialized, asdf will never try to initialize it again since that would waste a lot of time looking for .asd files all over again. So knowing all that, here is what happened. I installed and rebuilt the latest CCL a couple of months ago. As part of building the CCL IDE after that, both asdf and quickload were loaded into the CCL IDE image that was created (one question later is related to this) As a normal result of loading quickload, the asdf/source-registry:*source-registry* variable was initialized (another question below is related to this) When the CCL IDE image was built it included the value of that asdf *source-registry* variable, so that when the IDE was launched that variable was initialized. Only recently did I add additional asdf-defined systems to the ~/common-lisp/ directory. But of course when asdf tried to find them it couldn’t because the *source-registry* variable was effectively initialized when the IDE was built (long before I added my new systems). I can explicitly call an asdf function to reinitialize that variable and then everything is found normally. One question I have left is whether loading asdf and quickload into the CCL IDE is something that is done explicitly by the process that is now used to build the IDE or whether there is some option to not include them. Was there something that I should have done or not done when building the IDE that would have prevented this problem? Had there been nothing in my ~/common-lisp directory to find, then the value of that asdf variable would have been nil and that is enough to make asdf reinitialize it. But assuring that each time I build seems like a pain. My next question is why loading quicklisp causes it to initialize that variable? Conceivably it needs to search for .asd files that might be in its load environment and uses asdf to do so. Next I’m wondering whether there is some change to asdf code that can be made to reinitialize the *source-registry* every time the IDE is re-started. As another possibility, perhaps the CCL code for dumping the IDE can be modified in some way. In a private email Robert suggested: "If you have time to look, take a peek at asdf/uiop/image.lisp and asdf/bundle.lisp which should have code Fare wrote about dumping an image in a way that it will restart happily.” That seems like something that CCL maintainers might want to consider. While waiting for fixes or other suggestions, I will put an explicit call to reinitialize the *source-registry* in my ccl-ide-init.lisp file: (asdf/source-registry::initialize-source-registry) If anyone else has an environment similar to mine and rebuilds their own version of the IDE, I would suggest they do the same.

1 0

Forever Stable Branch
by Michał "phoe" Herda 20 Jan '22

20 Jan '22

Hey, I've poured my thoughts related to recent events into a blogpost that turned into a long-ish article. This mail is purely informational; comments via mail are welcome but not required. https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38 Linking a Reddit thread below and attaching the original article to this mail for posterity. https://www.reddit.com/r/Common_Lisp/comments/s8r075/ BR ~phoe

1 0

Quick note
by Robert Goldman 18 Jan '22

18 Jan '22

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

1 0

Earlier posting
by Robert Goldman 10 Jan '22

10 Jan '22

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 someone to say that they want to pressure another volunteer maintainer into changing a decision they don't like by breaking software, and trying to raise anger in the community. Surely a little attention to today's news shows that rage-stoking is not a means to building a healthy community of any sort. I understand that confronting this issue is more difficult than talking about whether or not ASDF should be issuing a warning. But that's not the question that is at hand. I will move to silence on this certainly at least for the rest of the day. Best to all

1 0

Considering resignation as maintainer
by Robert Goldman 09 Jan '22

09 Jan '22

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 that the resulting warnings will break people's systems and thus cause them to get angry and complain to me about ASDF checking system names. What is even worse is that the CL community tacitly accepts this as normal behavior. I would like to see the CL open source community pause and consider what constitutes a healthy community. I don't believe that someone trying to break things in order to pressure a volunteer maintainer of infrastructure is something that a healthy community should accept. If the community prefers a more rough-and-tumble approach, I can accept that, but if so it's time for the community to find an ASDF maintainer who is more in harmony with the values it (at least implicitly) espouses.

1 0

Need to call asdf:load-system (or equivalent) from asdf:test-system
by Albus Matt Piroglu 29 Dec '21

29 Dec '21

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: Hi, I'm trying to test a functionality that depends on loading systems. Thusly I ended up writing some tests that need to load a "test-system" during the tests, and I clear the system afterwards. A simplified code for the test in question is: (test check-the-system-is-loaded-as-expected () (asdf:load-system "my-test-system-under-test-folder") (is --check that the system loaded as expected--) (asdf:clear-system "my-test-system-under-test-folder") (delete-package "PACKAGE-FROM-TEST-SYSTEM")) and, to clarify, another test relies on the same system not being loaded, so I don't think a dependency would solve the issue, it is rather a dynamic decision to load or not. Now, I know that this feature is deprecated and may not work. What I'm wondering if there's a safer way to achieve this. Wouldn't some tests for asdf itself need loading some test systems for example? (hmm it actually might be a good idea to go check them now). OK, for example there's a hello-world-example.asd in test, which looks similar to my my-test-system-under-test-folder. So, instead of asdf:load-system in the above test code, should I be using a lower-level operation call? Thanks! Albus

3 4

:initform vs. :default-initargs
by Attila Lendvai 22 Dec '21

22 Dec '21

dear list, i wanted to set the default-component-class of our own system subclass using :default-initargs, but it's ignored because the slot has a :initform (as opposed to setting the default value using a :default-initargs entry). in the current ASDF setup, i need to override the slot (or the accessor method), which involves messing with internal symbols. if ASDF used :default-initargs then i could just override that using a :default-initargs entry on my own subclass (IIUC). https://lisptips.com/post/11728375873/initform-and-default-initargs i'm sending it for your consideration, it's not a pressing issue on my side. - attila PGP: 5D5F 45C7 DFCD 0A39

4 5

Re: ASDF tools/release.lisp and PGP keys
by Robert Goldman 22 Dec '21

22 Dec '21

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 packages for ASDF. No one has been doing that for years. I should probably prune the code for doing that.... Best, R On 22 Dec 2021, at 10:54, Attila Lendvai wrote: > Robert, > > i have this local diff: > > - (error "Please export variable DEBSIGN_KEYID to be the 8-hex hash of > your GnuPG secret key"))) > + (error "Please export variable DEBSIGN_KEYID to be the 16+ digit > hexadecimal hash of your GnuPG secret key"))) > > there's an ongoing attack against PGP keys where a white hat hacker is > brute-forcing the published keys to generate keys that have the same > hash/fingerprint, or at least the last 8 digits. > > luckily they also publish a revocation certificate for these fake > keys, but i recommend using longer than 8 digit fingerprints when > identifying PGP keys. > > just a head's up, probably not very urgent/relevant. > > - attila > PGP: 5D5F 45C7 DFCD 0A39

1 0

Version specifiers and constraints
by Eric Timmons 23 Nov '21

23 Nov '21

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 prefer to give feedback that way. If you do, please mostly ignore the non-documentation changes. The other changes were made quite a while ago and don't take into account some of the recent feedback I've received. Some notes: To support extensible version specifiers, I started with Didier's approach (first discussed at <https://mailman.common-lisp.net/pipermail/asdf-devel/2015-June/004698.html>, I believe). However, that approach required a non-standard system class if you wanted to extend the version specifier. That seemed rather heavy-handed, so I moved to an approach where you can specify a :version-class in your defsystem. This should also make it composable with custom classes. However, if you foresee issues with that, we can change it back. One of the version classes provided by UIOP is called semantic-version. It implements only the semver grammar and ordering relationships. It does not implement any sort of constraint on major versions matching or the like (note that such a thing is not even required by the semver spec!). However, I realize that "semantic version" can be a loaded term, so I'm happy to discuss changing the name of the class if anyone has a workable idea. The other version class is called default-version. Currently it's a subclass of semantic-version. However, given Robert's recent suggestion to limit the pre-release segment to alpha/beta/rc and an optional integer, that could be changed. In fact, we could implement Didier's preferred grammar as well, where X.Y.ZaW would be equivalent to X.Y.Z-alpha.W and the same with b/beta and rc/rc. The attractive thing about that is it means ASDF's defaults would likely cover the vast majority of version grammars developers would want to use. I'm particularly interested in feedback on the :compatible-versions argument to defsystem. I don't think any other build tool I have experience with provides such a thing. However, it seems like an elegant way to address the common complaint that more expressive version constraints encourage a system consumer to block versions of their dependencies that haven't even been released yet. -Eric

1 0

Next steps
by Robert Goldman 19 Nov '21

19 Nov '21

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 things that add new capabilities that don't seem like a patch version. Alternatively, we could just keep `master`, but it seems like that is becoming old standard practice, so changing to `main` would comply with the new de facto standard established by GitHub. Then, if we want to back patch, we can create a `stable` branch and cherry-pick onto that (using `maint` would create too much potential for confusion). Thoughts?

11 47