asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] [PROPOSAL] Easier configuration, installation, and removal of asdf systems
by Krzysztof Drewniak 20 Nov '10

20 Nov '10

On Sat, 2010-11-20 at 02:10 -0500, Faré wrote: > On 19 November 2010 16:20, Krzysztof Drewniak <krzysdrewniak(a)gmail.com> wrote: > >> 2- It's not clear that anyone would use it. What problem are you solving? > >> How does it help? > >> > > If solves the problem of not having a standard way to "install" a common > > lisp library. See my other reply for details. > > > There is nothing whatsoever to install in a CL library. > FASLs? They vary from implementation to implementation, > and even in a given implementation, depending on > OPTIMIZE settings, *features* and possibly more > (code coverage, grovelling, some lisp-in-lisp compilation > for e.g. continuations, etc.) > > And what the hell do you configuration settings correspond to? > Yet another layer of bureaucracy between the user and > the above-mentionned settings and features? > > > As fetching dependencies is clearly not in scope for asdf, dependencies > > will be checked to see if they are loadable in the beginning of > > install-op, and if they are not present, a helpful error is signalled. > > > What when a dependency is compiled with a different settings, entailing > different semantics for the final "library"? > > >> 4- How do you distinguish between fasls compiled with different options. > >> > > If config.asdf is modified, fasls are recompiled. If two different > > source trees of the same system are installed, they will vertanly not be > > installed in the same place, thuse distinguishing the fasls. > > > That's not the question asked. How do you make sure there is no unwanted > sharing between two "versions" of the fasls for a same library as installed > in the same tree? > > > Also, if you are using different "trees" of libraries, either use > > different :registry files, or don't use these operations. > > > That's not the question asked. If you have different trees, > you don't need to distinguish configurations. > But usually you don't. > > Or what the hell are your "configurations" useful for? > > > To clarify something in advance, config-get does NOT require you to have > > used install-op, you could have done the installation manually. > > > Your whole proposal sounds like more bureaucracy that doesn't actually > help anyone get anything done but adds more work for everyone. > I say emphatically NO to any of it. > > Please provide a use case — we'll tell you how to do without it. > > There are ways that a build system could benefit from understanding > multiple "configurations" of a same tree, but ASDF will never ever > possibly do that, since that would require major refactoring and > breaking backward compatibility. If you're interested in such things, > consider hacking XCVB instead. > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > Big Business has to *sell* the Vietnam War to you. Big Government can just > draft your ass and ship you overseas under threat of imprisonment and/or > death. Now, which one is better again? — rho(a)netdoor.com Never mind. asdf-install already solved most of the problem. -- X-Real-Email-With-Antispam: krzysdrewniak at gmail dot com pgp key on keyserver.ubuntu.com 94F02AE8

1 0

[asdf-devel] How to load a lisp file containing non ascii characters encoded in utf-8?
by pjb＠informatimago.com 20 Nov '10

20 Nov '10

What should be done in abcl to be able to load a lisp file containing non ascii characters encoded in utf-8? CL-USER(3): (load "test.lisp") Error loading /home/pjb/test.lisp at line 2 (offset 46) #<THREAD "interpreter" {74CB02}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xffc3 is malformed while recoding with charset US-ASCII Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): (lisp-implementation-version) "0.20.0" test.lisp is: ------------------------------------------------------------------------ ;; -*- mode:lisp;coding:utf-8 -*- (defvar *a* "é") ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 1

[asdf-devel] There is no way to compile abcl-src-0.22.0
by pjb＠informatimago.com 20 Nov '10

20 Nov '10

