armedbear-devel April 2010

armedbear-devel@common-lisp.net

19 participants
37 discussions

[armedbear-devel] Generating class files instead of functions-as-class-files
by Erik Huelsmann 18 Apr '10

18 Apr '10

Over the past months, I've been thinking about changing the way we generate our class files. Currently all of our class file generation is centered around producing a execute() method, with a constructor to support object initialization. This scheme seriously limits our flexibility. Imagine a function of 2 arguments, one required and one optional. Currently, we require a call to fastProcessArgs(), where we could have done with a class which implements the single as well as the two-argument execute() methods. Along the same lines, I'm looking to clean up our constructors: In my ideal world all the static field initializers will be moved to the class constructor <clinit>() which isn't called more than exactly once. To support this type of output, I started jvm-class-file.lisp. It's a file which centers around generation of true class files (with arbitrary numbers of methods), instead of "functions-as-classes" which are modelled using exactly 2 methods. The jvm-class-file.lisp file is local to my working copy for now, although I did send a version to Alessio some time ago. Apart from the flexibility this would achieve, I think I have another benefit: it would allow catching the full class file before it's a serialized. The resulting in-memory class file representation could be analysed, for example to find the stack inconsistencies we're looking (but not yet finding). There are serveral reasons to send this mail: 1. To keep you all in the loop 2. To see about your comments regarding the above direction 3. To see if there's anybody here who wants to help out As a general direction forward, I was thinking to start a branch so that there's some place to store my currently-private jvm-class-file.lisp. I'll have to create a BRANCH-README to document what the branch is about, what the status is and what is left to be done. The first step forward, I'd like to do on the trunk however: a first separation of code generation and class file writing. That would allow me to write a GUI tool for inspecting the resulting class files from a single COMPILE call and hence creating a tool which should help finding our "stack inconsistency" problems. Comments? Helpers? Bye, Erik.

1 0

[armedbear-devel] Stack inconsistency now uses interpreted form in FASL
by Mark Evenson 16 Apr '10

16 Apr '10

Since we seem to be up against a bit of a wall in [analysis of the stack inconsistencies in bytecode for some instances of HANDLER-BIND][1], I've [changed the compiler to fall back to using hte interpreted form][2] if the stack verification fails. To do this, I've introduced INTERNAL-COMPILER-ERROR which when signaled at any point in the compilation pass, causes PROCESS-TOPLEVEL-FORM to fall back to using the interpreted form. In its current form, the faulty bytecode is still included in the packed FASL which as a further optimization should not be included. [1]: http://trac.common-lisp.net/armedbear/ticket/89 [2]: http://trac.common-lisp.net/armedbear/changeset/12620 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Consolidating copy/paste code
by Erik Huelsmann 15 Apr '10

15 Apr '10

Yesterday Ville and I dedicated some time to the consolidation of copy/paste code and unnecessary virtual methods. There's quite a bit of copy/paste code in ABCL. A good example are LispReader, FaslReader and Stream.java. FaslReader had a number of functions which were *exactly* equal to functions in LispReader. A number of functions contained the same logic, but used different readtables. The same applies to functions in Stream.java where functions were declared twice - once with a faslRead* prefix and once with a read* prefix. The solution is - in this case, of course - to abstract the code from the readtable to be used. In other places the reasons for copy/pasting will be different. If you're lurking at this list, thinking of contributing but you don't know how: this is a much appreciated way to help out! We try to reduce the number of (copy/pasted) lines of code in ABCL; not at the expense of functionality, but as a way to ensure consistent maintenance in the future. Still no idea where to start? I left some remaining work in LispReader.java and FaslReader.java where there is more copy/pasted code. My idea is that the common bits get moved to Stream.java, using the ReadtableAccessor class to abstract from the readtables themselves. Looking forward to your contributions! Bye, Erik.

7 17

[armedbear-devel] ASDF2 in trunk
by Mark Evenson 15 Apr '10

15 Apr '10

