[slime-devel] Re: recording and compiling changed definitions

[Helmut Eller]

* Marco Baringer [2007-04-09 18:06+0200] writes:

> i'm sorry, but i fail to see how that is possible without having the
> editor (be it emacs or something embedded in the compiler) tell the
> compiler what text has been written/edited and what hasn't.
>
> or do you mean we should save all the files and then tell the compiler
> to re-read them all and infer what needs to be done? if that's what
> you're saying then i'd still like this feature if just for the emacs
> buffer listing the changes before the source code (which may or not be
> valid) is read/compiled.

Yes, I'm saying the compiler, not SLIME, should find changes and
figure out what needs to be compiled.

>
> the emacs side of eli keeps track of what files have been modified and
> passes the original and the new version to allegro who'd then do a
> smart diff. what i'm suggesting here is a slightly smarter version of
> that, why bother diff'ing if we can learn what's different as the
> changes get made?

Because it's more precise and needs less complicated code in Emacs.
Why re-implement half of the compiler in Emacs?

>> As far as I can see, this feature tries to work around slow compilers.
>> Why not fix the compiler instead?
>
> this feature serves two purposes:
>
> 1) make emacs keep track of all the code i've edited since the last
>    compile. even without actually being able to compile the code i
>    find the list-changed-forms buffer very useful. often i'll be
>    working on a single piece of functionality which is speard across
>    multiple files (one file has the db class definition, another the
>    corresponding xml-api implementation and a third has the core code
>    itself) it's a pain to remeber all the pieces i've touched. maybe
>    i've saved the buffers, so i can't just use buffer-modified-p,
>    maybe i haven't saved the buffers, so 'svn stat' doesn't help,
>    maybe i've edited the documentation and i don't care about those
>    files. in this case it really is nice to ask emacs for a list, in a
>    single buffer, of all the lisp forms i've been working on
>    rencently.
>
>    being able to order and compile these forms is really just icing on
>    the cake. i could just as well walk down the buffer and hit c on
>    each form to compile them manually in whatever order i want.

That wouldn't work for me because I press C-x C-s and C-c C-c every
few seconds anyway.

>
> 2) work around projects where build times are 20 minutes or more. you
>    can only speed up the compiler so far, some projects are just big
>    and there's nothing you can do about it.

That's what a incremental compiler is for: small changes to big
programs can be compiled instantaneously.

> now, having said all that there's no way, given an arbitrary set of
> changed lisp forms and an arbitrary set of existing definitions in the
> image, to properly infer what order they need to be compiled in
> without compiling and executing them. this last step is going to error
> if you get the order wrong, since you have to this to get the ordering
> right you're screwed in the general case.

That's true, but getting the order right on a per file basis instead
on a per form basis doesn't sound very difficult.  Most of the time,
the order of the files is defined by some kind of Makefile/asdf
definition.  Instead of tracking forms in the editor, you could give
the compiler an (ordered) list of files to watch.  If one file changes
the compiler could figure out which form changed and recompile only
the necessary parts. (This would also allow proper error messages for
those parts which haven't changed but are affected by the changes.)
Writing such a compiler isn't easy, but adding those feature to the
editor is IMO the wrong place.

> in practice the 80% solution is helpful, but i'll drop if it seems
> like bloat.

I think this is bloat.  We should instead encourage Lisp implementors
to write smarter compilers with proper dependency tracking.  Or write
a tool to properly analyze CL source code, but I doubt that you want
to do that in Emacs Lisp.

A "changed definition" feature like this was discussed here before and
at that time we concluded that C-c C-k is fast enough for most
purposes.

Helmut.