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

[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 24 Apr '10

24 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 19 Apr '10

19 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

[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