I've committed a snapshot of ASDF2 [in trunk][1], including [a copy of the texinfo manual][2]. [1]: http://trac.common-lisp.net/armedbear/changeset/12618 [2]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/asdf/asdf.texi… A potential gotcha for moving from ASDF: there is a translation mechanism for FASL locations in place by default (this code supersedes the ASDF-BINARY-LOCATIONS addon), so your FASLs end up in a central FASL cache by default. This output mechanism is *very* configurable, see the manual for examples. To totally disable output translations, one can simply eval (asdf:disable-output-translations) after loading ASDF2. With output translations, one may have the problem with code that wrangles *LOAD-TRUENAME* or *LOAD-PATHNAME* to get the source directory. The official ASDF2 recommendation is to rewrite your code to use ASDF:SYSTEM-RELATIVE-PATHNAME, possibly utilizing the presence of :ASDF2 in *FEATURES* to conditionalize old code. Examples of such definitions can be found in my patch as I adapted our ASDF definitions for test code. We still have to solve the problem arising from the possibility of not having a writable filesystem in an applet or servlet context, but that problem was present with the old ASDF as well. Anyone with problems in using ASDF2 please let me know. I have tested it quite a bit in the past months finding it generally much improved. The ASDF group is quite active in fixing things, so please be vocal and we should be able get you to a stable state. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] URL pathname code in trunk
by Mark Evenson 15 Apr '10

15 Apr '10

I've pushed the code for handling URLs in pathnames to the trunk in commits r12605-r12616. The [design documents what I was aiming for][1], namely allowing resources addressed by URL (i.e. a URI with a network authority) to be used as Lisp pathnames. I expect that this will work for anything that 'java.net.URL' works with, although I have yet to "shake down" the OSGi code using the "bundle:" scheme. After I push ASDF2 to the trunk, this will be the goal my next effort. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… Incomplete at this point: 1. The implementation is lacking proper URI/URL escaping. I intend to not have anything automagically happen, but rather provide functions for the user to encode/decode pathnames to string forms. It is a matter of writing (stealing?) decent URI escaping code at this point. Noteworthy changes: 1. JAR-PATHNAME and URL-PATHNAME are now subtypes of PATHNAME. 2. Both JAR-PATHNME and URL-PATHNAME are now valid arguments to OPEN with :DIRECTION :INPUT. 3. QUERY and FRAGMENTS are stored in the HOST plist. Not my favorite part of the design, but better than any other choice I could come up with. Users are expected to use the DEFSETF PATHNAME-URL-QUERY and PATHNAME-URL-FRAGEMENT functions to manipulate these quantities. 4. Fixed some fugliness with *LOAD-TRUENAME* and *LOAD-PATHNAME* with jar pathnames returning more of the expected values. 5. Jar pathnames use of a String to denote URLs has been replaced by the use of proper URL pathnames. If someone has code that I have brooken because it depended on the internal structure of jar pathnames from 0.19, shout out, and we'll figure out something. Hopefully, everyone was using namestrings anwyays, so everything should "just work". Feedback, bug reports, success stories welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Fwd: Consolidating copy/paste code
by Erik Huelsmann 13 Apr '10

13 Apr '10

Forgot to include the list. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Tue, Apr 13, 2010 at 10:00 AM Subject: Re: [armedbear-devel] Consolidating copy/paste code To: David Kirkman <dkirkman(a)ucsd.edu> Hi David, Let me start by thanking you for your contribution! Welcome! On Mon, Apr 12, 2010 at 2:59 AM, David Kirkman <dkirkman(a)ucsd.edu> wrote: > OK, Sounds like a nice afternoon project. Here's a patch that does what I > think you're asking in FaslReader and LispReader. > > But I ran into some trouble testing the changes. Following the > instructions at > http://common-lisp.net/project/armedbear/contributing.shtml > I end up with an OutOfMemoryError when running both test.ansi.interpreted > and test.ansi.compiled > > Is there an enviroment variable that needs to be set to get these > to run? I can make it work by putting <jvmarg value="-Xmx500M"> > lines in build.xml, which I've attached as a second patch. > > When I ran the tests after I made the change, I got one additional error > when running test.ansi.interpreted: PRINT.BACKQUOTE.RANDOM.14. I've also > attached the error. I can't figure it out. I eventually decided that a > 'random' test might give a different result if I run it again ... so I ran it > again (and again and again) ... and the error did not happen again. So I now > suspect that my patch does not introduce any new errors, but that > PRINT.BACKQUOTE.RANDOM.14 fails randomly from time to time. I saw Mark addressed the memory problems you had. That's good. I experience the PRINT.BACKQUOTE.RANDOM and some other random printing issues too. This is really something to look into. However, well, they're random... Unfortunately yesterday evening was very hectic, so I didn't get to have a look at your changes. I'll look at them at my earliest convenience; no later than the end of this week, hopefully tonight. Thanks again for your contribution! Bye, Erik.