Armed Bear Common Lisp --> "0.20.0" Clozure Common Lisp --> "Version 1.6-RC1-r14432M (LinuxX8664)" CLISP --> "2.49 (2010-07-07) (built 3499053122) (memory 3499054130)" CMU Common Lisp --> "19c (19C)" ECL --> "10.7.1" SBCL --> "1.0.19-gentoo" [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.272 seconds. Startup completed in 0.71 seconds. Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.232 seconds. Startup completed in 2.678 seconds. #<THREAD "interpreter" {664310D0}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. C-c C-c [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh ccl ;Compiler warnings for "/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp" : ; In SAFE-NAMESTRING: Unused lexical variable LEN Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.227 seconds. Startup completed in 2.638 seconds. #<THREAD "interpreter" {548997D1}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): Build completed successfully in 7.132986 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh clisp ;; Loading file build-abcl.lisp ... ;; Loaded file build-abcl.lisp ;; Loading file /data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp ... ;; Loaded file /data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp Platform: gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -lreadline -lncurses -ldl -lavcall -lcallback -lsigsegv libgnu_cl.a SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.8 libreadline 6.0 JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.233 seconds. Startup completed in 2.651 seconds. #<THREAD "interpreter" {1137D4A4}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): (quit) Build completed successfully in 11.080321 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh lisp ; Loading #P"/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp". ; In: LAMBDA (PATHNAME) ; (LET* (# #) ; (WHEN # ; #) ; STRING) ; Note: Variable BUILD-ABCL::LEN defined but never used. Platform: Linux ; [GC threshold exceeded with 12,010,408 bytes in use. Commencing GC.] ; [GC completed with 1,294,232 bytes retained and 10,716,176 bytes freed.] ; [GC will next occur when at least 13,294,232 bytes are in use.] JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x0. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC554)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0] (unix:unix-exit) Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x0. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC554)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0] (unix:unix-exit 1) Build completed successfully in 33.49 seconds. ; [pjb@kuiper :0.0 abcl-src-0.22.0]$ [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh ecl ;;; Loading "/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp" ;;; Loading "/data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp" Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Build failed. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh sbcl This is SBCL 1.0.19-gentoo, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; loading system definition from ; /usr/share/common-lisp/systems/asdf-binary-locations.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM ASDF-BINARY-LOCATIONS {1002BFE1B1}> as ; ASDF-BINARY-LOCATIONS ; in: LAMBDA NIL ; (LET* ((STRING (NAMESTRING PATHNAME)) (BUILD-ABCL::LEN (LENGTH STRING))) ; (WHEN (POSITION #\ STRING) ; (SETF STRING ; (CONCATENATE 'STRING "\"" (BUILD-ABCL::COMP STRING #\\) "\""))) ; STRING) ; ; caught STYLE-WARNING: ; The variable LEN is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.231 seconds. Startup completed in 2.547 seconds. #<THREAD "interpreter" {73EB904D}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): Build completed successfully in 7.044 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 1

[asdf-devel] [PROPOSAL] Easier configuration, installation, and removal of asdf systems
by Krzysztof Drewniak 19 Nov '10

19 Nov '10

Rationale: To make asdf easier to use by providing a standard interface for configuring, installing, and removing systems Details: To facilitate easier configuration, installation, and removal of asdf systems, I propose 2 new operations and 2 new functions be added. The operations would be install-op and remove-op, and the functions would be configure and config-of These new components would work as defined below: * New function: configure (defmethod configure (&rest options) ...) configure would, given a plist of options, print them to a file in the current directory (which is assumed to contain the asdf system to configure), for example `config.asdf'. If config.asdf already exists, it should be moved to config.asdf.bak before the mew config.asdf is written. * New operation: install-op install-op would, given a directory in which `configure' had been run, use the options given to configure to install the system. The options involved would be :sources and :registry . :sources is the pathname of a directory which is to be created, after which the contents of the current directory is copied into the directory named by :sources . After the files are copied, all .asd files in :sources are linked into the pathname located in :registry. It is an error to run install-op without first having called configure. * New function config-get (defmethod config-get (system config-key &optional default) ...) config-get will, given a system and config-key retrieve the value of config-key located in the config.asdf file located in the same director as the .asd file of the system (after dereferencing symlinks). This method is meant so that library/program authors can add additional configure options which the library/program can later access (Ex. a graphics library with an optional #d component could instruct users to pass `:3d t' or `:3d nil' depending on whether they want the 3d component. The user's choice would be accessed through config-get). The functions will return 2 values, the primary being the result of the lookup or default if the lookup fails, and a secondary which is T if the lookup succeeded and NIL otherwise. * New operation: remove-op remove-op would undo the operations preformed by install-op, first removing the symlinks in :registry then deleting :sources. Comments, suggestions, questions, etc. are appreciated. Krzysztof Drewniak [P.S. I will not be available between 09/22/2010 and 09/29/2010 due to a vacation resort in Mexico which has an 80% chance of no free Internet] -- X-Real-Email-With-Antispam: krzysdrewniak at gmail dot com pgp key on keyserver.ubuntu.com 94F02AE8

3 2

[asdf-devel] Directly loading "/home/etc/etc/system.asd"
by Theam Yong Chew 09 Nov '10

09 Nov '10

Hi all, Is there a way to load a system directly, leaving everything else (source-registry configuration, *central-registry*, or what not) alone? I hacked up something to do this, (asdf:load-system #P"c:/blah/blah/cl-ppcre-1.2.19/cl-ppcre.asd") so that there's no need to worry about specific versions or setting up paths to a specific library. If the library being loaded depends on other modules, then we return to searching the source-registry as if by typing this before loading our system: (asdf:load-system <lib-depended-upon>) Does asdf already support this? Will such a feature be useful? Yong.

2 1

[asdf-devel] ccl:rebuild-ccl and asdf
by R. Matthew Emerson 08 Nov '10

08 Nov '10

We've gotten a couple of bug reports from users who are having trouble doing (ccl:rebuild-ccl :clean t) when (require 'asdf) is in their init files. http://trac.clozure.com/ccl/ticket/765 http://trac.clozure.com/ccl/ticket/773 While it's undoubtedly best to start up without an init file when you're planning to rebuild the lisp (by using "ccl -n"), I'm wondering if there would be some way to avoid this particular issue involving ASDF. During the process of rebuilding ccl, we compile (but do not load) ccl:tools;asdf.lisp. Perhaps we could simply stop compiling ASDF as part of ccl:rebuild-ccl. That way, the compile-time side effects that seem to be causing the trouble would be avoided.

2 1

[asdf-devel] 2.010.1
by Faré 31 Oct '10

31 Oct '10

I renamed 2.147 into 2.010.1. We were going back and forth in version numbers (according to version-satisfies) between 2.1xx and 2.0xx, and at least that's stopped. We now have quite a few unstable 2.1xx releases in git with the "wrong" order, but presumably the few people who use asdf from git will know to upgrade from git and won't have trouble with it. Maybe I should have been more daring and have used 2.0.10.1, but that would have meant out-of-order versioning amongst stable releases, too, and that would have been more problematic. News: as compared to 2.010, 2.010.1 mostly works fine on GCL 2.7, except that GCL 2.7 has problems with condition handling (at least in the version I have from debian). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Clothes make the man. Naked people have little or no influence on society. — Mark Twain

1 0

[asdf-devel] New ASDF 2.010
by Faré 29 Oct '10

29 Oct '10

I just release ASDF 2.010 (same as 2.146), and I'd like all CL implementation vendors to test it and include it on their platforms so one could universally (require :asdf). As compared to 2.009: * much faster and more ported recursive groveling through directories looking for .asd's (notably fixes issues with ABCL) * portability tweaks for CCL, SCL, CLISP * eagerly error out when trying to use : in portable relative pathname designator strings * have compile-file* heed :output-file keyword * be backward-compatible with client fasl's using ASDF symbols from the obsolete ASDF-UTILITIES package that existed in ASDF2 up till 2.005 * for those who care about internals, in a comment, explanation of do-first vs in-order-to Actively supported and tested by me (on Linux amd64): ccl clisp sbcl ecl allegro abcl scl Supported but untested by me: lispworks (lacking a license), allegromodern, cmucl, any of the previous on windows Known to have many issues: gcl (still largely broken in 2.010, and still doesn't pass all tests in 2.147.) Never replied to my contact attempts: corman These implementations include asdf2 in their release and you can (require :asdf): ccl sbcl ecl abcl scl cmucl These don't yet, but probably should: allegro lispworks clisp gcl [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Be inconsistent — but don't do it all the time. — Unknown

1 0

[asdf-devel] Feature-conditional components
by Faré 24 Oct '10

24 Oct '10

1- ASDF has no such mechanism yet. Many people have asked for it (at least nikodemus, manic12, and myself recently). 2- the feature feature was never working before I fixed and cerror'ed it, and only does conditional *dependency* on another component, that has to independently exist or conditionally exist, for which we have no non-ugly mechanism. 3- the :if-component-dep-fails mechanism may or may not be working well enough to do that right now, but man it's ugly, non-intuitive, non-documented, and gross even if it were documented. 4- the very structure of ASDF objects doesn't allow a clean way of expressing conditionally-included components, and this can't be added as an extension (at least, not unless ASDF is extended to provide a proper API, anyway). Doing anything more sophisticated than #+foo or :if-component-dep-fails is going to be "interesting" and require major work. 5- XCVB has such a mechanism, and I propose that if ASDF is to adopt non-trivial conditionals, we should import XCVB's mini-language for conditionals, if not the rest of it. 6- Hey - why not develop XCVB some more? Like, port it to your favorite platform? I'd need a bit of help to make standalone backends for Windows, including a committed hacker to port relevant parts of IOLib to Windows. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Invent a clever saying, and your name shall live forever. — Anonymous

4 7

[asdf-devel] Error writing some output translation
by Mitch Berkson 18 Oct '10

18 Oct '10

I am encountering the error below when trying to load-system from directory d:/foo/: Error: Failed to MAKE-DIRECTORY file C:\Documents and Settings\mitch\Application Data\common-lisp\cache\lispworks-6.0.1-windows-x86\d\foo\d:\: The filename, directory name, or volume label syntax is incorrect.(123). I am able to load-system systems I have downloaded (e.g., lw-add-ons, cl-pdf) which are in a different directory (d:/lisp/). I have fooled around with a .conf file in the d:/foo/.config/common-lisp/asdf-output-translations.conf.d/ directory but that hasn't helped. I'd appreciate any suggestions. Mitch Berkson

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel