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

Release plan for asdf
by Faré 09 Jun '15

09 Jun '15

Dear Robert, I believe the plan to enable style-warnings for those using deprecated functions or missing useful metadata is great, but 1- justifies moving to version 3.2. 2- requires testing with a 3.2.0.x alpha release series that already have a version >= 3.2, so no magic problem occurs due to the change, as we had with the switch to 3.0.0. 3- is probably many months away at the current rate. 3- suggests releasing what we have now as 3.1.5. What are your blockers to a 3.1.5 release (besides lots of testing and corresponding bug fixes)? I really believe it would be nice to get the current bug fixes and clasp support out of the door before then. Last release 3.1.4 was in October; a lot of small fixes have happened since then, notably fixing default configuration on many systems, and things like chdir on abcl — or making asdf and uiop themselves comply with the latest metadata requirements (note that the test systems don't fulfill them.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It should be a grammatical if not legal offense to ascribe thoughts, opinions and decisions to "we" without a signed power of attorney.

4 9

program-op is nice!
by Attila Lendvai 06 Jun '15

06 Jun '15

Fare, your asdf/uiop image-dumping machinery is great! with only a few minutes of trying i've already made an exe for the dwim.hu service that seems to just work. i'm very pleasantly surprised, because it gets rid of the entire hu.dwim.build complexity, and is now even platform independent... thank you! :) FTR, the change is here: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.home;a=commitdiff;h=2… it all seems to just work, but i have a hard time telling asdf where to put the resulting exe. the :build-pathname arg of defsystem errors with absolute paths (which sounds reasonable), but then it's merely the filename of the exe. my problem is that it gets saved into the fasl cache, which i cannot calculate from the shell script side of the build script to mv the file to its final place. is there some doc or test that i have missed? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You think you know when you can learn; are more sure when you can write; even more when you can teach... but certain when you can program.” — Alan Perlis

2 3

[Asdf-devel] Registering preloaded systems for Quicklisp/ASDF
by Dave Cooper 05 Jun '15

05 Jun '15

Hi, I know this has been discussed, but what is currently the best practice for registering a preloaded system after loading Quicklisp? That is, I have a pre-built image with some Quicklisp/ASDF systems in it, which were loaded through so-called monolithic-fasls (now known as compile-bundles). So the pre-built image doesn’t itself have ASDF or Quicklisp. A downstream user then loads Quicklisp and ASDF (I take steps to ensure that they are loading the matching version of ASDF and Quicklisp as was used to build the image). Now I need to do something to tell Quicklisp and ASDF that certain systems are already loaded in this image, so it won’t try to re-load them as depended-upon systems. In this specific case, I don't want it to try to fetch and reload Gendl when the user does (ql:quickload ...) on an application which :depends-on :gendl (because gendl is already built into this image). asdf/find-system:register-preloaded-system seems like it should be the answer if we’re talking about plain ASDF, because it will prevent ASDF from raising a “missing-component” error for the system in question, if some other system :depends-on it and yet no source code is found. But in my case I can’t guarantee that “no source code is found.” The source might be there in the quicklisp dist directory. So apparently I need something stronger than register-preloaded-system? Or something else? -- My Best, Dave Cooper

3 21

Re: How would you feel...
by Robert P. Goldman 04 Jun '15

04 Jun '15

Andreas Davour wrote: > On Wed, 27 May 2015, Faré wrote: > > [snip] >>> My SBCL is at 3.1.3. I think 3.1.4 is solid enough that it should be >>> updated there. >>> >> I've bugged SBCL hackers many time since last october, to no avail. > > But remember hwo it looks like from the outside, though. > > You are changing the third number, which will look like a patch to a > minor revision. They probably wont bother with updating (if it's any > amount of work) unless they see 3.2 or 4.0 is my guess. That's how I > would think. Actually, if I was them, I wouldn't bother updating until I saw 3.2.1! ;-) But seriously, waiting until the first bugfixes show up doesn't work well unless *somebody* runs the initial release and tests it in actual day-to-day use. It would be nice to figure out a way that ASDF could work nicely with the implementations so that implementors have an easy option to use the latest ASDF patch version day-to-day and see how well it plays with the latest version of the CL implementation. Cheers, r

