- cl-debian@lists.common-lisp.net - mailman3.common-lisp.net

[cl-debian] [ann] [closer-announce] New project: filtered functions
by Pascal Costanza 04 Dec '09

04 Dec '09

Hi, I am very excited that I can finally annouce a public release of 'filtered functions', an extension of generic functions that Charlotte Herzeel, Jorge Vallejos, and myself have developed some time ago and that we are very excited about because it seems to be quite powerful in a number of very different scenarios. It took a while to release filtered functions, because it is a quite non-trivial extension of generic functions and requires a CLOS MOP implementation that is compliant with the AMOP specification to quite a deep level. Therefore, this required some serious preparation in the form of a much improved Closer to MOP library, that I released today as well. You can find filtered functions at the Closer project website at http://common-lisp.net/project/closer/ - below you will find a general overview of the concept. Filtered functions are an extension of generic functions, extended with a filtering step where the arguments received by a generic function are mapped to other values based on user-defined mapping functions. Those filtered values are then used to perform the actual selection and execution of applicable methods. Nevertheless, the methods that are eventually executed see the original objects as received by the generic function, and not the filtered ones. Here are some examples to illustrate the expressive power of filtered functions. Factorial ========= In order to be able to use filtered functions, we need to have filter functions that map received arguments to values that we actually want to base our dispatch on. For the factorial function, we want to distinguish between negative and positive numbers, and the number zero. For that we can just use the Common Lisp function SIGNUM that returns +1 for positive numbers, -1 for negative numbers, and just 0 for the number 0. The filtered function FAC can thus be defined as follows. (define-filtered-function fac (n) (:filters (:sign #'signum))) DEFINE-FILTERED-FUNCTION is exactly like DEFGENERIC, except that it can also define one or more filters. Here, it defines a filter with the name :SIGN wich specifices that the function SIGNUM is to be used for filtering. We can now define methods for FAC: (defmethod fac :filter :sign ((n (eql +1))) (* n (fac (- n 1)))) (defmethod fac :filter :sign ((n (eql 0))) 1) (defmethod fac :filter :sign ((n (eql -1))) (error "Fac not defined for negative numbers.")) Here, we use the qualifiers :FILTER :SIGN in the method definitions to indicate that we indeed want to use the :SIGN filter for method selection. We then use EQL specializers to ensure that the method definitions are applicable for the three different cases that SIGNUM yields. Remember that the method bodies always see the original arguments, not the filtered ones, and this is why the FAC methods can do the correct computations. State pattern ============= Filtered functions can be used to dispatch methods based on the state of an argument passed to a filtered function, which enables expressing State-like idioms. Assume the following simple CLOS class is defined for implementing a stack. (defconstant +stack-size+ 10) (defclass stack () ((contents :initform (make-array +stack-size+) :reader stack-contents)) (index :initform 0 :accessor stack-index))) Instances of this class have three different states: Such a stack can either be empty, or full, or anywhere in between (in 'normal' state). We can express this as a function that recognizes the state of a stack. (defun stack-state (stack) (cond ((<= (stack-index stack) 0) 'empty) ((>= (stack-index stack) +stack-size+) 'full) (t 'normal))) It is now straightforward to use stack-state in a filter named :state for the typical stack operations. (define-filtered-function stack-push (stack value) (:filters (:state #'stack-state))) (define-filtered-function stack-pop (stack) (:filters (:state #'stack-state))) (define-filtered-function stack-emptyp (stack) (:filters (:state #'stack-state))) We can now group the behavior of a stack according to its different states. Note that for 'normal' state, we do not need to mention the use of any filter here, because the methods are not specialized on anything specific anyway. (Filtered functions always allow for 'regular' methods alongside the filtered methods.) ;;; Normal state (defmethod stack-push (stack value) (setf (aref (stack-contents stack) (stack-index stack)) value) (incf (stack-index stack))) (defmethod stack-pop (stack) (decf (stack-index stack)) (aref (stack-contents stack) (stack-index stack))) (defmethod stack-emptyp (stack) nil) ;;; Empty state (defmethod stack-pop :filter :state ((stack (eql 'empty))) (error "Stack is empty.")) (defmethod stack-emptyp :filter :state ((stack (eql 'empty))) t) ;;; Full state (defmethod stack-push :filter :state ((stack (eql 'full)) value) (error "Stack is full.")) Note that we used a derived state function here, that determines the state of the stack based on some of its other properties. Since filter functions can be any functions, we could also use the reader of a slot as a filter function, and thus have the behavior of a filtered function depend on the explicit state of an object. Filtered functions can do a lot more: As already mentioned, they can use more than one filter; filter functions can see all the arguments a generic function receives; and filters can be guarded, which means that methods that use a particular filter may be completely ignored if the arguments don't fulfil a certain predicate. You can read the paper "Filtered Dispatch" at http://p-cos.net/documents/filtered-dispatch.pdf that I co-authored with Charlotte Herzeel, Jorge Vallejos and Theo D'Hondt for a more thorough introduction, background information and semantics, and which also includes an extensible metacircular Lisp interpreter as an example, based on implementing EVAL as a filtered function. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages 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 _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [closer-announce] New version of ContextL (v0.6)
by Pascal Costanza 04 Dec '09

