compile.el's recomputation of locations for omake

compile.el's recomputation of locations for omake

[Stefan Monnier]

I'm having some trouble with the timestamp business that you introduced
to try and handle the "omake -P" case.  Could you help me understand
exactly which scenario it's trying to handle?

Some more specific questions:
- The comment says:

;; Once any location in some file has been jumped to, the list is extended to
;; (COLUMN LINE FILE-STRUCTURE MARKER TIMESTAMP . VISITED)
;; for all LOCs pertaining to that file.
;; MARKER initially points to LINE and COLUMN in a buffer visiting that file.
;; Being a marker it sticks to some text, when the buffer grows or shrinks
;; before that point.  VISITED is t if we have jumped there, else nil.
;; TIMESTAMP is necessary because of "incremental compilation": `omake -P'
;; polls filesystem for changes and recompiles when a file is modified
;; using the same *compilation* buffer. this necessitates re-parsing markers.

  but it doesn't explain what data is stored in TIMESTAMP.  Is it the
  timestamp of when the location was visited by the user, or the
  timestamp of when all the locations of the file were turned into
  markers, or ...?

- As far as I can tell, the code first turns all the locs from (col
  line file) to (col line file marker), and then the locs that are
  visited (and only those) are extended with the additional (timestamp
  . visited).
  Is that on purpose?  Is it right?

- The code does:

    (setcdr (nthcdr 3 loc) (list timestamp))
    (setcdr (nthcdr 4 loc) t)))		; Set this one as visited.

  But AFAICT, this is identical to

    (setcdr (nthcdr 3 loc) (cons timestamp t)))) ; Set this one as visited.

  So the VISITED part seems unnecessary, since TIMESTAMP is only non-nil
  when visited is non-nil, IIUC.

- The time-check used to decide whether to recompute the locations looks
  at the TIMESTAMP entry, which will be nil for any not-yet-visited
  loc, AFAICT.  So we'll end up recomputing the locations pretty much
  every time, except when the user visits a location she
  already visited.  Am I missing something?

- The compilation-buffer-modtime used is changed whenever the
  compilation process outputs something.  That means that for a traditional
  (not "omake -P") compilation, if you visit an error before the process
  is finished, it will be recomputed if you try to visit it again later.

Basically, I think we should rethink this approach.  One venue that
seems more promising would be if omake outputs some special text
whenever it starts a new compilation, which we could recognize to mark
subsequent locations for recomputation.


        Stefan

Re: compile.el's recomputation of locations for omake

[Sam Steingold]

On Thu, Jan 27, 2011 at 9:28 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I'm having some trouble with the timestamp business that you introduced
> to try and handle the "omake -P" case.  Could you help me understand
> exactly which scenario it's trying to handle?

I can try, but I no longer use it and I am not planning on resuming...

> Some more specific questions:
> - The comment says:
>
> ;; Once any location in some file has been jumped to, the list is extended to
> ;; (COLUMN LINE FILE-STRUCTURE MARKER TIMESTAMP . VISITED)
> ;; for all LOCs pertaining to that file.
> ;; MARKER initially points to LINE and COLUMN in a buffer visiting that file.
> ;; Being a marker it sticks to some text, when the buffer grows or shrinks
> ;; before that point.  VISITED is t if we have jumped there, else nil.
> ;; TIMESTAMP is necessary because of "incremental compilation": `omake -P'
> ;; polls filesystem for changes and recompiles when a file is modified
> ;; using the same *compilation* buffer. this necessitates re-parsing markers.
>
>  but it doesn't explain what data is stored in TIMESTAMP.  Is it the
>  timestamp of when the location was visited by the user, or the
>  timestamp of when all the locations of the file were turned into
>  markers, or ...?

timestamp, IIRC, is the time when we last parsed the compilation
buffer and set up pointers to the source code.

>  So the VISITED part seems unnecessary, since TIMESTAMP is only non-nil
>  when visited is non-nil, IIUC.

maybe...

> - The compilation-buffer-modtime used is changed whenever the
>  compilation process outputs something.  That means that for a traditional
>  (not "omake -P") compilation, if you visit an error before the process
>  is finished, it will be recomputed if you try to visit it again later.

yes. is this a problem?

> Basically, I think we should rethink this approach.

maybe. I am sorry my approach did not work out.

> One venue that
> seems more promising would be if omake outputs some special text
> whenever it starts a new compilation, which we could recognize to mark
> subsequent locations for recomputation.

it certainly does (but I don't remember what).

It might well be that this whole thing should be dropped altogether.

I wrote it when I worked for a company which used omake for its build process.
we were quite unhappy with it and they might be switching away from it now.
omake is buggy, leaks memory like crazy, has obscene start up time
(which is why "-P" was introduced)
its development was stuck at v. 0.9.8.5 for 3+ years (until 0.9.8.6
was released a couple of months ago).

I am no longer sure this feature is worth supporting - but I am not
sure it is worthless either.
It is your call.

-- 
Sam Steingold <http://sds.podval.org>

Re: compile.el's recomputation of locations for omake

[Stefan Monnier]

> timestamp, IIRC, is the time when we last parsed the compilation
> buffer and set up pointers to the source code.

So the code seems to have bug since it only sets the time stamp on the
locations the user actually visits.

>> - The compilation-buffer-modtime used is changed whenever the
>>  compilation process outputs something.  That means that for a traditional
>>  (not "omake -P") compilation, if you visit an error before the process
>>  is finished, it will be recomputed if you try to visit it again later.

> yes. is this a problem?

Yes, it's a problem because:
- the reparse is not needed (we're presuming a traditional compilation,
  so reparsing is never needed).
- more importantly, in case the user has edited the buffer in the mean
  time (adding/removing lines), the reparsing will end up using
  incorrect line numbers that don't take into account the lines
  added/removed whereas the markers that were present before the
  reparsing did take that into account.  So the reparsing is not only
  a waste of time, but it also worsens the behavior.

>> Basically, I think we should rethink this approach.
> maybe.  I am sorry my approach did not work out.

No need to be sorry.

> I wrote it when I worked for a company which used omake for its build
> process.  we were quite unhappy with it and they might be switching
> away from it now.  omake is buggy, leaks memory like crazy, has
> obscene start up time (which is why "-P" was introduced) its
> development was stuck at v. 0.9.8.5 for 3+ years (until 0.9.8.6 was
> released a couple of months ago).

> I am no longer sure this feature is worth supporting - but I am not
> sure it is worthless either.
> It is your call.

Thanks.  I'll disable it via a `compilation--omake-hack' variable, then.


        Stefan