September 2005 - cl-debian@common-lisp.net

[cl-debian] Providing FASL version in SBCL and Clisp package control file
by René van Bevern 04 Sep '05

04 Sep '05

Hello CL-Debian, hello Will (attached is a patch for you). for the next version of dh-lisp, the Lisp debhelper, I plan it to find precompiled FASL files in the package and automatically add a dependency to the CL implementation that is required to load them. But the following is not just a requirement for dh-lisp but is needed if packages want to contain precompiled FASLs. To prevent such a package with precompiled lisp to end up in a stable release without the appropriate implementation, the package has to depend on a specific version of the implementation that is able to read the FASL format. CMUCL: This is easy and needs no modification, as the FASL format is available in the package version. CMUCL 19B has the FASL versions 19B also SBCL: Changes FASL file versions very often still. I sent a patch to the darcs repository of Peter that adds a "Provides: sbcl-fasl-loader-XX" to debian/control, XX being the fasl file version which is determined at build time Clisp: It is the same practice as with SBCL. As Clisp unfortunately has no repository on cl-debian.alioth.debian.org ;-), I attach a patch to this message. GCL: No idea, really, I never touched it and do not know if it breaks binary compatibility now and then. ;-) Depending on foo-fasl-loader-XX will prevent a fasl-providing package from entering testing/stable before the implementation version that provides foo-fasl-loader-XX. It will however not prevent foo-fasl-loader-XX+1 from entering testing, even though packages in testing depend on foo-fasl-loader-XX. But it enables the maintainer to see, that his package is uninstallable in testing, easily, and that the package needs a rebuild to work with a new version of CMUCL/SBCL/Clisp. After all, this shall prevent binary-incompatible packages silently being around in a stable release. Regards, René

1 0

[cl-debian] Bug#326092: cl-acl-compat: With SBCL PROCESS-ACTIVE-P does not work with non running threads.
by Kim Minh Kaplan 01 Sep '05

01 Sep '05

