pro

pro@common-lisp.net

1 participants
346 discussions

[pro] return-with-dynamic-extent...
by Pascal Costanza 13 May '12

13 May '12

Hi, Here is a description of what I think is a feature missing in Common Lisp, both the standard and current implementations, namely a more complete way to ensure stack allocation of objects. Based on some recent experience with translating some C++ benchmarks to Common Lisp - more specifically the fluid animate benchmark from the PARSEC benchmark suite - being able to allocate objects on the stack can be a major performance win. Unfortunately, this is harder than necessary to achieve in Common Lisp. Here is a simplified example. Assume you have the following class definition in C++: struct vec { int x; int y; int z; vec(int x, int y, int z): x(x), y(y), z(z) {} }; Then you can define the following operations on such a class: vec vplus(vec v1, vec v2) { vec v(v1.x+v2.x, v1.y+v2.y, v1.z+v2.z); return vec; } In such a function definition, the local variable v is stack allocated, plus the return value is returned by value, not by reference. This holds for any intermediate values as well, so if you have other operations like vminus, vmul and vdiv, etc., defined accordingly, you can write expressions like this: vplus(v1, vmul(v2, v3)); …and rest assured that all intermediate values are allocated on the stack as well. (C++ loses some performance in some cases because it can happen that it relies too much on copying of data structures, but this has been largely resolved in C++11, where move operations are supported really well.) In Common Lisp, you can declare local variables with dynamic extent: (let ((v (make-vec :x 1 :y 2 :z 3))) (declare (dynamic-extent v)) …) This has the effect that (in Common Lisp that support this) the struct that v refers to is stack allocated. Unfortunately, Common Lisp implementations can only do this for data structure constructors that the implementation knows about - there is no way for users to add additional operations to the set of known dynamic extent 'allocators.' For example, if you say the following: (defun vplus (v1 v2) (let ((v (make-vec :x (+ (vec-x v1) (vec-x v2)) :y (+ (vec-y v1) (vec-y v2)) :z (+ (vec-z v1) (vec-z v2))))) (declare (dynamic-extent v)) v)) …you can be very sure that the resulting program will fail, because the reference to the stack allocated data structure is returned, but the data will be gone afterwards. This had the consequence that in our attempts at translating the fluid animate benchmark, we had to introduce all intermediate results explicitly in separate variables, and be very explicit about all the necessary computational steps. This was very tedious and the result is not nice to look at. What would be nice is, if we could instead have some form of saying that we want to return a data structure on the stack: (defun vplus (v1 v2) (let ((v (make-vec :x (+ (vec-x v1) (vec-x v2)) :y (+ (vec-y v1) (vec-y v2)) :z (+ (vec-z v1) (vec-z v2))))) (declare (dynamic-extent v)) (return-with-dynamic-extent v)) The idea is that now, the data that v refers to is returned by value on the stack. If the call site receives the value with a matching dynamic-extent declaration, then v can just stay on the stack. Same (hopefully) for intermediate results in more complex expressions. Just like dynamic-extent declarations, an implementation should be allowed to ignore return-with-dynamic-extent and replace it with a mere return form. To be able to support move operations on the stack, it may be interesting to specify that eq and eql are not reliable anymore for data that is return by return-with-dynamic-extent. I presented the idea at ELS'12 in Zadar, and Christophe Rhodes commented that it may also be necessary to have some form of global declaim that states that a function will always return something with return-with-dynamic-extent, so it's easier for the compiler to know what to do with a return value. I don't claim that I have completely thought this through, but I think this should be doable and shouldn't have too many negative consequences for the rest of a system that doesn't use dynamic extents. I won't be able to implement this, but I just wanted to make sure that the idea is on the table, so someone who is interested may pick it up… Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

3 6

Re: [pro] pro Digest, Vol 20, Issue 2
by Devon Sean McCullough 07 May '12

07 May '12

> From: Steve Haflich <shaflich(a)gmail.com> > ... #+never #+notyet #+nomore or #+bug456 I myself have long used, e.g., #+| When bug 456 is fixed | Peace --Devon P.S. #+nil to unconditionally disable code would be an affront to NIL, the New Implementation of Lisp, which runs on the ancient DEC Vax VMS OS. My friend GSB was lead implementer.

1 0

[pro] [Q] naming convention
by Didier Verna 05 Apr '12

05 Apr '12

Hello, I have a FROB functionality that I would like to make available both at run-time via a function and at compile-time via a macro (which in turn will call the function). Are there any general conventions (apart from DEFINE- / MAKE-) for this kind of thing ? I'm having a hard time finding nice names for FROB the function and FROB the macro... Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

8 10

[pro] GPU/CUDA & common lisp
by Tamas Papp 05 Apr '12

05 Apr '12

Hi everyone, I am about to buy a new server for number crunching, and I would like to keep my options open about GPU/CUDA based computations. The most intensively parallelizable thing that I am doing is particle filtering, and currently that works fine (and is really fast) in a multi-core CPU with SBCL, but I keep hearing wonderful things about GPUs from people, and I was wondering if I could make use of them but still program in CL. I basically have two questions: - What is the current status of using CPUs for computation in CL (in particular SBCL)? All I found was CL-GPU but I haven't tried it yet (my current server does not have a GPU). - What hardware is supported (if I want to use CL)? Can I use something like Nvidia's TESCLA C line? Any help/pointers/accounts would be appreciated, I am just exploring this so I don't know much about it yet, apologies if I am not asking the right questions. Best, Tamas

4 5

[pro] how to validate an XML file agains an DTD?
by Alexandre Rademaker 04 Apr '12

04 Apr '12

Hello, I know that probably this is not the best place to ask this question but my message to cxml-devel had no answer!! ;-( http://lists.common-lisp.net/pipermail/cxml-devel/2012-March/000554.html I need to validate a XML file that doesn't have the doctype declaration. Actually, I don't have control over the creation of the XML files so I am not able to change the fact that those files don't have doctype declarations. My problem is how to validate does files against a DTD. I found at http://common-lisp.net/project/cxml/sax.html#parser that the correctly way should be: > (let ((d (cxml:parse-file "0675365413696898.xml" (cxml-dom:make-dom-builder))) (x (cxml:parse-dtd-file "LMPLCurriculo.DTD"))) (dom:map-document (cxml:make-validator x #"CURRICULO-VITAE") d)) But that gives me two warnings and returns NIL Warning: deprecated SAX default method used by a handler that is not a subclass of SAX:ABSTRACT-HANDLER or HAX:ABSTRACT-HANDLER Warning: deprecated SAX default method used by a handler that is not a subclass of SAX:ABSTRACT-HANDLER or HAX:ABSTRACT-HANDLER NIL That is, it is working. I also tried with an invalid XML and the code fired an error as expected! What about these warnings? Does anything changed in the library and was not documented? How to solve them? Best, Alexandre Rademaker http://arademaker.github.com/

1 0

[pro] Sub-function free variable binding differences between Scheme and CL
by Burton Samograd 05 Mar '12

05 Mar '12

Hello, I am curently translating the logic circuit simulator code from SICP into Common Lisp and have run into a snag that I would like to ask about. The Scheme code is as follows from section 3.3.4 (page 223 of my hardcover edition): (define (and-gate a1 a2 output) (define (and-action-procedure) (let ((new-value (locical-and (get-signal a1) (get-signal a2)))) (after-delay and-gat-delay (lambda () (set-signal! output new-value))))) (add-action! a1 and-action-procedure) (add-action! a2 and-action-procedure)) The code basically binds the local function and-action-procedure into a list of functions in a1 and a2 which are then called by another routine later to perform the action when a value is set on the wire. My translated Common Lisp code is: (defun make-and-gate (a1 a2 output) (flet ((logical-and (a b) (if (= a 1) b a)) (and-action-proc () (let ((new-value (logical-and (get-signal a1) (get-signal a2)))) (set-signal output new-value)))) (add-action a1 #'and-action-proc) (add-action a2 #'and-action-proc))) The problem is that the bindings of a1 and a2 in and-action-proc are not being bound to the values of the calling function in the Common Lisp version. This causes the calling of and-action-proc to fail because a1 and a2 are not bound and I am assuming being treated as dynamic (special) variables. I have also tried to define and-action-proc using labels with no difference in results. Is this a total schemantic difference between CL and Scheme? Is every function in Scheme a closure where free variables of sub-functions bound to the calling functions environment? If so, is there a way to emulate this in Common Lisp? I would also like to note that I am currently trying out writing this code using LispWorks Personal Edition, rather than my usual SBCL environment, if that would make any difference. -- Burton Samograd

2 3

[pro] ELS 2012, Zadar, Croatia
by Marco Antoniotti 01 Feb '12

01 Feb '12

Apologies for the multiple postings. PAPER SUBMISSION DEADLINE EXTENDED European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 http://european-lisp-symposium.org The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2012 European Lisp Conference is "Interoperability: Systems, Libraries, Workflows". Lisp based and functional-languages based systems have grown a variety of solutions to become more and more integrated with the wider world of Information and Communication Technologies in current use. There are several dimensions to the scope of the solutions proposed, ranging from "embedding" of interpreters in C-based systems, to the development of abstractions levels that facilitate the expression of complex context dependent tasks, to the construction of exchange formats handling libraries, to the construction of theorem-provers for the "Semantic Web". The European Lisp Symposium 2012 solicits the submission of papers with this specific theme in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: February 15th 2012: submission deadline (extended deadline) March 7th 2012: acceptance results April 30th 2012: Conference opens Program Commitee. Chair: Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY Local organizers: Damir Cavar, Eastern Michigan University Franjo Pehar, University of Zadar Damir Kero, University of Zadar Members: Giuseppe Attardi, Università degli Studi di Pisa, Pisa, ITALY Pascal Costanza, Intel, Bruxelles, BELGIUM Marc Feeley, Université de Montreal, Montreal, CANADA Scott McKay, Google, U.S.A. Kent Pitman, U.S.A. Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM Robert Strandh, LABRI, Université de Bordeaux, Bordaux, FRANCE Didier Verna, EPITA / LRDE, FRANCE Taiichi Yuasa, Kyoto University, JAPAN -- Marco Antoniotti -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

1 0

[pro] Defined but no used variable warning during setf expansion
by Burton Samograd 24 Jan '12

24 Jan '12

Hello, I am wondering if anyone can explain the reason for the defined but not used variable in setf that this code is experiencing: CL-USER> (set-macro-character #\$ (lambda (stream char) (declare (ignore char)) (let ((v (read stream))) (list (get v 'setf-handler-name) v)))) (defmacro defactive (var value &key write-handler read-handler) (let ((setf-handler-name (gensym))) `(progn (defparameter ,var ,value) (defmacro ,setf-handler-name (,var) (let ((read-handler (gensym))) `(let ((,read-handler (get ',',var :read-handler))) (if ,read-handler (funcall ,read-handler (eval ,',var)) ,',var)))) (defsetf ,setf-handler-name (,var) (new-val) (let ((write-handler (gensym))) `(let ((,write-handler (get ',',var :write-handler))) (when ,write-handler (funcall ,write-handler (eval ,',var) ,new-val)) (setf ,',var ,new-val)))) (setf (get ',var 'setf-handler-name) ',setf-handler-name) (setf (get ',var :write-handler) ,write-handler) (setf (get ',var :read-handler) ,read-handler) ,value))) (defmacro setactive (var &key read-handler write-handler) `(progn (when ,read-handler (setf (get ',var :read-handler) ,read-handler)) (when ,write-handler (setf (get ',var :write-handler) ,write-handler)))) (defactive x 0 :write-handler (lambda (old-val new-val) (format t "old: ~A new: ~A" old-val new-val)) :read-handler (lambda (val) (format t "value: ~A" val) val)) ;(setactive x :read-handler (lambda (val) (format t "~A !!! ~A" val))) ;(setactive x :write-handler (lambda (old-val new-val) (format t "~A !!! ~A" old-val new-val))) (defactive d6 (random 6) :read-handler (lambda (val) (let ((old val)) (setf d6 (random 6)) old))) STYLE-WARNING: redefining COMMON-LISP-USER::DEFACTIVE in DEFMACRO STYLE-WARNING: redefining COMMON-LISP-USER::SETACTIVE in DEFMACRO 1 CL-USER> (setf $x 10) ; in: SETF (#:G1129 X) ; (LET* ((#:G1175 X)) ; (MULTIPLE-VALUE-BIND (#:G1176) ; 10 ; (LET ((#:G1177 #)) ; (WHEN #:G1177 (FUNCALL #:G1177 # #:G1176)) ; (SETF X #:G1176)))) ; ; caught STYLE-WARNING: ; The variable #:G1175 is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition old: 0 new: 10 10 -- Burton Samograd http://kruhft.dyndns.org

5 5

[pro] Declarations in compilers (feedback welcome)
by Juan Jose Garcia-Ripoll 30 Dec '11

30 Dec '11

After struggling mentally with this for a few weeks, I would like to have some consultation before I introduce some changes in ECL -- not that I expect many users here, but at least some implementor-fellows and power users of other implementations. My concerns right now relate to how declarations should be used by a compiler, and in particular how declarations interact with SAFETY levels. Please correct me if I am wrong, but I have seen more or less the following approaches [a]- Most implementations blindly believe declarations below a certain safety level. Above it, they seem more or less useless. [b]- SBCL takes declarations (and THE) as type assertions. For instance, in (LET ((Y (FOO X))) (DECLARE (FIXNUM Y))) ...) the assignment to Y would be checked to be a FIXNUM. This means the type declaration is actually enforced and believed and only at SAFETY 0 the checks are dropped (*) In both cases one ends up with a model in which in order to truly believe a declaration and have no extra burden (assertions), one has to drop to SAFETY 0 in all code that is involved with it, which is a mess, because it might inadvertently affect other parts of the code. It is for this reason that I am considering an alternative model for ECL which would grade safety as follows - Type declarations are always believed - SAFETY >= 1 adds type checks to enforce them. - SAFETY = 0, no checks. - SAFETY = 1, the special form THE or additional proclamations on the functions can be used to deactivate the check. As in (LET ((Y (THE FIXNUM (FOO X))) ...) This would allow one to keep most code safe, while deactivating some checks when they are really known to be true (**). Do you think this is useful/useless? The problem I see with this approach is that all code around is written for model [a] or [b], but I could not come up with something more sensible so far. Juanjo (*) Actually the checks are also deactivated when SBCL can infer the type of the value that is assigned to Y. This is somewhat contradictory, because (SETF Y (THE FIXNUM (FOO X))) would still generate a check, but proclaiming FOO to return a FIXNUM would completely bypass the check. (**) Yes, indeed I know that LOCALLY exists for a reason, but it does more than THE. For instance, if I (LOCALLY (DECLARE (SAFETY 0)) (THE FIXNUM (FOO (SLOT-ACCESSOR X)))... this influences the safety of the code that accesses a structure, which is not good. P.S.: Thanks to Paul Khuong for pointing out that SBCL behaves differently w.r.t. declarations. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 6

[pro] what lisp command line arg parser is good?
by Mark H. David 21 Dec '11

21 Dec '11

Anyone with some thoughts on which command line parser is good to use? There seem to be n of them out there. None really stands out, that I can tell. Must be quicklisp readable, other than that, I don't have any kind of fancy requirements. Just something simple, and reliable. Widely used would be good, and/or well maintained. Any pro tips? Thanks, Mark

8 10

← Newer
1
...
20
21
22
23
24
25
26
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro