- armedbear-devel - mailman3.common-lisp.net

[Asdf-devel] ASDF 3.1.2 released
by Robert P. Goldman 06 May '14

06 May '14

The release version of ASDF 3.1, version 3.1.2, has finally arrived. It is loaded with bug-fixes, more portability (substantially better support on Windows; several new lisp implementations), better documentation (extensive revisions to the Texinfo manual), and new convenience features such as PACKAGE-INFERRED-SYSTEMs. We urge the maintainers of lisp implementations to move to version 3.1.2 directly, as it is clearly superior to its predecessors. This is especially true if you are currently bundling a pre-release version of ASDF. For a list of changes, see the attached changelog. Special thanks to Dave Cooper and Anton Vodonosov (alphabetically) for testing support. Thanks to all those who have participated in the discussions on ASDF-devel for bug fixes, suggestions, and course corrections. Thanks to Pete Keller for proofreading this announcement; any remaining errors are mine alone. Although he is no longer the lead maintainer, François-René Rideau (Fare), has continued to expend vast amounts of effort on ASDF, and provided invaluable guidance to the code submitted by the rest of us. The latest version of ASDF is available at the project website: http://common-lisp.net/project/asdf/ Robert P. Goldman ASDF maintainer-in-chief _______________________________________________ Asdf-devel mailing list Asdf-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

1 0

[Armedbear-devel] ABCL 1.3.1 testgrid results - no regressions
by Anton Vodonosov 01 May '14

01 May '14

Hi, I have tested ABCL 1.3.1, no regressions comparing to 1.3.0 and 1.2.1: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff23.html http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff24.html _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] Fixing #352 / JSS fails to introspect foo(long) methods
by olof＠macrolet.net 17 Apr '14

17 Apr '14

Hi, I've been trying to improve my idea in [1]. Attached is a slightly different patch, still with the same general idea though. I've added two tests, however I'd still like to do a bit more than that, especially testing the correct resolution of methods, i.e. Java::isMoreSpecialized. My current understanding is that with this patch all possible methods (like for the attached class DummyMethods) are found, but that isMoreSpecialized doesn't actually do what its name implies, namely finding the most specialized method. That is, I'm assuming that JCALL is supposed to use the (exact) same kind of method resolution as Java (if no method signature is given)? Additionally I actually wanted to add DummyMethods for testing from java-tests.lisp, but didn't work out for now. Best regards, Olof [1]: http://abcl.org/trac/ticket/352 _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 2

[Armedbear-devel] PROBE-DIRECTORY borks on wildcard character
by Faré 14 Apr '14

14 Apr '14

EXTENSIONS:PROBE-DIRECTORY fails when the directory name has wildcard characters See: https://bugs.launchpad.net/asdf/+bug/1307571 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Meta is Better. Anything you can do, I can do Meta. — Patrick Logan _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[armedbear-devel] ASDF-JAR vs ASDF3 deployment support
by Erik Huelsmann 04 Apr '13

04 Apr '13

Hi all, Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and their dependencies in JARs. As it turns out, the solution chosen has some problems with correctly packaging ASDs for systems which use the #. reader macro. As an example: bordeaux-threads uses a version.lisp-sexp file to canonically define the version number and the system definition reads that file in a #. form. However, this file isn't packaged because it's not part of the file listing in the system definition. This means asdf can't load the definition after deployment. With the advent of ASDF3, its developers have created infrastructure to combine fasls of a single system and even fasls of a system and all its dependencies into a single large combined FASL. Among others, this new infrastructure does not run into the issue ASDF-JAR is running into. While not completely equivalent to the JAR solution, using this infrastructure would help us a huge step along that way of getting better deployment. My current thinking is that if the single-packed-FASL needs to end up as a jar, we can work on that as a next step. The first step to take would be to create "concatenate fasls" functionality, which would do the following: * Detect all the file entries in all the passed-in fasls * Create a new output zip file with directories for each fasl being packed, populated with the files and directories of that fasl * create a toplevel ._ file which loads the sub-fasls' ._ files Comments? Bye, Erik.

5 8

