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

[armedbear-devel] IRONCLAD cannot be compiled on ABCL now
by Chun Tian (binghe) 08 Jul '11

08 Jul '11

Hi, ABCL developers The crypto library IRONCLAD [1] cannot be compiled on latest ABCL any more, I got following errors when compiling one of its source file. To show the core issue, create a lisp file with following single line and compile it, you'll see the same error: (defconstant a #.(make-array '(8 256) :element-type '(unsigned-byte 32) :initial-element 0)) I don't know how to fix this, have to ask help from ABCL maintainers. Regards, Chun Tian (binghe) [1] http://method-combination.net/lisp/ironclad/ -- Original error outputs: ; Compiling /Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp ... ; (IN-PACKAGE :CRYPTO) ; (DEFTYPE WHIRLPOOL-REGS ...) ; (DEFUN INITIAL-WHIRLPOOL-REGS ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-HASH-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-K-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-STATE-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-L-OFFSET+ ...) ; (DEFCONST +PRISTINE-WHIRLPOOL-REGISTERS+ ...) ; (DEFUN WHIRLPOOLREGS-DIGEST ...) ; (DEFCONSTANT +WHIRLPOOL-ROUNDS+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +RC+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +C-EVEN+ ...) #<THREAD "interpreter" {78D08435}>: Debugger invoked on condition of type PRINT-NOT-READABLE #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> cannot be printed readably. Restarts: 0: TRY-RECOMPILING Try recompiling whirlpool 1: RETRY Retry compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool">. 2: ACCEPT Continue, treating compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool"> as having been successful. 3: TOP-LEVEL Return to top level. [1] CRYPTO(9): :bt 20 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<PRINT-NOT-READABLE {6EA518B6}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:373) 3: org.armedbear.lisp.SimpleArray_UnsignedByte32.writeToString(SimpleArray_UnsignedByte32.java:287) 4: org.armedbear.lisp.Primitives$pf__stream_output_object.execute(Primitives.java:887) 5: (SYSTEM:%STREAM-OUTPUT-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 6: (SYSTEM::DUMP-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 7: (SYSTEM::DUMP-CONS (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 8: (SYSTEM::DUMP-OBJECT (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 9: (SYSTEM::DUMP-CONS (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 10: (SYSTEM::DUMP-OBJECT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 11: (SYSTEM:DUMP-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 12: (SYSTEM::OUTPUT-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 13: (SYSTEM::PROCESS-DEFCONSTANT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 14: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}> NIL) 15: (SYSTEM::PROCESS-TOPLEVEL-FORM (IRONCLAD::DEFCONST IRONCLAD::+C-EVEN+ #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}> NIL) 16: (#<FUNCTION {1F97D330}>) 17: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1F97D330}>) 18: (JVM::%WITH-COMPILATION-UNIT #<FUNCTION {28AA0484}>) 19: (COMPILE-FILE #P"/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/ASDF-TMP-whirlpool.abcl" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.abcl")

4 8

[armedbear-devel] ABCL Usage Problem
by Nishant Trivedi 27 Jun '11

27 Jun '11