04 Dec '09

Hi, I have just released a new version of ContextL. Here are the new features: + ContextL now supports delimited first-class dynamic environments and DYNAMIC-WIND. Due to popular demand, these feature can be used independently of the rest of ContextL, by way of using a separate system definition. (In that case, no features of CLOS MOP are used, so this should run in any ANSI-compliant Common Lisp implementation.) + Added support for Embeddable Common Lisp and resurrected support for Macintosh Common Lisp. Unfortunately, the CLOS MOP of Scieneer Common Lisp is too weak, so I cannot support ContextL there (yet). + Dependencies on portable-threads and trivial-garbage are removed - these libraries are no longer necessary for ContextL to work. + Improved use of synchronization features in multi-threaded Common Lisp implementations. + Lots of special thanks to the following people who provided useful patches and comments: Willem Broekema, Theam Yong Chew, Alexander Gravilov, Attila Lendvai, and Tobias Rittweiler. Extra special thanks to Duane Rettig (of Franz Inc.) and Martin Simmons (of LispWorks Ld.) for helping with Allegro-specific and LispWorks-specific issues. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages 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 _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [closer-announce] New release of Closer to MOP (v0.6)
by Pascal Costanza 04 Dec '09

04 Dec '09

Hi, I have just released a new version of Closer to MOP. This is a major new release, with a couple of substantial improvements: + Support for Embeddable Common Lisp has been completely reworked, and ECL is now officially supported in Closer to MOP (from ECL 9.12.2 on). + Macintosh Common Lisp has been reactivated as an open source project, and the support for MCL in Closer to MOP has been resurrected. + Scieneer Common Lisp is now supported to some degree as well. + In total, Closer to MOP now supports 9 different Common Lisp implementations: Allegro Common Lisp, CLisp, Clozure Common Lisp, CMU Common Lisp, Embeddable Common Lisp, LispWorks, Macintosh Common Lisp, Steel Bank Common Lisp, and Scieneer Common Lisp. + I have added support for the complete generic function invocation protocol. This includes COMPUTE-APPLICABLE-METHODS, COMPUTE-APPLICABLE-METHODS-USING-CLASSES, COMPUTE-DISCRIMINATING-FUNCTION, and COMPUTE-EFFECTIVE-METHOD, and MAKE-METHOD-LAMBDA (!). On top of that, Closer to MOP adds a missing piece in the protocol, namely COMPUTE-EFFECTIVE-METHOD-FUNCTION, for turning an effective method form into an actual function. Note, however, that support for the generic invocation is not available in all supported Common Lisp implementations: CMU Common Lisp, Macintosh Common Lisp and Scieneer Common Lisp unfortunately don't provide the necessary extensibility to support the protocols at all, and ECL has the slight restriction that method lambda forms have the same lambda list as the generic function for which they are defined, and not the format as specified in AMOP. + In previous Closer to MOP versions, the standard metobject definition macros and functions (DEFCLASS, DEFGENERIC, DEFMETHOD, ENSURE-CLASS, ENSURE-GENERIC-FUNCTION, etc.) sometimes forced the use of the replacement 'standard' metaobject classes of Closer to MOP (STANDARD-CLASS, STANDARD-GENERIC-FUNCTION and STANDARD-METHOD). This is now completely removed: If you don't use a :METACLASS or :GENERIC-FUNCTION-CLASS option explicitly, these defining operators will use the internal metaclasses of the respective Common Lisp implementation, under the assumption that they are usually more efficient than the replacements in Closer to MOP. If for some reason, you want to ensure to use the replacements, you have to do so explicitly. (Note: The main purpose of the replacements is to provide a common compatible basis for your own metaobject subclasses, not to be used in their own right.) + When synchronization is necessary, the code for Allegro Common Lisp and LispWorks now uses constructs that are compatible with their respective future SMP support. + In ECL and LispWorks, it is necessary to 'de-optimize' slot accesses for the reader and writer methods specified in DEFCLASS forms in order to ensure that SLOT-VALUE-USING-CLASS and (SETF SLOT-VALUE-USING-CLASS) are correctly used. This now only happens if there are actually applicable definitions available for them. Otherwise, they use the native optimized slot access. + Extra special thanks to Duane Rettig, Steve Haflich, and Juan Jose Garcia-Ripoll for fixing extra hard bugs in extra short amount of time. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages 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 _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [drakma-announce] New releases (1.1.0) of Drakma and Chunga...
by Edi Weitz 01 Dec '09

