asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] Chat with Anton Vodonosov
by Faré 27 Feb '13

27 Feb '13

Anton Vodonosov was kind enough to run cl-test-grid against ASDF 2.29, and here are the results, which I'm sharing with the asdf-devel list because some people might find this status informative. > I am thinking to add backtraces. Wasn't sure how (to depend > on some library like trivial-backtrace, but what if the library itself > is broken on the given lisp; or maybe copy/paste code to cl-test-gird; > did't know about asdf/driver, alghtouhg it will only work on the lates > ASDF). I will solve it somehow. Meantime it is necessary to reproduce > the problem manually. > At worst, you could copy/paste and simplify code from asdf/image. I already merged in code from xcvb-driver and trivial-backtrace, so it should work in more cases. And if you add implementations, please contribute them to asdf/image. >> Where are the SBCL results? > > At the same table, at the bottom part. If you want, here is > a separate SBCL-only table: > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-11-sbcl.html > Oh, sorry. Thanks. unicly: encoding problem. I wonder why it doesn't appear with other run — are you using an ASCII locale where you were using UTF-8 before? I should really make UTF-8 the default default at some point, but let's fix the other issues first. iolib, and through it scriptl, inotify, hemlock.base, dbus, cl-ws, clonsigna, clavatar, cl-popen: ouch, iolib modifies the readtable in the .asd file. That's nasty, and is broken by my recent use of with-standard-io-syntax around loading .asd files. I temporarily removed that wrapper in 2.29.2 until all clients are fixed, but clients should definitely get fixed. Upstream errors, need to contact the respective upstream authors if not done already: jwacs, netkthuth, meta-sexp: bad :version vs less forgiving asdf xcvb-bridge: fixed upstream already. weblocks: they are missing some dependencies in their .asd files. I sent them a patch, I think they applied it in the end, but not sure. qbook: sent patch upstream some time ago, no answer. mime4cl: bad use of defconstant for a list, caught by sbcl. Not an ASDF-specific issue. metacopy-with-contextl: the .asd file has an ugly output-files :around method that expects only one output file when there are now several. jenkins.api: has version requirements on all dependencies, but iterate doesn't have a version to compare to 1.4.4 cl-sam: has a version dependenceny on cffi 0.10.3, but latest cffi doesn't sport a version number deoxybytes-*, cl-prolog: WFM. Maybe it's looks like it's been fixed by 2.29.1??? Or maybe you're actually using 2.28.10?? This looks more like the bug I fixed in 2.28.11 aka 2.29. buildapp: needs to be updated for ASDF3 (specialization of previous unexported traverse function without &key) I'm adding the "contacting upstream errors" on my TODO list. I'm just telling Stelian for now that though I'm adding back compatibility with modifying the readtable within a .asd file, this is strongly frowned upon and we need a different solution, possibly using named-readtables. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It’s amazing that the amount of news that happens in the world everyday always just exactly fits the newspaper.

3 24

[asdf-devel] Mac OSX test upgrade status
by Robert Goldman 26 Feb '13

26 Feb '13

I got through almost all the upgrade tests before failing with allegromodern trying to upgrade from 1.85: ; registering #<system :asdf @ #x1000afe932> as asdf ; Fast loading /Users/rpg/lisp/asdf/build/asdf.fasl TEST ABORTED: Attempt to fast load a non-fasl file: #P"/Users/rpg/lisp/asdf/build/asdf.fasl" Script failed upgrade FAILED for allegromodern from 1.85 using method 'load-asdf-lisp'load-asdf-system I can see why this fails! When I look at ~/lisp/asdf/build/asdf.fasl in emacs I see this: #!/usr/local/bin/sbcl --script # FASL compiled from "/Users/rpg/lisp/asdf/build/asdf.lisp" using SBCL version 1.1.3.7-63e78fc which suggests to me that we may be leaking something from one test to another... best, r

2 3

[asdf-devel] standard io syntax woes
by Faré 26 Feb '13

26 Feb '13

Dear Common Lisp hackers, Inspecting with Anton Vodonosov the latest batch of cl-test-grid issues when running with asdf 2.29.x, we found an interesting case that mirrors the previous failure of iolib 0.7.3 with 2.29. In the hope of making the semantics of asd files more deterministic, with an eye on eventually making .asd files a strict subset of Lisp, I had put in 2.27 a with-standard-io-syntax around the loading of a .asd file. However, this is specified to bind *readtable* and *print-pprint-dispatch* to standard tables that are notionally read-only, though this immutability is NOT enforced on most implementations, instead there being unspecified bad consequences if you do mutate. So, I could conceivably (copy-readtable nil) and (copy-pprint-dispatch nil) every time, but that could be expensive on some implementations. Or I could say "it's the programmer's responsibility to ensure a proper table has been setup before he modifies it", but that would be harsh and a notable backward incompatibility (and there's no equivalent of named-readtables for pprint-dispatch). Or I could preserve the current semantics of a global table that everyone modifies causing "interesting" issues, by rebinding *print-pprint-dispatch* as well as *readtable* within the w-s-i-s, only ensuring that the other syntax variables are standard. Or I could remove the with-standard-io-syntax altogether, and say "yes, if you're doing any global modification, you suck and you're going to break something for someone, but that's none of my business". Anton leans for the latter. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One can be so anxious to put his "best foot forward" that he doesn't even notice that it isn't his own foot. — Harry Browne (HIFFIAUW)

7 12

[asdf-devel] Failures due to deferred warnings
by Faré 23 Feb '13

23 Feb '13

When we enable the checking of deferred warnings, the following 57 systems have issues. Now to contact the authors. Then of course, there are all the style-warnings that we are ignoring, but oh well. s-xml mcclim cl-csv clsql-helper lisp-on-lines regex zlib cl-mediawiki cl-neo4j cleric coleslaw com.informatimago.common-lisp.parser diff gdl-ta2 lispbuilder-regex marching-cubes mgl odd-streams open-vrp-lib pg prepl webactions xmls-tools adw-charting-vecto cl-azure cl-containers-test cl-fluiddb-test cl-fsnotify cl-gdata cl-graph-test cl-markdown-test cl-memcached cl-pdf-doc cl-protobufs-tests cl-quakeinfo cl-randist cl-redis clack-handler-hunchentoot clunit com.informatimago.linc com.informatimago.xcode computable-reals dcm elephant-tests hh-web json-template kanren-trs-test km lift-test lucene-in-action-tests parseltongue postoffice spinneret trivial-timeout-test weblocks-demo weblocks-demo-popover wilbur —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Justice is not concerned with the results of the various transactions but only with whether the transactions themselves are fair. — F.A. Hayek, "Law, Legislation and Liberty", I.6.j

4 10

[asdf-devel] asdf 2.30.2, (upgrage?) problem on ECL
by Anton Vodonosov 22 Feb '13

22 Feb '13

I decided to continue testing on other lisps. On ECL bytecode compiler there is a problem: /home/testgrid/lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -eval '(LOAD #P"/home/testgrid/quicklisp-patched2/setup.lisp")' (ql:quickload :alexandria) Condition of type: UNDEFINED-FUNCTION The function ASDF/SYSTEM:FIND-SYSTEM is undefined. Available restarts: 1. (ABORT) Give up on "alexandria" 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at QUICKLISP-CLIENT::RECURSE. In: #<process TOP-LEVEL>. File: (1 . #P"/home/testgrid/quicklisp-patched2/quicklisp/setup.lisp") (Position #2087)

2 4

[asdf-devel] help needed with asdf internals knowledge
by Attila Lendvai 21 Feb '13

21 Feb '13

dear asdf devels, i want to conditionally compile and load some lisp files on-demand at runtime, and i would like to use the asdf machinery for that. the set of files are not known at development time. the code in question is load-resource-file here: http://common-lisp.net/cgi-bin/darcsweb.cgi?r=cl-l10n-cl-l10n;a=headblob;f=… the current implementation is broken on asdf3 due to the assert (and a kludge in general): (defun load-resource-file (resource-file) (bind ((output-files (asdf:output-files (make-instance 'asdf::compile-op) (make-instance 'asdf:cl-source-file :pathname resource-file :parent (asdf:find-system :cl-l10n))))) (assert (length= 1 output-files)) (bind ((output-file (first output-files))) (ensure-directories-exist output-file) (when (or (not (cl-fad:file-exists-p output-file)) (> (file-write-date resource-file) (file-write-date output-file))) (compile-file resource-file :output-file output-file)) (load output-file)))) any help, pointers, thoughts are welcome! -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39

2 2

[asdf-devel] Fwd: possible to include a few "model" systems?
by Dan Lentz 21 Feb '13

21 Feb '13

Apologies I mistakenly sent this to sbcl-Devel rather than asdf-Devel list thanks to my pudgy fingers and iPhone... The changes to upcoming asdf sound amazing. I know there has been a huge investment in Devel/debugging etc, and full documentation is not a reasonable expectation at this point, but I wonder if it might be possible to include a few model systems which demonstrate what will be considered basic best practice with the new ASDF and exemplifying recommended usage of some of these new and replacement features/practices. Basically I'm just hoping to avoid any future situation where I build systems and layered functionality in a manner which seems reasonable but may contradict the popular opinion of what constitutes good system design. For example, in the past I used asdf component properties quite a bit as my local transient annotation slot for working on systems dynamically at runtime. If there are a few examples demonstrating proper use of the new functionalities (perhaps referencing the prior usage it supersedes when appropriate) It would probably be even more helpful to facilitate migration to exploit the new ASDF capabilities than formal reference style documentation... From such examples it will then be a simple matter to focus in for study of the relevant portions of the new asdf source code. Thanks to all the asdf volunteers for all of the work done to improve this important facility which in turn seems likely to substantially improve the whole common-lisp ecosystem as a viable, modern choice for development platform.

1 0

Re: [asdf-devel] [armedbear-devel] ASDF 2.29 released
by Mark Evenson 16 Feb '13

16 Feb '13

On 2/16/13 4:08 PM, Faré wrote: > Dear ABCL developers, > > ASDF 2.27 was a major rewrite of ASDF, and everything since then > should be considered as candidate releases for ASDF 3: > http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… > > ASDF 2.28 was released shortly after 2.27, without an announcement, > to fix an issue found by Stelian Ionescu using TEST-OP on some systems. > > ASDF 2.29 is a stability release, with which I'm once again > inviting implementers to update the ASDF they distribute. > > Please update ABCL to use ASDF 2.29. […] ABCL trunk has now been updated to [asdf-2.29][r14395] N.b.: I had to remove/recompile my SLIME fasls to get ASDF-2.29 to load. [r14395]: http://trac.common-lisp.net/armedbear/changeset/14395 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[asdf-devel] ASDF 2.29 released
by Faré 16 Feb '13

16 Feb '13

Dear Lisp hackers, ASDF 2.27 was a major rewrite of ASDF, and everything since then should be considered as candidate releases for ASDF 3: http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… ASDF 2.28 was released shortly after 2.27, without an announcement, to fix an issue found by Stelian Ionescu using TEST-OP on some systems. ASDF 2.29 is a stability release, with which I'm once again inviting implementers to update the ASDF they distribute. Since ASDF 2.27, ASDF 2.29 further brings: * deferred-warnings support for Allegro, CMUCL, SCL; fixes to the CCL support. * Upgrade fixes regarding fallback system versions; making it possible (via massive use of eval-when) to compile ASDF without loading it first. * Compatibility with private use of :D package nickname by not claiming it for package ASDF/DRIVER anymore. Also explicitly handle NIL in safe-file-write-date, in case the implementation doesn't issue a file-error in that case; make UTF-8 the default encoding for with-input-file. Be portable to #+(and sbcl (not sb-eval)). * Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393), defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it.

1 0

[asdf-devel] Example of deferred warnings?
by Raymond Toy 14 Feb '13

14 Feb '13

Is there an example of deferred warnings support? I have a possible implementation for cmucl, but I'd like to test it somehow before I propose a patch. Ray

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel