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

[armedbear-devel] Improvements to our Gray streams implementation
by Mark Evenson 28 Mar '11

28 Mar '11

As part of the long continuing road to Hunchentoot, I am pleased to announce that with [r13255][1], ABCL can now pass the flexi-streams-1.0.7 test suite as long as [trivial-gray-streams is patched to recognize the new FILE-POSITION generic][2]. [1]; http://trac.common-lisp.net/armedbear/changeset/13255 [2]: http://detroit.slack.net/~evenson/abcl/trivial-gray-streams-abcl-20110320a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Patches for metatilities-base and lift
by Mark Evenson 22 Mar '11

22 Mar '11

Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011. We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens. [1]: http://detroit.slack.net/~evenson/abcl/metatilities-base-20101006-darcs-abc… [2]: http://detroit.slack.net/~evenson/abcl/lift-20110320-git-abcl-20110322.diff -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 8

Re: [armedbear-devel] [Bordeaux-threads-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Chun Tian (binghe) 21 Mar '11

21 Mar '11

Hi, Mark I'm interesting in your work. First, I'd like to know, how to do a "condition variable wait with timeout" with your exist work, Second, do you think it's possible to make ABCL supporting some atomic operations, something like ATOMIC-INCF or ATOMIC-PUSH, this can be very useful to implement some lockless algorithms. Regards, Chun Tian (binghe) 在 2011-3-18，15:50， Mark Evenson 写道： > On 3/2/11 8:50 PM, Martin Simmons wrote: > >> I think that the implementation of condition-wait has some major problems: > > Thanks very much for the comments. > > I have an [updated patch][1] that attempts to address these issues for > further review for inclusion in BORDEAUX-THREADS. > > [1]: > http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff > >> 1) If no other threads are trying to claim the lock, then condition-wait will >> return immediately rather than waiting. > > I couldn't reproduce this behavior. In ABCL, the THREADS:OBJECT-WAIT > implementation is mainly a simple wrapping of the underlying > [java.lang.Object.wait()][2] which clearly should wait. > > [2]: > http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%… > >> 2) If two threads are waiting in condition-wait and two other threads call >> condition-notify, then it is possible that only one thread will return from >> condition-wait because the call to acquire-lock in one of them might return >> nil causing it to wait again. > > The DO looping construct has been replaced with a simpler subsequent > BT:ACQUIRE-LOCK that should solve this bug. > >> 3) If condition-notify is called by one thread when a waiting thread is just >> about to enter the threads:synchronized-on form (but before it gets >> synchronized), then the notify will be lost. This happens because the >> underlying threading primitives have no "memory" of calls to notify when >> nothing it waiting (which is also the expected semantics for POSIX condition >> variables BTW). > > THREADS:SYNCHRONIZED-ON is now the first form executed by > BT:CONDITION-WAIT so the window here is considerably narrowed. > >> Also, I think condition-notify should be using threads:object-notify rather >> than threads:object-notify-all. > > We now use THREADS:OBJECT-NOTIFY. > > > > > -- > "A screaming comes across the sky. It has happened before, but there > is nothing to compare to it now." > > > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

3 3

[armedbear-devel] ASDF 2.013 released
by Faré 20 Mar '11

20 Mar '11