1 0

[armedbear-devel] abcl hangs when building cl-pdf component pdf-geom.lisp
by james anderson 12 Apr '10

12 Apr '10

good afternoon; attached below is the transcript of an aborted build of cl-pdf. abcl hangs when it attempts to compile pdf-geom.lisp. is the cause clear from the stack? asdf@ip-10-251-122-82:/development/source/library$ sh ../metadata/com: 8000/fractalconcept/www/cl-pdf/build-system.sh abcl cd: 17: can't cd to /ebs/source/metadata/com\:8000/fractalconcept/www/ cl-pdf/ Armed Bear Common Lisp 0.19.1 Java 1.6.0_0 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 1.55 seconds. Startup completed in 3.804 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading #P"jar:file:/development/downloads/abcl- bin-0.19.1/abcl.jar!/org/armedbear/lisp/delete.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/delete.abcl" (0.048 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.143 seconds) ;Build root: #P"/ebs/source/metadata/lib/build-init.lisp". ;Incorporating asdf anew from #P"/ebs/source/metadata/lib/asdf.lisp". ; Loading #P"/ebs/source/metadata/lib/asdf.abcl" ... ; Loaded #P"/ebs/source/metadata/lib/asdf.abcl" (2.396 seconds) T CL-USER(2): ;For project :CL-PDF-PARSER, using ASDF registry (#P"/ebs/ source/upload/com:8000/fractalconcept/www/cl-pdf/" #P"/ebs/source/ library/asdf-registry/") ... ;System definition purged: :CL-PDF-PARSER... ;Load system :CL-PDF-PARSER... ; loading system definition from /ebs/source/upload/com:8000/ fractalconcept/www/cl-pdf/cl-pdf-parser.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf-parser.asd" ... ; registering #<SYSTEM :CL-PDF-PARSER {194566D}> as CL-PDF-PARSER ; Loaded #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf-parser.asd" (0.216 seconds) ; loading system definition from /ebs/source/upload/com:8000/ fractalconcept/www/cl-pdf/cl-pdf.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf.asd" ... ; registering #<SYSTEM :CL-PDF {D38C3D}> as CL-PDF ; Loaded #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf.asd" (0.037 seconds) ; loading system definition from /ebs/source/library/asdf-registry/ iterate.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/library/net/common-lisp/iterate/ iterate.asd" ... ; registering #<SYSTEM :ITERATE {148B272}> as ITERATE ; registering #<SYSTEM :ITERATE-PG {1BB6A69}> as ITERATE-PG ; registering #<SYSTEM :ITERATE-TESTS {28DF48}> as ITERATE-TESTS ; Loaded #P"/ebs/source/library/net/common-lisp/iterate/ iterate.asd" (0.206 seconds) WARNING: No architecture feature found in ((X86-64 AMD64 X86_64 X8664- TARGET) (X86 I686 I586 PENTIUM3 I486 I386 PC386 IAPX386 X8632-TARGET PENTIUM4) HPPA64 HPPA PPC64 (PPC32 PPC POWERPC) SPARC64 SPARC). WARNING: No architecture feature found in ((X86-64 AMD64 X86_64 X8664- TARGET) (X86 I686 I586 PENTIUM3 I486 I386 PC386 IAPX386 X8632-TARGET PENTIUM4) HPPA64 HPPA PPC64 (PPC32 PPC POWERPC) SPARC64 SPARC). ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/loop.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/loop.abcl" (0.924 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-types.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-types.abcl" (0.146 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-error.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-error.abcl" (0.001 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-functions.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-functions.abcl" (0.021 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-symbols.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-symbols.abcl" (0.595 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/dump-form.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/dump-form.abcl" (0.001 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/opcodes.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/opcodes.abcl" (0.059 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.148 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass1.abcl" ... ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.022 seconds) ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass1.abcl" (0.194 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass2.abcl" ... ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.055 seconds) ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass2.abcl" (1.221 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/package.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/ package.abcl" (0.001 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/iterate.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/ iterate.abcl" (0.632 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ defpackage.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ defpackage.abcl" (0.001 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/x11- colors.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/x11- colors.abcl" (0.784 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ encodings.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ encodings.abcl" (2.371 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ config.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ config.abcl" (0.006 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/font- metrics.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/font- metrics.abcl" (2.652 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/t1- font.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/t1- font.abcl" (0.527 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ font.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ font.abcl" (15.887 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ pdf.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ pdf.abcl" (3.353 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- base.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- base.abcl" (0.464 seconds) ; Compiling /ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- geom.lisp ... ; (IN-PACKAGE #:PDF) ^\Quit asdf@ip-10-251-122-82:/development/source/library$ 2010-04-12 11:44:59 Full thread dump OpenJDK Client VM (14.0-b16 mixed mode, sharing): "DestroyJavaVM" prio=10 tid=0x08e7e000 nid=0x22f2 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "interpreter" prio=10 tid=0x08f2d000 nid=0x22fa runnable [0xb4413000] java.lang.Thread.State: RUNNABLE at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) at sun.nio.cs.UTF_8$Decoder.xflow(UTF_8.java:183) at sun.nio.cs.UTF_8$Decoder.decodeArrayLoop(UTF_8.java:242) at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:324) at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:561) at org.armedbear.lisp.util.RandomAccessCharacterFile.read (RandomAccessCharacterFile.java:375) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:224) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:190) at org.armedbear.lisp.Stream._readChar(Stream.java:1684) at org.armedbear.lisp.LispReader$1.execute(LispReader.java:52) at org.armedbear.lisp.Stream.processChar(Stream.java:529) at org.armedbear.lisp.Stream.readPreservingWhitespace (Stream.java:449) at org.armedbear.lisp.Stream.readPreservingWhitespace (Stream.java:457) at org.armedbear.lisp.Stream.read(Stream.java:396) at org.armedbear.lisp.Stream$14.execute(Stream.java:2332) at org.armedbear.lisp.Symbol.execute(Symbol.java:798) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.compile_file_35.execute(compile- file.lisp:469) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.compile_file_32.execute(compile- file.lisp:469) at org.armedbear.lisp.compiler_pass2_578.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.compile_file_30.execute(compile- file.lisp:469) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:124) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:160) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.Lisp.funcall(Lisp.java:170) at org.armedbear.lisp.Primitives$pf_apply.execute (Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:158) at org.armedbear.lisp.Symbol.execute(Symbol.java:824) at org.armedbear.lisp.LispThread.execute(LispThread.java:632) at org.armedbear.lisp.asdf_303.execute(asdf.lisp:1503) at org.armedbear.lisp.clos_153.execute(clos.lisp:1437) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.clos_142.execute(clos.lisp:1371) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.clos_132.execute(clos.lisp:1205) at org.armedbear.lisp.StandardGenericFunction.execute (StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.asdf_318.execute(asdf.lisp:1561) at org.armedbear.lisp.clos_152.execute(clos.lisp:1437) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.clos_142.execute(clos.lisp:1371) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.clos_132.execute(clos.lisp:1205) at org.armedbear.lisp.StandardGenericFunction.execute (StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.asdf_359.execute(asdf.lisp:1646) at org.armedbear.lisp.compiler_pass2_582.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_578.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.Autoload.execute(Autoload.java:168) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.asdf_358.execute(asdf.lisp:1646) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.funcall(Lisp.java:168) at org.armedbear.lisp.Primitives$pf_apply.execute (Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:143) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.asdf_373.execute(asdf.lisp:1716) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Primitives$sf_return_from.execute (Primitives.java:3750) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators$sf_progn.execute (SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.eval(Lisp.java:455) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:770) at org.armedbear.lisp.Primitives$sf_tagbody.execute (Primitives.java:3667) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute (Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.eval(Lisp.java:455) at org.armedbear.lisp.Primitives$pf__eval.execute (Primitives.java:328) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute (Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.bindParametersAndExecute (Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:278) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:765) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:318) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:636) "Low Memory Detector" daemon prio=10 tid=0x08ebb800 nid=0x22f8 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x08eb8800 nid=0x22f7 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x08eb6c00 nid=0x22f6 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0x08eae000 nid=0x22f5 in Object.wait() [0xb46d3000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7181b310> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133) - locked <0x7181b310> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149) at java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:177) "Reference Handler" daemon prio=10 tid=0x08eac800 nid=0x22f4 in Object.wait() [0xb4724000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7181b0a8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run (Reference.java:133) - locked <0x7181b0a8> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x08eaac00 nid=0x22f3 runnable "VM Periodic Task Thread" prio=10 tid=0x08ebd400 nid=0x22f9 waiting on condition JNI global references: 695 Heap def new generation total 2112K, used 1035K [0x6f0a0000, 0x6f2e0000, 0x71800000) eden space 1920K, 43% used [0x6f0a0000, 0x6f172c78, 0x6f280000) from space 192K, 100% used [0x6f2b0000, 0x6f2e0000, 0x6f2e0000) to space 192K, 0% used [0x6f280000, 0x6f280000, 0x6f2b0000) tenured generation total 26796K, used 21848K [0x71800000, 0x7322b000, 0x8f0a0000) the space 26796K, 81% used [0x71800000, 0x72d56308, 0x72d56400, 0x7322b000) compacting perm gen total 12288K, used 10968K [0x8f0a0000, 0x8fca0000, 0x930a0000) the space 12288K, 89% used [0x8f0a0000, 0x8fb563d8, 0x8fb56400, 0x8fca0000) ro space 8192K, 89% used [0x930a0000, 0x937cd318, 0x937cd400, 0x938a0000) rw space 12288K, 59% used [0x938a0000, 0x93fcc748, 0x93fcc800, 0x944a0000) ^C asdf@ip-10-251-122-82:/development/source/library$ mor

