Watchpoints for emacs lisp.

Watchpoints for emacs lisp.

[alin.s]

I promised that I can do the watchpoints for emacs lisp when I have some
time.

Here I come back, and I ask whether they are still in the list of
requirements.

I would like to do them , if they are still necessary,


Alin.



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28512483.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Richard Stallman]

The feature is still desired.

Re: Watchpoints for emacs lisp.

[alin.s]

Richard Stallman wrote:
> 
> The feature is still desired.
> 


I think to do it so:

I insert to the struct Lisp_Symbol a field :watched: .

I write a function whose input it a string S. This function looks for the
given symbol in the corresponding obarray (global and local environment).
When it finds the symbol whose name is S , it sets the flag :watched: to
true.

Afterwards, in ALL functions that are able to change the value of a symbol,
I insert a checkpoint, which looks like that:

<if the symbol to change has the flag :watched: true, that call the
corresponding procedure of the debugger>

Is it ok the algorithm ? In how many obarrays should I look for the given
symbol ?








 





-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28523705.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Ken Raeburn]

On May 11, 2010, at 08:54, alin.s wrote:
> I think to do it so:
> 
> I insert to the struct Lisp_Symbol a field :watched: .

So, no support for watching for an element of an array or pair to be changed, or part of a string?

> I write a function whose input it a string S. This function looks for the
> given symbol in the corresponding obarray (global and local environment).
> When it finds the symbol whose name is S , it sets the flag :watched: to
> true.
> 
> Afterwards, in ALL functions that are able to change the value of a symbol,
> I insert a checkpoint, which looks like that:
> 
> <if the symbol to change has the flag :watched: true, that call the
> corresponding procedure of the debugger>
> 
> Is it ok the algorithm ? In how many obarrays should I look for the given
> symbol ?

If you do it this way, I think having a Lisp function take a symbol in which to set the flag, and having a user-callable function which uses (interactive "S") (which asks the user for a symbol name in the main obarray), is probably a good start.  Anything that isn't in the main obarray can be provided directly in lisp by the developer.

What about changes to the property list, or function value, of a symbol?

Ken

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

> I insert to the struct Lisp_Symbol a field :watched: .

No, that would add 8 more bytes to every symbol for a feature that's
almost never used.

I think a good starting point is to use the existing `constant'
field and just add a special WATCHED value to it (it already has 2bits
but only uses 1, so you don't even need to make the field any larger).

Then you just need to check all places where this `constant' field is
used and make them react appropriately (which may mean "don't do
anything since it's already signalling an error" in many places).

And then you need to add functions to set/clear this `watched' attribute.

> I write a function whose input it a string S. This function looks for the
> given symbol in the corresponding obarray (global and local environment).

No, don't take a string as argument: take a symbol.

> Is it ok the algorithm ? In how many obarrays should I look for the given
> symbol ?

If your arg is a symbol instead of a string, this question is
trivially solved.


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
>> I insert to the struct Lisp_Symbol a field :watched: .
> 
> No, that would add 8 more bytes to every symbol for a feature that's
> almost never used.
> 
> I think a good starting point is to use the existing `constant'
> field and just add a special WATCHED value to it (it already has 2bits
> but only uses 1, so you don't even need to make the field any larger).
> 

I did not know about that bit!


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28525731.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
>> I insert to the struct Lisp_Symbol a field :watched: .
> 
> I think a good starting point is to use the existing `constant'
> field and just add a special WATCHED value to it (it already has 2bits
> but only uses 1, so you don't even need to make the field any larger).
> 
> 

Here is the symbol structure. Can you point your finger on the unused bit ?


/* In a symbol, the markbit of the plist is used as the gc mark bit */

struct Lisp_Symbol
{
  unsigned gcmarkbit : 1;

  /* Non-zero means symbol serves as a variable alias.  The symbol
     holding the real value is found in the value slot.  */
  unsigned indirect_variable : 1;

  /* Non-zero means symbol is constant, i.e. changing its value
     should signal an error.  */
  unsigned constant : 1;

  /* Interned state of the symbol.  This is an enumerator from
     enum symbol_interned.  */
  unsigned interned : 2;

  /* The symbol's name, as a Lisp string.

     The name "xname" is used to intentionally break code referring to
     the old field "name" of type pointer to struct Lisp_String.  */
  Lisp_Object xname;

  /* Value of the symbol or Qunbound if unbound.  If this symbol is a
     defvaralias, `value' contains the symbol for which it is an
     alias.  Use the SYMBOL_VALUE and SET_SYMBOL_VALUE macros to get
     and set a symbol's value, to take defvaralias into account.  */
  Lisp_Object value;

  /* Function value of the symbol or Qunbound if not fboundp.  */
  Lisp_Object function;

  /* The symbol's property list.  */
  Lisp_Object plist;

  /* Next symbol in obarray bucket, if the symbol is interned.  */
  struct Lisp_Symbol *next;
};

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28567671.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

alin.s wrote:
> 
> 
> 
> Stefan Monnier wrote:
>> 
>>> I insert to the struct Lisp_Symbol a field :watched: .
>> 
>> I think a good starting point is to use the existing `constant'
>> field and just add a special WATCHED value to it (it already has 2bits
>> but only uses 1, so you don't even need to make the field any larger).
>> 
>> 
> 
> Here is the symbol structure. Can you point your finger on the unused bit
> ?
> 
> 
> /* In a symbol, the markbit of the plist is used as the gc mark bit */
> 
> struct Lisp_Symbol
> {
>   unsigned gcmarkbit : 1;
> 
>   /* Non-zero means symbol serves as a variable alias.  The symbol
>      holding the real value is found in the value slot.  */
>   unsigned indirect_variable : 1;
> 
>   /* Non-zero means symbol is constant, i.e. changing its value
>      should signal an error.  */
>   unsigned constant : 1;
> 
>   /* Interned state of the symbol.  This is an enumerator from
>      enum symbol_interned.  */
>   unsigned interned : 2;
> 
>   /* The symbol's name, as a Lisp string.
> 
>      The name "xname" is used to intentionally break code referring to
>      the old field "name" of type pointer to struct Lisp_String.  */
>   Lisp_Object xname;
> 
>   /* Value of the symbol or Qunbound if unbound.  If this symbol is a
>      defvaralias, `value' contains the symbol for which it is an
>      alias.  Use the SYMBOL_VALUE and SET_SYMBOL_VALUE macros to get
>      and set a symbol's value, to take defvaralias into account.  */
>   Lisp_Object value;
> 
>   /* Function value of the symbol or Qunbound if not fboundp.  */
>   Lisp_Object function;
> 
>   /* The symbol's property list.  */
>   Lisp_Object plist;
> 
>   /* Next symbol in obarray bucket, if the symbol is interned.  */
>   struct Lisp_Symbol *next;
> };
> 
> 

