[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? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
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. -- Juho Snellman
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. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
* 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
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 Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
* 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.
participants (8)
-
Attila Lendvai -
Christophe Rhodes -
Dan Weinreb -
Gary King -
Helmut Eller -
Juho Snellman -
Marco Baringer -
Nikodemus Siivola