2 2

Metadata check [WAS Re: How would you feel...]
by Robert P. Goldman 29 May '15

29 May '15

Faré wrote: >> OTOH, it's probably A Bad Thing if you depend on a system for something >> you are doing, and don't know what license it uses. >> > Well, we haven't codified any format for :license. I suppose we could adopt > the nomenclature used by Debian. Except what in Lisp circles goes by > the name "MIT" > (as notably used by ASDF itself) in Debian-speak is called "Expat". > Also, we don't have a story for multi-licensed code either. > For instance, I have code under LLGPL or bugroff, or BSD or bugroff. I didn't mean that we needed a codified format. I just meant that if you are using a system, and the humans involved don't know if your usage is legal (e.g., are you using pure GPL in a commercial application? are you delivering source for libraries when you deliver your code? etc.), that's a Bad Thing. Given that :LICENSE is currently arbitrary string valued, we can just make a string that indicates multiple possible licenses. We could certainly add some standard values (keywords?) for common licenses, and allow people to specify a list of such values (and an optional string), but I'm not sure what we would gain by this. I don't yet see a use case for machine-introspection on the :license, but I'm open to suggestions. > >> But that's why I created a special class of CONDITION for this case -- >> so you can muffle it if you don't care. It would be nice if there was >> some way to detect the distinction between internal systems (fix them!) >> and external systems (muffle). >> > At ITA, we started with muffling the external systems, but quickly > enough decided to fix them instead; code quality matters for libraries > we depend on, too. But we did have a list of style-warnings to muffle > and some of them were based on dependencies indeed. For now a programmer could match the name of the system in my MISSING-METADATA condition, and use that to make his or her decision about muffling. > >> I'll push my topic branch today. It needs a test script, and I'd like >> to make it skip signaling on "slashy" subordinate systems, but I'd love >> comments in the meantime. >> I pushed this as the QL-metadata-warning topic branch. Best, r

2 1

Re: Metadata check [WAS Re: How would you feel...]
by Robert P. Goldman 28 May '15

28 May '15

