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

[armedbear-devel] svn r13244 breaks DIRECTORY with wildcard
by Mark Evenson 16 Mar '11

16 Mar '11

Even though the commit message notes for r13244 "The wildcard filtering is broken atm, working on that" it would be preferable to not have patches that break things remain long on trunk. Among other things, this prevents the ANSI compiled tests from being run. CL-USER> (DIRECTORY "/Users/evenson/work/ansi-tests/scratch/*") produces The value NIL is not of type FIXNUM. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to sldb level 1. 2: [RETRY] Retry SLIME REPL evaluation request. 3: [*ABORT] Return to SLIME's top level. 4: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {3541D281}> #<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>) 1: (APPLY #<FUNCTION {3541D281}> (#<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {75EE0563}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:373) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:414) 6: org.armedbear.lisp.find_20.execute(find.lisp:171) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:138) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:825) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:688) 10: org.armedbear.lisp.pathnames_8.execute(pathnames.lisp:53) 11: org.armedbear.lisp.pathnames_7.execute(pathnames.lisp:53) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:670) 14: org.armedbear.lisp.pathnames_11.execute(pathnames.lisp:86) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:670) 17: org.armedbear.lisp.pathnames_14.execute(pathnames.lisp:131) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:801) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:653) 20: org.armedbear.lisp.directory_6.execute(directory.lisp:98) 21: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:636) 23: org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) 24: org.armedbear.lisp.Lisp.eval(Lisp.java:505) 25: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 26: (POSITION-IF #<FUNCTION {7A4CBCAF}> "*" :START NIL) 27: (SYSTEM::COMPONENT-MATCH-WILD-P "foo.txt" "*" NIL) 28: (SYSTEM::COMPONENT-MATCH-P "foo.txt" "*" NIL) 29: (PATHNAME-MATCH-P #P"foo.txt" #P"*") 30: (DIRECTORY "/Users/evenson/work/ansi-tests/scratch/*") -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Supporting object finalizers (to support trivial-garbage)
by Erik Huelsmann 13 Mar '11

13 Mar '11

One of the higher systems on the list of Quicklisp downloads is the trivial-garbage system (http://www.cliki.net/trivial-garbage) One of the things this package does is to provide 'normalized' access to object finalization functionality. I thought I'd quickly add that support (and did so in r13248). However, it seems our bootstrap compilation has now slowed down to a crawl. So, I'm ready to revert the commit and reopen the ticket I had opened to track progress. However, are you seeing the same? Do you have any good alternatives? I'd love some discussion on this subject: supporting Quicklisp downloaded packages looks like a good way to promote ourselves. Bye, Erik.

2 2

[armedbear-devel] Bug triaging / new milestones available
by Erik Huelsmann 11 Mar '11

11 Mar '11

Following the release, I closed the 0.25 milestone, opening the 0.26 .. 0.30 milestones. These are still empty, but could be filled with the outstanding tickets. If you don't have Trac access, please express your preferences here; if you have Trac access, please update the tickets according to your preference. Bye, Erik.

2 2

[armedbear-devel] [ANNOUNCE] ABCL 0.25.0 released
by Erik Huelsmann 11 Mar '11

11 Mar '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.25.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among lots of other things - a major refactoring of the compiler to be more robust in light of Java class file verification and object instantiation (MAKE-INSTANCE) speed-ups. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.25.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-src-0.25.0.ta… http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-src-0.25.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.25.0/releases/abcl-src-0.25.0.ta… http://common-lisp.net/project/armedbear/0.25.0/releases/abcl-src-0.25.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-bin-0.25.0.ta… http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-bin-0.25.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.25.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.25.0.zip.asc

2 1

[armedbear-devel] [Final CfPart] European Lisp Symposium, Hamburg, March 31 - April 1
by Didier Verna 09 Mar '11

09 Mar '11

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ Sponsors: EPITA, TUHH, Lispworks, Franz Inc., NovaSparks and Freiheit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ News: ~~~~~ * The final program is now online. * The early registration deadline is in 3 days, so hurry! Registration will still be possible afterwards. Invited Speakers: ~~~~~~~~~~~~~~~~~ Craig Zilles -- Compiling for the common case Marc Battyani -- Reconfigurable computing on steroids Apostolos Syropoulos -- Scala: an OO surprise Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Release branch (0.25) created: please test
by Erik Huelsmann 04 Mar '11

04 Mar '11

After the merge of the UNSAFE-P-REMOVAL branch to trunk, Mark Evenson discovered a regression: we failed to compile Montezuma. With some help of Alessio Stalla, I've been able to fix this regression last night, clearing up the last blocking issue for branching for a release. In order to make sure our release works with your software, please test the release branch with it. You can check out the branch using Subversion, from svn://common-lisp.net/project/armedbear/svn/branches/0.25.x Any findings can be reported to this list, or, if you have Trac access, directly as a Trac ticket. Thanks in advance for your efforts! Bye, Erik.

1 0

[armedbear-devel] Getting directory listing with symlinks included
by Zach Beane 02 Mar '11

02 Mar '11

If I have a directory containing a file named a.txt and a symlink b.txt that points to a.txt, is there any ABCL function I can call to get both directory entries as separate objects, i.e. the list (#p"a.txt" #p"b.txt")? The semantics of CL:DIRECTORY seem to require resolving the b.txt symlink, so I'm trying to figure out an extra-standard way to do it in ABCL, if possible. Thanks, Zach

2 7

Re: [armedbear-devel] Bordeaux Threads and ABCL
by Mark Evenson 01 Mar '11

01 Mar '11

On Feb 28, 2011, at 08:05 , Andrew Pennebaker wrote: > I'm having trouble getting threads to work on ABCL. I've filed [ticket #135][1] to track the current status of BORDEAUX-THREADS on ABCL. Apparently, among other things that affect trunk is that we have mistakenly left references to THREAD-LOCK and THREAD-UNLOCK in our autoloads which I will remove as soon as a track down the svn commit that removed ThreadLock.java. [1]: http://trac.common-lisp.net/armedbear/ticket/135 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] translate-logical-pathname downcasing paths inconsistently
by Jonathan P. Bona 27 Feb '11

27 Feb '11

As the following code and transcript demonstrate, translate-logical-pathname appears to be downcasing paths inconsistently: ;;; test.cl (setf (logical-pathname-translations "foo") '(("foo:bar;*.lisp" "/FooRoot/bar/*.lisp") ("foo:*.lisp" "/FooRoot/*.lisp"))) ;;; In the following pathname translation, the entire path is downcased (pprint (translate-logical-pathname "foo:bar;foobar.lisp")) ;;; In each of the next two, the entire path EXCEPT for the host is downcased -- ;;; the host is unchanged (pprint (translate-logical-pathname "foo:foobar.lisp")) (pprint (translate-logical-pathname "foo:Foobar.lisp")) --- Armed Bear Common Lisp 0.24.0 Java 1.6.0_22 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.478 seconds. Startup completed in 1.386 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "test.cl") #P"/fooroot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/foobar.lisp" T CL-USER(2): --- SBCL and CLISP both produce the following output for the above code: #P"/FooRoot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/foobar.lisp" Allegro's ALISP and MLISP both produce the following: #P"/FooRoot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/Foobar.lisp"

2 1

[armedbear-devel] :case :common
by pjb＠informatimago.com 27 Feb '11

27 Feb '11

CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" And that I understand "yeld strings in component values" to mean that the processing should be done on each parameter independently. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 4