February 2006 - announcements - mailman3.common-lisp.net

[ann] [cl-emb-announce] New release CL-EMB 0.4.3
by Stefan Scholl 19 Feb '06

19 Feb '06

New release CL-EMB 0.4.3 CL-EMB is a library to embed Common Lisp and special template tags into normal text files. Can be used for dynamically generated HTML pages. You can download it from http://common-lisp.net/project/cl-emb/ or install with ASDF-Install. CL-USER> (asdf:operate 'asdf:load-op :asdf-install) CL-USER> (asdf-install:install :cl-emb) Changes: - Faster file reading (fast slurping from <http://www.emmett.ca/~sabetts/slurp.html>) - New template tag @insert for inserting (text) files. Example: CL-USER> (emb:register-emb "test13" "The file:<pre><% @insert textfile %></pre>") #<CL-EMB::EMB-FUNCTION {5894326D}> CL-USER> (emb:execute-emb "test13" :env '(:textfile "/etc/gentoo-release")) "The file:<pre>Gentoo Base System version 1.6.14 </pre>" _______________________________________________ cl-emb-announce site list cl-emb-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/cl-emb-announce

1 0

[ann] [rdnzl-announce] New version 0.9.4
by Edi Weitz 18 Feb '06

18 Feb '06

On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" <s8ctxw402(a)sneakemail.com> wrote: > In port-lw.lisp, FFI-MAP-TYPE, change :float to :lisp-float. Yep, thanks, that (and adding :LANGUAGE :ANSI-C) did the trick! I've uploaded 0.9.4 which should work now. Could you please test? I'm a bit in a hurry because we're moving to a new flat on Wednesday... ) Thanks for your help, 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 version 0.9.3 (Was: (no subject))
by Edi Weitz 17 Feb '06

17 Feb '06

On Fri, 17 Feb 2006 00:49:16 -0500, "Dan Muller" <s8ctxw402(a)sneakemail.com> wrote: > My first post to this list... Hi... :) > Direct3D uses single floats throughout its interface, but in > LispWorks for Windows, all floating point types are equivalent to > double-float. So I've got this rather difficult situation, where > RDNZL can never find a method if it takes a single float argument! > Even if it could find it, a down-conversion from double to single > float would be needed, which probably shouldn't occur implicitly. > > I tried explicitly calling System.Convert.ToSingle, but by the time > I can get my hands on the return value, it has been turned back into > a double! I haven't been able to figure out a way around this > without modifying RDNZL, or writing some sort of .NET function that > returned a boxed single. But I'm not sure that the latter wouldn't > be unboxed, or that it would give the correct type for the method > lookup in RDNZL. Yeah, tough call. I don't see an easy general solution but for the moment I've uploaded version 0.9.3 which offers the following workaround: <http://weitz.de/rdnzl/#*coerce-double-floats-to-single*> You should be able to (temporarily) rebind this variable to T for single float arguments. Well, UNLESS your .NET method's signature contains both System.Single /and/ System.Double. Let me know if that helps or if you have a better idea. Cheers, Edi. _______________________________________________ rdnzl-announce mailing list rdnzl-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-announce

1 0

[ann] [gsharp-announce] Gsharp progress report
by Robert Strandh 15 Feb '06

15 Feb '06

