asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Multiple processing compiling the same file
by Jim Newton 31 Jan '18

31 Jan '18

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 best way to prevent this? I see in the asdf documentation that there is an asdf:*user-cache* variable whose value is the path name of the directory where asdf compiles into. Would it be advisable for my to arrange so that asdf:*user-cache* is a function of the pid and hostname and perhaps thread-id (if such a thing exists) to avoid such collisions? Or is there some better way to handle this which is build into asdf?

4 9

spurious reloads with systems not following the foo/bar naming convention?
by Attila Lendvai 31 Jan '18

31 Jan '18

dear list, i noticed it with CXML, but here's a smaller system to reproduce it with: git clone https://github.com/mmaul/cl-influxdb.git (ql:quickload :cl-influxdb) (asdf:load-system :cl-influxdb.examples) each time the examples are loaded the main systems gets reloaded. i see something interesting in the output that may be related: WARNING: Computing just-done stamp in plan NIL for action (ASDF/LISP-ACTION:PREPARE-OP "cl-influxdb" "cl-influxdb"), but dependency (ASDF/LISP-ACTION:LOAD-OP "cl-influxdb" "package") wasn't done yet! CL-USER> (asdf:asdf-version) "3.3.1.1" CL-USER> (lisp-implementation-version) "1.4.1.98.hu.dwim.3-a860f4780" -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “With or without religion, good people can behave well and bad people can do evil; but for good people to do evil — that takes religion.” — Steven Weinberg (1933–), 'A Designer Universe?'

2 3

Including uiop and not asdf in a built application
by Dave Cooper 16 Jan '18

16 Jan '18

Hi (I'm not sure who is current lead maintainer, but hopefully the group will have some wisdom), First of all, Happy New Year and thank you to whomever is monitoring this list. Your efforts are highly appreciated. Our build process for Gendl and GDL for the past several years has involved using monolithic-compile-bundle-op to make concatenated fasls, then loading these fasls into an empty image to create the final build. We do depend on (and include) uiop, but not asdf, in our final build product. In order to have uiop available separately for inclusion in the monolithic-compile-bundles, we have been putting a copy of the uiop/ directory (of the same version as the ASDF we're using) into quicklisp/local-projects/. Some time between ASDF 3.2.0.1 and ASDF 3.3.1, the function check-not-old-asdf-system got modified to add "uiop" to the test (first line of the function). This results (in ASDF 3.3.1) in a same-version uiop not getting loaded at all into a monolithic-compile-bundle, even if the system of said monolithic-compile-bundle contains a dependency on uiop and uiop is available in quicklisp/local-projects/. For this reason, out-of-the-box ASDF 3.3.1 was not working for our build process. I have "fixed" the problem temporarily by modifying my local asdf.lisp to remove the "uiop" from the test, i.e. I've replaced (or (not (member name '("asdf" "uiop") :test 'equal)) .... with (or (not (member name '("asdf") :test 'equal)) ... as the first line of the defun check-not-old-asdf-system. Question: Is there a supported way to do what I'm trying to do, without modifying the ASDF source code? Intuitively, it seems to me that we should be able to include uiop in build products using monolithic-compile-bundle-op, without including asdf. -- My Best, Dave Cooper, david.cooper(a)gen.works genworks.com, gendl.org +1 248-330-2979

3 4

package pollution by asdf
by Sam Steingold 16 Jan '18

16 Jan '18