Package: cl-acl-compat Version: 1.2.42+cvs.2005.08.05-1 Severity: normal Tags: patch Running SBCL and calling PROCESS-ACTIVE-P on a process that has not yet been started in a thread signals an error. Here is an example session: $ sbcl This is SBCL 0.9.3.36, 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. * (clc:clc-require :acl-compat) STYLE-WARNING: redefining INPUT-FILES (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining OUTPUT-FILES (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining PERFORM :AFTER (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining OUTPUT-FILES (COMPILE-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (COMPILE-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (LOAD-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (LOAD-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: implicitly creating new generic function URI-P STYLE-WARNING: implicitly creating new generic function URI-PARSED-PATH STYLE-WARNING: implicitly creating new generic function (SETF URI-PARSED-PATH) STYLE-WARNING: implicitly creating new generic function URI STYLE-WARNING: implicitly creating new generic function MERGE-URIS STYLE-WARNING: implicitly creating new generic function ENOUGH-URI STYLE-WARNING: implicitly creating new generic function INTERN-URI COMMON-LISP:STYLE-WARNING: Couldn't grovel for SIGEMT (unknown to the C compiler). COMMON-LISP:STYLE-WARNING: Couldn't grovel for SIGINFO (unknown to the C compiler). COMMON-LISP:STYLE-WARNING: Couldn't grovel for O_NOFOLLOW (unknown to the C compiler). COMMON-LISP:STYLE-WARNING: Couldn't grovel for O_DIRECTORY (unknown to the C compiler). COMMON-LISP:STYLE-WARNING: Couldn't grovel for O_DIRECT (unknown to the C compiler). COMMON-LISP:STYLE-WARNING: Couldn't grovel for O_LARGEFILE (unknown to the C compiler). ;;; Please wait, recompiling library... STYLE-WARNING: implicitly creating new generic function RECEIVE-FROM STYLE-WARNING: implicitly creating new generic function SEND-TO T * (acl-mp:process-active-p (acl-mp:make-process)) debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" {9003221}>: The value NIL is not of type SB-THREAD:THREAD. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-THREAD::THREAD-STATE NIL) 0] And here is a trivial fix. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages cl-acl-compat depends on: ii cl-ppcre 1.2.11-1 Portable Regular Express Library f ii cl-puri 1.3.1.2-1 Common Lisp Portable URI Library ii common-lisp-controller 4.16 This is a Common Lisp source and c cl-acl-compat recommends no packages. -- no debconf information

1 0

[cl-debian] Re: clc, asdf-install, slime, fasl paths, etc.
by Faré 01 Sep '05

01 Sep '05

Dear Peter, dear cl-debian'ers concerning common-lisp-controller, there's one function of it that I'd like to be more extensible: (defmethod asdf:output-files :around ((op asdf:operation) (c asdf:component)) "Method to rewrite output files to fasl-path" (let ((orig (call-next-method))) (cond ((beneath-source-path-p c) (mapcar #'source-path-to-fasl-path orig)) (t orig)))) In my script cl-launch.sh < http://www.cliki.net/cl-launch >, I reuse the same trick, but clisp made me realize I was overriding your method rather than composing with it. Thus, I think we should rather have (1) a defun for the path translation, so it can be reused in other contexts (?), (2) an extensible list of path translations that is looked up by said function, so I can extend it. Also, it looks like you could use (getenv "LOGNAME") instead of HOME, to choose your cache directory. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The only Real Programming Language is that in which the Universe was specified, God being the only Real Programmer (I thought God was an integer???). Hey! I would like the source code for the Universe. Let's demand that God make it free software! (Actually, it is: everyone has the _right_ to understand how the universe works; opportunity is of course a different matter) On 17/08/05, Faré <fahree(a)gmail.com> wrote: > Hello, CL-debian'ers. > > I'm a new subscriber here. > > I understand there are many concerns with having a fasl cache under > $HOME. However, there are times when this is not an option, and it > would be nice to have some semi-standard packaging system for CL that > supported but did not require system administrator access and/or that > could be shared between many machines with same architecture. > > * It is evil to have lots of differently named cache directories under > $HOME, that clutter backups (and/or prevent them from nicely fitting > in your favorite media). Having everything under ~/.cache/lisp-fasl/ > or ~/.lisp/cache/fasl/ should help. This would be the equivalent of > the current /var/cache/common-lisp-controller/$USERNAME/ > > * Since a same implementation (sbcl, ecl, clisp, etc.) can have many > variants (architectures, fasl or source versions), a proper cache > subdirectory should distinguish between them. c-l-c could (optionally) > rm -rf the global (and user?) cache directories when an implementation > package is removed. > > * It would be nice to semi-standardize a string to name the fasl > format -- and encourage implementations to provide a simple interface > to such a string, falling back to some gross hack such as the one used > by SLIME to generate its unique-directory-name. Be careful to make > this interface user-overridable, so that the user may differentiate > things that look the same but are not. For instance have it be a > variable impl-ext:*fasl-format-name* that the user could set in an > initialization file or command-line argument. > > > I could also build in a hook into clc to allow moving the cache > > directory. Slime could then instruct clc to use the same directory. > That would be nice. > > > You mean from user-homedir-pathname? We just use that as a method to > > make $USER unique. > Several users may have the same $HOME -- it's a user variable that can > be set to anything, and the administrator might share paths in > /etc/passwd, too. It would be better to use usernames from > getpwuid(getuid()) -- maybe let the shell script wrapper do that if > it's too hard to obtain from within all the various lisp > implementations. > > > asdf is only well-described for sbcl, that is one of reasons I make clc. > > I did not place the fasls in $HOME because I wanted to make life easier > > for administrators, and /var/cache normally is on the backup exclusion > > list already :-) > > >> Maybe we can think of something that would unify what happens for user > >> installations for slime, c-l-c and asdf-install? > > > > Well. I fear we have a fundamental difference in option: I do not think > > having fasls in (or beneath) the homedirectory is a good idea. > > > I think it's better to have a system cache, too. Sometimes this isn't > an option. Or sometimes, you want to share that cache between > machines. In any case, configurability would be nice, here. > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > Wir Mathematiker sind alle ein bisschen meschugge. > (We mathematicans are all a bit crazy). -- Lev Landau

2 4