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

[asdf-devel] Would like to disable bundle-op on known not-working implementation X platform combinations
by Robert P. Goldman 08 Apr '15

08 Apr '15

Per the principle of failing obviously, I propose to raise an error upon attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op tests have been failing for me on those platforms for as long as I can remember. For ECL, at least, I believe this to be an implementation bug, having to do with the Mac's 32-/64-bit hybrid architecture. With the current disarray in ECL maintenance, I don't see any signs of this being fixed. For ABCL the cause of this issue is more mysterious, but it is still persistent. Unless someone squawks, where "squawks" includes "explains why this test failure is specific to me or provides a proposed patch," I will make that change. Cheers, r

2 3

[asdf-devel] Allegro Modern test failures
by Robert P. Goldman 08 Apr '15

08 Apr '15

Looks like this may be due to problems configuring the fasl file locations for the tests. I see this in the transcript: ; Fast loading ; /home/rpg/lisp/asdf/build/fasls/acl/asdf/test/unintern-foo.fasl cfwbi-ufo asdf-test::c => #<excl:fasl-casemode-mismatch @ #x205e0e42> TEST ABORTED: #P"/home/rpg/lisp/asdf/build/fasls/acl/asdf/test/unintern-foo.fasl" was compiled in case-insensitive-upper mode. Continuing to load this file may result in symbol-name mismatches. Surely the build/fasls/ subdirectories should distinguish between ACL alisp and mlisp. Perhaps somehow the normal implementation location logic doesn't work in the tests?

1 0

[asdf-devel] Temporary FASL reconfiguration?
by Zach Beane 08 Apr '15

08 Apr '15

I'd like to change the output translations for a little while and then revert them to the previous configuration. Is that possible via the output translation configuration API? Zach

3 2

[asdf-devel] Much improved uiop:run-program
by Faré 08 Apr '15

08 Apr '15

stassats noticed that 1- run-program would fail in ECL while under SLIME, because ECL's system simultaneously insists in redirecting the I/O to current Lisp streams, and fails if they are not fd streams. 2- the current run-program is so tight a knot as to be horrible and unmaintainable. At the same time, I was procrastinating big time, and feeling I didn't want all that UIOP effort to go to waste. Therefore, 3- I fixed run-program, which involved teaching it about input as well as output, at which point error-output was a breeze. 4- Along the way, I fixed an embarrassing bug in with-temporary-file when using external-format, fixed bugs in slurp-input, identified a CCL bug #1114. 5- run-program is now much cleaner, maybe even maintainable by others, with a somewhat more portable interface to the underlying functionality, and a much improved API for the end-user. 6- Unhappily, 400 lines of code were added (but they include improved documentation). I only tested on Linux x64, using free software implementations and Allegro (Express Edition). Other people will need to test on LispWorks and on Windows, neither of which I can test. It's all committed on the git repository in the run-program topic branch: http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=shortlog;h=refs/he… See the commit message for more details on what changed. It should be mostly compatible for all users (= only inferior-shell and asdf tests, AFAICT). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You have the capacity to learn from mistakes. You'll learn a lot today.

1 0

[asdf-devel] New release candidate pushed
by Robert P. Goldman 08 Apr '15

08 Apr '15

This one puts the values in SYSTEM-DEPENDS-ON, SYSTEM-DEFSYSTEM-DEPENDS-ON, and SYSTEM-WEAKLY-DEPENDS-ON in canonical form before returning them. It also bundles fixes from Faré. Best, r

3 3

[asdf-devel] ASDF-BUNDLE breaks ECL (and a rant about related stuff)
by Juan Jose Garcia-Ripoll 08 Apr '15

08 Apr '15

Since 2.32 (probably earlier), ASDF can no longer produce standalone executables in ECL. The reason is that all those executables (stupidly in my opinion) have dependencies on libraries that should now be linked with the program. In particular, ASDF itself, UIOP, etc. Why is this so? Why do I have to link 800 Mb of library (ASDF and all its components) with every executable instead of abstracting a simpler load process where ASDF is not there unless, of course, a dependency on it is declared? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 4