Hi, When I start CLISP with the full linking set (i.e., including all possible extensions), I have 63 packages in (list-all-packages), and 37 of them (more than half!) comes from asdf (22 ASDF/* and 15 UIOP/*). I wonder if I am the only one unhappy about this. In particular, has it ever been considered that it might be a good idea to limit the number of packages asdf creates? Thanks. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://www.dhimmitude.org http://honestreporting.com http://no2bds.org WHO ATE MY BREAKFAST PANTS?

3 2

Syntax control code
by Robert Goldman 07 Jan '18

07 Jan '18

I just pushed an edit of syntax-control.md in which I try to capture the terminology. Status: several Allegro failures break for me on test-syntax-control. Results from Linux: build/results/allegro8_64-test.text build/results/allegro8_64_s-test.text build/results/allegromodern8_64-test.text build/results/allegromodern8_64_s-test.text build/results/allegromodern_64-test.text build/results/allegromodern_64_s-test.text These failures seem to be due to NAMED-READTABLES not working properly on these platforms, rather than on anything ASDF itself does. Concern: As I was reading over syntax-control.md, it was brought home to me that the ASDF shared syntax is initialized to the *initial syntax* on the host implementation, rather than the standard syntax of ANSI CL. My understanding is that this is done for backwards-compatibility with some QL systems that assume they have access to extended syntax from some implementation(s). I'm concerned that this will create a maintenance headache going forward just so someone *else* can avoid making some minor clean-up. Should we just suck it up and make the shared syntax start out with the initial syntax? Why not break it now, and save ourselves trouble later? Also, it seems like "initial syntax" is not well-defined, even on a single implementation, since ASDF might be loaded at arbitrary times, possibly after modifications to the "initial initial" readtable. Finally, going forward, people will be yelling at *us* if implementations change their initial syntax. Unless there's a really important reason to keep this, I think we should kill it.

4 4

One bug down, one bug up
by Faré 03 Jan '18

03 Jan '18

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 experience, it might be great bug to get really into it. Context: I did this interactive debugging session, but it went quite slow and after two hours we only narrowed down the root issue: we needed the primary-system-* functions to distinguish between "syntactic" and "semantic" primariness, since the two notions aren't identical in the existing codebase, and my just ignoring the issue caused these spurious rebuilds. I once again failed to properly record the 2.5 hour interaction, but one of the participants might have done so, though it's not as valuable as I'd have hoped. Then, It took me the next morning to slowly develop a bug fix. See explanation in the bug and code in the MR: https://bugs.launchpad.net/asdf/+bug/1739514 https://gitlab.common-lisp.net/asdf/asdf/merge_requests/91 Now now now, while thinking very hard about the correct fix to the above bug, and especially about the up-to-date-p condition in find-system, I realized that there was a lingering bug in it, of the kind order as the bug that broke ASDF 2, except in a much rarer situation: if you update the defsystem-depends-on of a loaded system a that could cause a change in how the a.asd file would be evaluated; then this should trigger a reload of a.asd when you next operate on a; but it won't because the timestamp is not propagated, because find-system fails to integrate well enough with the dependency graph usage and construction (which integration is new with 3.3). https://bugs.launchpad.net/asdf/+bug/1741083 This seems to be like it's "just" a variant at the meta-level of the famous bug that broke ASDF 2 (see my 25 page paper on the history of ASDF about that). Except that now the infrastructure to propagate timestamps, what more across evaluation phases, already exists; therefore fixing this bug should mostly "just" use the existing infrastructure. Then again, it could possibly break the universe again, though I bet it won't: I believe there should be "just" an update of find-system and the creation of a new operation class prepare-define-op. In any case, not my problem anymore, because it's clearly not a regression. But a great opportunity for whoever steps up and fixes this bug and whatever else they find. You better step forward while I'm still here to answer questions: considering how hard it was for me to page back the crucial elements of the algorithm into memory after just one year, don't wait. PS: Another exercise for a future ASDF maintainer would be to do the boring work and fix all the 300+ systems on Quicklisp that trigger the bad-system-name warning, one by one. This is also a great exercise for getting to know what kind of clients are around. And for fixing them according to my best_practices document. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every great truth begins as heresy and ends as superstition. — Thomas Henry Huxley

1 0

ASDF debugging on Hangouts?
by Faré 27 Dec '17

27 Dec '17

Dear CLers, with ASDF 3.3.1 released and the syntax-control branch pending review, there's not much left for me to do with ASDF before I actually retire. Now I'm looking for hackers to whom to pass the torch of ASDF hacking. It so happens that I seem to have introduced (probably with 3.3.0) a regression that breaks static image dumping of workout-timer with cffi-toolchain. If people are interested, I could do the entire debugging session over Google Hangouts, from isolating the bug and filing a bug report to writing regression test and submitting a merge request. That would be a good way to introduce newcomers to ASDF hacking. Having a public ask questions as I make progress would be a good way to keep the video relevant. Is anyone interested? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If there's a book you really want to read but it hasn't been written yet, then you must write it. — Toni Morrison [same with software, —♯f]

8 23

Relativising FASL Cache Paths
by Nicolas Hafner 17 Dec '17

17 Dec '17

Hello everyone. I have a rather particular problem that I have so far not been able to solve on my own without brittle workarounds. Specifically, I'm looking for a way to ensure that the directory paths stored in the FASL cache directory are, if possible, truncated according to some other path (by enough-pathname or a similar facility). The reason I want this is for Portacle <https://portacle.github.io/>. The Portacle directory should be relocatable and you should even be able to take it with you on a flash drive to run on other machines. However, this usually means that the absolute position of the directory on the file system will change, even if the Lisp files and FASLs within it remain at the same relative locations. I would thus like to stop ASDF from recompiling everything when the directory is moved absolutely, and instead rely on paths relative to Portacle's own "root" directory if possible. My current approach involves setting asdf/output-translations::*output-translation-function* to a modified version that attempts to relativise the path as seen here <https://github.com/portacle/config/blob/master/sbcl-init.lisp#L70>. However, this sometimes leads to issues <https://github.com/portacle/portacle/issues/62> as the translated path might be relative and other components down the line seem to expect absolute paths. Any advice on how to proceed on this would be appreciated. Sincerely, Nicolas Hafner

3 6

ASDF + QL maintenance needed.
by Faré 12 Dec '17

12 Dec '17

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 introduced the bug (often a combination of the two). Recent Quicklisp build report: http://report.quicklisp.org/2017-12-11/failure-report.html I've started these two pull requests: https://github.com/marijnh/Postmodern/pull/115 https://github.com/zkat/chanl/pull/12 If there are candidate maintainers, we could do some more of these together. This would build up: * Good practice for dealing with build issues in quicklisp * Knowledge of what is or isn't the contract provided by ASDF 3.3. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If instead of teaching other people what government should be and should do, you'd teach yourself what government actually is and does do, you'd be a libertarian.

1 1

ASDF 3.3.1 is released
by Robert Goldman 17 Nov '17

17 Nov '17

Today we release ASDF 3.3.1, the first bugfix release for the 3.3.0 release series. Of primary interest in this release are 1. a fix for an incompatibility in the UIOP stamp-comparison functions. The handling of infinity as a bound in these functions changed between 3.2 and 3.3, potentially causing problems in backward compatibility. In order to maintain compatibility, the old behavior was restored to the stamp-comparison functions, and new functions -- TIMEstamp comparison functions -- were added to carry the new behaviors. 2. a fix for upgrade from version 3.2.1 3. fixes for bugs that can occur when the default readtable is manipulated inside a dependency loaded by DEFSYSTEM-DEPENDS-ON. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 -- to upgrade to 3.3.1 at their earliest convenience. Here is the changelog entry for 3.3.1: cl-asdf (2:3.3.167-1) unstable; urgency=low New milestone: * UIOP compatibility fix: Introduced new replacement "timestamp" comparison functions, because of inadvertent change in the API. Functions that are compatible with the old semantics are retained as "stamp" comparison functions, but will eventually be deprecated. * Upgrade fix: Upgrade from 3.2.1 needed repair. * Syntax manipulation: Fix for bugs that could be introduced when the default readtable was manipulated during the loading of a defsystem-depends-on system. * Tests: tests for new capabilities and bugs * Documentation: a number of improvements and clarifications.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel