unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Report the evolution of Emacs Lisp sources.
@ 2008-08-20 11:46 A Soare
  2008-08-20 20:14 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 12+ messages in thread
From: A Soare @ 2008-08-20 11:46 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: Emacs   Dev  [emacs-devel]



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






^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: Report the evolution of Emacs Lisp sources.
@ 2008-08-20 20:53 A Soare
  2008-08-21  2:02 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 12+ messages in thread
From: A Soare @ 2008-08-20 20:53 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: Emacs   Dev  [emacs-devel]



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






^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: Report the evolution of Emacs Lisp sources.
@ 2008-08-19 20:13 A Soare
  0 siblings, 0 replies; 12+ messages in thread
From: A Soare @ 2008-08-19 20:13 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: Emacs   Dev  [emacs-devel]


>    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






^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: Report the evolution of Emacs Lisp sources.
@ 2008-08-18 10:14 A Soare
  2008-08-19 13:22 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 12+ messages in thread
From: A Soare @ 2008-08-18 10:14 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: Emacs   Dev  [emacs-devel]


>    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






^ permalink raw reply	[flat|nested] 12+ messages in thread
* Report the evolution of Emacs Lisp sources.
@ 2008-08-18  7:05 A Soare
  0 siblings, 0 replies; 12+ messages in thread
From: A Soare @ 2008-08-18  7:05 UTC (permalink / raw)
  To: Emacs   Dev  [emacs-devel]


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






^ permalink raw reply	[flat|nested] 12+ messages in thread
* Report the evolution of Emacs Lisp sources.
@ 2008-08-18  7:05 A Soare
  2008-08-18  9:44 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 12+ messages in thread
From: A Soare @ 2008-08-18  7:05 UTC (permalink / raw)
  To: Emacs   Dev  [emacs-devel]



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






^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2008-08-21  2:02 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-20 11:46 Report the evolution of Emacs Lisp sources A Soare
2008-08-20 20:14 ` Thien-Thi Nguyen
  -- strict thread matches above, loose matches on Subject: below --
2008-08-20 20:53 A Soare
2008-08-21  2:02 ` Thien-Thi Nguyen
2008-08-19 20:13 A Soare
2008-08-18 10:14 A Soare
2008-08-19 13:22 ` Thien-Thi Nguyen
2008-08-18  7:05 A Soare
2008-08-18  7:05 A Soare
2008-08-18  9:44 ` Thien-Thi Nguyen
2008-08-18 10:05   ` Miles Bader
2008-08-19 13:11     ` Thien-Thi Nguyen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).