Hi All, We are trying to use ABCL for a project which requires a system coded in LISP to talk to another coded in JAVA. We are facing some issues and I would appreciate any help anyone can afford. For this project, I am using Windows 7 platform. I downloaded and built ABCL jar on my machine using ANT. I also setup the required system variables (JAVA_HOME, PATH and CLASSPATH). However, when I try to run the example code to call Java from Lisp ( as described at http://common-lisp.net/project/armedbear/doc/abcl-user.html) I keep getting the following error in ABCL: #<THREAD "interpreter" {13BC30A}>: Debugger invoked on condition of type ERROR Class not found: Main I have also manually compiled the Main.java file and placed the ".class" in the same folder as the lisp file that calls it. I am able to get built-in Java classes like "int". At this point I am stuck and would appreciate if anyone can help me out with this issue. Thanks in advance. Regards, Nishant.

2 1

[armedbear-devel] MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-VALUE conceptual problem
by Mark Evenson 22 Jun '11

22 Jun '11

Today, I spent a bit of time trying to figure out a way to efficiently compute message digest for Quicklisp. After confirming that java.security.MessageDigest implements the required digests, I noticed we didn't have a way to easily get at the underlying Java byte[] array in (SIMPLE-VECTOR (UNSIGNED-BYTE 8)). So, I patched the underlying Java code as attached, and wrote the following routine: (defun sha-256 (path) (let ((buffer (make-array 8192 :element-type '(unsigned-byte 8)) (digest (jstatic "getInstance" "java.security.MessageDigest" "SHA-256"))) (with-open-file (in path :element-type '(unsigned-byte 8)) (loop :for bytes = (read-sequence buffer in) :while (plusp bytes) :do (jcall-raw "update" digest (make-immediate-object buffer) 0 bytes)) (jcall "digest" digest))))) But then I noticed that MAKE-IMMEDIATE-OBJECT calls JOBJECT-LISP-VALUE which makes no conceptual sense. The doc for MAKE-IMMEDIATE-OBJECT reads "[a]ttempts to coerce a given Lisp object into a java-object" while the doc JOBJECT-LISP-VALUE reads "Attempts to coerce JAVA-OBJECT into a Lisp object". This seems wrong here, but I don't understand how exactly. I think we need to distinguish three types of values here: JAVA-OBJECT, LispObject, and the "raw" value of the Java. How should we really structure our Java FFI here? With my patch, for an underlying lisp value of type (SIMPLE-VECTOR (UNSIGNED-BYTE 8)), both MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-OBJECT return the byte[] array. I would think that MAKE-IMMEDIATE-OBJECT should just do this, which JOBJECT-LISP-OBJECT should .... return an error if its argument isn't of type JAVA-OBJECT? I don't know. I am confused. Can someone help me understand the right way forward here? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

[armedbear-devel] ASDF-JAR contrib packages systems in jar files
by Mark Evenson 20 Jun '11

20 Jun '11

The ASDF-JAR contrib now packages up ASDF systems in jar archives. Comments and/or additional needs from this system are welcome. From the documentation: ASDF-JAR ======== Mark Evenson Created: 20-JUN-2011 Modified: 20-JUN-2011 ASDF-JAR provides a system for packaging ASDF systems into jar archives for ABCL. Given a running ABCL image with loadable ASDF systems the code in this package will recursively package all the required source and fasls in a jar archive . To install ASDF systems, [Quicklisp]() is probably the best contemporary solution, although a version of ASDF-INSTALL is also packaged in ABCL contribs. [Quicklisp]: http://www.quicklisp.org Once the requisite ASDF systems have been installed, ensure that this contrib is loaded via CL-USER) (require :abcl-contrib) CL-USER> (require :asdf-jar) Then, to say package the Perl regular expression system ("CL-PPCRE"), one uses the ASDF-JAR:PACKAGE as follows: CL-USER> (asdf-jar:package :cl-ppcre) ; Loading #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" ... ; Loaded #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" (0.029 seconds) Packaging ASDF definition of #<ASDF:SYSTEM "cl-ppcre"> as /var/tmp/cl-ppcre-all-2.0.3.jar. Packaging contents in /var/tmp/cl-ppcre-all-2.0.3.jar with recursive dependencies. #P"/var/tmp/cl-ppcre-all-2.0.3.jar" The resulting jar contains all source and fasls required to run the ASDF system including any transitive ASDF dependencies. Each asdf system is packaged under its own top level directory within the jar archive. The jar archive itself is numbered with the version of the system that was specified in the packaging. To load the system from the jar one needs to add the ASDF file locations to the ASDF *CENTRAL-REGISTRY*. If one wishes to load the fasls from the jar alone, one needs to tell ASDF not to override its output translation rules. The function ASDF-JAR:ADD-TO-JAR does both of these options serving as the basis for customized load strategies tailored to end-user deployment needs. So, after CL-USER> (asdf-jar:add-to-asdf "/var/tmp/cl-ppcre-all-2.0.3.jar") a subsequent CL-USER> (asdf:load-system :cl-ppcre) should load the ASDF system from the jar. Setting CL:*LOAD-VERBOSE* will allow one to verify that the subsequent load is indeed coming from the jar. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-cvs] r13338 - trunk/abcl/doc/manual
by Ville Voutilainen 18 Jun '11

18 Jun '11

On 17 June 2011 10:01, <mevenson(a)common-lisp.net> wrote: > Separate content/presentation rules via LaTeX include directives. > Properly use the as yet unwritten \code{} markup. The listings-package might be useful for source code listings. At any rate, writing a macro for it manually would be just wrong. :) There are existing packages for that, let's use them, ok? On the choice of LaTeX, +1 high praise, I love it, although I've never used it much to generate html with proper links/frames and all. The little dabbling I've done seemed non-problematic, though, and the output on non-html in TeX has always been superior to anything I've tried.

2 1

Re: [armedbear-devel] [quicklisp] The "kitchen" behind quicklisp repositories
by Mark Evenson 14 Jun '11

14 Jun '11

On 6/10/11 13:52 , Zach Beane wrote: […] > I'm not exactly sure what I will need, yet, but certainly if it was easy > for ABCL to provide a fast way to compute the SHA1/SHA256/SHA512 digest > of disk files, that would be helpful. […] Attached please find code for ABCL which directly manipulates the underlying JVM APIs for fast I/O ("NIO") and uses the built-in MessageDigest computation. Is this sufficient for your needs? ABCL needs to look at how to make such things happen natively in Lisp a lot faster, but that won't be happening in the near future. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] Using print and read together.
by Ted Kosan 13 Jun '11

