I submitted CLAZY and CL-ENUMERATIONS to Quicklisp and found out that there were some problems with them. Mostly due to (unwarranted) package locks in SBCL and CLISP. Fixing these problems led to some revisitation of the code base and subsequent improvements (I hope).
Both libraries should appear in future Quicklisp releases.
I finally got around to write my very own HTML documentation system. Of course, this may be pointless and useless, but I found the alternatives "out there" lacking this or that (obviously!). So here I am, trying to automate the process of producing documentation like that of CLAZY, which I hand-crafted in the past. In the process, needless to say, I got carried away and got lost in the land of featurism only to contemplate my overall ignorance of most things webbish.
As usual, Edi Weitz came to my rescue by offering his CL-WHO and HTML-TEMPLATE, which raised a question: which of the two approaches is best? Note that the answer should consider how many dependencies my system files can have.
Let's start with the simple problem I have: I need to produce a .html file that contains, say, a "header" for my documentation. I could do it using CL-WHO in the following way (just a snippet, not working...)
(defun produce-header-file (fs header-pathname)
(declare (type frameset fs)
(type pathname header-pathname))
(let ((fs-order (frameset-order fs))
(fs-head-title (frameset-head-title fs))
(fs-body-title (frameset-body-title fs))
)
(with-open-file (hs header-pathname
:direction :output
:if-exists :supersede
:if-does-not-exist :create)
(with-html-output (hs hs :indent t)
(fmt "~A" (cl-fad:pathname-as-file header-pathname))
(fmt +doctype-frameset-control-string+)
(:html
(:head
(:title (str fs-head-title))
(:link :rel "stylesheet" :href "clstyle.css"))
(:body :style "margin: 0pt 0pt 0pt 0pt;"
(:div
:class "header"
:style "padding-left: 2em; padding-top: 5pt; color: #41286f; font-size: 14pt"
(:strong (str fs-body-title))
(:div
:class "navigation"
:style "right: 2m"
(:a
:href "index.html"
:class "navigation-link-selected"
:target "_parent"
(str "Home"))
)))))
)))
Or I could use HTML-TEMPLATE and ship around a "template" file like the following (again, this is just a snippet and contains errors):
<!-- header.html --> <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title><!-- TMPL_VAR HEAD_TITLE --></title> <link rel="stylesheet" href="clstyle.css"> </head> <body style="margin: 0pt 0pt 0pt 0pt;"> <div class="header" style="padding-left: 2em; padding-top: 5pt; "> <strong><i><!-- TMPL_VAR BODY_TITLE --></i></strong><br/> <div class="navigation" style="right: 2m"> <!-- TMPL_LOOP frames --> <!-- TMPL_IF current_frame --> <a href=<!-- TMPL_VAR frame --> class="navigation-link-selected" target=_parent><!-- TMPL_VAR f_nav_name ->></a> <!-- TMPL_ELSE --> <a href=<!-- TMPL_VAR frame --> class="navigation-link" target=_parent><!-- TMPL_VAR f_nav_name ->></a> <!-- /TMPL_IF --> <!-- /TMPL_LOOP --> </div> </div> </body> </html> <!-- end of file : header.html -->
I am inclined to go the CL-WHO way. I do not have to ship around an extra file and record its location etc etc; yet the HTML-TEMPLATE does have appeal. Any ideas out there?
Hello,
here is a NEW post after a long time. And the topic of this post is NEW. Of course, this is old stuff, but here it is: it's a post about the new operator. I'd bet there are many other little hacks like this floating around, but I finally got sucked in into writing a little library that introduces a new operator (and a newq one) in Common Lisp.
Why? After a very long time of putting up with make-instance and make-this and make-that, and after many other brain things going on in my head (cit. King Julien of the Lemurs) I decided that Common Lisp needed something capable of doing the following:
or even
So; what's the big deal? Not much, but I also want to be able to write:
The problem is that as soon as you wade in CL "type specifiers" land, you hit the dreaded "implementation dependent" wall, or, worse, the "this is not even mentioned in the ANSI spec" wall. Think of DEFSTRUCT and the fact that there is no portable way to get to the constructor, not to mention DEFTYPE.
Apart from that, I think that the little piece of code I wrote would maybe make programming in CL feel more in tune with the times. After all you can also write things like the following, which I think are rather cool.
What do you think? Is this worth a CDR? Ping me if you want to see the code.
I have been working for some time on the CL-UNIFICATION library. Somehow, "unification" and "parsing" are related but not quite (I bet the literature on the topic is huge). In an afternoon of the Easter vacation, I decided to take the easy way out of extending CL-UNIFICATION with some "parsing" functionality: I just added Edi Weitz's wonderful CL-PPCRE library. Edis' library has a very simple and intuitive interface which made the integration a SMOP! The result is the following. Now you can write the following (assuming all the packages are USEed):
(unify #T(regexp "a(b+)c(d+)" (?bs ?ds)) "abbbbcddd")
The call will produce an environment where ?BS is bound to "bbbb" and ?DS is bound to "ddd". Here is a full transcript.
CL-USER 3 > (in-package "UNIFY") #<The CL.EXT.DACF.UNIFICATION package, 326/512 internal, 20/64 external> UNIFY 4 > (unify #T(regexp "a(b+)c(d+)" (?bs ?ds)) "abbbbcddd") #<UNIFY ENVIRONMENT: 1 frame 200BC147> UNIFY 5 > (v? '?bs *) "bbbb" T UNIFY 6 > (v? '?ds **) "ddd" TOf course, the other matching operations work as expected.
UNIFY 9 > (match-case ("abbbbcdd") (#T(regexp "a(b+)c(d+)" (?bs ?ds)) (concatenate 'string ?ds ?bs)) (t "It did not work!")) "ddbbbb"I.e., there is an interface to get to the actual regexp groups (beyond those available directly in CL-PPCRE). Maybe the syntax of the regexp unification templates could be made even more CL-PPCRE-like by exploiting "named registers", but, for the time being, the above is the best way to use it.
Hello,
I just bumped into this while trying to load MEL-BASE into LW. The library has a file 'environment.lisp' which contains the following code.
#+openmcl (defun gethostname () "Returns the hostname" (ccl::%stack-block ((resultbuf 256)) (if (zerop (#_gethostname resultbuf 256)) (ccl::%get-cstring resultbuf) (error "gethostname() failed."))))As we know, OpenMCL, its predecessors, and its successors, define #_ as areader macro to call up system functions. Now, LW (M 5.x) barfs on this, because it tries to
READ the DEFUN in order to discard it.
I do not know if this is a bug or not (I have not checked), but it reinforced my preference for code organization, where I relegate implementation dependencies in separate files. I.e., I do not write a file like 'foo.lisp' and pepper it with a lot of #+, #-. I would relegate such system dependencies in a ccl.lisp (or a cmucl.lisp) file, and I would conditionally include the file in the .asd or .system file. This way I feel I have more control over system dependencies, and I do not incur in snag like the #_ one.
(cheers)
I just cleaned up a bit the CLAZY library. Things are tidier in the implementation, obvious bugs have been swatted away and the web site is more informative (although by no means complete). A big thank goes to Theam Yong Chew, Joshua Taylor and Raffael Cavallaro for ideas and testing. Some more extensions are in the pipeline...
(cheers)