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