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

Re: [armedbear-devel] [armedbear] #89: compiler stack inconsistency
by Mark Evenson 27 Apr '10

27 Apr '10

I tracked this back to before the split of 'abcl' from 'j' observing the error through [rev0 of the copy of abcl][1] I keep in Mercurial], so can confirm the lack of regression back to 2008-12-20. 0 e7def953d497 2008-12-20 20:35 +0100 ehuelsmann [svn r11457] Create separate project directories for ABCL and J. [1]: http://trac.common-lisp.net/armedbear/changeset/11457/trunk/abcl -- "No, this is not a disentanglement from, but a progressive /knotting-into/ […]"

1 0

[armedbear-devel] encoding bug in Stream.readPreservingWhitespace (classpath)
by Eric Marsden 25 Apr '10

25 Apr '10

Hi, Attempting to run ABCL with jamvm (which uses the classpath libraires), I get ,---- | Armed Bear Common Lisp 0.20.0-dev | Java 1.5.0 GNU Classpath | JamVM | Low-level initialization completed in 0.371 seconds. | Exception in thread "interpreter" java.lang.IllegalStateException | at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:163) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:168) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:156) | at org.armedbear.lisp.Stream._unreadChar(Stream.java:1708) | at org.armedbear.lisp.Stream._readToken(Stream.java:1144) | at org.armedbear.lisp.Stream.readToken(Stream.java:1009) | at org.armedbear.lisp.Stream.processChar(Stream.java:508) | at org.armedbear.lisp.Stream.readList(Stream.java:660) | at org.armedbear.lisp.LispReader$3.execute(LispReader.java:88) | at org.armedbear.lisp.Stream.processChar(Stream.java:505) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:484) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:492) | at org.armedbear.lisp.Stream.read(Stream.java:430) | at org.armedbear.lisp.Load.loadStream(Load.java:556) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:522) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:412) | at org.armedbear.lisp.Load.loadSystemFile(Load.java:337) | at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:159) | at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:93) | at org.armedbear.lisp.Main$1.run(Main.java:48) | at java.lang.Thread.run(Thread.java:745) `---- I see in org.armedbear.lisp.Stream.read() a sequence int n = _readChar(); if (n >= 0) { char c = (char) n; // ### BUG: Codepoint conversion Readtable rt = rta.rt(thread); if (!rt.isWhitespace(c)) _unreadChar(c); } which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed? -- Eric Marsden

2 3

[armedbear-devel] eql for java objects
by Alan Ruttenberg 25 Apr '10

25 Apr '10

(eql (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle") (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle")) -> NIL I think it should be eql, probably eq. I know they are equal. The documentation for eq says: Returns true if its arguments are the same, identical object; otherwise, returns false. They are and they are not. That they are not is only a quirk of the implementation. eql adds equality for characters and numbers I'd argue that was done because of uncertainly over boxing in different implementations and not wanting to fall back to a more expensive equal call. Seems that java objects are an equivalent case. Where this matters is that case and friends use eql for comparison. One ought to be able to write a standard case statement that switches off of an enum defined java, but one can't at the moment. That's all, Alan

6 18

[armedbear-devel] Fwd: threads, join, clos
by Erik Huelsmann 25 Apr '10

25 Apr '10

Sent mail to David personally; meant to include the list. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Sat, Apr 24, 2010 at 9:37 AM Subject: Re: [armedbear-devel] threads, join, clos To: David Kirkman <dkirkman(a)ucsd.edu> Hi David, On Sat, Apr 24, 2010 at 6:52 AM, David Kirkman <dkirkman(a)ucsd.edu> wrote: > Hi, > > Is there an equivalent of java.lang.Thread.join() on the lisp side of > things? I looked around in LispThread.java and threads.lisp, but I > don't see anything obvious. I'd like to be able to write something > like: > > (let ((threads (loop for i from 0 to 5 > collect > (make-thread #'(lambda() > (format t "hey~%")))))) > (mapc #'thread-join threads) > (format t "is for horses~%")) > > I've attached a patch that implements this version of thread-join. It > implements java semantics, this thread-join always returns nil. I guess we didn't join our threads until now :-) Thanks for taking the time to code it up. I have one question regarding the patch though: How would the caller know the difference between the scenario where an Interrupted exception occurs and the one where the thread is really joined? Should we use the return value NIL to signal "not joined" and T for "joined"? Bye, Erik.

3 8

[armedbear-devel] loading stale fasls
by David Kirkman 25 Apr '10

25 Apr '10

While trying to come up with reproducible thread errors this morning, I ran into trouble with abcl loading stale fasls. e.g., If I change a lisp file, and don't recompile it (load "foo") will load "foo.abcl" and not the more recent "foo.lisp". I think that Load.java (line 91) is not doing (what I think) it's supposed to: if (abclLastModified > lispLastModified) { return lispPathname; } else { return abclPathname; } I think we need to switcheroo lispPathname and abclPathname. At least that makes abcl behave the way that I expect! If that's the way it's supposed to work, here is a patch. -david

2 1

[armedbear-devel] threads, join, clos
by David Kirkman 23 Apr '10

23 Apr '10

Hi, Is there an equivalent of java.lang.Thread.join() on the lisp side of things? I looked around in LispThread.java and threads.lisp, but I don't see anything obvious. I'd like to be able to write something like: (let ((threads (loop for i from 0 to 5 collect (make-thread #'(lambda() (format t "hey~%")))))) (mapc #'thread-join threads) (format t "is for horses~%")) I've attached a patch that implements this version of thread-join. It implements java semantics, this thread-join always returns nil. I guess java doesn't really have a way to return arbitrary values, but we easily do! I was thinking about hacking it up a bit more so that thread-join would return the value of the function passed to make-thread, e.g. so that (thread-join (make-thread #'(lambda () 1))) would return 1. But then it occurred to me that this functionality is probably already in there under a different name. So, how do you guys join your threads? Cheers, -david k. P.S. Are there any known thread safety issues with CLOS? I've been getting some weird MOP errors that I made go away by redefining slot-value such that it has to acquire a global lock before it can do anything. I assume that the problem is in my code: but the threads that are executing when I get the failures share no code (or variables), and every time the errors pop up slot-value is on the callstack someplace.

1 0

[armedbear-devel] ELW 2010 deadline extension -- April 25th
by Didier Verna 21 Apr '10

21 Apr '10

+------------------------------------------------------------+ | CALL FOR PAPERS | | 7th European Lisp Workshop | | June 22 2010, Maribor, Slovenia, co-located with ECOOP | +------------------------------------------------------------+ Important Dates =============== Submission deadline: April 25, 2010 ** EXTENDED ** Notification of acceptance: May 05, 2010 ECOOP early registration deadline: May 10, 2010 7th European Lisp Workshop: June 22, 2010 Please note that registration must be done with ECOOP itself. For more information visit http://www.european-lisp-workshop.org Contact: Didier Verna, didier(a)lrde.epita.fr Invited Speaker =============== Manuel Serrano (INRIA, France) http://www-sop.inria.fr/members/Manuel.Serrano/ Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and remains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components: there will be formal talks, and interactive turorial/demo/coding sessions. Papers ====== Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. Suggested topics include (but are not limited to): - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Protocol meta-programming and libraries - New language features and abstractions - Software evolution - Development aids - Persistent systems - Dynamic optimization - Implementation techniques - Hardware Support - Efficiency, distribution and parallel programming - Educational approaches and perspectives - Experience reports and case studies Interactive Tutorial/Demo/Coding Sessions ========================================= Additionally, we invite less formal talks in the form of interactive tutorial/demo/coding sessions. The purpose of these sessions is both to demonstrate and receive feedback on any interesting Lisp system, either stable or under development. Being less formal than technical paper presentations, these sessions are expected to be highly interactive. Submission Guidelines ===================== Potential contributors are encouraged to submit: - a long paper (around 10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes, - a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future, - a proposal for an interactive tutorial/demo/coding session (1-2 pages) describing the involved library or application, and the subject of the session. Papers (both long and short) should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms (see below). Authors will later be required to sign an ACM copyright form, as the workshop proceedings will be published in the ACM Digital Library. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=elw2010 Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux 1, France Christophe Rhodes, Goldsmiths College, University of London -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22

1 0

[armedbear-devel] Expecting to find integer on stack
by Alan Ruttenberg 18 Apr '10

18 Apr '10

Not even sure where to begin to try to help you with this... This is with a just checked out abcl. -Alan Exception in thread "interpreter" java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1286) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1347) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1340) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:224) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_7.execute(compile-file.lisp:71) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_5.execute(compile-file.lisp:71) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_10.execute(compile-file.lisp:103) at org.armedbear.lisp.Symbol.execute(Symbol.java:799) at org.armedbear.lisp.LispThread.execute(LispThread.java:600) at org.armedbear.lisp.compile_file_40.execute(compile-file.lisp:486) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_37.execute(compile-file.lisp:486) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_35.execute(compile-file.lisp:486) 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:600) 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:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_312.execute(asdf.lisp:1542) at org.armedbear.lisp.clos_178.execute(clos.lisp:1484) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.clos_167.execute(clos.lisp:1418) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.clos_157.execute(clos.lisp:1252) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.asdf_327.execute(asdf.lisp:1600) at org.armedbear.lisp.clos_177.execute(clos.lisp:1484) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.clos_167.execute(clos.lisp:1418) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.clos_157.execute(clos.lisp:1252) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.asdf_366.execute(asdf.lisp:1685) at org.armedbear.lisp.compiler_pass2_579.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.asdf_365.execute(asdf.lisp:1685) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) 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:811) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.asdf_377.execute(asdf.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:504) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:529) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:266) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:98) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:613) Process inferior-lisp finished

2 1

[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