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

[asdf-devel] Error loading closure-html
by Futu Ranon 30 Mar '10

30 Mar '10

Hello, I wanted to test closure-html so I installed and attempted to load it in LispWorks 6 on Windows. CL-USER 3 > (asdf:load-system 'closure-html) > > Error: External format (:UTF-8 :EOL-STYLE :LF) produces characters of type > SIMPLE-CHAR, which is not a subtype of the specified element-type BASE-CHAR. > 1 (abort) Return to level 0. > 2 Return to top loop level 0. > > Type :b for backtrace or :c <option number> to proceed. > Type :bug-form "<subject>" for a bug report template or :? for other > options. > > CL-USER 4 : 1 > :b > Call to ERROR > Call to STREAM::EXTERNAL-FORMAT-STREAM-DEFAULTED-ELEMENT-TYPE > Call to STREAM::EXTERNAL-FORMAT-OPEN > Call to OPEN > Call to ASDF:FIND-SYSTEM > Call to ASDF:OPERATE > Call to ASDF:LOAD-SYSTEM > Call to EVAL > Call to CAPI::CAPI-TOP-LEVEL-FUNCTION > Call to CAPI::INTERACTIVE-PANE-TOP-LOOP > Call to MP::PROCESS-SG-FUNCTION > > CL-USER 5 : 1 > > This diff corrects it for me. I don't have another lisp to test it immediately to see if this needs to be conditional. --- a/system/asdf/asdf.lisp +++ b/system/asdf/asdf.lisp @@ -1022,7 +1022,7 @@ to `~a` which is not a directory.~@:>" (< (car in-memory) (safe-file-write-date on-disk)))) (let ((package (make-temporary-package))) (unwind-protect - (with-open-file (asd on-disk :if-does-not-exist nil) + (with-open-file (asd on-disk :if-does-not-exist nil :element-type :default) (if asd (let ((*package* package)) (asdf-message Is this correct or is there something broken on my end?

4 8

[asdf-devel] SBCL port of ECL's extensions
by Juan Jose Garcia-Ripoll 29 Mar '10

29 Mar '10

I just cut & paste what I submitted to the appropriate record in launchpad https://bugs.launchpad.net/asdf/+bug/542583 where the port can be downloaded and given a try. I attach a straightforward port of two operations that ECL supports: - Building a unified FASL file that contains either a system, or a system plus all its dependencies. - Building an ASDF system that, using the previous feature, can replace an existing one (this include *.asd file) The implementation tries to be done with future extensions in mind, such as bundling all executables plus resources into an application, dumping images, etc, but all is constrained into new files that are not required for booting -- should simplify the process of reloading ASDF. The patch need not be accepted as is. I will submit it for discussion at the mailing list. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

4 16

[asdf-devel] ABCL testing issue
by Faré 28 Mar '10

28 Mar '10

http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/20100316T233422/a… > > Testing: test-force.script > Armed Bear Common Lisp 0.18.1 > Java 1.6.0_0 Sun Microsystems Inc. > OpenJDK Client VM > Low-level initialization completed in 1.985 seconds. > Startup completed in 3.591 seconds. > > Caught ERROR while processing --eval option "(load "test- > force.script")": > Failed to find asdf-abcl.lisp in /ebs/test/asdf/tmp/asdf-abcl.abcl. > Using abcl , test-force.script failed > This looks like a failure in ABCL's make-pathname or merge-pathnames mechanism. Mark, can you comment? >> In run-tests.sh I currently use >> export ASDF_OUTPUT_TRANSLATIONS="${asdfdir}:${asdfdir}/tmp/fasls/$ >> (basename >> $command):" > > the problem arises when running run-tests.sh from a web server. > > would it controvert the purpose fo the tests to set it to a single > directory which i know the web server process can use? > Not at all. Make the variable unmodified if it still exists. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The Constitution may not be perfect, but it's a lot better than what we've got!

3 3

[asdf-devel] question for API
by Robert Goldman 24 Mar '10

24 Mar '10

One thing I find myself doing over and over (and I don't think I'm alone in this) in .asd files is to capture a pathname for the directory of the system definition file. This is particularly important when one has code that wants to load data files, in the presence of FASL file relocation (since it means that source code files can't effectively use *load-truename*). Bits of code like this seem like a good candidate for being added to the ASDF API. Any thoughts? R

2 4

[asdf-devel] Enforcing pure *.asd files
by Juan Jose Garcia-Ripoll 24 Mar '10

24 Mar '10

This is an idea that has been long floating in the back of my mind, and was brought back to life by these comments http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf The problem is that many people use *.asd files to do things like building up packages, creating operations, defining methods, etc. That makes it impossible to ship those libraries because the side effects are not recorded in the system itself. So if ECL traverses the system to build a standalone program it will know which sources are required, but those sources may for instance rely on a package that was created in the *.asd definition. My suggestion is a gradual move towards enforcing that *.asd files become mere descriptions of the system and that side effects needed for building and loading are listed in the system itself. - System definitions should be read and recorded by ASDF in pure form, that is as S expressions, with a hash that maps system names to s-expressions. - Instead of using LOAD we use a LOOP and READ. If a form which is not a DEFSYSTEM is found, we have two options: if we enforce strict mode, an error is signaled, otherwise the form is evaluated after emitting a warning. - Warnings could also be emitted when a DEFSYSTEM clause does not match the name of the file, or when more than one such clauses is found. - The system definition should be scanned for a class name and for a keyword option, :asdf-support If the :asdf-support option is found, it should name a file with side effects that are needed for the ASDF definition to be used. The file should be loaded using LOAD. - The original S expression is now parsed and the system definition is created. The warning could be really self-explanatory, stating the following: - Dependencies that are needed for processing the system definition must be listed in :asdf-support - Dependencies that are needed for load/compile-op should be listed in :depends-on I can think on even more elegant ways to do this. For instance having proxy classes, such as proxy-system and proxy-component which are used to store the S-expression for the system and using change-class on these objects to transform them into valid systems and components on demand, that is only when the systems are needed. It should also be possible to write an utility that grovels existing ASDF systems looking for potential problems and suggesting changes. What the solution above does not address is the following sentence from Daniel's comment: As to the "no". Simply doing asdf:find-component may result in side effects, both in the package of interest and in random other packages before it. These side effects include dumping fasls. There are several asd files that force things to load early in order to extend ASDF by defining custom classes." In other words, the side effects in :asdf-support can be really harmful, or costly. However this proposal could help us identify what libraries do have side effects and also help enforce further restrictions in the side effects they may have. I mean, there are many many other ways to do this, but I think you get the idea. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

7 24

[asdf-devel] maintaining the ASDF web site
by Robert Goldman 23 Mar '10

23 Mar '10

OK, I've looked at this, and I'm afraid I am not going to take this on in its current form. If someone else would be so kind as to wrangle the markdown and grok the scripts, that's fine. If after some time, no one else expresses a willingness to do this, then I will try to do some of it, but I hereby put the community on notice: I don't know markdown, and I'm not going to learn markdown. If this is left to me, the markdown will go away, and HTML will gradually take its place. HTML is ugly, annoying, difficult, etc., but it has the immense advantage, to me, that I know it, and I know the toolchain (which is basically emacs + my browser). So there it is --- anyone interested in taking this over? Best, r

2 1

[asdf-devel] Please hands off the manual...
by Robert Goldman 23 Mar '10

23 Mar '10

I would like to move the manual into a newly-created subdirectory per tcr's suggestion. I want to minimize merging issues, so please commit any changes you might have; I will do the directory juggling this afternoon. Thanks! r

1 0

[asdf-devel] Package manipulation [ was ASDF traverse changed behavior? ]
by Juan Jose Garcia-Ripoll 23 Mar '10

23 Mar '10

On Thu, Mar 18, 2010 at 1:36 AM, Robert Goldman <rpgoldman(a)sift.info> wrote: > Is it possible that somehow the compilation of asdf-ecl is recording > some information about the package that is somehow damaged by the > package surgery? > I will dig into that later during the weekend. I think the point is something we discussed long at the ECL mailing list, namely that symbols are NOT created as a compiled file is run. Symbols are constants and as such a compiler is allowed to coalesce all references to symbols in the same compiled file. The problem would thus be the following. The compiler loads the file, it resolves all references to symbols, storing them in the array of constants, including PERFORM. The code is executed. PERFORM is uninterned and a new symbol is created. We reach the DEFMETHOD forms, which now are executed but since they reference the *old* version of the symbol, the method is installed with the wrong name in the wrong generic function. In other words, one can not expect the side effects that operations have in packages work the same for a compiled and a source file. It is just as if you expect that the side effects that aare caused by changing the readtable would also affect the way a cmpiled file behave. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

4 9

[asdf-devel] something in recent commit causes ACL testing to go into an infinite loop
by Robert Goldman 23 Mar '10

23 Mar '10

Now when I run the tests on allegro I get a FILE-INCOMPATIBLE-FASL-ERROR on file3.fasl. ASDF then tries to invoke the ASDF:RETRY restart. Then it gets the FILE-INCOMPATIBLE-FASL-ERROR on file3.fasl. ASDF then tries to invoke the ASDF:RETRY restart. Then .... This happened when I tested with 8.2 after testing on 8.1. When I run this interactively, with the -d option on the command line, I can invoke a restart which recompiles the file in question, and the tests complete successfully (21 of 21 successful). So this suggests that there is a bug in the ASDF:RETRY restart.

2 6

[asdf-devel] How is the website maintained?
by Robert Goldman 23 Mar '10

23 Mar '10

How does one change the website? Is the stuff in the repository still live? Can we just change git contents and have it automagically updated on the website? I have posted some tickets about this because I don't know how the website is updated. I'd knock some of them off if someone would hand me a clue on a silver platter... thanks, r

2 1