January 2011 - pro - mailman3.common-lisp.net

[pro] Final empty parameters to format directives
by Didier Verna 11 Feb '11

11 Feb '11

Hello, I just fell upon a case where implementations seem to differ on what to do. The question is how to interpret a format directive in which the last parameter is followed by a comma. Consider this test case: (defun fmt (stream argument colonp atsignp &rest params) (declare (ignore stream argument colonp atsignp)) (format t "~S~%" params)) (format t "~1,2/fmt/~%" t) (format t "~1,2,/fmt/~%" t) (format t "~1,2:/fmt/~%" t) (format t "~1,2,:/fmt/~%" t) Here's what you get from various implementations: SBCL / ECL / ABCL: (1 2) (1 2 NIL) (1 2) (1 2) CMU-CL / CCL / CLISP / Allegro / LispWorks: (1 2) (1 2) (1 2) (1 2) Funnily, my instinct tells me that nobody's right, as I would have expected to get this: (1 2) (1 2 NIL) (1 2) (1 2 NIL) Indeed, the parameters list is implicitely terminated by the directive character OR a colon / at-sign. So using a final comma seems to me like adding another, empty, parameter at the end. I'm willing to report those divergences to the respective implementations, but the problem is that I don't really know what to report :-) Who's right? No matter how I read the spec, I cannot make a decision and it seems to me that this is an unspecified corner case. I reckon it's probably not a big deal, but this could be a problem for user-defined functions relying on the actual number of parameters that they get. Comments? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4

[pro] Are you an Imager or a Filer?
by Ala'a Mohammad 10 Feb '11

10 Feb '11

Hi, I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable? Regards, Ala'a Mohammad.

18 23

[pro] 404 animals
by Daniel Weinreb 03 Feb '11

03 Feb '11

There appears to be a new trend of putting cute animals on your HTTP 404 page. Twitter has a "Fail Whale", and now Tumblr has "TumblBeasts": http://www.observer.com/2011/tech/tumblr-adds-oatmeals-suggested-tumbeasts-… Perhaps we can have an easy way to make Lisp-based web sites use the "powered by alien technology" cute green creature? :) -- Dan

13 14

Re: [pro] simple-style-warning
by Vladimir Sedach 27 Jan '11

27 Jan '11

So from what I understand now, the way to accomplish a "simple-style-warning" without having compile-file return failure-p is to define a subclass of style-warning with the format-control/arg slots and a :report function myself. Is this correct? Vladimir

2 2

[pro] User defined format functions
by Didier Verna 26 Jan '11

26 Jan '11

Hello, there are situations in which I find myself frequently using the same format "pattern", which I'd like to abstract away. A concrete example is from my Declt package[1] which prints a lot in Texinfo format. Since Texinfo has a couple of special characters (e.g. @), I have an ESCAPE function which takes a string and returns another one with all special characters escaped. In the Declt code, I hence have very frequent calls which look like this: (format stream "... ~A ..." #|...|# (escape str) #|...|#) This is frustrating because I would like to abstract away the relation "~A <-> #'escape". Of course there are solutions (I could provide my own wrapper around FORMAT in some way) but none of them seem satisfactory. I'm aware of the ~// construct, which I find extremely cumbersome. Does anybody actually use it? It seems to me that the package handling part, specifically, makes it totally unusable. Just imagine that I would need to do something like that if I were to use it: (format stream "... ~/com.dvlsoft.declt:escape/ ..." #|...|# str #|...|#) and you get the idea! :-) No, in fact, the problem is that FORMAT control sequences are not extensible. This reminds me of something that we have in the Gnus mail/newsreader. It's called "user format functions". Gnus Group and Summary buffer lines, for example, are define by a format string with a set of predefined %<char> constructs. One of them, %u<char> lets you define and use your own function, called gnus-user-format-function-<char>. So what I would like to do is more or less define a function FORMAT-FUNCTION-E, just like a standard formatter, and then be able to write something like that: (format stream "... ~\e\ ..." #|...|# str #|...|#) Of course, there are package issues. Maybe we would need a centralized mapping between function names (what goes in ~\\) and actual symbols denoting the actual function? Possibly with the possibility to override the mapping by providing a package prefix in the ~\\ construct? In fact, the more I think about it, the more it sounds like having a format-table facility, much like what a readtable is, with a similar API. You could do (in-format-table :my-table-name) at the beginning of a file and have a totally customized set of format control sequences, possibly inheriting the standard ones. WDYT? Does something like that already exists[2]? Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt [2] I've heard of something called fmt for scheme, but don't know much about it. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

6 11

[pro] User defined format functions
by Didier Verna 25 Jan '11

25 Jan '11

