armedbear-devel

armedbear-devel@common-lisp.net

1202 discussions

[armedbear-devel] abcl-1.0 -- The Manual
by Mark Evenson 23 Sep '11

23 Sep '11

We have always informally answered the question as to when ABCL would deserve a 1.0 release number when it was a conforming ANSI implementation. Since we are more or less ANSI complete at this point from a feature standpoint with the recent implementation of the long form of DEFINE-METHOD-COMBINATION, it makes some sense to push for an ABCL 1.0 release which we could potentially announce at ECLM 2011, since Erik, Alessio, and I will attend. The [CLHS outlines the requirements for conforming implementation][1] as including […] 1.5.1.2 Documentation of Implementation-Dependent Features 1.5.1.3 Documentation of Extensions […] 1.5.1.5 Conformance Statement […] [1]: http://www.lispworks.com/documentation/HyperSpec/Body/01_ea.htm To this end, I started an [ABCL manual written in LaTex][2]. With LaTeX we have the ability to include diagrams rather easily, something that despite Texinfo's claims to the contrary, I think should not be prohibited in documentation. I have not found a suitable LaTex2HTML translator (although many exist), but would probably approach this as a problem to be addressed after we produce an initial manual. [2]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/manual To render the manual in PDF, install [TeX Live 2011][3], and simply issue cmd$ pdflatex abcl.tex in a the manual directory. [3]: http://www.tug.org/texlive/ The structure of the manual is roughly in place, from which I have been cribbing ideas from the [SBCL][4] and [CCL][5] manuals [4]: http://www.sbcl.org/manual/ [5]: http://ccl.clozure.com/ccl-documentation.html but have still not committed to a final structure. I have started to create LaTeX macros in 'abcl.sty' to create an environment in which contributors can work on the manual without necessarily understanding that much of LaTeX by creating a semantics/presentation layer. Currently, this mostly consists of ways of marking up text as being Lisp, Java, or Shell source code. I plan to at least to produce a method to indicate that text refers to a given Lisp symbol in a given package so a reasonable cross referencing system can produce an index and page references. A tension exists in the current effort between being a manual, and a tutorial with examples. I would propose we concentrate on the manual aspects, while allowing inclusion of examples as the existing text gives a pretty reasonable introduction to extending ABCL via Java that would be a shame to lose. But I could be persuaded to remove or move to an appendix if we wanted to emphasize concision. Since TeX easily allows comments in documents with '%' characters, one can find various notes and ideas present in the current document to bring one up to speed on what I have in mind. I intend to document the JAVA, EXTENSIONS, and SYSTEM packages by adding doctstrings to out implementation for all exported symbols, following the convention that there should be a short synopsis statement for the function as the first sentence, followed by a newline, followed by more explicit text. I intend to write a Lisp tool that "scrapes" these docstrings from a live ABCL process, transforming into the appropriate LaTeX source which we would then include in the manual. This isn't sufficient but necessary in my opinion to meet the criteria of documenting implementation dependent features. If someone wished to help, getting our exported docstrings in order would be a task somewhat orthogonal to the production of the manual. So, I would invite potential contributors to the manual to look at the source, build the PDF version, and consider what sections they would like to tackle. Then we can divide this manual up into sections by file, so people can work somewhat in isolation. As an informal deadline, I think we should have a plan in place by October 1 to have a chance of finishing things by ECLM 2011. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] FASL Format bump on trunk
by Erik Huelsmann 20 Sep '11

20 Sep '11

Everybody running off trunk should be warned that I just updated the FASL format number: the fixes for CLOSURE-HTML changed the format in a backward incompatible way. The new format number is 38, the old one 37. Format bumps are relatively rare and format 37 has been in use for quite a while now. I'm sorry for the inconvenience caused, if any. Bye, Erik.

1 0

Re: [armedbear-devel] SVN r13600 breaks clean trunk Build
by ehuels＠gmail.com 20 Sep '11

20 Sep '11

