From mkg at vt.edu Tue Dec 19 20:47:34 2006 From: mkg at vt.edu (Mark K. Gardner) Date: Tue, 19 Dec 2006 15:47:34 -0500 Subject: [closure-devel] How to get started Message-ID: <20061219204734.GA2332@nirgal.cns.vt.edu> I would like to build Closure, play around with it and if possible contribute to its progress. However, I cannot seem to build it with either cmucl or sbcl. It appears from the mailing list that both should work. (I am running it on Debian x86 with cmucl 19d-20061116-1 and sbcl 0.9.16.0-1) To start with, I checked out the source from CVS then tried to build: CVSROOT=:pserver:anonymous at common-lisp.net:/project/closure/cvsroot cvs login # passwd anonymous cvs co -P closure ---------------- In cmucl: # ./BUILD ; Warning: This function is undefined: ; OOS Error in KERNEL:%COERCE-TO-FUNCTION: the function OOS is undefined. [Condition of type UNDEFINED-FUNCTION] I am stumped with this one. ---------------- In sbcl: # ./BUILD # * debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR in thread #: READER-ERROR at 363 (line 18, column 44) on #: package "EXT" not found I was able to get around this by changing --- BUILD.sbcl~ 2006-12-19 15:36:13.000000000 -0700 +++ BUILD.sbcl 2006-12-19 15:38:04.000000000 -0700 @@ -17,7 +17,7 @@ (ignore-errors (require :gray-streams)) -(unless (find-class 'ext::fundamental-stream) +(unless (find-class 'sb-ext::fundamental-stream) (error "The graystreams was not loaded successfully.")) ;; Switch off bullshit But then I get hung up on: debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #: The name "MULTIPROCESSING" does not designate any package. What package should I be using if not MULTIPROCESSING? -- Mark From eric.marsden at free.fr Tue Dec 26 13:33:33 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Tue, 26 Dec 2006 14:33:33 +0100 Subject: [closure-devel] How to get started In-Reply-To: <20061219204734.GA2332@nirgal.cns.vt.edu> (Mark K. Gardner's message of "Tue, 19 Dec 2006 15:47:34 -0500") References: <20061219204734.GA2332@nirgal.cns.vt.edu> Message-ID: <87mz5a7pea.fsf@free.fr> >>>>> "mkg" == Mark K Gardner writes: mkg> I would like to build Closure, play around with it and if possible mkg> contribute to its progress. However, I cannot seem to build it with mkg> either cmucl or sbcl. It appears from the mailing list that both mkg> should work. (I am running it on Debian x86 with cmucl 19d-20061116-1 mkg> and sbcl 0.9.16.0-1) don't bother with the BUILD script, it looks outdated. I have added a quickstart guide to running Closure on SBCL with GNU/Linux at http://common-lisp.net/project/closure/quickstart.html -- Eric Marsden From eric.marsden at free.fr Thu Dec 28 22:21:37 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Thu, 28 Dec 2006 23:21:37 +0100 Subject: [closure-devel] PATCH: load GIF files without an external application Message-ID: <87k60b8xvy.fsf@free.fr> Hi, Closure currently loads GIF files by saving the contents to a temporary file, running gif2png on the file, then slurping in that file. The attached patch (well, it isn't packaged as a proper patch) allows Closure to load GIF files directly, thanks to Zach Beane's Skippy library. http://www.xach.com/lisp/skippy/ Interlaced GIF files are not currently supported by Skippy (but this should change shortly). Only the last frame of animated GIFs will be displayed (yes, this is a feature). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gif-skippy.lisp URL: -------------- next part -------------- -- Eric Marsden From eric.marsden at free.fr Thu Dec 28 22:31:17 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Thu, 28 Dec 2006 23:31:17 +0100 Subject: [closure-devel] PATCH: HTTP and HTTPS support via the Drakma library Message-ID: <87fyaz8xfu.fsf@free.fr> Hi, The attached rough patch splices the Drakma library into Closure for HTTP support. Drakma is a very nice web client library by Edi Weitz: http://weitz.de/drakma/ Unlike the current Closure code, the library supports HTTPS and HTTP/1.1. I see this as an opportunity to replace some of the undermaintained code in Closure by high quality external libraries; this concerns src/net/http.lisp (replaced by Drakma) src/net/url.lisp (partially replaced by PURI) src/net/uri.lisp (ditto) I haven't yet started trying to remove stale code; this is just a proof of concept. A likely candidate for similar replacement is the GSTREAM code, which could likely advantageously be replaced by Flexi-streams. Opinions on whether this is a good route to pursue are welcome. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: http-drakma.lisp URL: -------------- next part -------------- -- Eric Marsden From david at lichteblau.com Fri Dec 29 21:44:07 2006 From: david at lichteblau.com (David Lichteblau) Date: Fri, 29 Dec 2006 22:44:07 +0100 Subject: [closure-devel] Closure depends on CXML now Message-ID: <20061229214407.GA13197@babayaga.math.fu-berlin.de> Hi, Closure CVS now depends on CXML's rune implementation and XML parser. I had postponed this commit for a long time, because the most interesting feature to me is the "character rune" implementation in CXML. However, there are many places in Closure were the rune abstraction was not being used entirely correctly, leaving Closure broken with character runes. After an evening of hacking, Closure can now render its homepage using character runes. Encouraged by that success, I decided to finally commit the patch. Note that my changes will most likely have left many of these little bugs in place. If you get any errors about characters not being integers, you can try one of two solutions: a) Switch to integer runes using (pushnew :rune-is-integer *features*) before loading anything. Make sure to recompile both CXML and Closure after changing this setting. b) Fix the code to correctly use runes. That's mostly trivial. Just write #/U+0020 instead of 32; write #"foo" instead of #.(map 'vector #'char-code "foo"); use rune-code instead of identity when codes are really needed even on unicode-aware lisps; similarly rune-char when characters are needed even on non-unicode lisps. Etc. Note that the CSS parser is a special case, it uses integers larger than 2^16 in places and can't be switches to characters easily. d. From david at lichteblau.com Fri Dec 29 22:39:19 2006 From: david at lichteblau.com (David Lichteblau) Date: Fri, 29 Dec 2006 23:39:19 +0100 Subject: [closure-devel] PATCH: HTTP and HTTPS support via the Drakma library In-Reply-To: <87fyaz8xfu.fsf@free.fr> References: <87fyaz8xfu.fsf@free.fr> Message-ID: <20061229223919.GA13736@babayaga.math.fu-berlin.de> Hi, Quoting Eric Marsden (eric.marsden at free.fr): > Unlike the current Closure code, the library supports HTTPS and > HTTP/1.1. I see this as an opportunity to replace some of the > undermaintained code in Closure by high quality external libraries; > this concerns > > src/net/http.lisp (replaced by Drakma) if Drakma lives up to the standard of all other "Edi-ware", that sounds like a good idea. It would be nice if we could remove as much implementation-dependent code as possible in favour of /good/ abstractions. According to Drakma's web page, it uses trivial-sockets, which isn't really that much better than what we have in glisp already. Since usocket appears to have compatibility code for trivial-sockets, would it be a good idea to migrate to usocket for all of closure's socket needs? > src/net/url.lisp (partially replaced by PURI) > src/net/uri.lisp (ditto) Hmm, I started using PURI in CXML without thinking much about it, and it certainly works, but how good is it really? Perhaps we should improve Closure's URI support instead? I would switch CXML to "Closure-URI" if that happened. d. From eric.marsden at free.fr Sat Dec 30 22:08:37 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Sat, 30 Dec 2006 23:08:37 +0100 Subject: [closure-devel] Extension: query Yahoo search's API and present results Message-ID: <87lkkpc9zu.fsf@free.fr> Hi, The attached file illustrates how to query Yahoo's REST search API, extract the interesting information from the resulting XML stream using CXML's DOM interface, and display the results as HTML within Closure. The results as presented are currently ugly, but look at how few lines of code are required to implement this extension! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: closure-extra.lisp URL: -------------- next part -------------- -- Eric Marsden