Hello, there are situations in which I find myself frequently using the same format "pattern", which I'd like to abstract away. A concrete example is from my Declt package[1] which prints a lot in Texinfo format. Since Texinfo has a couple of special characters (e.g. @), I have an ESCAPE function which takes a string and returns another one with all special characters escaped. In the Declt code, I hence have very frequent calls which look like this: (format stream "... ~A ..." #|...|# (escape str) #|...|#) This is frustrating because I would like to abstract away the relation "~A <-> #'escape". Of course there are solutions (I could provide my own wrapper around FORMAT in some way) but none of them seem satisfactory. I'm aware of the ~// construct, which I find extremely cumbersome. Does anybody actually use it? It seems to me that the package handling part, specifically, makes it totally unusable. Just imagine that I would need to do something like that if I were to use it: (format stream "... ~/com.dvlsoft.declt:escape/ ..." #|...|# str #|...|#) and you get the idea! :-) No, in fact, the problem is that FORMAT control sequences are not extensible. This reminds me of something that we have in the Gnus mail/newsreader. It's called "user format functions". Gnus Group and Summary buffer lines, for example, are define by a format string with a set of predefined %<char> constructs. One of them, %u<char> lets you define and use your own function, called gnus-user-format-function-<char>. So what I would like to do is more or less define a function FORMAT-FUNCTION-E, just like a standard formatter, and then be able to write something like that: (format stream "... ~\e\ ..." #|...|# str #|...|#) Of course, there are package issues. Maybe we would need a centralized mapping between function names (what goes in ~\\) and actual symbols denoting the actual function? Possibly with the possibility to override the mapping by providing a package prefix in the ~\\ construct? In fact, the more I think about it, the more it sounds like having a format-table facility, much like what a readtable is, with a similar API. You could do (in-format-table :my-table-name) at the beginning of a file and have a totally customized set of format control sequences, possibly inheriting the standard ones. WDYT? Does something like that already exists[2]? Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt [2] I've heard of something called fmt for scheme, but don't know much about it. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 3

[pro] A little success story...
by Pascal Costanza 24 Jan '11

24 Jan '11

Hi, I just wanted to report on a little success story. In the recent few months, I have been working on a new project that concerns itself with parallel programming. For that purpose, I experimented with variations of a home-grown work-stealing scheduler. (See http://en.wikipedia.org/wiki/Cilk#Work-stealing for a description of what work stealing is.) The development platform is LispWorks 6.0, which comes with an excellent library for SMP. (I would say it's the best of any dynamic language I am currently aware of, not just those of Lisp dialects.) Performance matters in parallel programming. The benchmark application was a structured grid computation, like is for example used for computing heat equations, for running game of life, or for similar applications. This is easy to parallelize, because each processor can perform part of the computation on a sub-grid independently of all the other processors. The hardware that I ran the experiments on is a 4x 6-core Intel Xeon "Dunnington" 2.67 GHz running Ubuntu. For 200 iterations on a 4096x4096 matrix of single float values, I got the following runtimes: - with 8 cores ca. 19-20 secs. - with 16 cores ca. 9-10 secs. - with 24 cores ca. 8 secs. The same experiment was also implemented by others in our group in the following languages: Unified Parallel C, Cilk++, C with MPI, OpenMP, and C++ with Threading Building Blocks. They all have slight variations in runtime, but all roughly in the same ballpark. The runtimes were: - with 8 cores ca. 10-11 secs. - with 16 cores ca. 8-10 secs. - with 24 cores ca. 8-10 secs. The advantage of using Common Lisp is that I could still use higher-order constructs (closures) and have a pretty decent separation of concerns in the software architecture, while still getting very good efficiency. Of course, this required some pretty low-level tricks with type and optimization declarations in several places, but the nice thing about Common Lisp is that you don't have to be low-level right from the start, and only at the places that you identify as bottlenecks. Unfortunately, I cannot present a lot more details at this stage, because most of this is covered by an NDA. I hope, though, that I can make the work-stealing scheduler available as an open source library at some later stage. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

3 5

Re: [pro] Learning Lisp the Bump Free Way
by raito＠raito.com 21 Jan '11

21 Jan '11

Quoting Vladimir Sedach <vsedach(a)gmail.com>: > 2. There are no libraries to do <X>/I can't find any libraries. It may sound shocking, but there's non-programmers out there who complain if there isn't a free-as-in-beer application to do what they want. This argument is the programmer corollary. It always appears to me as though the real argument is "No one else has already done my work for me." But then, when I first learned C, we got stdio and stdlib, and nothing else, really, so my view may be skewed. I do find discussions that pit the syntaxes of Lisp vs. other languages very amusing, and not for the reason most Lisp users might. Yes, many new languages have long drawn out discussions about how their syntax should change, while Lisp has had the same syntax for a very long time. But here's where libraries come in... It seems like an awful lot of Lisp libraries exist to wank about with the language than libraries in other languages, rather than to actually do the sort of tasks that programmers look to do. This may make it look like Lisp is defective. After all, if you need a bunch of libraries to 'correct' the language, it can't be any good, right? And because there seems to be several libraries to 'correct' the same problem in different ways, it's pretty obvious that the 'community' can't even agree on how to do it. In some people's minds, this is a problem. (And yes, I know that it's a rather superficial view, but from someone casually considering Lisp, a superficial view is all you're going to get). Neil Gilmore raito(a)raito.com

10 13

[pro] Learning Lisp the Bump Free Way
by Daniel Weinreb 21 Jan '11

21 Jan '11

This is a very nice essay to help people get over their initial problems with Lisp: http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way I also just came across an online book called "Successful Lisp", by David B. Lamkins (maybe many of you already know about this): http://psg.com/~dlamkins/sl/ It's also available from Amazon, in trade paperback (300 pages). http://www.amazon.com/Successful-Lisp-How-Understand-Common/dp/3937526005/r… I'm not sure whether we need any more Lisp textbooks now that we have Practical Common Lisp, but it's somehow just nice to know that there are more books about Lisp that managed to get published; at least in the sense that Amazon has it (the web site of the publisher seems to have expired). -- Dan

16 22

[pro] simple-style-warning
by Vladimir Sedach 21 Jan '11

21 Jan '11

Is there a portable way to create a simple-style-warning condition that when signaled with WARN won't cause SLIME to claim that file compilation failed, that works for all/most CL implementations? I'm trying to use this: (define-condition simple-style-warning (style-warning simple-warning) ()) (found in one of KMP's usenet posts: http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c55278c8…) but it works inconsistently in SBCL and CCL. Thank you, Vladimir

3 2