I see 3 free bits here: 1+1+1+2 =5.

(the bits 6-7-8 are free).

Why do you say that it's impossible to insert a new field :watch: there ? It
takes 2 values, so it will rest 2 free bits.





-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28567697.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

In GDB there are watchpoints to stop when changing the value, but there are
also watchpoints to stop when read/write.

It should be done here the same.
-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28567803.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Suppose that we have the symbol

X = ( 3 . ( 4 . some_cons ) ) 

and

Y = some_cons.

Suppose that I have set the watch bit on X, but not on Y.

In these conditions, modifying Y will not stop into the watchpoint of X.

That means that setting a watchpoint on a symbol X, should be a recursive
operation, id est, setting recursively a :watch: field for all the
cons-cells, symbols, strings, etc, which are present in X.

That means that we need to insert a watch field in all lisp data
strucutures, not only n symbol, etc

Is that algorithm right ?







-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28567880.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Helmut Eller]

* alin.s [2010-05-15 13:56+0200] writes:

> Suppose that we have the symbol
>
> X = ( 3 . ( 4 . some_cons ) ) 
>
> and
>
> Y = some_cons.
>
> Suppose that I have set the watch bit on X, but not on Y.
>
> In these conditions, modifying Y will not stop into the watchpoint of X.
>
> That means that setting a watchpoint on a symbol X, should be a recursive
> operation, id est, setting recursively a :watch: field for all the
> cons-cells, symbols, strings, etc, which are present in X.
>
> That means that we need to insert a watch field in all lisp data
> strucutures, not only n symbol, etc
>
> Is that algorithm right ?

Can't you use the MMU for this?  Protect the page(s) the watched object
is on; in the SIGSEGV handler set the QUIT flag and store some info in a
global place so that the debugger can figure out which object triggered
the watchpoint.

Helmut

Re: Watchpoints for emacs lisp.

[alin.s]

Helmut Eller-2 wrote:
> 
> * alin.s [2010-05-15 13:56+0200] writes:
> 
>> Suppose that we have the symbol
>>
>> X = ( 3 . ( 4 . some_cons ) ) 
>>
>> and
>>
>> Y = some_cons.
>>
>> Suppose that I have set the watch bit on X, but not on Y.
>>
>> In these conditions, modifying Y will not stop into the watchpoint of X.
>>
>> That means that setting a watchpoint on a symbol X, should be a recursive
>> operation, id est, setting recursively a :watch: field for all the
>> cons-cells, symbols, strings, etc, which are present in X.
>>
>> That means that we need to insert a watch field in all lisp data
>> strucutures, not only n symbol, etc
>>
>> Is that algorithm right ?
> 
> Can't you use the MMU for this?  Protect the page(s) the watched object
> is on; in the SIGSEGV handler set the QUIT flag and store some info in a
> global place so that the debugger can figure out which object triggered
> the watchpoint.
> 
> Helmut
> 
> 
> 
> 

Probably it works. But GC would call the handler lots of times, and this
might be inconvenient.

I can set the flag :watch to 1 for that objects, and when the handler is
called, it passed the address of the object that generated the segv. it has
just to check the :watch flag first and decides so whether the debugger is
called.

Depending on the data segment, the handler knows whether a string, cons
cell, symbol , etc was modified.

Emacs is possible to run extremely slow with such a solution.

What the other think about it?



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28568286.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

> In GDB there are watchpoints to stop when changing the value, but there are
> also watchpoints to stop when read/write.

> It should be done here the same.

I don't know about "should".  There are different kinds of watchpoint
you might be interested in, and there are different techniques you can
use to implement a watchpoint feature.  Depending on the technique you
use, that restricts the kind of watchpoints you can support.

