What do you use in List instead of assert() in C/C++?
Is the any kind of preprocessor in Lisp? How to you switch from Debug ro
Release configuration in Makefile when compiling Lisp code?
V.Ch. wrote:
> What do you use in List instead of assert() in C/C++?
ASSERT
> Is the any kind of preprocessor in Lisp?
Macros.
> How to you switch from Debug ro
> Release configuration in Makefile when compiling Lisp code?
Macros or read-time conditionalization, that is #+ or #-
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> V.Ch. wrote:
>
>> What do you use in List instead of assert() in C/C++?
>
>
> ASSERT
>
Thanks for the keyword (although it was quite obvious - shame I hadn't
looked it up before posting).
However, it doesn't seem to work quite how I expected (i.e. zero runtime
overhead in Release build).
It looks like the closest to C-style assert is the following code:
#+debug (assert ....)
The first problem with this is that it looks clumsy. Is there any way
(using macros, whatever) to make this less verbose (and preferably
without any ugly characters, just an identifier)?
The second problem is that in order to use this I need to add a symbol
:debug to the *features* list. How to do this from the Makefile (i.e.
from a command-line parameter to lisp)?
V.Ch. wrote:
> Pascal Costanza wrote:
>
>> V.Ch. wrote:
>>
>>> What do you use in List instead of assert() in C/C++?
>>
>>
>>
>> ASSERT
>>
>
> Thanks for the keyword (although it was quite obvious - shame I hadn't
> looked it up before posting).
>
> However, it doesn't seem to work quite how I expected (i.e. zero runtime
> overhead in Release build).
"Release build" is a MSVC term. It does not necessarily apply to a
"delivered application" in Common Lisp, or, for what that matters, to a
Linux GCC project.
>
> It looks like the closest to C-style assert is the following code:
>
> #+debug (assert ....)
>
> The first problem with this is that it looks clumsy. Is there any way
> (using macros, whatever) to make this less verbose (and preferably
> without any ugly characters, just an identifier)?
You write a macro.
(in-package "MY-DEBUG")
(defvar *debugging* t)
(defmacro asserting (datum &rest args)
`(when *debugging*
(assert ,datum ,@args)))
then in your code you write
(use-package "MY-DEBUG")
(defun my-stuff (x)
(asserting (plusp x)) ....)
Just before delivering an application you do
(setf my-debug:*debugging* nil)
;;; deliver the application.
Note that you can become even more clever and ensure that your ASSERTING
macro actually always expands to NIL when the debug variable is NIL.
> The second problem is that in order to use this I need to add a symbol
> :debug to the *features* list. How to do this from the Makefile (i.e.
> from a command-line parameter to lisp)?
You don't usually use Makefiles with Common Lisp, and your command-line
is the REPL itself. Different implementations do it differently.
However, you can usually call a function that "dumps" an application
with all the bells and whistles you need. Of course, usually you are
always *within* the CL enviroment while you do so. So, in some sense,
you have much more flexibility and homogeneity than depending on the IDE
or on a separate framework (a Makefile) to control such things. Again
this is implementation dependent. YMMV.
Cheers
--
Marco
On Fri, 06 May 2005 16:03:56 -0400, Marco Antoniotti wrote:
>
>
> V.Ch. wrote:
>> Pascal Costanza wrote:
>>
>>> V.Ch. wrote:
>>>
>>>> What do you use in List instead of assert() in C/C++?
>>>
>>>
>>>
>>> ASSERT
>>>
>>
>> Thanks for the keyword (although it was quite obvious - shame I hadn't
>> looked it up before posting).
>>
>> However, it doesn't seem to work quite how I expected (i.e. zero runtime
>> overhead in Release build).
>
> "Release build" is a MSVC term. It does not necessarily apply to a
> "delivered application" in Common Lisp, or, for what that matters, to a
> Linux GCC project.
>
>
>
>>
>> It looks like the closest to C-style assert is the following code:
>>
>> #+debug (assert ....)
>>
>> The first problem with this is that it looks clumsy. Is there any way
>> (using macros, whatever) to make this less verbose (and preferably
>> without any ugly characters, just an identifier)?
>
> You write a macro.
>
> (in-package "MY-DEBUG")
>
> (defvar *debugging* t)
>
> (defmacro asserting (datum &rest args)
> `(when *debugging*
> (assert ,datum ,@args)))
>
> then in your code you write
>
> (use-package "MY-DEBUG")
>
> (defun my-stuff (x)
> (asserting (plusp x)) ....)
>
Hmm, but that doesn't do what the OP wanted: it _will_ introduce a runtime
overhead (not that this would be a big performance hit but itself it does
alter the machine code that gets produced).
>
> Just before delivering an application you do
>
> (setf my-debug:*debugging* nil)
>
> ;;; deliver the application.
>
>
> Note that you can become even more clever and ensure that your ASSERTING
> macro actually always expands to NIL when the debug variable is NIL.
That's the way to go to avoid runtime presence of the assertion check. But
that requires recompilation of all sources.
>> The second problem is that in order to use this I need to add a symbol
>> :debug to the *features* list. How to do this from the Makefile (i.e.
>> from a command-line parameter to lisp)?
>
> You don't usually use Makefiles with Common Lisp, and your command-line
> is the REPL itself.
Don't you? Hmm, i still do use makefiles for my software builds.
Especially in the presence of macros one missing recompilation can result
in astonishing effects :-)
> Different implementations do it differently. However, you can usually
> call a function that "dumps" an application with all the bells and
> whistles you need. Of course, usually you are always *within* the CL
> enviroment while you do so. So, in some sense, you have much more
> flexibility and homogeneity than depending on the IDE or on a separate
> framework (a Makefile) to control such things. Again this is
> implementation dependent. YMMV.
So, you write your "makefile" in Lisp. Well, to switch on debuging that
would be: (pushnew :debug *features*)
To switch of debugging: (setf *features* (remove :debug *features*))
HTH Ralf Mattes
> Cheers
R. Mattes wrote:
> On Fri, 06 May 2005 16:03:56 -0400, Marco Antoniotti wrote:
>
>
>>
>>V.Ch. wrote:
>>
>>>Pascal Costanza wrote:
>>>
>>>
>>>>V.Ch. wrote:
>>>>
>>>>
>>>>>What do you use in List instead of assert() in C/C++?
>>>>
>>>>
>>>>
>>>>ASSERT
>>>>
>>>
>>>Thanks for the keyword (although it was quite obvious - shame I hadn't
>>>looked it up before posting).
>>>
>>>However, it doesn't seem to work quite how I expected (i.e. zero runtime
>>>overhead in Release build).
>>
>>"Release build" is a MSVC term. It does not necessarily apply to a
>>"delivered application" in Common Lisp, or, for what that matters, to a
>>Linux GCC project.
>>
>>
>>
>>
>>>It looks like the closest to C-style assert is the following code:
>>>
>>>#+debug (assert ....)
>>>
>>>The first problem with this is that it looks clumsy. Is there any way
>>>(using macros, whatever) to make this less verbose (and preferably
>>>without any ugly characters, just an identifier)?
>>
>>You write a macro.
>>
>>(in-package "MY-DEBUG")
>>
>>(defvar *debugging* t)
>>
>>(defmacro asserting (datum &rest args)
>> `(when *debugging*
>> (assert ,datum ,@args)))
>>
>>then in your code you write
>>
>>(use-package "MY-DEBUG")
>>
>>(defun my-stuff (x)
>> (asserting (plusp x)) ....)
>>
>
> Hmm, but that doesn't do what the OP wanted: it _will_ introduce a runtime
> overhead (not that this would be a big performance hit but itself it does
> alter the machine code that gets produced).
(defmacro assertion (datum &rest args)
(when *debugging*
`(assert ,datum ,@args)))
>
>
>
>>Just before delivering an application you do
>>
>>(setf my-debug:*debugging* nil)
>>
>>;;; deliver the application.
>>
>>
>>Note that you can become even more clever and ensure that your ASSERTING
>>macro actually always expands to NIL when the debug variable is NIL.
>
>
> That's the way to go to avoid runtime presence of the assertion check. But
> that requires recompilation of all sources.
... and what exactly do you do when you produce a "Release" instead of a
"Debug" configuration? Setting -DNDEBUG on the command line or via the
IDE looks like demanding a recompilation to me.
>
>>>The second problem is that in order to use this I need to add a symbol
>>>:debug to the *features* list. How to do this from the Makefile (i.e.
>>>from a command-line parameter to lisp)?
>>
>>You don't usually use Makefiles with Common Lisp, and your command-line
>>is the REPL itself.
>
>
> Don't you? Hmm, i still do use makefiles for my software builds.
> Especially in the presence of macros one missing recompilation can result
> in astonishing effects :-)
I use MK:DEFSYSTEM or ASDF. I have not used a Makefile for Common Lisp
projects in ages. Actually I don't think I ever used one. I did use
`make' for Java projects though.
>>Different implementations do it differently. However, you can usually
>>call a function that "dumps" an application with all the bells and
>>whistles you need. Of course, usually you are always *within* the CL
>>enviroment while you do so. So, in some sense, you have much more
>>flexibility and homogeneity than depending on the IDE or on a separate
>>framework (a Makefile) to control such things. Again this is
>>implementation dependent. YMMV.
>
>
> So, you write your "makefile" in Lisp. Well, to switch on debuging that
> would be: (pushnew :debug *features*)
> To switch of debugging: (setf *features* (remove :debug *features*))
Yes, that would be one way of doing it. Using (carefully) the macro I
posted, would be another. It is a matter of taste and convenience. The
point is that *is* Common Lisp. No separate pre-processor and no
separate language.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>You write a macro.
>>>
>>>(in-package "MY-DEBUG")
>>>
>>>(defvar *debugging* t)
(eval-when (:compile-topleve :load-toplevel :execute)
(defconstant +debugging+ t))
>>>(defmacro asserting (datum &rest args)
>>> `(when *debugging*
>>> (assert ,datum ,@args)))
>>>
>>>then in your code you write
>>>
>>>(use-package "MY-DEBUG")
>>>
>>>(defun my-stuff (x)
>>> (asserting (plusp x)) ....)
>>>
>> Hmm, but that doesn't do what the OP wanted: it _will_ introduce a
>> runtime
>> overhead (not that this would be a big performance hit but itself it does
>> alter the machine code that gets produced).
>
> (defmacro assertion (datum &rest args)
> (when *debugging*
> `(assert ,datum ,@args)))
(defmacro assertion (datum &rest args)
(when +debugging+
`(assert ,datum ,@args)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Hi Pascal
Good point. But that would prevent you from doing things like
(load "debugging-support")
(setf my-debug:*debugging* nil)
(compile-the-stuff)
(deliver "myapplication")
Cheers
--
Marco
Pascal Bourguignon wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>>>>You write a macro.
>>>>
>>>>(in-package "MY-DEBUG")
>>>>
>>>>(defvar *debugging* t)
>
>
> (eval-when (:compile-topleve :load-toplevel :execute)
> (defconstant +debugging+ t))
>
>
>>>>(defmacro asserting (datum &rest args)
>>>> `(when *debugging*
>>>> (assert ,datum ,@args)))
>>>>
>>>>then in your code you write
>>>>
>>>>(use-package "MY-DEBUG")
>>>>
>>>>(defun my-stuff (x)
>>>> (asserting (plusp x)) ....)
>>>>
>>>
>>>Hmm, but that doesn't do what the OP wanted: it _will_ introduce a
>>>runtime
>>>overhead (not that this would be a big performance hit but itself it does
>>>alter the machine code that gets produced).
>>
>>(defmacro assertion (datum &rest args)
>> (when *debugging*
>> `(assert ,datum ,@args)))
>
>
> (defmacro assertion (datum &rest args)
> (when +debugging+
> `(assert ,datum ,@args)))
>
>
Pascal Bourguignon wrote:
>
> (eval-when (:compile-topleve :load-toplevel :execute)
> (defconstant +debugging+ t))
>
I don't fully understand when this eval-when executes (read HyperSpec
once, but obviously need to come back later;) ), and why it's better
than a straightforward variable declaraion, but what if all these
conditions - :compile-topleve :load-toplevel :execute - don't hold?
Looks like we are getting undefined variable during macro expansion, but
need +debugging+ set to nil instead.