Hi Mark, You fixed it already, I see. Sorry about the breakage. Which library fails next? :-) bye, Erik. Sent from my Nokia phone -----Original Message----- From: Mark Evenson Sent: 20/09/2011, 10:00 To: Armed Bear Subject: [armedbear-devel] SVN r13600 breaks clean trunk Build Unfortunately, the recent commit to fix the compilation of circularity in FASL has broken the compilation of jvm.lisp when building from scratch. It is not immediately obvious to me how to fix this, as it seems to involve the forms emitted by the compiler. … ; Compiling /home/evenson/work/abcl/src/org/armedbear/lisp/jvm.lisp ... ; (IN-PACKAGE "JVM") ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp (0.0010 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp (0.074 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp (0.095 seconds) ; (DEFVAR *CLOSURE-VARIABLES* ...) ; (DEFVAR *ENABLE-DFORMAT* ...) ; (DEFVAR *CALLBACKS* ...) ; (DECLAIM (INLINE INVOKE-CALLBACKS)) ; (DEFUN INVOKE-CALLBACKS ...) ; (DEFMACRO DFORMAT ...) ; (DECLAIM (INLINE U2 ...)) ; (DEFKNOWN U2 ...) ; (DEFUN U2 ...) ; (DEFKNOWN S1 ...) ; (DEFUN S1 ...) ; (DEFKNOWN S2 ...) ; (DEFUN S2 ...) ; (DEFMACRO WITH-SAVED-COMPILER-POLICY ...) ; (DEFVAR *COMPILER-DEBUG* ...) ; (DEFVAR *POOL* ...) ; (DEFVAR *STATIC-CODE* ...) ; (DEFVAR *CLASS-FILE* ...) ; (DEFVAR *EXTERNALIZED-OBJECTS* ...) ; (DEFVAR *DECLARED-FUNCTIONS* ...) ; (DEFSTRUCT (ABCL-CLASS-FILE # ...) ...) ; (DEFUN CLASS-NAME-FROM-FILESPEC ...) ; (DEFUN MAKE-UNIQUE-CLASS-NAME ...) 69.461 seconds real time 150877519 cons cells PROGRAM-ERROR: Wrong number of arguments for #<DUMP-OBJECT {1BE20C}>. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." _______________________________________________ armedbear-devel mailing list armedbear-devel(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[armedbear-devel] SVN r13600 breaks clean trunk Build
by Mark Evenson 20 Sep '11

20 Sep '11

Unfortunately, the recent commit to fix the compilation of circularity in FASL has broken the compilation of jvm.lisp when building from scratch. It is not immediately obvious to me how to fix this, as it seems to involve the forms emitted by the compiler. … ; Compiling /home/evenson/work/abcl/src/org/armedbear/lisp/jvm.lisp ... ; (IN-PACKAGE "JVM") ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp (0.0010 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp (0.074 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp (0.095 seconds) ; (DEFVAR *CLOSURE-VARIABLES* ...) ; (DEFVAR *ENABLE-DFORMAT* ...) ; (DEFVAR *CALLBACKS* ...) ; (DECLAIM (INLINE INVOKE-CALLBACKS)) ; (DEFUN INVOKE-CALLBACKS ...) ; (DEFMACRO DFORMAT ...) ; (DECLAIM (INLINE U2 ...)) ; (DEFKNOWN U2 ...) ; (DEFUN U2 ...) ; (DEFKNOWN S1 ...) ; (DEFUN S1 ...) ; (DEFKNOWN S2 ...) ; (DEFUN S2 ...) ; (DEFMACRO WITH-SAVED-COMPILER-POLICY ...) ; (DEFVAR *COMPILER-DEBUG* ...) ; (DEFVAR *POOL* ...) ; (DEFVAR *STATIC-CODE* ...) ; (DEFVAR *CLASS-FILE* ...) ; (DEFVAR *EXTERNALIZED-OBJECTS* ...) ; (DEFVAR *DECLARED-FUNCTIONS* ...) ; (DEFSTRUCT (ABCL-CLASS-FILE # ...) ...) ; (DEFUN CLASS-NAME-FROM-FILESPEC ...) ; (DEFUN MAKE-UNIQUE-CLASS-NAME ...) 69.461 seconds real time 150877519 cons cells PROGRAM-ERROR: Wrong number of arguments for #<DUMP-OBJECT {1BE20C}>. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Bug in handling of keyword arguments
by Eric Marsden 19 Sep '11

19 Sep '11

Hi, ,---- | Armed Bear Common Lisp 0.27.0-dev-svn-13545M | Java 1.6.0_23 Sun Microsystems Inc. | OpenJDK 64-Bit Server VM | Low-level initialization completed in 1.02 seconds. | Startup completed in 1.96 seconds. | CL-USER(10): (defun foo (a b) | (find a '(1 2 3) b 1)) | FOO | CL-USER(11): (compile 'foo) | #<THREAD "interpreter" {12BC8F01}>: Debugger invoked on condition of type PROGRAM-ERROR | Unrecognized keyword argument B | Restarts: | 0: TOP-LEVEL Return to top level. `---- I should be able to invoke FOO with :start or :end values for B. -- Eric Marsden

2 2

[armedbear-devel] BUG: Stack inconsistency (java.lang.VerifyError)
by eric.marsden＠free.fr 06 Sep '11

06 Sep '11

Hi, Attempting to use ABCL to build a current development checkout of SBCL on Linux/i686, I encountered the following error. ABCL builds SBCL on Linux/AMD64 correctly, with the same openjdk version. ------------------ file foo.lisp ------------------------------------------ (in-package :cl-user) (defun symbolicate (&rest things) (let* ((length (reduce #'+ things :key (lambda (x) (length (string x))))) (name (make-array length :element-type 'character))) (let ((index 0)) (dolist (thing things (values (intern name))) (let* ((x (string thing)) (len (length x))) (replace name x :start1 index) (incf index len)))))) (macrolet ((def (name &optional variant) `(defun ,(if variant (symbolicate name "/" variant) name) (function mutex) (declare (function function)) (flet ((%call-with-system-mutex () (dx-let (got-it) (unwind-protect (when (setf got-it (get-mutex mutex)) (funcall function)) (when got-it (release-mutex mutex)))))) (declare (inline %call-with-system-mutex)) ,(ecase variant (:without-gcing `(without-gcing (%call-with-system-mutex))) (:allow-with-interrupts `(without-interrupts (allow-with-interrupts (%call-with-system-mutex)))) ((nil) `(without-interrupts (%call-with-system-mutex)))))))) (def call-with-system-mutex) (def call-with-system-mutex :without-gcing) (def call-with-system-mutex :allow-with-interrupts)) ---------------------- Armed Bear Common Lisp 0.13.0-dev Java 1.6.0_23 Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 0.344 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/tmp/foo") ; Compiling /tmp/foo.lisp ... ; (IN-PACKAGE :CL-USER) ; (DEF CALL-WITH-SYSTEM-MUTEX) ; in (MACROLET (#) ...) ; Caught STYLE-WARNING: ; Undefined variable: GOT-IT Stack inconsistency at index 63: found 3, expected 1. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Inconsistent stack height 1 != 3 at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.getConstructor(Class.java:1674) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1147) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1074) at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:186) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_4.execute(compile-file.lisp:63) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_8.execute(compile-file.lisp:103) at org.armedbear.lisp.LispThread.execute(LispThread.java:680) Eric

1 1

[armedbear-devel] [ANNOUNCE] ABCL 0.27.0 released
by Erik Huelsmann 03 Sep '11

03 Sep '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.27.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among other things - wider compatibility for Quicklisp encapsulated systems basedon reports for problems with ABCL: fixes for PARENSCRIPT, NAMED-READTABLES and CL-INTERPOL (CL-UNICODE fix). Additionally, ABCL has regained the ability to build SBCL. The release notes can be found at: http://common-lisp.net/project/armedbear/release-notes-0.27.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.zip.asc

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13546 - trunk/abcl
by Erik Huelsmann 29 Aug '11

29 Aug '11

Hi Mark, Could you add the changes related to JSS, JAR packaging and the like that you have been putting on trunk? The current list is compiled based on r13382 (branch point 0.26) up to HEAD, manually eliminating the revisions which have been merged into the 0.26 branch. Looking at the list, I'd like to create another release soon: the pretty printer fixes haven't made it in a public release yet, nor have many of the JAR packaging fixes and improvements that you committed. As always, if you see things differently, discussion welcome, of course! Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 28, 2011 at 10:36 PM Subject: [armedbear-cvs] r13546 - trunk/abcl To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 28 13:36:34 2011 New Revision: 13546 Log: More CHANGES updates. Modified: trunk/abcl/CHANGES Modified: trunk/abcl/CHANGES ============================================================================== --- trunk/abcl/CHANGES Sun Aug 28 13:11:41 2011 (r13545) +++ trunk/abcl/CHANGES Sun Aug 28 13:36:34 2011 (r13546) @@ -14,6 +14,13 @@ Changes ------- + * Renamed LispObject.writeToString() method to (more lispy) printObject() + + * New LispObject.princToString() for user readable output + + * Changed behaviour of LispObject.unreadableString() to signal + errors when *PRINT-READABLY* is non-NIL + * Static initializers moved to <clinit>() (java: static { }) to prevent repeated execution when invoking the constructor multiple times @@ -24,6 +31,11 @@ * File compiler (COMPILE-FILE) clean-ups + * When calling a function with the wrong number of arguments, + report the expected (range) of arguments + + * Upgraded ASDF to 2.017 + Fixes ----- @@ -39,6 +51,15 @@ * [ticket #163] Local functions shadow global macro and function bindings (fixes PARENSCRIPT support) + * [ticket 158] Readable printing of the string "#<abc>" does not signal + a PRINT-NOT-READABLE error anymore + + * Fixed SYNTAX.SHARP-BACKSLASH.6 and SYNTAX.SHARP-BACKSLASH.7 + + * Fixed many PPRINT.* test suite failures + + * [ticket #151] LOAD fails for whitespace in JAR-PATHNAME + Version 0.26.2 ============== _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

2 1

[armedbear-devel] Compiling large Java-classes slow?
by Ole Myren Rohne 24 Aug '11

24 Aug '11

Hi ABCL-developers, Is there a recent change (since May?) that would have made compiling files containing large wrapped Java-classes excessively slow? If so, is there any hope of this eventually improving? Ole

2 3

[armedbear-devel] More efficient compilation of forward references -- WAS: r13536 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 23 Aug '11

23 Aug '11

When you look at the ### FASLATONCE comments, you may be wondering what I'm doing here. Well, I'm looking at a way to make our own compilation much faster again, but also to make our compiled code much faster. The problem - as I understand it now - with our slow compilation since the introduction of the jvm-class-file.lisp file is NOT so much the fact that we store lots of data in structures now (I thought it was when I did that work though). Rather, my current understanding is that the declaration order of functions in a file is extremely important for the performance of said fasl: Backward referenced functions (those being defined first and called from code "further down the file") are being called through direct calls of the execute() method of a final static field in the class of the calling function. Since the value is final, the JVM is allowed to assume the jump is always going to go to the same class's execute() method which can be very easily optimized. Forward referenced functions (those being called before they are defined -- although still defined in the same file) are being resolved through a call to the getSymbolFunctionOrDie() function of the function's symbol. Since that variable is *not* final, the call to the return value of getSymbolFunctionOrDie() can't be as easily JITted. Hence my idea to compile all toplevel compilands *after* the entire file has been processed and all toplevel functions have been discovered. At that time, the functions can be compiled and all forward references can be resolved and hard coded using final static fields. However: this introduces the risk of circularity during fasl loading. My remarks relate to that problem. Bye, Erik. On Tue, Aug 23, 2011 at 11:34 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Tue Aug 23 14:34:33 2011 > New Revision: 13536 > > Log: > Move more static field initialization to the static class initializer > <clinit>() code. > > Additionally, place some remarks where I expect issues once I start > compiling forward references the same way as backward references. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 13:35:32 2011 (r13535) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 14:34:33 2011 (r13536) > @@ -1392,7 +1392,7 @@ > (local-function-compiland local-function)))) > (field-name (local-function-field local-function))) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > ;; fixme *declare-inline* > (declare-field field-name +lisp-object+) > (emit-new class-name) > @@ -1416,7 +1416,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; strings may contain evaluated bits which may depend on > ;; previous statements > (declare-field g +lisp-object+) > @@ -1432,7 +1432,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; The readObjectFromString call may require evaluation of > ;; lisp code in the string (think #.() syntax), of which the outcome > ;; may depend on something which was declared inline > @@ -1455,7 +1455,7 @@ > ;; fixme *declare-inline*? > (remember g obj) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > (declare-field g +lisp-object+) > (emit 'ldc (pool-string g)) > (emit-invokestatic +lisp+ "recall" > @@ -4149,6 +4149,11 @@ > (emit-load-local-function local-function) > (emit-move-from-stack target)) > ((inline-ok name) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-function name) +lisp-object+) > (emit-move-from-stack target)) > @@ -4166,6 +4171,11 @@ > (emit-load-local-function local-function)) > ((and (member name *functions-defined-in-current-file* :test > #'equal) > (not (notinline-p name))) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-setf-function name) +lisp-object+) > (emit-move-from-stack target)) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel