December 2009 - cl-debian@common-lisp.net

[cl-debian] [ann] [rdnzl-announce] New release 0.13.2 (Was: New release 0.13.1)
by Edi Weitz 22 Dec '09

22 Dec '09

On Tue, Dec 22, 2009 at 12:14 PM, Raymond Wiker <rwiker(a)gmail.com> wrote: > Sooo, I think that maybe import-assembly should do something like > > (or [LoadWithPartialName ...] > (let (..) > [Load ...]) Yes, that's of course better. I should have thought of that myself... I made a new release with this change. Thanks and Happy Holidays, Edi. _______________________________________________ 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] [rdnzl-announce] New release 0.13.1 (Was: Could not load file or assembly error)
by Edi Weitz 22 Dec '09

22 Dec '09

I have now released a new version 0.13.1 which uses Load as a fallback (I had the same idea initially) and also exports do-rdnzl-collection. Raymond, thanks again for your help, but essentially this "fix" is against your original idea to catch errors early if an assembly isn't found, right? Do you have a better idea? (And good to hear about your experiences with RDNZL. I don't know of many users who deploy RDNZL "in earnest" - I'm certainly not one of them - but I'm always happy to hear about it.) Seth, thanks for the report. Cheers, Edi. On Tue, Dec 15, 2009 at 12:52 PM, Raymond Wiker <rwiker(a)gmail.com> wrote: > I just checked, and it does not appear that I used gacutil to register > rdnzl.dll. > > I tried running the messagebox example, using rdnzl 0.12.2 and 0.13. > 0.12.2 works, 0.13 does not. If I modify import.lisp so that > load-assembly uses the old code (with LoadWithPartialName), the > example works. Likewise if I change the code to try > LoadWithPartialName first, with Load (as used in 0.13) as a fallback. > The fallback probably won't help in the loading, but may be useful for > error trapping/reporting. > > Sorry about this - I will remember to test the demo programs as well > as my own code the next time... > > If you end up doing a new version instead of a rollback, it would be > good to have do-rdnzl-collection exported - it is implemented and > documented, but not exported (exactly as it was in the patch i sent, > so this, too, is my fault; again, sorry.) > > On a more positive note: I'm using rdnzl for feeding documents into a > search engine, and rdnzl works just great for me - good performance, > and no sign of any memory leaks - and also reasonably easy to get > working. Thanks again for allowing me to do (almost) Microsoft-free > programming under Windows :-) > > On Tue, Dec 15, 2009 at 11:51 AM, Raymond Wiker <rwiker(a)gmail.com> wrote: >> Could be due to the patch, but I think you may have to explicitly >> register rdnzl.ddl (using gacutil)? I seem to remember that I had to >> do that on Win7. I'll take a look on my Win7 installation. >> >> On Tue, Dec 15, 2009 at 8:03 AM, Edi Weitz <edi(a)agharta.de> wrote: >>> Hi Raymond, >>> >>> I think this is due to your recent patch. Isn't this supposed to work anymore? >>> >>> Thanks, >>> Edi. >>> >>> >>> On Tue, Dec 15, 2009 at 12:10 AM, Seth Burleigh <seth(a)tewebs.com> wrote: >>>> Im attempting to get this to work on windows 7. I have .net 3.5 installed >>>> but when I try this. >>>> >>>> >>>> >>>> (defpackage :rdnzl-test (:use :cl :rdnzl)) >>>> >>>> (in-package :rdnzl-test) >>>> >>>> >>>> >>>> (enable-rdnzl-syntax) >>>> >>>> (import-types "System.Windows.Forms" >>>> >>>> "MessageBox" "MessageBoxButtons" "DialogResult") >>>> >>>> >>>> >>>> >>>> >>>> I get the error >>>> >>>> .NET error (System.IO.FileNotFoundException): Could not load file or >>>> assembly 'System.Windows.Forms' or one of its dependencies. The system >>>> cannot find the file specified. >>>> >>>> >>>> >>>> Im pretty new to all of this, though im guessing this has something to do >>>> >>>> with setting environmental vars or something. But since you know the library >>>> >>>> I figure you’ll probably know the solution. >>>> >>>> >>>> >>>> Looking forward to getting this to work! Thanks! >>>> >>>> >>>> _______________________________________________ >>>> 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] [closer-announce] [CfP] ELS 2010
by Pascal Costanza 14 Dec '09

14 Dec '09

3rd European Lisp Symposium =========================== <http://www.european-lisp-symposium.org> May 6-7, 2010, Fundacao Calouste Gulbenkian, Lisbon, Portugal Important Dates ~~~~~~~~~~~~~~~~ + Submission Deadline: *January 29, 2010* + Author Notification: March 1, 2010 + Final Paper Due: March 26, 2010 + Symposium: *May 6-7, 2010* We hope, as in previous years, to invite authors of accepted research contributions to submit an extended version of their papers to a special issue of the Journal of Universal Computer Science (J.UCS). 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. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2010 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. Topics include, but are not limited to: + Language design and implementation + Language integration, interoperation and deployment + Development methodologies, support and environments + Reflection, protocols and meta-level architectures + Lisp in Education + Parallel, distributed and scientific computing + Large and ultra-large-scale systems + Hardware, virtual machine and embedded applications + Domain-oriented programming + Lisp pearls + Experience reports and case studies We invite submissions (through EasyChair) in two categories: original contributions and tutorials. * Original contributions should neither have been published previously nor be under review in any other refereed events or publication. Research papers should describe work that advances the current state of the art, or presents old results from a new perspective. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The programme committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. * Tutorial submissions should be extended abstracts of up to four pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The programme committee will evaluate tutorial proposals based on the likely interest in the topic matter, the clarity of the presentation in the extended abstract, and the scope for interactive participation. The tutorials will run during the symposium on May 6, 2010. Programme Chair ~~~~~~~~~~~~~~~~ Christophe Rhodes, Goldsmiths, University of London, UK Local Chair ~~~~~~~~~~~~ Antonio Leitao, Technical University of Lisbon, Portugal Programme Committee ~~~~~~~~~~~~~~~~~~~~ + Marco Antoniotti, Universita Milano Bicocca, Italy + Giuseppe Attardi, Universita di Pisa, Italy + Pascal Costanza, Vrije Universiteit Brussel, Belgium + Irene Anne Durand, Universite Bordeaux I, France + Marc Feeley, Universite de Montreal, Canada + Ron Garret, Amalgamated Widgets Unlimited, USA + Gregor Kiczales, University of British Columbia, Canada + Nick Levine, Ravenbrook Ltd, UK + Scott McKay, ITA Software, Inc., USA + Peter Norvig, Google Inc., USA + Kent Pitman, PTC, USA + Christian Queinnec, Universite Pierre et Marie Curie, France + Robert Strandh, Universite Bordeaux I, France + Didier Verna, EPITA Research and Development Laboratory, France + Barry Wilkes, Citi, UK + Taiichi Yuasa, Kyoto University, Japan -- 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 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