Re: Report the evolution of Emacs Lisp sources.

Re: Report the evolution of Emacs Lisp sources.

[A Soare]

Another application of this algorithm is to detect common blocks from many different procedures. This is not an improvment in the speed, but in the size of the lap.



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Report the evolution of Emacs Lisp sources.

[Thien-Thi Nguyen]

() A Soare <alinsoar@voila.fr>
() Wed, 20 Aug 2008 13:46:25 +0200 (CEST)

   Another application of this algorithm is to detect common
   blocks from many different procedures. This is not an
   improvment in the speed, but in the size of the lap.

That would be wonderful.  It's nice to have a way to find out
which code has already been written (and how many times!).  A good
tool for caging the ego, at the very least...

I wish you good luck finding a stopping point for your current
activities so that you can start hacking on this.

thi

Re: Report the evolution of Emacs Lisp sources.

[A Soare]

I am sorry, for the next period I will be very very "deborde" (please help me to translate). I have lots of problems much more interesting and difficult to solve and I have to finish with quickly to pass more far. But I think that I do it in future. Anyways, when I started to solve the problem of indentation, I couldn't figure a clear definition for indentation, and finally I gave a definition as an integral over the code, which can be applied for every arborescent structure (i.e. for every major mode), and I implemented it for lisp, and that will be the future code to indent lisp code in emacs. In future parse-partial-sexp will return the indetation for every major mode. That is why I consider that the problem of indentation was much more difficult, because it was fog around, no clear definition.

Alin Soare.


> Message du 20/08/08 à 22h17
> De : "Thien-Thi Nguyen" <ttn@gnuvola.org>
> A : alinsoar@voila.fr
> Copie à : "Emacs Dev [emacs-devel]" <emacs-devel@gnu.org>
> Objet : Re: Report the evolution of Emacs Lisp sources.
> 
> 
> () A Soare <alinsoar@voila.fr>
> () Wed, 20 Aug 2008 13:46:25 +0200 (CEST)
> 
>    Another application of this algorithm is to detect common
>    blocks from many different procedures. This is not an
>    improvment in the speed, but in the size of the lap.
> 
> That would be wonderful.  It's nice to have a way to find out
> which code has already been written (and how many times!).  A good
> tool for caging the ego, at the very least...
> 
> I wish you good luck finding a stopping point for your current
> activities so that you can start hacking on this.
> 
> thi
> 
> 

____________________________________________________

Des photos de vacances à partager ? Voila vous offre 1 Go d’espace de stockage. http://macle.voila.fr

Re: Report the evolution of Emacs Lisp sources.

[Thien-Thi Nguyen]

() A Soare <alinsoar@voila.fr>
() Wed, 20 Aug 2008 22:53:15 +0200 (CEST)

   I am sorry, for the next period I will be very very "deborde"
   (please help me to translate).

You could say you will be "swamped under", or simply "busy".
No worries, more time for the ideas to cook in the brain...

   I have lots of problems much more interesting and difficult to
   solve and I have to finish with quickly to pass more far. But I
   think that I do it in future.

Then i look forward to news from you, later.

thi

Re: Report the evolution of Emacs Lisp sources.

[A Soare]

>    Yes, it could generate a simple prototype for change logs... as
>    application. When you cut, add, or modify an old structure it
>    will immediately see that.
> 
> The analysis described in the paper you referenced is very
> superficial compared to what is possible w/ elisp.  For example,
> you can use byte-compiler properties (e.g., no side-effects) to
> report the safety of a change.

Yes, lap is a kind of expressing the parsing tree directly, without generating parsing tree during evaluation. So you are almost right (not taking into account that anyways we must run for every file byte-compile instead of read).

In fact all the problem is to compare 2 trees (the parsed code) whose each node keeps a key = <function name> and a leave has key = <a variable name [or] a lisp_object (string, number, etc)>. and to report a minimum set of changes.

> 
>    But note that if you work on version X from the day x, you must
>    keep the original from the day x, otherwise it will detect in
>    your report the changes made by others!
> 
> Actually, reporting the changes made by others is exactly what i
> had in mind.  Sometimes what people write in ChangeLog files is
> better understood w/ a little help from a "second opinion".
> 

true


Yes, I can do it, and maybe I will do it, but later. For now I am concentrated on another issues.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Report the evolution of Emacs Lisp sources.

[A Soare]