Using a field on the `symbol' structure only allows you to catch
modifications via setq/let (and friends).  It's very limited, but has
the advantage of being very simple, cheap, and lightweight to implement.

If you want to be able to watch a random expression (which would be
great, of course), then indeed you'll need something a lot more
intrusive, such as a playing MMU tricks or adding extra checks at
various places.


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
> 
> If you want to be able to watch a random expression (which would be
> great, of course), then indeed you'll need something a lot more
> intrusive, such as a playing MMU tricks or adding extra checks at
> various places.
> 
> 

I do not think thta somewhere in code is changed the value of a symbol,
otherwise than via calling Fset & similar.




-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28574560.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Sun, May 16, 2010 at 3:07 PM, alin.s <alinsoar@voila.fr> wrote:
>
>
>
> Stefan Monnier wrote:
>>
>>
>> If you want to be able to watch a random expression (which would be
>> great, of course), then indeed you'll need something a lot more
>> intrusive, such as a playing MMU tricks or adding extra checks at
>> various places.
>>
>>
>
> I do not think thta somewhere in code is changed the value of a symbol,
> otherwise than via calling Fset & similar.


Local variables? Buffer local variables?

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> 
> Local variables? Buffer local variables?
> 
> 

A watchpoint system must catch all kind of symbols.



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28574758.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Sun, May 16, 2010 at 3:42 PM, alin.s <alinsoar@voila.fr> wrote:
>
>
>
> Lennart Borgman (gmail) wrote:
>>
>>
>> Local variables? Buffer local variables?
>>
>>
>
> A watchpoint system must catch all kind of symbols.


Maybe you are missing the point. Please see Stefans post.

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> 
>>>
>>> Local variables? Buffer local variables?
>>>
>>
>> A watchpoint system must catch all kind of symbols.
> 
> Maybe you are missing the point. Please see Stefans post.
> 
> 

I think I miss it, because I think that I understood Sefan's post.



Alin


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28576885.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

>> If you want to be able to watch a random expression (which would be
>> great, of course), then indeed you'll need something a lot more
>> intrusive, such as a playing MMU tricks or adding extra checks at
>> various places.
> I do not think thta somewhere in code is changed the value of a symbol,
> otherwise than via calling Fset & similar.

aset, puthash, setcar, setcdr, nconc, put-text-property, ... modify
existing objects and can hence affect the values held by symbols without
going though Fset or similar.


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
> 
>> I do not think thta somewhere in code is changed the value of a symbol,
>> otherwise than via calling Fset & similar.
> 
> aset, puthash, setcar, setcdr, nconc, put-text-property, ... modify
> existing objects and can hence affect the values held by symbols without
> going though Fset or similar.
> 
> 

I'll implement mmu . Can I find a documentation/manual to see how alloc.c
works for every kind of Lisp Object ?


Alin

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28577398.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

> I'll implement mmu . Can I find a documentation/manual to see how alloc.c
> works for every kind of Lisp Object ?

There's alloc.c and that's about it.


        Stefan

Re: Watchpoints for emacs lisp.

[Andreas Schwab]

"alin.s" <alinsoar@voila.fr> writes:

> I see 3 free bits here: 1+1+1+2 =5.

There is a lot of padding in struct Lisp_Symbol, you can put 24 bits
into that hole.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

>>> I insert to the struct Lisp_Symbol a field :watched: .
>> I think a good starting point is to use the existing `constant'
>> field and just add a special WATCHED value to it (it already has 2bits
>> but only uses 1, so you don't even need to make the field any larger).
> Here is the symbol structure.

Update your Bzr checkout, this struct has changed since the version you have.


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
>>>> I insert to the struct Lisp_Symbol a field :watched: .
>>> I think a good starting point is to use the existing `constant'
>>> field and just add a special WATCHED value to it (it already has 2bits
>>> but only uses 1, so you don't even need to make the field any larger).
>> Here is the symbol structure.
> 
> Update your Bzr checkout, this struct has changed since the version you
> have.
> 
> 

It is strange, because I checked out before yesterday , using

cvs -d:pserver:anonymous@cvs.gnu...



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28574547.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Chad Brown]

On May 16, 2010, at 6:05 AM, alin.s wrote:
> Stefan Monnier wrote:
>> Update your Bzr checkout...
> It is strange, because I checked out before yesterday , using cvs...

Maybe my reformatting will help clear things up.

*Chad

Re: Watchpoints for emacs lisp.

[alin.s]

Chad Brown-6 wrote:
> 
>> Stefan Monnier wrote:
>>> Update your Bzr checkout...
>> It is strange, because I checked out before yesterday , using cvs...
> 
> Maybe my reformatting will help clear things up.
> 
> 

You mean: cvs revision is no longer maintained !?


Alin



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28576879.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Chad Brown-6 wrote:
> 
> On May 16, 2010, at 6:05 AM, alin.s wrote:
>> Stefan Monnier wrote:
>>> Update your Bzr checkout...
>> It is strange, because I checked out before yesterday , using cvs...
> 
> Maybe my reformatting will help clear things up.
> 
> *Chad
> 
> 
> 

Here is the output of how I tried to check the sources out.

debian:~/Desktop/bzr-2.1.0# ./bzr whoami "Alin Soare <alinsoar@voila.fr>"
bzr: warning: some compiled extensions could not be loaded; see
<https://answers.lau                                                                       
nchpad.net/bzr/+faq/703>
debian:~/Desktop/bzr-2.1.0# ./bzr init-repo --2a emacs/
Shared repository with trees (format: 2a)
Location:
  shared repository: emacs
bzr: warning: some compiled extensions could not be loaded; see
<https://answers.lau                                                                       
nchpad.net/bzr/+faq/703>
debian:~/Desktop/bzr-2.1.0# cd emacs/
debian:~/Desktop/bzr-2.1.0/emacs# bzr checkout URL_TO_UPSTREAM_TRUNK trunk
bash: bzr: command not found
debian:~/Desktop/bzr-2.1.0/emacs# ../bzr checkout URL_TO_UPSTREAM_TRUNK
trunk
bzr: ERROR: Not a branch:
"/root/Desktop/bzr-2.1.0/emacs/URL_TO_UPSTREAM_TRUNK/".
bzr: warning: some compiled extensions could not be loaded; see
<https://answers.lau                                                                       
nchpad.net/bzr/+faq/703>


I do not know how to check out. I followed the instructions from here:

http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs


Alin
-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28577522.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

How can I use bzr/something else to check emacs devel sources out ?


Alin.
-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28577940.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Sun, May 16, 2010 at 11:31 PM, alin.s <alinsoar@voila.fr> wrote:
>
> Here is the output of how I tried to check the sources out.
>
> debian:~/Desktop/bzr-2.1.0# ./bzr whoami "Alin Soare <alinsoar@voila.fr>"
> bzr: warning: some compiled extensions could not be loaded; see
> <https://answers.launchpad.net/bzr/+faq/703>

Read the link.

> debian:~/Desktop/bzr-2.1.0/emacs# bzr checkout URL_TO_UPSTREAM_TRUNK trunk

bzr checkout lp:emacs trunk

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> On Sun, May 16, 2010 at 11:31 PM, alin.s <alinsoar@voila.fr> wrote:
>>
>> Here is the output of how I tried to check the sources out.
>>
>> debian:~/Desktop/bzr-2.1.0# ./bzr whoami "Alin Soare <alinsoar@voila.fr>"
>> bzr: warning: some compiled extensions could not be loaded; see
>> <https://answers.launchpad.net/bzr/+faq/703>
> 
> Read the link.
> 
>> debian:~/Desktop/bzr-2.1.0/emacs# bzr checkout URL_TO_UPSTREAM_TRUNK
>> trunk
> 
> bzr checkout lp:emacs trunk
> 
> 

WAW. How easy it was. Now it is downloading...


Thank you.


Alin


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28578288.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> 
> bzr checkout lp:emacs trunk
> 
> 

I installed bzr (latest version) and executed bzr checkout lp:emacs trunk,
but I got a .pack package.

debian:~/trunk/.bzr/repository/upload# file m2byd3g1f72ci5wa2v5n.pack
m2byd3g1f72ci5wa2v5n.pack: data

The problem is: how can I create a normal repository, like in cvs?

I want to see the sources of emacs, not compressed into an unknown format.
How can I uncompress that file ?

Alin.

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28585093.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Mon, May 17, 2010 at 5:52 PM, alin.s <alinsoar@voila.fr> wrote:
>
>
>
> Lennart Borgman (gmail) wrote:
>>
>>
>> bzr checkout lp:emacs trunk
>>
>>
>
> I installed bzr (latest version) and executed bzr checkout lp:emacs trunk,
> but I got a .pack package.
>
> debian:~/trunk/.bzr/repository/upload# file m2byd3g1f72ci5wa2v5n.pack
> m2byd3g1f72ci5wa2v5n.pack: data
>
> The problem is: how can I create a normal repository, like in cvs?
>
> I want to see the sources of emacs, not compressed into an unknown format.
> How can I uncompress that file ?


Did you do all the steps in the instructions on EmacsWiki?

   bzr whoami "Alin Soare <alinsoar@voila.fr>"
   bzr init-repo --2a emacs/
   cd emacs
   bzr checkout lp:emacs trunk

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> 
> 
> Did you do all the steps in the instructions on EmacsWiki?
> 
>    bzr whoami "Alin Soare <alinsoar@voila.fr>"
>    bzr init-repo --2a emacs/
>    cd emacs
>    bzr checkout lp:emacs trunk
> 
> 
> 

Thanks.

I have just restarted the computer. Your new combination made linux crash.

In the bottom there is the emacs directory , after I pressed the reset
button. 

It did not work. Probbaly it consommed all memory, because the hdd occupied
all processor, and I had to press reset.

I do not know who played with emacs' sources, but the old cvs worked
excellent. With bzr I have been trying for 2 days to check out, and I still
have no idea how it works.



debian:~/emacs# find | xargs ls -al
-rw-r--r-- 1 root root       35 2010-05-17 08:12 ./.bzr/branch-format
-rw-r--r-- 1 root root      141 2010-05-17 08:12 ./.bzr/README
-rw-r--r-- 1 root root       54 2010-05-17 08:12 ./.bzr/repository/format
-rw-r--r-- 1 root root       72 2010-05-17 08:12
./.bzr/repository/pack-names
-rw-r--r-- 1 root root        0 2010-05-17 08:12
./.bzr/repository/shared-storage
-rw-r--r-- 1 root root 17035264 2010-05-17 08:20
./.bzr/repository/upload/v59sw47xsiq8k41jqx39.pack
-rw-r--r-- 1 root root       84 2010-05-17 08:12
./trunk/.bzr/branch/branch.conf
-rw-r--r-- 1 root root       35 2010-05-17 08:12 ./trunk/.bzr/branch-format
-rw-r--r-- 1 root root       39 2010-05-17 08:12 ./trunk/.bzr/branch/format
-rw-r--r-- 1 root root        8 2010-05-17 08:12
./trunk/.bzr/branch/last-revision
-rw-r--r-- 1 root root      102 2010-05-17 08:12
./trunk/.bzr/branch/lock/held/info
-rw-r--r-- 1 root root        0 2010-05-17 08:12 ./trunk/.bzr/branch/tags
-rw-r--r-- 1 root root      141 2010-05-17 08:12 ./trunk/.bzr/README

.:
total 3
drwxr-xr-x  4 root root   96 2010-05-17 08:12 .
drwxr-xr-x 57 root root 3128 2010-05-17 08:34 ..
drwxr-xr-x  4 root root  168 2010-05-17 08:12 .bzr
drwxr-xr-x  3 root root   72 2010-05-17 08:12 trunk

./.bzr:
total 8
drwxr-xr-x 4 root root 168 2010-05-17 08:12 .
drwxr-xr-x 4 root root  96 2010-05-17 08:12 ..
-rw-r--r-- 1 root root  35 2010-05-17 08:12 branch-format
drwxr-xr-x 2 root root  48 2010-05-17 08:12 branch-lock
-rw-r--r-- 1 root root 141 2010-05-17 08:12 README
drwxr-xr-x 7 root root 264 2010-05-17 08:12 repository

./.bzr/branch-lock:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 4 root root 168 2010-05-17 08:12 ..

./.bzr/repository:
total 8
drwxr-xr-x 7 root root 264 2010-05-17 08:12 .
drwxr-xr-x 4 root root 168 2010-05-17 08:12 ..
-rw-r--r-- 1 root root  54 2010-05-17 08:12 format
drwxr-xr-x 2 root root  48 2010-05-17 08:12 indices
drwxr-xr-x 2 root root  48 2010-05-17 08:12 lock
drwxr-xr-x 2 root root  48 2010-05-17 08:12 obsolete_packs
-rw-r--r-- 1 root root  72 2010-05-17 08:12 pack-names
drwxr-xr-x 2 root root  48 2010-05-17 08:12 packs
-rw-r--r-- 1 root root   0 2010-05-17 08:12 shared-storage
drwxr-xr-x 2 root root  96 2010-05-17 08:14 upload

./.bzr/repository/indices:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 7 root root 264 2010-05-17 08:12 ..

./.bzr/repository/lock:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 7 root root 264 2010-05-17 08:12 ..

./.bzr/repository/obsolete_packs:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 7 root root 264 2010-05-17 08:12 ..

./.bzr/repository/packs:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 7 root root 264 2010-05-17 08:12 ..

./.bzr/repository/upload:
total 16652
drwxr-xr-x 2 root root       96 2010-05-17 08:14 .
drwxr-xr-x 7 root root      264 2010-05-17 08:12 ..
-rw-r--r-- 1 root root 17035264 2010-05-17 08:20 v59sw47xsiq8k41jqx39.pack

./trunk:
total 0
drwxr-xr-x 3 root root  72 2010-05-17 08:12 .
drwxr-xr-x 4 root root  96 2010-05-17 08:12 ..
drwxr-xr-x 4 root root 160 2010-05-17 08:12 .bzr

./trunk/.bzr:
total 8
drwxr-xr-x 4 root root 160 2010-05-17 08:12 .
drwxr-xr-x 3 root root  72 2010-05-17 08:12 ..
drwxr-xr-x 3 root root 184 2010-05-17 08:12 branch
-rw-r--r-- 1 root root  35 2010-05-17 08:12 branch-format
drwxr-xr-x 2 root root  48 2010-05-17 08:12 branch-lock
-rw-r--r-- 1 root root 141 2010-05-17 08:12 README

./trunk/.bzr/branch:
total 12
drwxr-xr-x 3 root root 184 2010-05-17 08:12 .
drwxr-xr-x 4 root root 160 2010-05-17 08:12 ..
-rw-r--r-- 1 root root  84 2010-05-17 08:12 branch.conf
-rw-r--r-- 1 root root  39 2010-05-17 08:12 format
-rw-r--r-- 1 root root   8 2010-05-17 08:12 last-revision
drwxr-xr-x 3 root root  72 2010-05-17 08:12 lock
-rw-r--r-- 1 root root   0 2010-05-17 08:12 tags

./trunk/.bzr/branch-lock:
total 0
drwxr-xr-x 2 root root  48 2010-05-17 08:12 .
drwxr-xr-x 4 root root 160 2010-05-17 08:12 ..

./trunk/.bzr/branch/lock:
total 0
drwxr-xr-x 3 root root  72 2010-05-17 08:12 .
drwxr-xr-x 3 root root 184 2010-05-17 08:12 ..
drwxr-xr-x 2 root root  72 2010-05-17 08:12 held

./trunk/.bzr/branch/lock/held:
total 4
drwxr-xr-x 2 root root  72 2010-05-17 08:12 .
drwxr-xr-x 3 root root  72 2010-05-17 08:12 ..
-rw-r--r-- 1 root root 102 2010-05-17 08:12 info
debian:~/emacs#






-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28585789.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Mon, May 17, 2010 at 6:40 PM, alin.s <alinsoar@voila.fr> wrote:
>
>
>
> Lennart Borgman (gmail) wrote:
>>
>>
>>
>> Did you do all the steps in the instructions on EmacsWiki?
>>
>>    bzr whoami "Alin Soare <alinsoar@voila.fr>"
>>    bzr init-repo --2a emacs/
>>    cd emacs
>>    bzr checkout lp:emacs trunk
>>
>>
>>
>
> Thanks.
>
> I have just restarted the computer. Your new combination made linux crash.
>
> In the bottom there is the emacs directory , after I pressed the reset
> button.
>
> It did not work. Probbaly it consommed all memory, because the hdd occupied
> all processor, and I had to press reset.


Bazaar uses a lot of memory when doing a checkout of Emacs. It seems
like it hit a GNU/Linux bug here.


> I do not know who played with emacs' sources, but the old cvs worked
> excellent. With bzr I have been trying for 2 days to check out, and I still
> have no idea how it works.


There are alternatives, but I have never used them. Please see:

   http://www.emacswiki.org/emacs/EmacsFromGit

Re: Watchpoints for emacs lisp.

[alin.s]

Lennart Borgman (gmail) wrote:
> 
> 
> Bazaar uses a lot of memory when doing a checkout of Emacs. It seems
> like it hit a GNU/Linux bug here.
> 

I have only 500K of memo, and a processor Quad, with 4 modues.




> 
>> I do not know who played with emacs' sources, but the old cvs worked
>> excellent. With bzr I have been trying for 2 days to check out, and I
>> still
>> have no idea how it works.
> 
> There are alternatives, but I have never used them. Please see:
> 
>    http://www.emacswiki.org/emacs/EmacsFromGit
> 
> 

Yes, I want some alternatie. I do not want bzr either.



-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28586371.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Git works. It is downloading.

It downloaded 65M, and shown 20%.

That means about 320 M.

I do not understand what happens. How emacs passed from 20M before to 300 M
!?

How can I check out emacs? 

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28587094.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

alin.s wrote:
> 
> 
> Git works. It is downloading.
> 
> 

I forgot to say that it is downloading into a tmp file with PACK header, so
probably will block again my computer after downloading 320M !

bzr was better. It blocked it after only 16 M of download.


Alin

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28587122.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

Thanks all for help.

Git works. Hope you keep it available. Bzr is too obfuscated for me.

I can see the sources of emacs again... Pfff...


Alin
-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28588352.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Eli Zaretskii]

> Date: Mon, 17 May 2010 11:39:11 -0700 (PDT)
> From: "alin.s" <alinsoar@voila.fr>
> Cc: 
> 
> It downloaded 65M, and shown 20%.
> 
> That means about 320 M.
> 
> I do not understand what happens. How emacs passed from 20M before to 300 M
> !?

It didn't.  The 320MB is the entire history of the development trunk,
right from revision 1 to the current 100K+.  Relax.  The first
checkout takes a long time, as the wiki says.

> How can I check out emacs? 

Continue what you are doing now.  It's a one-time effort.  Go for a
coffee if you cannot stand waiting for it to finish.

Re: Watchpoints for emacs lisp.

[Lennart Borgman]

On Mon, May 17, 2010 at 8:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> How can I check out emacs?
>
> Continue what you are doing now.  It's a one-time effort.  Go for a
> coffee if you cannot stand waiting for it to finish.


I think some people would suggest some food and sleep too. It might be
a life saver in this situation. ;-)

Re: Watchpoints for emacs lisp.

[Chad Brown]

On May 17, 2010, at 11:39 AM, alin.s wrote:

> Git works. It is downloading.
> 
> It downloaded 65M, and shown 20%.
> 
> That means about 320 M.
> 
> I do not understand what happens. How emacs passed from 20M before to 300 M
> !?

Either system stores a significant percentage of emacs' history on your local computer, and allow you to access it in myriad ways.  Once you have that history, you'll only need to download the changes (more or less; see the constant stream of troubles caused by the lack of the `smart server' and painful design faults in bazaar).

How much history?  These are the last few lines of `bzr log':

	revno: 1
	committer: Jim Blandy <jimb@redhat.com>
	timestamp: Thu 1985-04-18 00:48:29 +0000
	message:
	  entered into RCS

So, ~25 years, but let's assume some significant gaps.

My working tree of emacs (from bazaar) right now is just over 300M.  My (separate) installed tree is just barely under 250M.  My computer is a few years old, so I could probably only comfortably have several dozen of these before I started to care.   Given that the lisp tree itself is ~55M, I'm not sure how you had a 20M source tree, but the answer seems to be ``the development sources of emacs are now distributed with history included, rather than history stored on a remote server''.  This is sometimes an improvement (for some cases, a dramatic improvement), but it's not without cost.  

*Chad

Re: Watchpoints for emacs lisp.

[Adrian Robert]

Chad Brown <chadpbrown <at> gmail.com> writes:

> How much history?  These are the last few lines of `bzr log':
> 
> 	revno: 1
> 	committer: Jim Blandy <jimb <at> redhat.com>
> 	timestamp: Thu 1985-04-18 00:48:29 +0000
> 	message:
> 	  entered into RCS

Hmm, interesting, I didn't realize Redhat was around in 1985!

(In other words, why is revision of the logs taking place and can it be stopped?)

Re: Watchpoints for emacs lisp.

[Chad Brown]

On May 18, 2010, at 1:22 AM, Adrian Robert wrote:

> Chad Brown <chadpbrown <at> gmail.com> writes:
> 
>> How much history?  These are the last few lines of `bzr log':
>> 
>> 	revno: 1
>> 	committer: Jim Blandy <jimb <at> redhat.com>
>> 	timestamp: Thu 1985-04-18 00:48:29 +0000
>> 	message:
>> 	  entered into RCS
> 
> Hmm, interesting, I didn't realize Redhat was around in 1985!
> 
> (In other words, why is revision of the logs taking place and can it be stopped?)

I wondered that myself, and assumed that it was either a policy 
decision to prefer workable email addresses or an accident of a 
conversion process. 

*Chad

...who seems to have messed up his own multiple-address hygienics, sigh.

Re: Watchpoints for emacs lisp.

[Andreas Schwab]

Chad Brown <yandros@MIT.EDU> writes:

> I wondered that myself, and assumed that it was either a policy 
> decision to prefer workable email addresses or an accident of a 
> conversion process. 

The latter.  Since CVS only stores account names and the conversion
process allows only for a simple mapping from account names to full
addresses the last known address won.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Watchpoints for emacs lisp.

[alin.s]

Please tell me how can I revert the buffers after U modified them and I want
to come back to trunk version.

And how can I update to get the latest patch, that appeared from the last
check out.

I use git.

Thanks,


Alin.


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28657657.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Ken Raeburn]

On May 24, 2010, at 10:36, alin.s wrote:
> Please tell me how can I revert the buffers after U modified them and I want
> to come back to trunk version.

"git reset --hard" may be what you want?  It'll reset the checked-out files to match the repository, discarding your edits.  Or did you just mean M-x revert-buffer to get rid of your unsaved changes?

> And how can I update to get the latest patch, that appeared from the last
> check out.

"git pull", which does a "git fetch" (updates from the remote source) and "git merge" (pulls the changes into your working branch)

Ken

Re: Watchpoints for emacs lisp.

[alin.s]

Ken Raeburn-2 wrote:
> 
>> Please tell me how can I revert the buffers after U modified them and I
>> want
>> to come back to trunk version.
> 
> "git reset --hard" may be what you want?  It'll reset the checked-out
> files to match the repository, discarding your edits.  Or did you just
> mean M-x revert-buffer to get rid of your unsaved changes?
> 
>> And how can I update to get the latest patch, that appeared from the last
>> check out.
> 
> "git pull", which does a "git fetch" (updates from the remote source) and
> "git merge" (pulls the changes into your working branch)
> 
> 


Thanks

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28677826.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

The block of code that selects a new symbol (in make-symbol) protects the
shared resource 'symbol_free_list' and the list of blocks for symbol
allocation (symbol_block) against a concurrent access using the 
MALLOC_BLOCK_INPUT macro. As far as I know, emacs is only on 1 thread of
execution.

In which cases the access to this shared resource is concurrent?





-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28657973.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Jan Djärv]

2010-05-24 17:12, alin.s skrev:
>
>
>
> The block of code that selects a new symbol (in make-symbol) protects the
> shared resource 'symbol_free_list' and the list of blocks for symbol
> allocation (symbol_block) against a concurrent access using the
> MALLOC_BLOCK_INPUT macro. As far as I know, emacs is only on 1 thread of
> execution.
>
> In which cases the access to this shared resource is concurrent?
>

Gtk+ creates threads.

	Jan D.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

> The block of code that selects a new symbol (in make-symbol) protects the
> shared resource 'symbol_free_list' and the list of blocks for symbol
> allocation (symbol_block) against a concurrent access using the 
> MALLOC_BLOCK_INPUT macro. As far as I know, emacs is only on 1 thread of
> execution.

> In which cases the access to this shared resource is concurrent?

If you build without -DSYNC_INPUT, Emacs may call malloc from
asynchronous signal handlers (yes, it's usually considered as a no-no in
Unix programming, which is why we have switched to SYNC_INPUT).

Another case may have to do with the Gtk build which does use several
threads (tho the extra ones are limited to the Gtk UI part and I'm not
sure if they could interact with this).


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
> 
>> In which cases the access to this shared resource is concurrent?
> 
> If you build without -DSYNC_INPUT, Emacs may call malloc from
> asynchronous signal handlers (yes, it's usually considered as a no-no in
> Unix programming, which is why we have switched to SYNC_INPUT).
> 

In which situation it is useful to create new symbols in signal handlers ?

 

> Another case may have to do with the Gtk build which does use several
> threads (tho the extra ones are limited to the Gtk UI part and I'm not
> sure if they could interact with this).
> 

ok, thanks.


Alin.

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28678945.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

>>> In which cases the access to this shared resource is concurrent?
>> If you build without -DSYNC_INPUT, Emacs may call malloc from
>> asynchronous signal handlers (yes, it's usually considered as a no-no in
>> Unix programming, which is why we have switched to SYNC_INPUT).
> In which situation it is useful to create new symbols in signal handlers ?

Without -DSYNC_INPUT we run a whole lot of code within the signal
handlers, so whether that code can create symbols or not, I don't know,
but figuring it out is difficult.  Hence -DSYNC_INPUT.


        Stefan

Re: Watchpoints for emacs lisp.

[alin.s]

Stefan Monnier wrote:
> 
>>>> In which cases the access to this shared resource is concurrent?
>>> If you build without -DSYNC_INPUT, Emacs may call malloc from
>>> asynchronous signal handlers (yes, it's usually considered as a no-no in
>>> Unix programming, which is why we have switched to SYNC_INPUT).
>> In which situation it is useful to create new symbols in signal handlers
>> ?
> 
> Without -DSYNC_INPUT we run a whole lot of code within the signal
> handlers, so whether that code can create symbols or not, I don't know,
> but figuring it out is difficult.  Hence -DSYNC_INPUT.
> 
> 
> 

Thanks.

-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28683346.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

I also like the idea to catch the moment when a watched symbol is freed by
gc.


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28693899.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Andreas Schwab]

"alin.s" <alinsoar@voila.fr> writes:

> I also like the idea to catch the moment when a watched symbol is freed by
> gc.

This is not useful because anything being watched can never be collected
by gc since it still has a reference.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Watchpoints for emacs lisp.

[alin.s]

Andreas Schwab-2 wrote:
> 
> 
>> I also like the idea to catch the moment when a watched symbol is freed
>> by
>> gc.
> 
> This is not useful because anything being watched can never be collected
> by gc since it still has a reference.
> 
> 

I did not think it.


-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p28711395.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[alin.s]

I have a little misunderstanding.

How can I call the debugger from the C code ?

How can I find out whether I should call the edebug or simply the old
debugger (debug) ?


Alin
-- 
View this message in context: http://old.nabble.com/Watchpoints-for-emacs-lisp.-tp28512483p29084789.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Watchpoints for emacs lisp.

[Stefan Monnier]

> I have a little misunderstanding.
> How can I call the debugger from the C code ?
> How can I find out whether I should call the edebug or simply the old
> debugger (debug) ?

C code cannot call Edebug since Edebug only applies to Lisp code.
As for calling `debug' there are various ways to do that, one of them is
to call the function stored in the variable `debugger', i.e.

  val = apply1 (Vdebugger, arg);

but it's usually not needed/desired (most of the time, the better
option is to signal an error, which can then in turn trigger the
debugger depending on debug-on-error and such).


        Stefan

Re: Watchpoints for emacs lisp.

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 28, 2010 at 12:05:23AM +0200, Andreas Schwab wrote:
> "alin.s" <alinsoar@voila.fr> writes:
> 
> > I also like the idea to catch the moment when a watched symbol is freed by
> > gc.
> 
> This is not useful because anything being watched can never be collected
> by gc since it still has a reference.

Doesn't Emacs have weak references? (OK, weak hash tables, but that
might be the mechanism needed here).

Regards
- --  tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFMAJcuBcgs9XrR2kYRAufGAJ0ZbSbHrp2EIpO2O05wSNQi9wlu+wCdEbtY
EJCHvUhE2uHdOb0F3CIv/Xc=
=yjoq
-----END PGP SIGNATURE-----

Re: Watchpoints for emacs lisp.

[Ken Raeburn]

On May 18, 2010, at 04:22, Adrian Robert wrote:
> Chad Brown <chadpbrown <at> gmail.com> writes:
> 
>> How much history?  These are the last few lines of `bzr log':
>> 
>> 	revno: 1
>> 	committer: Jim Blandy <jimb <at> redhat.com>
>> 	timestamp: Thu 1985-04-18 00:48:29 +0000
>> 	message:
>> 	  entered into RCS
> 
> Hmm, interesting, I didn't realize Redhat was around in 1985!
> 
> (In other words, why is revision of the logs taking place and can it be stopped?)

I assume it's probably something like mapping the FSF account "jimb" consistently to the most recent email id he's using in the logs as of the (re-)conversion date, since the CVS logs don't have the email info.  There are ChangeLog files which have email addresses, but since they're not a standard part of every software project, and they're not always updated as part of the same CVS commit (and certainly weren't updated in the same instant with RCS), it wouldn't surprise me if the conversion tool didn't try to use them for figuring out email addresses.  And really, it would be much more of a manual process, since the email address and FSF account name don't necessarily have some obvious and easy-to-program correspondence.

Even if someone did go back and rewrite the old commits with the old email addresses people were using at the time, I don't know about bzr, but git would see it as a completely rewritten history, resulting in new commit ids, etc.  I've wasted enough time dealing with VCS issues with Emacs, and still haven't quite untangled from the bzr switch; personally I'd rather this just not get "fixed".

Ken

Re: Watchpoints for emacs lisp.

[Adrian Robert]

On May 19, 2010, at 7:30 AM, Ken Raeburn wrote:

> On May 18, 2010, at 04:22, Adrian Robert wrote:
>> Chad Brown <chadpbrown <at> gmail.com> writes:
>> 
>>> How much history?  These are the last few lines of `bzr log':
>>> 
>>> 	revno: 1
>>> 	committer: Jim Blandy <jimb <at> redhat.com>
>>> 	timestamp: Thu 1985-04-18 00:48:29 +0000
>>> 	message:
>>> 	  entered into RCS
>> 
>> Hmm, interesting, I didn't realize Redhat was around in 1985!
>> 
>> (In other words, why is revision of the logs taking place and can it be stopped?)
> 
> I assume it's probably something like mapping the FSF account "jimb" consistently to the most recent email id he's using in the logs as of the (re-)conversion date, since the CVS logs don't have the email info.  There are ChangeLog files which have email addresses, but since they're not a standard part of every software project, and they're not always updated as part of the same CVS commit (and certainly weren't updated in the same instant with RCS), it wouldn't surprise me if the conversion tool didn't try to use them for figuring out email addresses.  And really, it would be much more of a manual process, since the email address and FSF account name don't necessarily have some obvious and easy-to-program correspondence.
> 
> Even if someone did go back and rewrite the old commits with the old email addresses people were using at the time, I don't know about bzr, but git would see it as a completely rewritten history, resulting in new commit ids, etc.  I've wasted enough time dealing with VCS issues with Emacs, and still haven't quite untangled from the bzr switch; personally I'd rather this just not get "fixed".

I agree.. I was getting a bit mixed up with ChangeLogs.. it would have been good though difficult to try to use that info instead of 1:1 from CVS account, but not worth huge efforts now.

Thanks for the clarification.

Re: Watchpoints for emacs lisp.

[Andreas Schwab]

"alin.s" <alinsoar@voila.fr> writes:

> Git works. It is downloading.
>
> It downloaded 65M, and shown 20%.
>
> That means about 320 M.

If you want to look just at the latest revision you can do this:

$ mkdir emacs
$ cd emacs
$ git init
Initialized empty Git repository in /home/andreas/emacs/.git/
$ git remote add origin git://repo.or.cz/emacs
$ git fetch --depth=1 origin master
remote: Counting objects: 3172, done.
remote: Compressing objects: 100% (1967/1967), done.
remote: Total 3172 (delta 1226), reused 1979 (delta 1179)
Receiving objects: 100% (3172/3172), 32.21 MiB | 1.93 MiB/s, done.
Resolving deltas: 100% (1226/1226), done.
From git://repo.or.cz/emacs
 * branch            master     -> FETCH_HEAD
$ git update-ref refs/remotes/origin/master FETCH_HEAD
$ git co -t origin/master
Checking out files: 100% (3056/3056), done.
Branch master set up to track remote branch master from origin.
Already on 'master'

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Watchpoints for emacs lisp.

[A. Soare]

> > I insert to the struct Lisp_Symbol a field :watched: .
> 
> So, no support for watching for an element of an array or pair to be changed, or part of a string?

Hm... I thought only to symbols, true. Not to arrays, not to numbers.

Can you use the change of an array if a symbol does not point to it? Probably yes. There exist lambda function (functions without name), but probably one can debug also the change of an array without name.


.....

> > Afterwards, in ALL functions that are able to change the value of a symbol,
> > I insert a checkpoint, which looks like that:
> > 
> > <if the symbol to change has the flag :watched: true, that call the
> > corresponding procedure of the debugger>
> > 
> > Is it ok the algorithm ? In how many obarrays should I look for the given
> > symbol ?
> 
> If you do it this way, I think having a Lisp function take a symbol in which to set the flag, and having a user-callable function which uses (interactive "S") (which asks the user for a symbol name in the main obarray), is probably a good start.  Anything that isn't in the main obarray can be provided directly in lisp by the developer.
> 
> What about changes to the property list, or function value, of a symbol?
> 

Can you figure an algorithm for checking very fast (O (0)) whether a symbol has a given property ?

Yes, surely yes, if property lists would have been implemented with fast search algo, which is not the case of emacs.  


Alin



____________________________________________________

 Les scandales de cannes, les palmes d'or, l'actualité du festival sur voila.fr http://evenementiel.voila.fr/festival-de-cannes2010/

Re: Watchpoints for emacs lisp.

[Ken Raeburn]

On May 11, 2010, at 09:54, A. Soare wrote:
>>> I insert to the struct Lisp_Symbol a field :watched: .
>> 
>> So, no support for watching for an element of an array or pair to be changed, or part of a string?
> 
> Hm... I thought only to symbols, true. Not to arrays, not to numbers.
> 
> Can you use the change of an array if a symbol does not point to it? Probably yes. There exist lambda function (functions without name), but probably one can debug also the change of an array without name.

The 'aset' function can change an element of a vector or string (or certain other objects), in place.  So any existing references to the containing vector/string/whatever will now see the new element.  Similarly, setcar and setcdr can change the values contained within a cell that may be referred to elsewhere, and the change will be visible.  This isn't the case with numbers, as numbers can't act as containers or references for other values.

>> What about changes to the property list, or function value, of a symbol?
>> 
> 
> Can you figure an algorithm for checking very fast (O (0)) whether a symbol has a given property ?

I don't think that matters.  You could have the flag on the symbol indicate that the handler should be called if *any* of the slots are changed (function, value, plist, aliasing, becoming buffer-local, etc).  The property list may be changed by changing the 'plist' field in the C structure, which would be noticed by the above mechanism, or it can be changed by altering elements of the list stored in the 'plist' field.  If you make it possible to watch for changes to a cons cell, though, that could be applied to the (original) property list itself.  (Managing that and figuring out when to stop watching those cells could be tricky, but the fundamentals would be there.)

However, I don't think there's any spare room in a cons cell allocation at the moment.  Doing this efficiently, and ideally without getting too intimate with the garbage collection system, could be difficult... perhaps watching symbols would suffice for a first cut, and cons cells could be worked on later if desired.  (But I'd still suggest you have the watchpoint trigger for changes to *any* field of a symbol, not just the 'value' field.)

Ken

Re: Watchpoints for emacs lisp.

[Stephen J. Turnbull]

A. Soare writes:

 > Can you use the change of an array if a symbol does not point to
 > it?

Anything that can be the value of a symbol can be a component of a
list, vector, or other structure (buffer, frame, etc) without being
the value of any symbol.

Cf. `setf'.