Dear mailing list member, As promised, here is another Gsharp progress report, again mainly for those who follow neither the CVS mailing list nor the #lisp IRC channel. I have worked on several different things since the last progress report: * Key signatures are now Gsharp objects (as opposed to just vectors) with their own protocol. I did not change the external format yet again, and instead made it possible for the current one to deal with either representation; * Gsharp can now handle elements with zero duration. That turned out to be a major reorganization of the code. This functionality will be used for elements such as key signature changes and clef changes; * I changed the class hierarchy of elements according to a suggestion by Christophe Rhodes, so that there is now an additional class `rhythmic-element' that represents elements with non-zero duration; * The external format for representing buffer objects has been modified, though Gsharp can still read the old format. The new format is easier to extend with new types of objects. Instead of using a dispatch macro character, there is now a single macro character `[', which is followed by a fully qualified symbol name that indicates the name of the class of the object; * I reorganized the command tables so that the one used by the command loop can be determined by the type of the current layer, and the type of the element preceding the cursor. This makes it easier to use the same key strokes for different kinds of elements and different kinds of layers; * I started implementing ties. The code for representing ties in the buffer seems to be working. However, rendering ties is hard, and requires access to the book by Ted Ross, which I have now ordered so that I can finish this work. Rendering ties turns out to be messy in other ways as well, since most rendering code at the moment works "vertically" by measures, whereas ties need to be processed "horizontally" by layers; * I introduced two new packages esa-buffer and esa-io (that I hope will become part of a separate ESA library one day) which contain code adapted from Climacs that manages buffer/file i/o in an application independent way. I made Gsharp take advantage of these new packages to behave more like an editor application should, with named buffers and Emacs-style file i/o (C-x C-s, C-x C-w, etc); * Gsharp now has an `info pane' (what Emacs calls "mode line") that shows the name of the buffer, whether it needs saving, etc. Documentation changes: * I updated the documentation to reflect an old change from using a CLIM interactor pane to using an ESA minibuffer. The documentation is still not fully up-to-date, nor is it complete, but it is better than it was. New score: * There is a new, partially-completed score in the Scores directory. It is a tune used in a commercial on NZ TV. Minor fixes: * Fixed a bug that made Gsharp crash for empty clusters. These were used in one of the scores in the Scores directory, but I had not used that particular score to test Gsharp for a while. Now, all the scores in the Scores directory should work; * Fixed a bug that ignored the explicit x-offset of elements. This bug was introduced when the spacing algorithm was altered. One of the scores in the Scores directory needs explicit x-offsets in order to avoid overlaps of elements in crossing voices; * The temporary midi file generated by the `play' commands is not put in /tmp. It is still not uniquely named, nor is it cleaned up; * Fixed a bug that did not recognize modifications to lyrics elements so did not invalidate the corresponding element. Related fixes: * I modified the font viewer in the Fonts directory (another CLIM application) to play nicely with the others, and not destroy the port. Now the viewer can be used from the CLIM Desktop. That's all for this time. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- _______________________________________________ gsharp-announce site list gsharp-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/gsharp-announce

1 0

[ann] [rdnzl-announce] New version 0.9.2 (Was: Problem with invoking static member)
by Edi Weitz 13 Feb '06

13 Feb '06

On Thu, 9 Feb 2006 14:20:59 -0500 (EST), Jim Sokoloff <jim(a)sokoloff.com> wrote: > I'll propose the following patch (attached) to invoke: > > Currently it takes an object (for an instance method) or a type name > (for a static method). > > After this patch, object can also a cons of a loaded assembly and a > type name, and it will call a static method on the type from that > assembly. Thanks Jim, I've uploaded a new version (0.9.2) which incorporates your patch. Cheers, Edi. _______________________________________________ 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] Hunchentoot 0.1.3 released
by Edi Weitz 08 Feb '06

08 Feb '06

ChangeLog: Version 0.1.3 2006-02-08 Removed KMRCL workaround Download: <http://weitz.de/files/hunchentoot.tar.gz> _______________________________________________ tbnl-announce site list tbnl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-announce

1 0

[ann] [tbnl-announce] New version 0.9.7
by Edi Weitz 08 Feb '06

08 Feb '06

ChangeLog: Version 0.9.7 2006-02-06 More robust computation of content length 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

[ann] [lifp-announce] Website created, LIFP 0.1 released
by Timofei Shatrov 07 Feb '06

07 Feb '06

Well, there are two things that happened: *I got a common-lisp.net account, so there is now LIFP's own website and mailing list! *LIFP 0.1 is officially released, and it is quite cool! Nothing significant changed since sneak peek, but at least Cloak of Darkness works as intended. -- Best regards, Timofei Shatrov mailto:grue@mail.ru _______________________________________________ lifp-announce mailing list lifp-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/lifp-announce

1 0

[ann] [cl-xmpp-announce] New version: 0.7.2 (bug and compatability fixes)
by Erik Enge 06 Feb '06

06 Feb '06

Version 0.7.2 of cl-xmpp (Common Lisp XMPP library) is out. It contains a few bugfixes and is updated for the latest CXML release. http://common-lisp.net/project/cl-xmpp/ Thanks, Erik. _______________________________________________ cl-xmpp-announce mailing list cl-xmpp-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-xmpp-announce

1 0

[ann] [elephant-announce] Elephant 0.5.0 is released under the LLGPL
by Robert L. Read 06 Feb '06

06 Feb '06

Elephant 0.5.0 is now available under the LLGPL. I put the following text on the project website: The latest version is 0.5.0, release Feb. 5, 2006. It is released under the LLGPL. This version works with ACL, OpenMCL, and SBCL with or without Unicode support. It has significant bug fixes over 0.4.0, especially with respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, and Waldo Rubinstein. The tutorial and documentation are improved, but may still lag the source code in some ways. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF _______________________________________________ elephant-announce site list elephant-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-announce

1 0