01 Dec '09

...can be found at the usual location. If you update one of the libraries, please update both. What's new? http://weitz.de/drakma/CHANGELOG.txt http://weitz.de/chunga/CHANGELOG.txt Thanks, Edi. _______________________________________________ drakma-announce mailing list drakma-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [cl-gd-announce] New release 0.5.7 (Was: cl-gd patch)
by Edi Weitz 23 Nov '09

23 Nov '09

2009/11/15 Jeff Cunningham <j.k.cunningham(a)comcast.net>: > In any event, now that I've seen Hans' request, I slapped my forehead for > not seeing the debug statements, removed them, and here's the remade patch. I've now uploaded release 0.5.7 which contains your patch. Thanks, Edi. _______________________________________________ cl-gd-announce mailing list cl-gd-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-gd-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [rdnzl-announce] New release 0.13.0 (Was: [rdnzl-devel] LoadWithPartialName vs Load)
by Edi Weitz 12 Nov '09

12 Nov '09

Thanks Raymond, I've just made a new release. I made a few cosmetic changes, so please check if I didn't break anything. On Tue, Nov 10, 2009 at 11:55 AM, Raymond Wiker <rwiker(a)gmail.com> wrote: > I've had a little startup trouble with RDNZL, but this is mainly due to my > lack of familiarity with .NET. The use of Load instead of > LoadWithPartialName will most likely not be noticed by most people, but will > provide (IMO) more helpful behaviour in case of errors. It can also be > extended, at some later point, to use fully-qualified assembly names. > > The enclosed patch includes the trivial change to load-assembly, as well as > a new macro called do-rdnzl-container. do-rdnzl-container does for general > enumerable collections what do-rdnzl-arrays does for arrays. > > Thank you for making rdnzl available! > > > > > On Nov 9, 2009, at 22:16 , Edi Weitz wrote: > >> Hi Raymond, >> >> I have to admit that I rarely, if ever, used RDNZL myself. I started >> writing it for fun and only finished it because I gave a talk about >> it. At that time I was ambitious enough to bring it into a usable >> state, but as I didn't have any serious projects relying on it, I >> didn't keep track with .NET development and I'm sure it's out of tune >> now. >> >> If you have changes to make RDNZL better, I'm happy to accept patches, >> but I won't be able to test or evaluate them due to lack of time. >> I'll simply pack them into a new release if they follow the usual >> patch guidelines: >> >> http://weitz.de/patches.html >> >> Thanks, >> Edi. >> >> >> On Mon, Nov 9, 2009 at 9:36 AM, Raymond Wiker <rwiker(a)gmail.com> wrote: >>> >>> Hi, >>> I'm trying to use rdnzl to interface with certain .NET libraries. >>> These libraries have a callback mechanism that requires me to subclass >>> a C# class (or implement a C# interface) with two specific methods. I >>> haven't seen any mention that RDNZL can be used to subclass C# classes >>> (which I guess would be non-trivial to do), so I'm guessing that I >>> need to write a C# wrapper class for interfacing with Lisp. >>> >>> I'm having certain problems with this, probably caused by some .NET >>> details that I haven't (yet) understood. As part of unravelling this, >>> I've discovered that import-assembly calls load-assembly and that a >>> failure in load-assembly will cause a null assembly to be returned, >>> from which import-assembly will import exactly zero items. In other >>> words, any errors from load-assembly will not be signalled until >>> later. >>> >>> The MS documentation states that LoadWithPartialName (as used by >>> load-assembly) is an obsolete call, and that that >>> System.Reflection.Assembly.Load() should be used instead. Load() can >>> even be used with partial names, like this: >>> >>> (defun load-assembly-2 (name) >>> (let ((fullname (new "System.Reflection.AssemblyName"))) >>> (setf [%Name fullname] name) >>> [System.Reflection.Assembly.Load fullname])) >>> >>> I've just tried this, and load-assembly-2 gives an exception which is >>> transferred perfectly through RDNZL in cases where load-assembly >>> returns null. >>> >>> Regards, >>> Raymond Wiker >>> >>> _______________________________________________ >>> rdnzl-devel mailing list >>> rdnzl-devel(a)common-lisp.net >>> http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel >>> >>> >> >> _______________________________________________ >> rdnzl-devel mailing list >> rdnzl-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel > > > _______________________________________________ rdnzl-announce mailing list rdnzl-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [cl-ppcre-announce] New release 2.0.3
by Edi Weitz 28 Oct '09