Erik Huelsmann wrote: > Hi, > > In various occasions I have seen that you plan to make the metadata > arbitrary string or even general values. While I think that's okay, to > provide lists of suggested values so that use of the values gets easier > and if most people use the suggested values, the value system could end > up centralized around those values. In my opinion, that would add value, > especially for machine interpretation. Note that this isn't something that I have planned. It is something that is the de facto current standard. To date, all the metadata are given simply as strings, and they aren't of use for other than human inspection. If someone would suggest a list of keywords for the licenses, we could certainly incorporate that in some fashion. But it would complicate any introspection code. Presumably that code would be taking the metadata and formatting it for the user. So it would now have to consider the possibility of keywords, which should be translated, and probably lists of keywords (per Fare's email), as well as strings. That would complicate the work of anyone trying to make use of the code. Now, if there was something where someone might want to say: (find :gnu-gpl (mapcar #'asdf:component-license my-systems)) [actually, that wouldn't work because of the possibility component-license is list valued] and do something with the results, then it might be worth making such an effort. But I haven't seen any "pull" for such a feature in ASDF. cheers, r > > Regards > > Erik > > On May 27, 2015 8:54 PM, "Robert P. Goldman" <rpgoldman(a)sift.net > <mailto:rpgoldman@sift.net>> wrote: > > Faré wrote: > >> OTOH, it's probably A Bad Thing if you depend on a system for > something > >> you are doing, and don't know what license it uses. > >> > > Well, we haven't codified any format for :license. I suppose we > could adopt > > the nomenclature used by Debian. Except what in Lisp circles goes by > > the name "MIT" > > (as notably used by ASDF itself) in Debian-speak is called "Expat". > > Also, we don't have a story for multi-licensed code either. > > For instance, I have code under LLGPL or bugroff, or BSD or bugroff. > > I didn't mean that we needed a codified format. I just meant that if > you are using a system, and the humans involved don't know if your usage > is legal (e.g., are you using pure GPL in a commercial application? are > you delivering source for libraries when you deliver your code? etc.), > that's a Bad Thing. > > Given that :LICENSE is currently arbitrary string valued, we can just > make a string that indicates multiple possible licenses. > > We could certainly add some standard values (keywords?) for common > licenses, and allow people to specify a list of such values (and an > optional string), but I'm not sure what we would gain by this. > > I don't yet see a use case for machine-introspection on the :license, > but I'm open to suggestions. > > > > >> But that's why I created a special class of CONDITION for this > case -- > >> so you can muffle it if you don't care. It would be nice if > there was > >> some way to detect the distinction between internal systems (fix > them!) > >> and external systems (muffle). > >> > > At ITA, we started with muffling the external systems, but quickly > > enough decided to fix them instead; code quality matters for libraries > > we depend on, too. But we did have a list of style-warnings to muffle > > and some of them were based on dependencies indeed. > > For now a programmer could match the name of the system in my > MISSING-METADATA condition, and use that to make his or her decision > about muffling. > > > >> I'll push my topic branch today. It needs a test script, and I'd > like > >> to make it skip signaling on "slashy" subordinate systems, but > I'd love > >> comments in the meantime. > >> > > I pushed this as the QL-metadata-warning topic branch. > > Best, > r >

2 1

Should we abandon support for IMAGE ops on Lispworks?
by Robert P. Goldman 27 May '15

27 May '15

I'm starting to be inclined to suggest we abandon support for this kind of operation on Lispworks. Lispworks does not provide a portable means to invoke from the command-line, indeed invocation from the command line is *IMPOSSIBLE* unless you pay extra for a Professional license. Also, image-dumping is only possible if you have a Professional license. What's even The Right Thing here? Should we be checking to see if image creation is possible? And how do we capture the fact that some of our stuff requires that the user create a LW image that can be invoked from the command line w/o starting up the IDE? I really wish they would ship with a simple command-line executable... Cheers, r

2 1

How would you feel...
by Robert P. Goldman 27 May '15

27 May '15

About holding the release briefly while I negotiate with Xach about metadata? Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well. I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata. Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly. I'll put in a topic branch for this. cheers, r

2 6

Getting failure on LW 6 and 7 on Mac and Linux on test-run-program
by Robert P. Goldman 27 May '15

27 May '15

Here's the error: TEST ABORTED: Undefined function LISP-INVOCATION/IMPLEMENTATIONS::INVOKE-LISP-VIA-SCRIPT called with arguments (:CROSS-COMPILE NIL :LOAD "/Users/rpg/lisp/asdf/test/make-hello-world.lisp" :EVAL "(asdf-test::make-hello-image)" :RUN-PROGRAM-ARGS (:INPUT NIL :IGNORE-ERROR-STATUS T :OUTPUT (#<Synonym stream to HARLEQUIN-COMMON-LISP:*BACKGROUND-OUTPUT*> :LINEWISE T :PREFIX "stdout: ") :ERROR-OUTPUT (#<Synonym stream to HARLEQUIN-COMMON-LISP:*BACKGROUND-OUTPUT*> :LINEWISE T :PREFIX "stderr: "))). Investigating, but wanted to pass this on for now. Cheers, r

2 2

Purpose of components of type :static-file?
by Dave Cooper 26 May '15

26 May '15

Hi, What is the intended purpose of the :static-files component-type in ASDF? I see a couple examples of their use in the ASDF manual, but didn't see an explanation or real example of how to use them downstream from including them in the defsystem form in the .asd file. Presumably they can be used for README, license, example files, and other resources which go with a system but are not Lisp source files to be compiled and loaded with the system. If so, then what are the supported/expected operations with static-files? For example, is there a way to query a system for files of type :static-file, so that you can do something with them (e.g. copy them to a distribution directory)? Best Regards, Dave P.S. my apologies if this has been discussed in this list before -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) +1 248-330-2979

3 2

Declaring code obsolete
by Faré 23 May '15

23 May '15

Dear lispers, I'm looking for hackers to review my branch obsolete-function-warnings: https://gitlab.common-lisp.net/asdf/asdf/tree/obsolete-function-warnings In it, I add support to UIOP for issuing conditions for obsolete functions, and use it for UIOP and ASDF deprecated functions. They can be style-warning, warning, continuable error or error, if possible at compile-time via a compiler-macro, or at first use at runtime. Last option is plain error at compile-time for having failed to delete the functions when promised. There is also a cool but somewhat dangerous optional feature that can automatically bumps the status of an obsolete function at every release — you better not use it lightly. Finally, this was the opportunity to realize that there are plenty of offenders in Quicklisp that use long obsolete APIs of ASDF and need be updated. Yikes. QUESTIONS: * Does it make sense to go from :style-warning to :warning to :error to :delete ? * Does it make sense for :error to be a continuable error, or should I introduce an extra step for :cerror, then an :error that isn't continuable? * Robert is in charge of the release schedule, so he should decide what automatic bumping to use, if any. I suppose he may want style-warning now while we're in 3.1, then warning at 3.2, then error at 3.3, then function deleted in 3.4; except for some recently deprecated functions that should only start issuing style-warning in 3.2, and for some backward compatibility package munging that I hope can go away in 3.3. * At some point soon, someone must contact all those people using obsolete functions and classes, and chide them or offer patches. * Now is a good time to upgrade, since all maintained implementations at long last provide asdf3 (May 2013, so a 2 year delay from release to ubiquity; let's hope 3.1 will be ubiquitous next year). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "To speak algebraically, Mr. M. is execrable, but Mr. G. is (x+1)ecrable." — Edgar Alan Poe

1 0

New version of ASDF pushed
by Robert P. Goldman 19 May '15

19 May '15

I have just pushed 3.1.4.5, which contains fixes to UIOP's configuration file finding/XDG functions needed to fix launchpad bug 1437480. Testing would be very much appreciated, especially by those using the configuration file finding functions.

2 10

Patch to UIOP/LISP-BUILD:GET-OPTIMIZATION-SETTINGS for SBCL
by Douglas Katzman 18 May '15

18 May '15

Hi ASDF developers, I'm changing SB-C::*POLICY* from a list to a struct. (This yields us a nice compile-file speedup.) Instead of accessing the global policy with (CDR (ASSOC ...)) it should be accessed with (SB-C::POLICY-QUALITY) as per the attached diff. This function has been present since 2000-12-29 and the interface is unchanged, so a new ASDF can work just fine with an older SBCL. The reverse is not possible. I'll patch the ASDF that ships with SBCL. Doug

2 2

EXPECTED test failures & clisp
by Robert P. Goldman 07 May '15

07 May '15

Do we have a way of indicating that we expect a test to fail? There's a string in the output that talks about "Unexpected test failures in..." but I am not sure if there's actually any notion of expected vs. unexpected test failure. IIRC in the past when I knew a test would fail I just used reader macros to make sure it wouldn't run. This is actually not as good as having the test run but not cause a failure. I ask because I get test failures in clisp on run-program, because somehow clisp lets the common-lisp prompt leak into the output of running a program. So I get something like ("[4]> hello, world") instead of ("hello, world") IIRC this is a known clisp problem, and may even be fixed in the clisp source. But there hasn't been a clisp release for almost five years now, and I don't intend to build it from source. With no releases since 2010, IMO clisp is only "living dead," and possibly simply "dead."

3 2

Ding dong the witch is dead!
by Faré 06 May '15

06 May '15

Dear lispers, with the recent release of LispWorks 7 (congratulations to the LispWorks team!), each and every maintained CL implementation now provides ASDF 3, and ASDF 2 can be declared officially dead. Adieu, ASDF 2, you served your purpose, but you won't be missed. I propose that free software libraries (including ASDF itself) may safely assume ASDF 3 everywhere and drop support for ASDF 2 or earlier. Note: I didn't count GCL as an actively maintained CL implementation, which is only slightly harsh. Maintained (and ship with asdf 3): abcl ccl clasp clisp cmucl ecl mkcl sbcl allegro lispworks Unmaintained (but have worked at some point with asdf): gcl mcl xcl cormanlisp genera mocl scl https://youtu.be/PHQLQ1Rc_Js —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Computer programming is omnipotence without omniscience." — Prospero, as cited by Eliezer Yudkowsky

2 1

UIOP documentation?
by Jared C. Davis 06 May '15

06 May '15

Hi, The ASDF web site at https://common-lisp.net/project/asdf/ has a very nice manual. Is there similar documentation for UIOP itself? If so, it would be great to add a link to it from the ASDF web page. Cheers, Jared -- Jared C. Davis <jared(a)cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/

4 8

Re: UIOP documentation?
by Robert P. Goldman 06 May '15

06 May '15

Faré wrote: >> > I looked at the link to the version that's supposed to have good docs: >> > >> > http://bimib.disco.unimib.it/people/Marco.Antoniotti/Projects/CL/HELAMBDAP/… >> > >> > AFAICT it shows only the docs for BACKWARD-INTERFACE, and maybe not even >> > all of those. >> > > Oh! It has more documentation than that, but depending on your screen > resolution, it can be totally unobvious that you can scroll the > package pane. Le sigh. I tried to document that in the uiop/README.md, > but that needs also be told in the index.html. > That is a *horrible* left pane. As you say, there is no visible affordance, indicating an ability to scroll that pane. The pane also has no border, which hides the fact that, instead of filling the frame with package entries, it takes only 25% of the height of the pane. I guess that's because it wants to put the package interface below the package menu. A border around those frames would help the user understand how the layout is to be used. Also, one I have selected one package, clicking on another in the sidebar takes a *very* long time (so long that I thought it was not going to update at all) to update the main frame.

1 0

Fwd: UIOP documentation?
by Faré 06 May '15

06 May '15

[I got notification on the below message being rejected because the quickdocs url is blacklisted by http://lookup.uribl.com/ !? I stripped said url so the message makes it to the list.] On Tue, May 5, 2015 at 8:35 PM, Robert P. Goldman <rpgoldman(a)sift.net> wrote: > Faré wrote: >> UIOP has no manual, but it has a README.md which guides you through >> the code and links to a website with interactive help as extracted >> from docstrings. I included a direct link on the ASDF webpage in >> doc/index.html — but only the maintainer has the rights to update the >> actual webpage. > > I looked at the link to the version that's supposed to have good docs: > > http://bimib.disco.unimib.it/people/Marco.Antoniotti/Projects/CL/HELAMBDAP/… > > AFAICT it shows only the docs for BACKWARD-INTERFACE, and maybe not even > all of those. > Oh! It has more documentation than that, but depending on your screen resolution, it can be totally unobvious that you can scroll the package pane. Le sigh. I tried to document that in the uiop/README.md, but that needs also be told in the index.html. > As you report, the quickdocs page, http://....org/uiop/api, only > provides docs for UIOP/PACKAGE. > > Also, for some reason these aren't clickable links in the README.md: > they come through as preformatted text, instead. > OK, I was assuming ReST-style magic. I pushed a fix to that. Actually, I made a few passes over both README.md and uiop/README.md. I also merged into the minimakefile branch. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An anarchist is a man who is careful to always use pedestrian crossings, because he utterly detests talking with policemen. — Georges Brassens

1 0

Lisp scripting
by Faré 06 May '15

06 May '15

>> * minimakefile. Can we get this in before we cut 3.2? Actually, >> merging before 3.1.5 would allow to test the release functions before >> we release an actual 3.2. > > The last time I was working with minimakefile it was still at the state > where every time I tried a new command, I would get a new error. I got > tired of this and gave up. I'll try again, but this one is your cause: > I don't care if CL never becomes a scripting language. I'm willing to > run with it if it works, but if it gives me grief, I'll give up again. > Indeed, it's my pet topic; I apologize for the bugs, and I am grateful to you for bearing with me thus far. Obviously, there was a big gap from "(seems to) works for me" to "works robustly for everyone"; but this time, I believe the bugs have been shaken, and the new test system is superior in many ways, including not drowning the screen in so much noise, providing better replay information on error, supporting one more Lisp (clasp), an interactive list of commands, ability to invoke tests from the SLIME REPL, etc. Please try again, and merge into master if satisfactory. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When one realises one is asleep, at that moment one is already half-awake. ― Pyotr Uspensky

1 0