[slime-devel] compiling forms/regions/defuns with (optimize (debug 3) (speed 0) (safety 0))
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
On Tue, 2006-11-21 at 18:57 +0100, Marco Baringer wrote:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
It would be a good idea if these settings actually worked in SBCL, instead of (sometimes) making the compiler bomb out :(
Maybe it could wrap the code in a user-defined thing that defaulted to your value except on SBCL.
On Nov 21, 2006, at 1:18 PM, Dan Weinreb wrote:
On Tue, 2006-11-21 at 18:57 +0100, Marco Baringer wrote:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
It would be a good idea if these settings actually worked in SBCL, instead of (sometimes) making the compiler bomb out :(
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
-- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
dlw@itasoftware.com wrote:
On Tue, 2006-11-21 at 18:57 +0100, Marco Baringer wrote:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
[...]
It would be a good idea if these settings actually worked in SBCL, instead of (sometimes) making the compiler bomb out :(
They will be more likely to work in SBCL if any such problems are reported to SBCL developers, preferably with a failing test case.
On Wed, 2006-11-22 at 03:37 +0000, Juho Snellman wrote:
dlw@itasoftware.com wrote:
On Tue, 2006-11-21 at 18:57 +0100, Marco Baringer wrote:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
[...]
It would be a good idea if these settings actually worked in SBCL, instead of (sometimes) making the compiler bomb out :(
They will be more likely to work in SBCL if any such problems are reported to SBCL developers, preferably with a failing test case.
I did report it to our local SBCL maintainer. It would be extremely difficult to send a reproducible test case to anyone external since the test case was a recompile of our entire software base. I could send just a stack trace, if that would help.
Dan Weinreb dlw@itasoftware.com writes:
I did report it to our local SBCL maintainer. It would be extremely difficult to send a reproducible test case to anyone external since the test case was a recompile of our entire software base. I could send just a stack trace, if that would help.
Reporting the error, SBCL version, and a stack-trace is definitely much better then nothing at all.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Dan Weinreb dlw@itasoftware.com writes:
I did report it to our local SBCL maintainer. It would be extremely difficult to send a reproducible test case to anyone external since the test case was a recompile of our entire software base. I could send just a stack trace, if that would help.
Who is your local SBCL maintainer?
Cheers,
Christophe
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
this is a good idea. i'm already using a stone-age variant of this: some of my asdf systems (mostly the test systems) have a :after method that issue a (declaim ...) to enable debug 3, therefore i don't have to keep it in mind, and still everything i C-c C-c (and that will most probably break because of this :) is compiled with debug.
so my suggestion is to make it an alterable state of a swank connection in one way or another; i would find that more fitting for my usecases.
* Marco Baringer [2006-11-21 18:57+0100] writes:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
Bad idea, because it will mess up source code locations.
Would something like
(eval `(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) (compile ,form)))
do the right thing?
Helmut.
heller@common-lisp.net wrote:
- Marco Baringer [2006-11-21 18:57+0100] writes:
what do people think about a varient of slime-compile-defun which wrapped the code in
(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) ,@form)
i'd bind this to C-u C-c C-c (and C-u C-c C-k)
good idea? bad idea?
Bad idea, because it will mess up source code locations.
Would something like
(eval `(locally (declaim (optimize (speed 0) (safety 3) (debug 3))) (compile ,form)))
do the right thing?
No. Declaim will apply the declarations into the global environment, so any subsequent compilations would also be done using that optimization policy. Wrapping a locally around the declamation will not change that.
I'm afraid there's no portable way of restoring the optimization policy back to its original state. CMUCL has an extension to with-compilation-unit for this. In SBCL swank-compile-string could bind sb-c::*policy*, proclaim the new policy, and only then do the compile-file. I don't know about other implementations.
Juho Snellman jsnell@iki.fi writes:
I'm afraid there's no portable way of restoring the optimization policy back to its original state. CMUCL has an extension to with-compilation-unit for this. In SBCL swank-compile-string could bind sb-c::*policy*, proclaim the new policy, and only then do the compile-file. I don't know about other implementations.
but we could add a :declarations parameter to swank-backend:swank-compile-string. on lisps where it's possible (sbcl, cmucl for now) we'd use whatever hooks it took to change these settings locally, other lisps could just ignore them.
is this good enough?
* Marco Baringer [2006-11-22 14:28+0100] writes:
but we could add a :declarations parameter to swank-backend:swank-compile-string. on lisps where it's possible (sbcl, cmucl for now) we'd use whatever hooks it took to change these settings locally, other lisps could just ignore them.
is this good enough?
Alternatively, we could add something (backend specific) to access the current optimization policy and do something like:
(let ((old-policy (get-policy))) (proclaim '(optimize (debug 3))) (compile ...) (proclaim old-policy))
Helmut.
-
Attila Lendvai -
Christophe Rhodes -
Dan Weinreb -
Gary King -
Helmut Eller -
Juho Snellman -
Marco Baringer -
Nikodemus Siivola