[ann] [cl-json-announce] ANN: cl-json
by Henrik Hjelte 05 Feb '06

05 Feb '06

cl-json is a Common Lisp parser and generator for JSON. Homepage : http://common-lisp.net/project/cl-json License : MIT What is JSON? ------------ JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. Read more at http://json.org /Henrik Hjelte _______________________________________________ cl-json-announce mailing list cl-json-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-json-announce

1 0

[closer-announce] [ANN] New versions of Closer libraries + AspectL
by Pascal Costanza 03 Feb '06

03 Feb '06

New versions of the libraries in the Closer Project have been released, including the Closer to MOP compatibility layer for the CLOS MOP and the ContextL extension for Context-oriented Programming. Furthermore, AspectL has been moved to the Closer Project, with its new version 0.7. Previously, it was an independent project that I haven't maintained anymore. Now that bitrot has started to increase, I have ported it to the Closer to MOP layer which turned out to be a surprisingly smooth process. This especially means that the number of Common Lisp implementations that it runs on has increased. Two bugs in Allegro Common Lisp that have led to problems in conjunction with AspectL have also been fixed in the meantime: A bug that has prevented a non-special slot to be turned into a special slot has been fixed in Allegro 7.0 and 8.0, and the limitation that a defmethod form doesn't accept more than one qualifier has been fixed in Allegro 8.0. Allegro Common Lisp 8.0 now supports the full functionality of AspectL. Furthermore, the following changes have been made to AspectL: - Some of the functionality was previously ported from AspectL to ContextL, mostly because it is not genuine aspect-oriented functionality. Those parts are now removed from AspectL implementation-wise in order to avoid code duplication. Instead, AspectL imports that functionality from ContextL, and exports it again for compatibility reasons. Existing AspectL code should mostly work as before. - Likewise, the CLOS MOP wrappers are completely removed because Closer to MOP supports compatibility across different CLOS MOP implementations much better. - Finally, the package structure is much simplified. Instead of placing every functionality in its own package, there is now the (previously already available) ASPECTL package from which everything can be imported. The previous scheme was too complicated and offered no obvious advantages. See http://common-lisp.net/project/closer/ for the Closer Project and http://common-lisp.net/project/closer/aspectl.html for AspectL. 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

[aspectl-announce] [ANN] New version of AspectL
by Pascal Costanza 03 Feb '06

03 Feb '06

New versions of the libraries in the Closer Project have been released, including the Closer to MOP compatibility layer for the CLOS MOP and the ContextL extension for Context-oriented Programming. Furthermore, AspectL has been moved to the Closer Project, with its new version 0.7. Previously, it was an independent project that I haven't maintained anymore. Now that bitrot has started to increase, I have ported it to the Closer to MOP layer which turned out to be a surprisingly smooth process. This especially means that the number of Common Lisp implementations that it runs on has increased. Two bugs in Allegro Common Lisp that have led to problems in conjunction with AspectL have also been fixed in the meantime: A bug that has prevented a non-special slot to be turned into a special slot has been fixed in Allegro 7.0 and 8.0, and the limitation that a defmethod form doesn't accept more than one qualifier has been fixed in Allegro 8.0. Allegro Common Lisp 8.0 now supports the full functionality of AspectL. Furthermore, the following changes have been made to AspectL: - Some of the functionality was previously ported from AspectL to ContextL, mostly because it is not genuine aspect-oriented functionality. Those parts are now removed from AspectL implementation-wise in order to avoid code duplication. Instead, AspectL imports that functionality from ContextL, and exports it again for compatibility reasons. Existing AspectL code should mostly work as before. - Likewise, the CLOS MOP wrappers are completely removed because Closer to MOP supports compatibility across different CLOS MOP implementations much better. - Finally, the package structure is much simplified. Instead of placing every functionality in its own package, there is now the (previously already available) ASPECTL package from which everything can be imported. The previous scheme was too complicated and offered no obvious advantages. See http://common-lisp.net/project/closer/ for the Closer Project and http://common-lisp.net/project/closer/aspectl.html for AspectL. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium _______________________________________________ aspectl-announce site list aspectl-announce(a)common-lisp.net http://common-lisp.net/mailman/listinfo/aspectl-announce

1 0

[ann] [rdnzl-announce] New release 0.9.0 / Experimental support for SBCL
by Edi Weitz 01 Feb '06

01 Feb '06

ChangeLog: Version 0.9.0 2006-02-01 Experimental support for SBCL/Win32 Download: <http://weitz.de/files/RDNZL.tar.gz> Cheers, Edi. _______________________________________________ rdnzl-announce mailing list rdnzl-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-announce

1 1