armedbear-devel April 2010

armedbear-devel@common-lisp.net

19 participants
37 discussions

[armedbear-devel] READ-LINE inlining fixed, but READ-LINE shouldn't be inlined?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Ticket 89 was about a class verification error which is now fixed, I'm wondering whether we should be inlining calls to Stream.readLine() at all: it seems like this would be incompatible with Gray streams support, after we complete it. Regards, Erik.

1 0

[armedbear-devel] Stack issues fixed: what to do with their workaround?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Hi Mark, A while ago, it looked we had a few regressions in the compiler regarding stack consistency: ticket #89 and the issue reported by Alan (PROGV inside AND). The former you ran into when trying to get ASDF2 running on ABCL. As it turned out, these were both were not regressions, but very old bugs. Both are fixed too. For ticket 89, you implemented a work-around, where the compiler would ask the user to replace the compiled form with an interpreted version. Other than this question, are there any side effects of your change? Anything we might want to consider reverting before our next release? Regards, Erik.

1 0

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 26 Apr '10

26 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 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel April 2010