- pro - mailman3.common-lisp.net

[pro] Dan Weinreb Memorial Celebration
by Tom Emerson 09 Oct '12

09 Oct '12

[Apologies for those for whom this is a repost] Dan Weinreb Memorial Celebration A memorial to celebrate the life of Dan Weinreb will be held on Sunday, October 21, 2012 from 1:30 p.m. - 4:30 p.m. Chatham Café, 3 Cambridge Center, 4th floor, Cambridge, MA Family and friends are welcome to join us as we share memories of Dan and celebrate his life. A short program will begin at 2:15 p.m. If you plan to attend, please RSVP using the following link: http://anyvite.com/events/home/dcbce0bnop Knowing how many people are attending will help us greatly. Additional information about the event is available on Facebook at http://www.facebook.com/events/360648707356145/ Please CHECK the Facebook link before you attend for any changes in location or time. The page will also contain information about parking and directions. For questions or more information, contact Dena Brody at denabrody(a)comcast.net -- Tom Emerson tremerson(a)gmail.com http://www.dreamersrealm.net/tree

1 0

[pro] [Q] introspecting setf expanders
by Didier Verna 09 Oct '12

09 Oct '12

Hello, I cannot find a standard way to figure out whether a setf expander has been defined for a symbol FOO (via either DEFSETF or DEFINE-SETF-EXPANDER). Is there one? Otherwise, I would also be happy with an SBCL-only solution. Thank you ! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

6 7

[pro] examples of compiled embedded DSL
by Yakov Zaytsev 01 Oct '12

01 Oct '12

hello all, i'm looking for examples of small languages embedded in Common Lisp which are compiled so effectively small language programs do not run from the host compiler (CL) environment but from other run-time i know about parenscript and would love to know about more available in the public (or story about closed implementations)

2 1

[pro] [Q] unicode support
by Didier Verna 29 Sep '12

29 Sep '12

Hello, does anyone have a global view on the status of unicode support in the main CL implementations (SBCL, CMU-CL, ECL, CCL, CLISP, ABCL, ACL, LispWorks). By that, I mean mostly being able to encode source files in utf8 with the following concerns: - do I need to do something special at the implementation-level ? - do I need to do something special at the ASDF system level ? - could this break the code of people using my libraries ? Thank you. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

5 4

[pro] [Q] interpretation / byte-compilation / compilation
by Didier Verna 26 Sep '12

26 Sep '12

Hello, does anyone have a global view on the status of this in the main CL implementations (SBCL, CMU-CL, ECL, CCL, CLISP, ABCL, ACL, LispWorks). By that, I mean mostly: - which implementation can do what, - how do you ask for interpretation, bytecomp or comp. I find this information quite hard to figure out. Unless I missed it, I think it would be good to have a page somewhere summarizing this. Thank you ! -- 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] Looking for comments/corrections on Lisp Doc-Generation Tool Review
by Sabra Crolleton 26 Sep '12

26 Sep '12

Hello all, I put together a draft of a review of common lisp documentation generation tools at https://sites.google.com/site/sabraonthehill/lisp-document-generation-apps. As almost everyone on the list has more experience than I have with lisp (and some of you are authors of these programs), I would appreciate any corrections or comments on the draft. I've only had time to test with sbcl (1.0.58) but do intend to try to test with other lisps as well. Thank you. Sabra

8 9

[pro] common-lisp.net down?
by Pascal Costanza 15 Jul '12

15 Jul '12