>    In this moment, the only method to see how the code of emacs
>    evaluated is `diff'.
> 
> Do you mean to say "evolved" instead of "evaluated"?

evolved, thanks.

> 
>    One can show the differences, by comparing the internal
>    representation of the lisp code tree of 2 versions. I saw this
>    idea for the C code here: [CIL-based AST-diff tool]
> 
>    An advantage of this method would be to report only one when
>    the name of a variable changes. This method will also ignore to
>    report the null-effect characters like blanks or empty new
>    lines. diff reports everything.
> 

> 
>    What do you think, it would be useful such a tool to make
>    reports of lisp code changes? Maybe I will try it, but it might
>    be _realy_ useful?
> 
> Well, there's a lot of noise possible discussing "might be useful"
> (see other threads), so i'll just say that personally i would love
> to have a tool that could intuit and summarize changes, to help
> generate ChangeLog entries.  [dreaming...]  I could hook it up to
> a visualization program[0] and make annotated movies, w/ voice
> commentary...

Yes, it could generate a simple prototype for change logs... as application. When you cut, add, or modify an old structure  it will immediately see that. But note that if you work on version X from the day x, you must keep the original from the day x, otherwise it will detect in your report the changes made by others!


Alin Soare.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Report the evolution of Emacs Lisp sources.

[Thien-Thi Nguyen]

() A Soare <alinsoar@voila.fr>
() Mon, 18 Aug 2008 12:14:45 +0200 (CEST)

   Yes, it could generate a simple prototype for change logs... as
   application. When you cut, add, or modify an old structure it
   will immediately see that.

The analysis described in the paper you referenced is very
superficial compared to what is possible w/ elisp.  For example,
you can use byte-compiler properties (e.g., no side-effects) to
report the safety of a change.

   But note that if you work on version X from the day x, you must
   keep the original from the day x, otherwise it will detect in
   your report the changes made by others!

Actually, reporting the changes made by others is exactly what i
had in mind.  Sometimes what people write in ChangeLog files is
better understood w/ a little help from a "second opinion".

thi

Report the evolution of Emacs Lisp sources.

[A Soare]

In this moment, the only method to see how the code of emacs evaluated is `diff'.

One can show the differences, by comparing the internal representation of the lisp code tree of 2 versions. I saw this idea for the C code here: http://www.cs.umd.edu/~mwh/papers/evolution.pdf .

An advantage of this method would be to report only one when the name of a variable changes. This method will also ignore to report the null-effect characters like blanks or empty new lines. diff reports everything.

What do you think, it would be useful such a tool to make reports of lisp code changes? Maybe I will try it, but it might be _realy_ useful?



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Report the evolution of Emacs Lisp sources.

[A Soare]

In this moment, the only method to see how the code of emacs evaluated is `diff'.

One can show the differences, by comparing the internal representation of the lisp code tree of 2 versions. I saw this idea for the C code here: http://www.cs.umd.edu/~mwh/papers/evolution.pdf .

An advantage of this method would be to report only one when the name of a variable changes. This method will also ignore to report the null-effect characters like blanks or empty new lines. diff reports everything.

What do you think, it would be useful such a tool to make reports of lisp code changes? Maybe I will try it, but it might be _realy_ useful?



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Report the evolution of Emacs Lisp sources.

[Thien-Thi Nguyen]

() A Soare <alinsoar@voila.fr>
() Mon, 18 Aug 2008 09:05:01 +0200 (CEST)

   In this moment, the only method to see how the code of emacs
   evaluated is `diff'.

Do you mean to say "evolved" instead of "evaluated"?

   One can show the differences, by comparing the internal
   representation of the lisp code tree of 2 versions. I saw this
   idea for the C code here: [CIL-based AST-diff tool]

   An advantage of this method would be to report only one when
   the name of a variable changes. This method will also ignore to
   report the null-effect characters like blanks or empty new
   lines. diff reports everything.

To its credit, diff can be told to ignore many things, including
certain classes of whitespace.  But your general point stands.

   What do you think, it would be useful such a tool to make
   reports of lisp code changes? Maybe I will try it, but it might
   be _realy_ useful?

Well, there's a lot of noise possible discussing "might be useful"
(see other threads), so i'll just say that personally i would love
to have a tool that could intuit and summarize changes, to help
generate ChangeLog entries.  [dreaming...]  I could hook it up to
a visualization program[0] and make annotated movies, w/ voice
commentary...

     ttn: Ah, now the variable name has changed.  What luck, we
          have the before and after authors here -- WDYT?
 guest-1: Good choice; short, sweet, not too cryptic.
 guest-2: Umm, what does `x' /really/ mean?
 guest-1: You have obviously lost the thread of this patch series.
 guest-2: Not like you have any better idea, you, you... cowboy!
          [clicks ball-point pen furiously]
 guest-1: Well, i guess `long-screen-eating-varname' is better?
          Too much fun with M-/ again, i take it?
          [sneers]
 guest-2: I strive for semantic cohesion, but maybe that's too
          difficult for one-byte GSR-drunk twitchers to grok.
 guest-1: How dare you mock my keyboard-fu!  Cretin!
     ttn: Ah, now the variable name has changed back.  The
          ChangeLog entry mentions "aliasing problems"...
 guest-2: See, see!  It was /you/ who broke the build.
 guest-1: Feh, nobody uses this code anyway.
     ttn: [amidst scuffling sounds] That concludes the audio
          portion of "the underbelly of emacs", please enjoy
          the remaining video portion...

Or maybe not.  :-D

thi

_________________________________________________________________
[0] http://www.gnuvola.org/software/j/buffer-thumbnail/output/

Re: Report the evolution of Emacs Lisp sources.

[Miles Bader]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>      ttn: [amidst scuffling sounds] That concludes the audio
>           portion of "the underbelly of emacs", please enjoy
>           the remaining video portion...

I thought Emacs was all thick, luxuriant fur.

-Miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Re: Report the evolution of Emacs Lisp sources.

[Thien-Thi Nguyen]

() Miles Bader <miles.bader@necel.com>
() Mon, 18 Aug 2008 19:05:45 +0900

   I thought Emacs was all thick, luxuriant fur.

Fur is but hair, a conduit for sweat.
Sweat is but toxin, escaped from within.
Within is but dreams, molded by change.
Change is but memory, stretched over time.
Time is but sequences of buffered perception.

Buffered perception is our luxury; thank Emacs and its hackers.

thi