[asdf-devel] Subtle bug fixed in restore-image & dump-image
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, I wasted quite some time today with a weird weird bug. I was streamlining the build of Lisp code within Google, which will now use as little of ASDF as possible to take advantage of their massively scalable build system, blaze: http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system… Of course, I wanted to reuse the infrastructure of UIOP, without the rest of ASDF/DEFSYSTEM that my colleagues were wary to exclude (at least by default) from the build. Now, I was dumping an image with dump-image, restoring it with restore-image, which was hooking into the declared *image-entry-point*, and everything was sailing from there, receiving via the shell interface commands to execute build actions. One of the actions, of course, was in turn to build new lisp executables. And there: fail. Somehow the new binary was refusing to see anything but the default values of the *image-restore-hook* or *image-entry-point*. What the $%^@? The problem, fixed in ASDF 3.1.0.8, was that restore-image itself was binding the special variables for *entry-point* and *image-restore-hook*. This meant that the global bindings were now shadowed, yet, it is those global bindings now unreachable that SBCL would be preserving at next dump-image. Oops. Conclusion: there are a few cases particularly in application construction, where you really want to be accessing the global bindings of a variable, and where dynamic binding is a no-no. Thanks to pkhuong for confirming the behavior of SBCL. I learned that lesson the hard way. I hope you don't have to. In other news, when you have massive distributed systems, you can really trade off 10x CPU for ¼x latency on top of a previous a tradeoff of O(n)xCPU for O(1)xlatency. Slave away, CPUs, we want low latency on large Lisp compilations! (The O(n)xCPU for O(1) saving in latency is parallelizing, where every file has to be loaded once for every other file that depends on it, rather than once — the classic XCVB more. The further 10xCPU for 4x saving in latency is loading dependencies as source code in unoptimized interpret mode, rather than waiting for 4x slower compilation then loading fast from 10x faster fasl or 50x faster cfasl.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "If men are good, you don't need government; if men are evil or ambivalent, you don't dare have one." — Robert LeFevre

1 0

[asdf-devel] Re: [armedbear-devel] Re: cl-test-grid: Testing ABCL-1.2.0-RC
by Faré 08 Apr '15

08 Apr '15

On Tue, Jun 11, 2013 at 1:32 PM, Zach Beane <xach(a)xach.com> wrote: > Faré <fahree(a)gmail.com> writes: > >> Inferior-shell *should* be able to compile with ASDF 2. >> If not, it's a bug. Meh: not as easy for me to test as I'd like. > > It uses the slash/package name thing. I'm not sure when it was > introduced, but my build system doesn't understand it. > Autodetection of foo/bar as meaning "read it from foo.asd" is an asdf3-ism, but systems named like that work on asdf2 (and asdf1) just like any other system defined in a .asd — of which there used to be a lot even before this convention was invented. i.e. once defined asdf can use them, but before the .asd file is loaded asdf1&2 have no idea where to look for them. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb

2 3

[asdf-devel] 3.0.2.21
by Faré 08 Apr '15

08 Apr '15

