Save & load file

Marco Antoniotti marcoxa at cs.nyu.edu
Wed Jul 15 17:28:58 UTC 2015


> On Jul 15, 2015, at 18:49 , Martin Simmons <martin at lispworks.com> wrote:
> 
>>>>>> On Wed, 15 Jul 2015 07:48:17 -0500, Blake McBride said:
>> 
>> On Wed, Jul 15, 2015 at 6:48 AM, Attila Lendvai <attila at lendvai.name> wrote:
>> 
>>>> I don't like to be forced to re-compile it in order to load it for the
>>>> following reasons:
>>> 
>>> ASDF solves most of these problems, including fasl file placement,
>>> especially if you are willing to write a line or two to load your
>>> codebase with some debugging extras (a (DECLAIM (OPTIMIZE DEBUG)), and
>>> i also have some macros that react to variables, notably dribble level
>>> logging stops being a no-op).
>>> 
>>> among the things you listed the only thing that i don't know how to
>>> solve in my ASDF/slime setup is losing track of what i've edited and
>>> haven't given to the lisp for redefinition yet. what i do is i keep
>>> track of it in my head, and whenever i suspect that things may be out
>>> of sync, then i press 3 key combination to restart the lisp and
>>> recompile/reload the project.
>>> 
>>> hth,
>>> 
>> 
>> So, it sounds like we can setup ASDF, learn a bunch of steps, add debugging
>> code to our app, and just reset the whole world if we think we might have
>> gotten confused,
>> 
>> or,
>> 
>> we can just use slime-save-and-load.
>> 
>> Is that a fair statement?
> 
> A third option is to implement slime-compile-buffer using
> slime-compile-region.  I often use Compile Buffer when developing in the
> LispWorks IDE.
> 
> The main advantage of compiling v.s. source code loading is that you get the
> compiler diagnostics such as "assumed special" warnings.

I second that.

“Compile Buffer” is a very good thing to have.

MA





More information about the slime-devel mailing list