13 Jun '11

Hello, I am currently working through the "Land of Lisp" book by Conrad Barski and I am using ABCL to run all of the code in the book. In the following code, the prompt that is printed by 'print' is not seen until after 'read' returns: (defun add-five() (print "Pleaser enter a number:") (let ((num (read))) (print "When I add five I get") (print (+ num 5)))) Is it possible to configure ABCL to have the output from 'print' be visible immediately so that it can be used to prompt the user to input some information? Thanks in advance, Ted

3 2

[armedbear-devel] ASDF 2.016 released
by Faré 09 Jun '11

09 Jun '11

Dear Lisp implementors, below is the announcement for ASDF 2.016, as posted on the asdf-announce mailing-list, also accessible via its gmane mirror gmane.lisp.asdf.announce. Please have me take your list off my forwarding aliases if unappropriate. Can you upgrade your implementation to ship with the latest ASDF? Thanks! If you're still using 2.015 (or something even older), there have been many bug fixes, robustness, portability and upgradability enhancements and a few features implemented since. We recommend that you keep (require :asdf) working as well as (require "asdf"). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Consider this: the first hole ever dug on the moon by a man-made machine is now done. It is the most expensive hole in the history of the human race. Now, what does that mean? How do we know whether this is one of man's noblest achievements or if it is a game being played by a small group of lunatics for their own amusement — at our expense?" — Neil Postman, "Teaching as a Subversive Activity" ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 7 June 2011 20:30 Subject: ASDF 2.016 released To: asdf-announce(a)common-lisp.net Cc: ASDF-devel <asdf-devel(a)common-lisp.net> Dear CL users, I released ASDF 2.015.12 as 2.016. Please test, and upon success update your implementations and lisp distributions. Since 2.015, we have the following improvements: * Portability: Fixes for ECL, RMCL. Tweaks for CLISP. Improvements to Windows configuration, notably for LispWorks. * Fix to load-source-op (broken in 2.014.13 - oops). * Avoid infinite loops in defsystem in cases of bad interference between quicklisp and your source-registry. * Small fixes regarding upgrade, compile-file* :output-file. * Make defsystem-depends-on actually useful by allowing a system thus depended on to define the class of the system depending on it. The XCVB bridge notably relies on this feature. * Some documentation updates. Notably, for the sake of CLISP, (require "asdf") is the new canonical way to load ASDF, instead of (require :asdf). Sigh. * Better tests, notably wrt hot upgrade. Happy hacking! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American diplomat to the Russian: "My country too is free: in the USA too anyone may freely publish the dirty little secrets of president Medvedev!"

2 3

[armedbear-devel] Patch to get ABCL working with TRIVIAL-GARBAGE
by Mark Evenson 07 Jun '11

07 Jun '11

Thanks to Erik's recent work to support both object finalizers and weak reference, and my own recent implementation of weak hash tables, ABCL as of [r13310][] now supports [trivial-garbage][] with the [attached patch][trivial-garbage-20101006-darcs-abcl-20110607a.diff]. [r13310]: http://trac.common-lisp.net/armedbear/changeset/13310 [trivial-garbage]: http://www.cliki.net/trivial-garbage [trivial-garbage-20101006-darcs-abcl-20110607a.diff]: http://detroit.slack.net/~evenson/abcl/trivial-garbage-20101006-darcs-abcl-… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #150: MAKE-PATHNAME ignores version in :DEFAULTS
by Erik Huelsmann 04 Jun '11

04 Jun '11

Same commit-simulation, please ignore. On Sat, Jun 4, 2011 at 11:25 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #150: MAKE-PATHNAME ignores version in :DEFAULTS > -----------------------+---------------------------------------------------- > Reporter: mevenson | Owner: mevenson > Type: defect | Status: closed > Priority: minor | Milestone: 0.26 > Component: java | Version: 0.24 > Resolution: fixed | Keywords: pathname asdf > -----------------------+---------------------------------------------------- > > Comment(by mevenson): > > (In [13294]) Fix #150: MAKE-PATHNAME ignores version in :DEFAULTS. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/150#comment:8> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0