announcements January 2006

announcements@common-lisp.net

2 participants
8 discussions

[ann] [flexi-streams-announce] New version 0.5.2 (Was: patch: FLEXI-OUTPUT-STREAM superclasses)
by Edi Weitz 25 Jan '06

25 Jan '06

On Wed, 25 Jan 2006 14:46:12 -0800, James Bielman <jamesjb(a)jamesjb.com> wrote: > I need to replace a horrible mess of character stream vs binary > stream code at work and flexi-streams looks like it will help clean > all this up nicely. Good... :) > LispWorks (4.3.7 on Linux) was complaining about > flexi-output-streams not being output-streams because the > superclasses are incorrect---here's a patch: Ouch! How could that work at all? Needless to say that LW 4.4.6 didn't complain because that's what I'm using all the time. Thanks, I've uploaded a corrected version. Cheers, Edi. ChangeLog Version 0.5.2 2006-01-26 Fixed typos in stream.lisp (thanks to James Bielman) Download <http://weitz.de/files/flexi-streams.tar.gz> _______________________________________________ flexi-streams-announce mailing list flexi-streams-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-announce

1 0

[ann] [tbnl-announce] New release 0.9.5
by Edi Weitz 22 Jan '06

22 Jan '06

ChangeLog: Version 0.9.5 2006-01-22 Made creation of REQUEST object safer (thanks to Robert J. Macomber) Replaced some erroneous DECLAIMs with DECLAREs (thanks to SBCL's style warnings) Slight documentation enhancements Download: <http://weitz.de/files/tbnl.tar.gz> Cheers, Edi. _______________________________________________ tbnl-announce site list tbnl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-announce

1 1

[ann] [closer-announce] Closer Project: New Releases
by Pascal Costanza 19 Jan '06

19 Jan '06

Today, I have released new versions of all the packages currently included in the Closer Project - see http://common-lisp.net/project/ closer/ for the project and http://p-cos.blogspot.com/2006/01/closer- project-new-releases.html for the announcment. This project is an umbrella project for a few subprojects whose aim is to improve the usability of the CLOS MOP across different Common Lisp implementations. It is also the home of ContextL, a full-fledged CLOS extension in its own right providing language constructs for Context-oriented Programming (COP). All packages now support the current versions of all supported Common Lisp implementations. They are: • Allegro Common Lisp 7.0 Enterprise Edition. • Allegro Common Lisp 8.0 Enterprise Edition. • CLisp 2.35 - 2.37 • CMU Common Lisp 19c • LispWorks 4.4.5, 4.4.6 for Macintosh, Personal Edition • LispWorks 4.4.5, 4.4.6 for Macintosh, Professional Edition • Macintosh Common Lisp 5.1 • OpenMCL 1.0 • SBCL 0.9.7, 0.9.8 Highlights of the new versions. MOP Feature Tests 0.4: • All previous known but untested problems have either been resolved or turned into actual tests. • Added a test for checking whether the slot order requested by a primary method for COMPUTE-SLOTS is honored by a MOP. (Thanks to Christophe Rhodes for the suggestion.) • Added a test for checking whether the object returend by COMPUTE- DISCRIMINATING-FUNCTION can be funcalled and whether the second parameter to SET-FUNCALLABLE-INSTANCE-FUNCTION can be a 'real' closure. • Added a test for checking whether one can use one's own :ALLOCATION kinds. • Added a test for checking whether a generic function without any methods defined can still be called. • Added a test for checking whether a DEFMETHOD form can have multiple qualifiers. • Added more fine-grained tests for checking SLOT-XXX-USING-CLASS functions. • Added a test whether REINITIALIZE-INSTANCE on a class metaobject calls FINALIZE-INHERITANCE. Luckily, all implementations pass that test. Closer to MOP 0.3: • The supported Common Lisp implementations improved with regard to their support for the MOP, with varying extent. This required a few changes here and there. • The lack of extensible :ALLOCATION kinds in Allegro Common Lisp, as specified in AMOP, is fixed. Thanks to John Foderaro for giving me the important hint on how to solve this. ContextL 0.2: • When rebinding special places, it is now checked whether they actually contain special symbols, so this is now a safe operation. This can be tweaked to omit the check for improved performance. • Changing a non-special slot to a special slot in an already existing class is now also supported in Allegro Common Lisp from 7.0 on. Thanks to Duane Rettig for fixing the related bug in Allegro and thereby enabling this feature. • Improved parsing of layered methods: The :METHOD option in DEFINE- LAYERED-FUNCTION is now parsed and processed correctly. Furthermore, one can now optionally give a name to the otherwise anonymous layer parameter. This is useful for calling CALL-NEXT-METHOD with changed parameters. • Added a new namespace for layers. Before, their names could accidentally clash with class names. • Added a number of performance tweaks and better error messages. • Fixed a few bugs. Special thanks go to John Foderaro, Duane Rettig and Christophe Rhodes (in alphabetical order) for exceptional help. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium _______________________________________________ closer-announce mailing list closer-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/closer-announce

1 0

[ann] [rdnzl-announce] Re: New versions 0.8.0/0.5.0
by Edi Weitz 16 Jan '06

16 Jan '06

On Mon, 16 Jan 2006 00:58:59 +0000, "lisp" <lisp(a)spikeisland.com> wrote: > I am happy to report that this works! Great! > If you run the function gc-test below in a LWW DLL image, you can > see the delegate adapter for the Click event being reclaimed and > releasing the closure from the callback hash table. > > If you open a process browser window *before* running this, you will > see the process created by LWW to handle the callback from .NET's gc > thread. Inspecting this process's arguments reveals > (rdnzl:%foreign-callable/releasedelegateadapter). This process is > used for all subsequent callbacks from the gc thread. If you kill > it, a new one will be created for the next gc callback. > > If you run this code in a conventional .exe LWW image you do not get > the callback from .NET's gc thread. Thanks for the detailed info. I'll try this tomorrow. > I have run into a further problem - with LWW this time I think. As > far as I can tell, LWW will occasionally run a foreign callback on > the wrong thread resulting in a stack overflow exception condition > being raised. With a form running in a new process and generating > event callbacks, the listener process occasionally reports a stack > overflow and shows the callback happening in *its* backtrace - > presumably confusing the stack check. I've not yet been able to > verify this or reproduce it reliably. > > Any thoughts or suggestions would be welcome... No idea. But it would be /very/ helpful if you could reproduce this and submit a bug report to LispWorks support. As you'll know they're currently working on the 5.0 release which will have some changes in the threading code as well. It'd be nice if they could fix that before they release the new version. Thanks again, Edi. _______________________________________________ rdnzl-announce mailing list rdnzl-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-announce

1 0

[ann] [rdnzl-announce] New versions 0.8.0/0.5.0 (was: bug in delegate adapter release mechanism)
by Edi Weitz 13 Jan '06

13 Jan '06

Hi Dominic! On Fri, 13 Jan 2006 00:29:08 +0000, "lisp" <lisp(a)spikeisland.com> wrote: > I've tracked down what looks to be a bug in the mechanism for > releasing delegate adapters. > > The foreign callable ReleaseDelegateAdapter is declared with a > return type of ffi-void-pointer but tries to return the result of > remhash - a boolean. On LWW (at least) this results in: > > Condition: T cannot be converted to foreign type :POINTER. Call to > SYSTEM::FOREIGN-CALLABLE-ENTRY-POINT-NEW-PROCESS-AUX (offset 21) > SYSTEM::FUNC : RDNZL::%FOREIGN-CALLABLE/RELEASEDELEGATEADAPTER > > I would suggest changing it (and the corresponding initialisation > and DLL code) to have a void return type: > > (ffi-define-callable (ReleaseDelegateAdapter ffi-void) > ((index ffi-integer)) ;; remove entry from hash table if CLR is done with it > (remhash index *callback-hash*)) > > Also, in DelegateAdapter.cpp you have a comment on the destructor > that it doesn't appear to be working: > > // the destructor notifies Lisp that this instance is no longer used - > // at least in theory, this doesn't seem to work right now > DelegateAdapter::~DelegateAdapter() { release(indexIntoLisp); } > > This may have beeen the caused by the callback/threading issues > discussed recently. At least it has certainly worked for me here > (hence this bug report) when using a DLL based LWW image (many > thanks for your recent example of this). Perhaps the .NET GC is > running in a different thread, so the callback was failing in a > normal .EXE image? Makes perfect sense to me. I've updated both the Lisp and the C++ code according to your recommendations - see ChangeLogs below. However, I'm a bit in a hurry and I couldn't figure out an easy example which shows that ReleaseDelegateAdapter is actually called - at least not from a DLL-based LWW image. Could you please check if it works and report back to the list if possible? Thanks a lot, Edi. Lisp code: ---------- Version 0.8.0 2006-01-13 Fix mechanism which releases delegate adapters (thanks to Dominic Robinson) Updated to DLL version 0.5.0 <http://weitz.de/files/RDNZL.tar.gz> C++ code (optional): -------------------- Version 0.5.0 2006-01-13 Fix mechanism which releases delegate adapters (thanks to Dominic Robinson) <http://weitz.de/files/RDNZL_cpp.tar.gz> _______________________________________________ rdnzl-announce mailing list rdnzl-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-announce

1 0

[ann] [tbnl-announce] New: TBNL 0.9.4, Hunchentoot 0.1.2
by Edi Weitz 03 Jan '06

03 Jan '06

ChangeLog TBNL: Version 0.9.4 2006-01-03 Handle "Expect: 100-continue" for non-Apache front-ends Re-introduced IGNORE-ERRORS in GET-REQUEST-DATA ChangeLog Hunchentoot: Version 0.1.2 2006-01-03 Mention TBNL version number in server name header Download: <http://weitz.de/files/tbnl.tar.gz> <http://weitz.de/files/hunchentoot.tar.gz> Have fun, Edi. _______________________________________________ tbnl-announce site list tbnl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-announce

1 0

[ann] [tbnl-announce] New Hunchentoot release 0.1.1
by Edi Weitz 01 Jan '06

01 Jan '06

ChangeLog: Version 0.1.1 2005-12-31 Fixed package stuff and HYPERDOC support Download: <http://weitz.de/files/hunchentoot.tar.gz> Cheers, Edi. _______________________________________________ tbnl-announce site list tbnl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-announce

1 0

[ann] [tbnl-announce] New release 0.9.3
by Edi Weitz 01 Jan '06

01 Jan '06

Hi and Happy New Year! ChangeLog: Version 0.9.3 2006-01-01 Fixed bug in READ-HTTP-REQUEST Download: <http://weitz.de/files/tbnl.tar.gz> Cheers, Edi. _______________________________________________ tbnl-announce site list tbnl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-announce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

announcements January 2006