28 Oct '09

There's a new release 2.0.3 out which you can download from the usual place. The change from 2.0.2 to 2.0.3 is only relevant to LispWorks users. Edi. _______________________________________________ cl-ppcre-announce mailing list cl-ppcre-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-ppcre-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [parenscript-announce] New Parenscript release.
by Vladimir Sedach 21 Sep '09

21 Sep '09

Hello, A new version of Parenscript has been released. This release comes with partial support for LOOP and DESTRUCTURING-BIND Common Lisp facilities (thanks to the efforts of Daniel Gackle and Scott Bell), much faster compilation speed, many bugfixes, real and efficient lexical scoping for all special forms that introduce bindings, as well as the ability to direct compiler output directly to a stream. One thing that has been removed is support for the dot symbol notation (ie - 'object.property' would be special cased into (slot-value object 'property) by the compiler) - this has been done to allow Parenscript code to be a useful target for code walkers designed for regular Lisp code. The consequence is that any code that relies on the dot notation will need to be changed to use non-opaque object slot access. Thank you, Vladimir _______________________________________________ parenscript-announce mailing list parenscript-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] [ann] [cl-cairo2-announce] syntax change in cl-cairo2
by Tamas K Papp 24 May '09

24 May '09

Hi everyone, I pushed a new version of cl-cairo2 to the GIT repository http://github.com/tpapp/cl-cairo2/tree/master where it is kept now. The most important change is that I disposed of the *context* global variable, and moved context to the first argument, so now you write (move-to context 0 -2) instead of (move-to 0 -2 context) or (setf *context*) (move-to 0 -2) I know this is an important change in syntax, and may break a lot of code. I apologize for the inconvenience, but this has been a major wart on the initial design and I have always wanted to fix it. Best, Tamas _______________________________________________ cl-cairo2-announce mailing list cl-cairo2-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-cairo2-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 1

[cl-debian] You are no longer subscribed to qbook
by owner＠packages.qa.debian.org 30 Mar '09

30 Mar '09

Processing commands for pts(a)qa.debian.org: > Subject: Re: CONFIRM 5f4a0ae6e1be87c0f7759b3c98f49ebd cl-debian(a)common-lisp.net has been unsubscribed from qbook(a)packages.qa.debian.org. > > On Mon, 30 Mar 2009 20:46:57 +0200, > > As list administrator, your authorization is requested for the > > following mailing list posting: > > > > List: cl-debian(a)common-lisp.net Five lines without new commands: stopping. 1 command(s) successfully treated. Good bye !

1 0