Hi, It seems that common-lisp.net is down. Is that correct? (Sorry for spamming this list, but I don't know who the current maintainer is…) Thanks, Pascal -- Pascal Costanza

3 3

[pro] style question about types, coercion, expectations for function parameters
by Ryan Davis 01 Jun '12

01 Jun '12

Pro-cl, I'd like to sanity check some of the lisp idioms my shop has (re)invented. Some background: We do a lot of web programming, shuffling data to and fro, occasionally doing interesting calculations, but mostly pushing bits around and displaying information in ways humans can use. We have very few CPU bound operations, and most of those are complicated SQL queries, not lisp operations. Most of the applications we create have few users. As such, we haven't put much time into optimizing our lisp code, and rely on dynamism to support rapid development. We have very few type declarations, liberal use of CLOS, not too concerned with consing, etc. Basically using the simplest code we can get away with. It works well for our purposes, and we complicate code for speed when we can't get away with it. We came to lisp from C#, so have a distaste for that style of static typing. I'd like some more opinions on a pattern that has cropped up. One of the problems we were having was quickly determining what a function expected for it's arguments. As a somewhat contrived example, SLIME helpfully would tell me that #'send-email wanted (to from subject body), but then it was left to me to guess what values I should pass in. In real code this was frequently non-trivial, and we'd be hand-tracing to figure out where the parameter was used to figure out what it should be. Should "to" be a string, a CLOS Client object, or the database ID of a Client? The answer we arrived at was "yes": (defun send-email (to from subject body) (let ((to (etypecase to (string to) ((integer 0) (email (fetch-client to))) (client (email to)) ))) ;; ... more code )) The "to" parameter can be anythings that can be mapped to an email address. It is send-email's job to send email, and it will figure it out based on whatever you provide. If it can't do it, it'll tell you. Usually the etypecase is pulled into it's own function, and we have something like: (defun send-email (to from subject body) (let ((to (coerce-email to))) ;; ... more code )) And also usually wrapped into a setf-generating macro and we have: (defun send-email (to from subject body) (coerce-email! to) ;; ... more code ) This is very easy to follow, and when figuring out what to pass for "to", it's trivial to M-. a few times and see what are the allowed values. In rare cases we want this typecase to be extensible, for example to allow another package to add new mappings. When this happens we end up with a generic method: (defmethod coerce-email (to) ;;same typecase as before ) ;;elsewhere (defmethod coerce-email ((to server)) (administrator-email to)) Method dispatch takes care of the rest. Sometimes the coerce-* function is a cond or typecase, and strays outside the flexibility offered by standard method combination, things like using Access's [1] generic interface. In practice, this is approach is mostly used for converting database CLOS objects to integer IDs and vice versa, depending on whether the function wants an integer ID or an instantiated object. Some alternatives we tried: * using defmethods, but it didn't seem to offer any advantage over a simple typecase, it was just more typing, more code to read later, and less flexibility if the business wanted something weird. * using check-type or assert to constrain the input options, like C#/Java style static-typing, but that just resulted in duplicate code at call sites to convert from whatever you had to whatever send-email wanted. * having multiple similarly named functions where the function name indicated what type was expected (eg: send-email, send-email-to-client, send-email-to-client-id), this also didn't seem to offer any advantage over a simple typecase * naming parameters after what can be accepted (client-id, email-string, client-or-id, etc) ended up hard to keep up to date. There are a lot of tradeoffs with this approach, and obviously this wouldn't work for anything with high performance requirements. Has anyone else run into a similar problem and come up with a different/same/better solution? Any problems I'm missing? [1] https://github.com/AccelerationNet/access Thanks, -- Ryan Davis Acceleration.net Director of Programming Services 2831 NW 41st street, suite B Gainesville, FL 32606 Office: 352-335-6500 x 124 Fax: 352-335-6506

5 4

[pro] ANNOUNCE: Docbrowser (and WAT - Whatever Active Templates)
by Elias Martenson 30 May '12

30 May '12

I'm making this post here because my project, Docbrowser, was included in the latest update of Quicklisp, and I wanted to give a heads-up to anyone who may be interested in the project. Docbrowser is a documentation browser for Common Lisp. It uses Hunchentoot to provide a simple way of getting an overview of the functions, classes and variables). The source code is available at http://code.google.com/p/docbrowser/, or you could just install it via Quicklisp. The project also contains a template system that generates Lisp code that is subsequently compiled. It's quite effective, and while it's not an "official" project on its own right (yet), I just wanted to get the word out in case anyone is interested in looking at it. Regards, Elias

1 0

[pro] Default behavior of standard output streams
by Didier Verna 26 May '12

26 May '12

Hello, there is a discrepancy amongst compilers on how the default output streams behave in some situations. Consider the following test case: (format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%") Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways: myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1 SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty) ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL. Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3. I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*. WDYT? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

7 6