3 3

[armedbear-devel] Bug in metaclass support
by Alessio Stalla 11 Apr '10

11 Apr '10

Hello, this piece of code produces an error: (defclass foo () () (:METACLASS STANDARD-CLASS) (:DOCUMENTATION "bar")) condition of type PROGRAM-ERROR: Invalid initarg :DOCUMENTATION while it works perfectly fine without :metaclass, presumably because make-instance is not called to create the class metaobject. On class redefinition (say, I define foo without :documentation, and redefine it with it), it gives no error. This breaks Cells which always puts in a :metaclass option even when superfluous. Bye, Alessio

2 1

[armedbear-devel] Ticket #88: Predicate to distinguish Java-based and lisp-compiled functions
by Erik Huelsmann 10 Apr '10

10 Apr '10

Regarding ticket 88, I have the following idea: Lisp functions inherit from either Primitive or CompiledClosure. CompiledClosure isn't used elsewhere, but Primitive is used everywhere in Java too. How about creating an (empty) CompiledPrimitive which isn't used Java-side. Then, with a simple 'instanceof' test, functions can be tested to have been compiled from Lisp or created from Java. How about that? Bye, Erik.

1 0

[armedbear-devel] Low memory condition signalling
by Erik Huelsmann 09 Apr '10

09 Apr '10

Hi, Yesterday I completed an abcl-dev blogpost about 0.18 which handles out of memory (OOM) conditions much better than earlier versions. However, as the post concludes, it would be even lispier to have a low-memory signal instead of OOM, because in that case the condition system can be used to handle the situation right in the call stack where the condition occurred, in order to be able to continue execution after handling the condition. Douglas Miles suggested we use JMX memory management notifications to create this behaviour. Before we can implement such behaviour, a number of questions need to be answered: * How does an application tell the difference between our current OOM condition and the new behaviour? -> this is important, because the current behaviour unwinds the stack; the future one won't * Do we remove the current behaviour? * Do we let the user select the parameters for signalling the requested condition? * Should we let the user install handlers to be called when a condition like this occurs? * <others>? Regards, Erik.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel April 2010