[armedbear-devel] REMOVE CACHES: r14460 changes FASL entry point name
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi all, Commits between r14456 and r14460 change the FASL entry point name. Everybody tracking trunk will need to blow their caches away. Bye, Erik.

1 0

[armedbear-devel] Patch for ASDF2.26.32 to support concatenated fasls for ABCL
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! In order for these commands to generate a fasl per ASDF system, I had to apply the patch below to ASDF. $ ./abcl CL-USER(1): :ld c:/users/erik/quicklisp/setup CL-USER(2): (ql:quickload :bordeaux-threads) CL-USER(3): (asdf:oos 'asdf:binary-op :bordeax-threads) The commands above work with current trunk (r14460) and produces 2 concatenated fasls in my cache directory: 1 for alexandria and 1 for bordeaux-threads. This patch is required (also attached, to prevent line wrapping): diff --git a/bundle.lisp b/bundle.lisp index 568f894..24fbf90 100644 --- a/bundle.lisp +++ b/bundle.lisp @@ -185,7 +185,7 @@ (or #+ecl (or (equalp type (compile-file-type :type :object)) (equalp type (compile-file-type :type :static-library))) #+mkcl (equalp type (compile-file-type :fasl-p nil)) - #+(or allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) + #+(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) (defgeneric* (trivial-system-p) (component)) diff --git a/uiop/lisp-build.lisp b/uiop/lisp-build.lisp index e2e376d..4b7e819 100644 --- a/uiop/lisp-build.lisp +++ b/uiop/lisp-build.lisp @@ -669,11 +669,12 @@ it will filter them appropriately." ;;; Links FASLs together (with-upgradability () (defun combine-fasls (inputs output) - #-(or allegro clisp clozure cmu lispworks sbcl scl xcl) + #-(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (error "~A does not support ~S~%inputs ~S~%output ~S" (implementation-type) 'combine-fasls inputs output) #+clozure (ccl:fasl-concatenate output inputs :if-exists :supersede) #+(or allegro clisp cmu sbcl scl xcl) (concatenate-files inputs output) + #+abcl (sys:concatenate-fasls inputs output) #+lispworks (let (fasls) (unwind-protect

1 0

[armedbear-devel] Support for concatenated fasls
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF: Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip. My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._". How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation? Bye, Erik.

2 2

[armedbear-devel] bug in format ~f
by Carlos Ungil 03 Apr '13

03 Apr '13

Hello, comparing output from different implementations I've found the following (minor) bug: > (format t "~,2f" 0.999) 1.0 ;; should be 1.00 I think there is a problem here as well: > (format t "~5f" 0.00000001) .0000 ;; should print " 0.0" Only SBCL gives the output I would expect, most implementations print ".0000" as ABCL does. From the HyperSpec 22.3.3.1: "If the parameter d is omitted, then there is no constraint on the number of digits to appear after the decimal point. A value is chosen for d in such a way that as many digits as possible may be printed subject to the width constraint imposed by the parameter w and the constraint that ___no trailing zero digits may appear in the fraction, except that if the fraction to be printed is zero, then a single zero digit should appear after the decimal point___ if permitted by the width constraint." This problem appears only when the value is close to zero, otherwise the output is fine: > (format t "~5f" 1.00000001) 1.0 ;; OK I guess those zero digits are not considered trailing because there is no non-zero digit before but I think the specification still requires the fraction to be printed with a single zero digit after the decimal point. Regards, Carlos Ungil

2 1

[armedbear-devel] Other findings (was Re: Questions about r14452 (Fix cl-cont))
by Erik Huelsmann 02 Apr '13

02 Apr '13

> Well, to some extent I can see your problem. Indeed there seem to be no > slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The > layoutFuncallableStandardClass is what confused me, but that's indeed the > layout of the metaclass. > > So, you're correct that the fix works by accident. The solution should be > to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. > That slot can contain the name of the object (ie function) for which the > item is defined. In that case, we should probably remove the direct slot > MOP::NAME on the standard generic function, since it's already defined on > the superclass if we decide to do that. > > While studying this problem using DESCRIBE, it seems our current implementation dispatches (DESCRIBE (MAKE-INSTANCE 'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the STANDARD-OBJECT way... Yet more to investigate... Bye, Erik.

2 2