Dear Armed Bear developers, congratulations for your many releases since I last contacted you. I've just released ASDF 2.013. I don't know which version you're using, but there have been numerous small bug fixes and improvements in ASDF. For the sake of sharing those improvements, I think it would be a good time to push ASDF to all Lisp implementations. Could you include it in yours? While abcl is used as part of my automated test suite, I don't often upgrade my abcl copy (currently 0.22.0) -- it would help if there were a debian package. Please make sure ASDF suits your purposes, and contact me with any patch you use for inclusion upstream. PS: I created a mailing-list asdf-announce. Maybe someone amongst you could join it, so I don't need to push my announces to this mailing-list. Or maybe I can just Cc: my announce to this mailing-list and not bother with further explanations? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 20 March 2011 00:29 Subject: ASDF 2.013 released To: asdf-announce(a)common-lisp.net Dear Common Lisp Users, I just blessed ASDF 2.012.12 as 2.013. It includes many small improvements since previous release, for portability, robustness, usability. For the sake of making these improvements available to all users, I invite all vendors and packagers to update their software to include this latest release. Improvements since 2.012: * Fixes and cleanups for CLISP, ECL, SBCL. * Added support for two legacy platforms: (R)MCL, Genera * Cleanup features: now using #+asdf-unix and #+asdf-window * Many cleanups and improvements regarding our portable pathname layer * Fixes a regression in source-registry scanning from 2.011.4 * Remember *source-registry-parameter* and *output-translations-parameter* * Export and document coerce-pathname (f.k.a merge-component-name-type) * allow description and long-description for all components * Several documentation updates Happy hacking, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I hold that America, Champion of the World is a betrayal of its humble beginnings as One Nation Underdog.

2 2

Re: [armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Mark Evenson 18 Mar '11

18 Mar '11

On 3/18/11 4:41 PM, Ville Voutilainen wrote: > On 18 March 2011 17:37, Mark Evenson<evenson(a)panix.com> wrote: >> This was the previous implementation, which was the subject of the >> criticism: >> >> (defun condition-wait (condition lock) >> (check-type condition condition-variable) >> (release-lock lock) >> (do () >> ((acquire-lock lock nil)) >> (threads:synchronized-on condition >> (threads:object-wait condition)))) > > If this is directly mapped to a pthread implementation, the loop must be there. I think it is slightly different, as the semantics of BT:CONDITION-WAIT are merely that the lock is always reacquired before returning. The caller of BT:CONDITION-WAIT is required to check for spurious wakeups. > >> I believe the race condition is on the the synchronization on the condition >> variable, not on the mutex lock. > > The condition variable needs to use the mutex lock given, not a separate lock. The condition variable interface is using the mutex lock specified in BT:CONDITION-WAIT. For the ABCL implementation, I'm using the Java monitor associated with the condition variable for the additional synchronization needed to implement BT:CONDITION-NOTIFY which couldn't use the mutex lock without contention problems. But definitely check my logic here, as it has been faulty before. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

Re: [armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Mark Evenson 18 Mar '11

18 Mar '11

On 3/2/11 8:50 PM, Martin Simmons wrote: > I think that the implementation of condition-wait has some major > problems: Thanks very much for the comments. I have an [updated patch][1] that attempts to address these issues for further review for inclusion in BORDEAUX-THREADS. [1]: http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff > 1) If no other threads are trying to claim the lock, then > condition-wait will return immediately rather than waiting. I couldn't reproduce this behavior. In ABCL, the THREADS:OBJECT-WAIT implementation is mainly a simple wrapping of the underlying [java.lang.Object.wait()][2] which clearly should wait. [2]: http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%… > 2) If two threads are waiting in condition-wait and two other threads > call condition-notify, then it is possible that only one thread will > return from condition-wait because the call to acquire-lock in one of > them might return nil causing it to wait again. The DO looping construct has been replaced with a simpler subsequent BT:ACQUIRE-LOCK that should solve this bug. > 3) If condition-notify is called by one thread when a waiting thread > is just about to enter the threads:synchronized-on form (but before > it gets synchronized), then the notify will be lost. This happens > because the underlying threading primitives have no "memory" of > calls to notify when nothing it waiting (which is also the expected > semantics for POSIX condition variables BTW). THREADS:SYNCHRONIZED-ON is now the first form executed by BT:CONDITION-WAIT so the window here is considerably narrowed. > Also, I think condition-notify should be using threads:object-notify > rather than threads:object-notify-all. We now use THREADS:OBJECT-NOTIFY. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[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