This weekend, thanks to Dave Cooper, there was much bug fixing on windows, particularly (but not only) related to run-program (and, unhappily, also unearthing implementation bugs in at least in Allegro and SBCL). PJB also found a bug in with-temporary-file, that was fixed. Because I was remote-debugging and failed to think about sharing a topic branch, this led to many increments in patch number. The test system was made more robust as a result. I also found a bug in test-module-pathnames (failure to specify *test-directory* to merge-pathnames*) that may or may not explain the test failures that Robert was seeing on LispWorks/Mac, and Dave on sbcl/win -- Robert, does your pathname under LispWorks have a non-nil host and/or device? That would explain it. SBCL/win also has massive failures in asdf-pathname-test, which I don't fully understand (I don't understand this janderson-contributed test in general), but every other file write test is a failure. Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features, modulo a rename of file asdf/defsystem to asdf/parse-defsystem (with a nickname for the old package name) and system asdf/header to asdf/prelude. Maintaining that topic branch is slightly costly, I've been using it for a week and removed a lot of kinks and relative inefficiencies. The new features are the support for the package-system "one package per file" style of quick-build, and some useful :use-reexport and :mix-reexport options of uiop:define-package. I believe it's not affecting anything negatively and is robust, and I'd really like to be able to encourage people to "just use it" without waiting for a few more months until the next release. [I'm using it for lisp-interface-library, but it's more awkward if people have to use the asdf extension asdf-package-system.] —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it.

4 8

"Solved" (was: Re: [asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25)
by Dave Cooper 08 Apr '15

08 Apr '15

> > > It's not crucial that I release with this latest 3.0.2.32, but I just bring > > up this issue in case it is actually a lurking asdf bug which needs to be > > shaken out before 3.0.3 release... > > > > If something is broken, we definitely want to solve before release. > But I fear the problem is with your configuration somehow. > I "solved" the issue by the following bootstrap procedure: 1. compile/load adsf3 2. (remhash "uiop" asdf::*preloaded-systems* 3. load quicklisp's setup.lisp Without step (2), the preloaded system of uiop occurs first in *system-definition-search-functions*, so the separable project for uiop (in my case, in local-projects), never ends up being found, and therefore ends up missing from the monofasl (I do suspect that the fact that it silently fails to be included in the monofasl can be considered a bug -- this probably should throw an error when trying to build the monofasl and realizing that the uiop.fasl is not showing up to the party, shouldn't it?) So is this a use case which should be more directly supported? Does this call for an unregister-preloaded-system or some such thing? Regards, Dave On Tue, Oct 22, 2013 at 10:57 AM, Faré <fahree(a)gmail.com> wrote: > > So I went ahead and tried > > > > (load (compile-file "quicklisp/asdf.lisp")) > > > > before loading quicklisp/setup.lisp. > > > If you already changed the quicklisp copy and *required-asdf-version* > to something later than your implementation-provided ones, as I > believe you are, this step is redundant. > > > And yes, I copied version.lisp.expr into quicklisp/local-projects/uiop/. > > > Did you use cp -aL with -L to dereference the symlink? > It worked for me. > > > To test that it wasn't ignoring the uiop in local-projects because it is > the > > same version as what is already loaded, I even temporarily bumped the > > version number in that version.lisp-expr to 3.0.2.33. > > > No, I don't think it's magically checking the version against > downgrade, as it is doing for asdf itself. Maybe it should? > > CL_SOURCE_REGISTRY=~/cl/poiu rlwrap sbcl --eval "'(#.(map () 'require > '(:asdf :poiu)) #.(in-package :asdf) #.(load \"~/quicklisp/setup\"))" > * (system-source-directory :uiop) > #P"/home/tunes/quicklisp/local-projects/uiop/" > > I didn't even have to (ql:register-local-projects) in that session — > or maybe its effects were persistent across section? Looking at the > source, it builds an index, so you need to run it once after you > installed the copy of uiop, and thereafter its effects should persist. > > > Still no dice -- I still get > > > > (asdf:system-source-directory :uiop) --> nil > > > > after loading the quicklisp/setup.lisp and (ql:register-local-projects) > > > > Quicklisp works in general after the upgrade. It just can't find the > source > > directory (or any source directory) for :uiop. > > > > > It's not crucial that I release with this latest 3.0.2.32, but I just > bring > > up this issue in case it is actually a lurking asdf bug which needs to be > > shaken out before 3.0.3 release... > > > If something is broken, we definitely want to solve before release. > But I fear the problem is with your configuration somehow. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > What one person receives without working for, another person must work for > without receiving. — Adrian Rogers > -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

3 10