frames vs. weak hash tables and garbage collection

frames vs. weak hash tables and garbage collection

[Joe Wells]

In a fresh “emacs -Q”, define this function:

  (defun reproduce-bug ()
    (let ((ht (make-hash-table :weakness 'key)))
      (let ((x
	     (make-frame)
	     ;;(get-buffer-create "xyzzy")
	     ))
	(puthash x t ht)
	(delete-frame x)
	;;(kill-buffer x)
	)
      ;; The only reference to the new frame is now the key in the hash
      ;; table.  Because of the weakness, this key should not keep the
      ;; frame alive.
      (garbage-collect)
      ;; The hash table should now be empty.
      (let (l)
	(maphash (lambda (k v) (push (cons k v) l)) ht)
	l)))

Then evaluating (reproduce-bug) will produce a result like this:

  ((#<dead frame emacs@localhost.localdomain 0x88e2278> . t))

It should instead return nil.

If I replace the calls to make-frame and delete-frame by calls to
get-buffer-create and kill-buffer (see commented out lines above),
things work properly.  So this verifies that weak hash tables work at
least for some data types.

There are two possibilities that occur to me:

1. Maybe frames are simply not being garbage collected at all.

2. Maybe the feature of weak keys in hash tables doesn't work for the
   particular case of frames.

I hope this bug report is helpful.

Joe

======================================================================
In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-06-27 on artemis
Windowing system distributor `The X.Org Foundation', version 11.0.70000000
configured using `configure  '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: jbw
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Re: frames vs. weak hash tables and garbage collection

[Eric Hanchrow]

I wish all bug reports were this clear.
-- 
When I just need to kick back after a long day of changing 1.s
into 0.s and 0.s into 1.s, nothing satisfies my primal fish urge
better than a can of Genova [tuna].
        -- Ben Collins-Sussman

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@macs.hw.ac.uk>
() Thu, 30 Aug 2007 02:27:32 +0100

   ;; The only reference to the new frame is now the key in the hash
   ;; table.  Because of the weakness, this key should not keep the
   ;; frame alive.

there's a lot of stuff going on w/ make-frame.

try replacing `(make-frame)' with:

  (x-create-frame-with-faces)

here, i see that `reproduce-bug' returns nil.
what do you see?

thi

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@macs.hw.ac.uk>
() Thu, 30 Aug 2007 02:27:32 +0100

         (garbage-collect)

another thing: one gc pass may not be enough.
i see (reproduce-bug) => nil only at:

(dotimes (i N)
  (garbage-collect))

where (< 1 N).  my emacs is tweaked, however (ymmv).

thi

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Joe Wells <jbw@macs.hw.ac.uk>
> () Thu, 30 Aug 2007 02:27:32 +0100
>
>    ;; The only reference to the new frame is now the key in the hash
>    ;; table.  Because of the weakness, this key should not keep the
>    ;; frame alive.
>
> there's a lot of stuff going on w/ make-frame.
>
> try replacing `(make-frame)' with:
>
>   (x-create-frame-with-faces)
>
> here, i see that `reproduce-bug' returns nil.
> what do you see?

It doesn't help me to even replace make-frame with x-create-frame (the
primitive used by x-create-frame-with-faces).

Are you able to reproduce the bug at all with the code I originally
sent?

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> another thing: one gc pass may not be enough.
> i see (reproduce-bug) => nil only at:
>
> (dotimes (i N)
>   (garbage-collect))
>
> where (< 1 N).  my emacs is tweaked, however (ymmv).

Running garbage-collect 10 times makes no difference for me.

Here is the code I am now using to reproduce the bug:

  (defun reproduce-bug ()
    (let ((ht (make-hash-table :weakness 'key)))
      (let* (after-make-frame-functions
             (x
              (x-create-frame nil)
              ;;(x-create-frame-with-faces)
              ;;(make-frame)
              ;;(get-buffer-create "xyzzy")
              ))
        (puthash x t ht)
        (delete-frame x)
        ;;(kill-buffer x)
        )
      ;; The only reference to the new frame is now the key in the hash
      ;; table.  Because of the weakness, this key should not keep the
      ;; frame alive.
      (loop repeat 10 do (garbage-collect))
      ;; The hash table should now be empty.
      (let (l)
        (maphash (lambda (k v) (push (cons k v) l)) ht)
        l)))

With the above definition, I still get (reproduce-bug) returning
((#<dead frame emacs@localhost.localdomain 0xa2ae808> . t)) instead of
nil.

-- 
Joe

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@macs.hw.ac.uk>
() Fri, 31 Aug 2007 16:15:00 +0100

   With the above definition, I still get (reproduce-bug) returning
   ((#<dead frame emacs@localhost.localdomain 0xa2ae808> . t))
   instead of nil.

crazy idea...  have you tried doing this experiment under ratpoison?
for the record:

 $ ratpoison.working-2007-05-04 --version
 ratpoison 1.4.2-CVS (built May  4 2007 11:37:01)
 $ emacs --version
 GNU Emacs 22.0.97.4
 Copyright (C) 2007 Free Software Foundation, Inc.
 GNU Emacs comes with ABSOLUTELY NO WARRANTY.
 You may redistribute copies of Emacs
 under the terms of the GNU General Public License.
 For more information about these matters, see the file named COPYING.
 $ free
              total       used       free     shared    buffers     cached
 Mem:        516616     419580      97036          0      80808     187968
 -/+ buffers/cache:     150804     365812
 Swap:      1510068          0    1510068


i recall emacs21 had weak-hash problems, but i think those were
fixed in emacs22.  such problems when hacking EDB were one reason
i transitioned away from being an emacs21 holdout (about two years
ago).

thi

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@macs.hw.ac.uk>
() Fri, 31 Aug 2007 16:15:00 +0100

sorry i missed this question.

   Are you able to reproduce the bug at all
   with the code I originally sent?

no.  maybe you have "too much" memory.
did you try 100 (1000?) gc passes?

thi

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@csb.bu.edu>
() 01 Sep 2007 21:03:26 -0400

   > maybe you have "too much" memory.

   What do you mean?

i confesss not looking into emacs' gc innards (yet); the
comment was motivated by fuzzy remembrance of some gc systems
that reclaim "enough" (but not all) to keep going.  if emacs
is like that, then maybe "enough" was reclaimed (but not the
dead frame).  if so, we would need to increase the garbage
creation to get past the threshold.  see following:

   > did you try 100 (1000?) gc passes?

   Yes, I've just now tried with 1000 repetitions [...] makes
   no difference; I still get the bug.

how about doing a lot of consing before or in between?  maybe:

(make-list 100000 (random))
...
(loop repeat 1000 do (progn (make-list 10000 (random))
                            (garbage-collect)))

btw, these are just idle suggestions, please don't take them
too seriously.  i really dislike making them when bug-hunting,
but the ignorantly curious side of me prevails sometimes...

thi

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Joe Wells <jbw@csb.bu.edu>
() 01 Sep 2007 21:10:12 -0400

   As long as I am not completely filling swap, is there any way
   that Emacs could even be aware of how much memory I have on the
   machine?

well, i could continue wallowing in my ignorance, but source is
available, so i looked in src/alloc.c.  you will probably want to
do (setq gc-cons-threshold SOME-LOWER-NUMBER), based on:

| gc-cons-threshold is a variable defined in `src/alloc.c'.
| Its value is 400000
| 
| *Number of bytes of consing between garbage collections.
| Garbage collection can happen automatically once this many bytes have been
| allocated since the last garbage collection.  All data types count.
| 
| Garbage collection happens automatically only when `eval' is called.
| 
| By binding this temporarily to a large number, you can effectively
| prevent garbage collection during a part of the program.
| See also `gc-cons-percentage'.

basically, by tweaking this (and perhaps some other gc-FOO vars),
you can make "enough" satisfiable only when it includes the dead frame.

   Do you mean the database interface stuff?  That brings back
   memories!  I last hacked on that in 1992 (I think it was 1992),
   before Emacs 19 came out.

yes, i revived it in 2004: <http://www.gnuvola.org/software/edb/>.
there were some very twisted things mernst did, but it's ok now.
perhaps one of these days EDB will find itself in a git repo or two.

thi

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Has anyone else been able to reproduce this bug?

Joe

Joe Wells <jbw@macs.hw.ac.uk> writes:

> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> () Joe Wells <jbw@macs.hw.ac.uk>
>> () Thu, 30 Aug 2007 02:27:32 +0100
>>
>>    ;; The only reference to the new frame is now the key in the hash
>>    ;; table.  Because of the weakness, this key should not keep the
>>    ;; frame alive.
>>
>> there's a lot of stuff going on w/ make-frame.
>>
>> try replacing `(make-frame)' with:
>>
>>   (x-create-frame-with-faces)
>>
>> here, i see that `reproduce-bug' returns nil.
>> what do you see?
>
> It doesn't help me to even replace make-frame with x-create-frame (the
> primitive used by x-create-frame-with-faces).
>
> Are you able to reproduce the bug at all with the code I originally
> sent?
>
> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> another thing: one gc pass may not be enough.
>> i see (reproduce-bug) => nil only at:
>>
>> (dotimes (i N)
>>   (garbage-collect))
>>
>> where (< 1 N).  my emacs is tweaked, however (ymmv).
>
> Running garbage-collect 10 times makes no difference for me.
>
> Here is the code I am now using to reproduce the bug:
>
>   (defun reproduce-bug ()
>     (let ((ht (make-hash-table :weakness 'key)))
>       (let* (after-make-frame-functions
>              (x
>               (x-create-frame nil)
>               ;;(x-create-frame-with-faces)
>               ;;(make-frame)
>               ;;(get-buffer-create "xyzzy")
>               ))
>         (puthash x t ht)
>         (delete-frame x)
>         ;;(kill-buffer x)
>         )
>       ;; The only reference to the new frame is now the key in the hash
>       ;; table.  Because of the weakness, this key should not keep the
>       ;; frame alive.
>       (loop repeat 10 do (garbage-collect))
>       ;; The hash table should now be empty.
>       (let (l)
>         (maphash (lambda (k v) (push (cons k v) l)) ht)
>         l)))
>
> With the above definition, I still get (reproduce-bug) returning
> ((#<dead frame emacs@localhost.localdomain 0xa2ae808> . t)) instead of
> nil.
>
> -- 
> Joe

Re: frames vs. weak hash tables and garbage collection

[Glenn Morris]

Joe Wells wrote:

> Has anyone else been able to reproduce this bug?

Yes, but I doubt that I can do anything about it, except note that it
exists.

Re: frames vs. weak hash tables and garbage collection

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Thu, 27 Sep 2007 03:20:41 -0400

   Joe Wells wrote:

   > Has anyone else been able to reproduce this bug?

   Yes, but I doubt that I can do anything about it,
   except note that it exists.

i responded in another thread but perhaps it got dropped.
gist: there is a new variable gc-cons-percentage.  perhaps
frobbing it (and other gc-foo vars) one can re-instate the gc
behavior of previous emacsen.  thus: i don't think this is a bug.

thi

Re: frames vs. weak hash tables and garbage collection

[Stefan Monnier]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

> Can you try  stepping thru the function sweep_weak_table
> when it operates on this hash table, and see what it does
> when it gets to this line

> 	  int key_known_to_survive_p = survives_gc_p (HASH_KEY (h, i));

> and following lines?

Please check the gnu.emacs.bug newsgroup (apparently the gateway to the
mailing-list isn't working right) where I explained the cause of the problem:
basically it's kept alive by the "recent input events" array and the
`values' variable.


        Stefan

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The following message is a courtesy copy of an article
> that has been posted to gnu.emacs.bug as well.
>
>> Can you try  stepping thru the function sweep_weak_table
>> when it operates on this hash table, and see what it does
>> when it gets to this line
>
>> 	  int key_known_to_survive_p = survives_gc_p (HASH_KEY (h, i));
>
>> and following lines?
>
> Please check the gnu.emacs.bug newsgroup (apparently the gateway to the
> mailing-list isn't working right) where I explained the cause of the problem:
> basically it's kept alive by the "recent input events" array and the
> `values' variable.

Your explanation doesn't show up in gnu.emacs.bug either.  Can you
please resend?

By the way, great work in tracking the problem down!

I suppose this means frames are never being garbage collected at all?

-- 
Joe

Re: frames vs. weak hash tables and garbage collection

[Stefan Monnier]

> Your explanation doesn't show up in gnu.emacs.bug either.  Can you
> please resend?

Hmm... not sure what's going on.  There's not much more to send.

> By the way, great work in tracking the problem down!

Thanks.

> I suppose this means frames are never being garbage collected at all?

Not at all: the array of recent input events (as the name implies) only keep
recent events, so after some number of events (300, more precisely) the
reference disappears, making it possible to collect the frame.
The reference from `values' is just due to the fact that you run
`reproduce-bug' from M-: and that its return value contains the frame, so
it's a rather unusual circumstance.

But it seems that `values' is never flushed, so it is a source of leaks.
We should probably fix it (I'd remove it since almost noone even knows that
it exists, but I guess Richard uses it once in a blue moon).


        Stefan

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Your explanation doesn't show up in gnu.emacs.bug either.  Can you
>> please resend?
>
> Hmm... not sure what's going on.  There's not much more to send.
>
>> By the way, great work in tracking the problem down!
>
> Thanks.
>
>> I suppose this means frames are never being garbage collected at all?
>
> Not at all: the array of recent input events (as the name implies) only keep
> recent events, so after some number of events (300, more precisely) the
> reference disappears, making it possible to collect the frame.

Ah!

So this is some sort of “reverse heisenbug” which only shows up when
you look for bugs right away?

> The reference from `values' is just due to the fact that you run
> `reproduce-bug' from M-: and that its return value contains the frame, so
> it's a rather unusual circumstance.

I'm confused.  The frame can only show up in values if it fails to be
garbage collected for another reason.  The frame should already have
been garbage collected before the expression finished evaluation and
hence should never get into values.  So in my case it must be the
recent events array which was the cause of the appearance of a failure
to garbage collect.

(I suppose your point is that if one ever tests garbage collection
behavior with M-: (eval-expression), then there is a high likelihood
of getting confused.  Personally, I usually evaluate expressions with
C-x C-e (eval-last-sexp), which does not add to values.)

Anyway, although I can see that the recent events array would be
enough to cause the problem, I'm not sure it is the only cause.  If I
understand correctly, the array you are talking about is recent_keys
which is cleared by clear-this-command-keys.  However, I still get the
bug when I insert a use of clear-this-command-keys into the bug
reproduction code:

  (defun reproduce-bug ()
    (let ((ht (make-hash-table :weakness 'key)))
      (let ((x
             (make-frame)
             ;;(get-buffer-create "xyzzy")
             ))
        (puthash x t ht)
        (delete-frame x)
        ;;(kill-buffer x)
        )
      ;; Give time for various frame related events to be handled, in
      ;; case this is needed.
      (sit-for 1)
      ;; There may be a reference to the frame in the array of recent
      ;; events, so we clear this array.
      (clear-this-command-keys)
      ;; In theory, the only reference to the new frame is now the key
      ;; in the hash table.  Because of the weakness, this key should
      ;; not keep the frame alive.
      (garbage-collect)
      ;; The hash table should now be empty.
      (let (l)
        (maphash (lambda (k v) (push (cons k v) l)) ht)
        l)))

Is there another array of recent events different from recent_keys?

> But it seems that `values' is never flushed, so it is a source of leaks.
> We should probably fix it (I'd remove it since almost noone even knows that
> it exists, but I guess Richard uses it once in a blue moon).

Perhaps it should have a length limit at least?

-- 
Joe

Re: frames vs. weak hash tables and garbage collection

[Stefan Monnier]

>> The reference from `values' is just due to the fact that you run
>> `reproduce-bug' from M-: and that its return value contains the frame, so
>> it's a rather unusual circumstance.

> I'm confused.  The frame can only show up in values if it fails to be
> garbage collected for another reason.

Right.  In your case the reason is the recent events array.

> Anyway, although I can see that the recent events array would be
> enough to cause the problem, I'm not sure it is the only cause.

Could be, but at least it matched the behavior I saw:
if I hit a key 300 times, set `values' to nil, and call garbage-collect then
the hash-table entry gets deleted (I modified your test case to make the
hash-table global).

>   (defun reproduce-bug ()
>     (let ((ht (make-hash-table :weakness 'key)))
>       (let ((x
>              (make-frame)
>              ;;(get-buffer-create "xyzzy")
>              ))
>         (puthash x t ht)
>         (delete-frame x)
>         ;;(kill-buffer x)
>         )
>       ;; Give time for various frame related events to be handled, in
>       ;; case this is needed.
>       (sit-for 1)
>       ;; There may be a reference to the frame in the array of recent
>       ;; events, so we clear this array.
>       (clear-this-command-keys)
>       ;; In theory, the only reference to the new frame is now the key
>       ;; in the hash table.  Because of the weakness, this key should
>       ;; not keep the frame alive.
>       (garbage-collect)
>       ;; The hash table should now be empty.
>       (let (l)
>         (maphash (lambda (k v) (push (cons k v) l)) ht)
>         l)))

No idea about this one, but it may very well be due to transient effects
such as the fact that the stack is scanned conservatively, so there may
still be a spurious pointer to the frame left over somewhere at the time you
call `garbage-collect'.

Also the sit-for is enough to cause redisplay and execution of process
filters, but I'm not convinced it's enough to cause the frame events to be
added to the "recent events array", so maybe these will appear after the
call to clear-this-command-keys.

>> But it seems that `values' is never flushed, so it is a source of leaks.
>> We should probably fix it (I'd remove it since almost noone even knows that
>> it exists, but I guess Richard uses it once in a blue moon).

> Perhaps it should have a length limit at least?

Yes.  I.e. it should be a ring.


        Stefan

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The reference from `values' is just due to the fact that you run
>>> `reproduce-bug' from M-: and that its return value contains the frame, so
>>> it's a rather unusual circumstance.
>
>> I'm confused.  The frame can only show up in values if it fails to be
>> garbage collected for another reason.
>
> Right.  In your case the reason is the recent events array.
>
>> Anyway, although I can see that the recent events array would be
>> enough to cause the problem, I'm not sure it is the only cause.
>
> Could be, but at least it matched the behavior I saw:
> if I hit a key 300 times, set `values' to nil, and call garbage-collect then
> the hash-table entry gets deleted (I modified your test case to make the
> hash-table global).
>
>>   (defun reproduce-bug ()
>>     [ ... new version of code deleted ... ]
>>     ... )
>
> No idea about this one, but it may very well be due to transient effects
> such as the fact that the stack is scanned conservatively, so there may
> still be a spurious pointer to the frame left over somewhere at the time you
> call `garbage-collect'.

It seems it is not the stack.  See below.

> Also the sit-for is enough to cause redisplay and execution of process
> filters, but I'm not convinced it's enough to cause the frame events to be
> added to the "recent events array", so maybe these will appear after the
> call to clear-this-command-keys.

Okay.  Using a recursive-edit seems to be enough:

  (defun reproduce-bug ()
    (let ((ht (make-hash-table :weakness 'key)))
      (let ((x
             (make-frame)
             ;;(get-buffer-create "xyzzy")
             ))
        (puthash x t ht)
        (delete-frame x)
        ;;(kill-buffer x)
        )
      ;; Give time for various frame related events to be handled, in
      ;; case this is needed.
      (recursive-edit)
      ;; There may be a reference to the frame in the array of recent
      ;; events, so we clear this array.
      (clear-this-command-keys)
      ;; In theory, the only reference to the new frame is now the key
      ;; in the hash table.  Because of the weakness, this key should
      ;; not keep the frame alive.
      (garbage-collect)
      ;; The hash table should now be empty.
      (let (l)
        (maphash (lambda (k v) (push (cons k v) l)) ht)
        l)))

Evaluate (reproduce-bug) and type C-M-c (exit-recursive-edit) in the
recursive edit, and it correctly returns nil.

(By the way, I tried doing

  (setq unread-command-events (append (kbd "C-M-c") nil))

just before the recursive edit, but that wasn't enough.  It needs to
have real user interaction.  I'm curious if there is some purely
programmatic way of simulating the effects of a recursive edit with
only C-M-c typed in it, because this would help in building test
cases.)

Conclusion:  There is no bug with garbage collection of deleted
frames, but merely the appearance of a bug, because the recent event
array keeps the frame alive for a while.

Thanks for tracking down the cause of the appearance of a bug!

-- 
Joe

Re: frames vs. weak hash tables and garbage collection

[Richard Stallman]

    But it seems that `values' is never flushed, so it is a source of leaks.
    We should probably fix it (I'd remove it since almost noone even knows that
    it exists, but I guess Richard uses it once in a blue moon).

I don't use it myself.  I put it in because a history of values
is a useful thing for any read-eval-print loop.  We could delete it,
but it might be better to do more to inform people about it.
For instance, mention it in the text in the *scratch* buffer.

Then they might indeed find it useful.  Or if they don't,
we could delete it.

I agree with the suggestion to truncate it to a specified maximum
length.  How about 40?

Re: frames vs. weak hash tables and garbage collection

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     But it seems that `values' is never flushed, so it is a source of leaks.
>     We should probably fix it (I'd remove it since almost noone even knows that
>     it exists, but I guess Richard uses it once in a blue moon).
>
> I don't use it myself.  I put it in because a history of values
> is a useful thing for any read-eval-print loop.  We could delete it,
> but it might be better to do more to inform people about it.
> For instance, mention it in the text in the *scratch* buffer.
>
> Then they might indeed find it useful.  Or if they don't,
> we could delete it.
>
> I agree with the suggestion to truncate it to a specified maximum
> length.  How about 40?

Personally, I can't remember using anything more than (car values).
Maybe once I used something older than the most recent addition to the
list.

So it seems to me a length of 3 would probably be plenty.

By the way, the name “values” is not good.  I would suggest
“eval-expression-recent-values”.

-- 
Joe

Re: frames vs. weak hash tables and garbage collection

[Stefan Monnier]

>> But it seems that `values' is never flushed, so it is a source of leaks.
>> We should probably fix it (I'd remove it since almost noone even knows that
>> it exists, but I guess Richard uses it once in a blue moon).
>> 
>> I don't use it myself.  I put it in because a history of values
>> is a useful thing for any read-eval-print loop.  We could delete it,
>> but it might be better to do more to inform people about it.
>> For instance, mention it in the text in the *scratch* buffer.
>> 
>> Then they might indeed find it useful.  Or if they don't,
>> we could delete it.
>> 
>> I agree with the suggestion to truncate it to a specified maximum
>> length.  How about 40?


> Personally, I can't remember using anything more than (car values).
> Maybe once I used something older than the most recent addition to the
> list.

> So it seems to me a length of 3 would probably be plenty.

> By the way, the name “values” is not good.  I would suggest
> “eval-expression-recent-values”.

ielm implements its own mechanism for it and it calls it "*", "**", and
"***", giving access only to the last 3 values.
I do use these occasionally (contrary to `values' which I've never used).

So I guess 3 is plenty indeed.  In many circumstances where I could use this
kind of feature I prefer using (setq sm-tmp <exp>) and then refer to that
value as `sm-tmp' this way I can reuse this value many times easily
(whereas with `values' I'd have to keep track of the position within the
list etc...).


        Stefan

RE: frames vs. weak hash tables and garbage collection

[Drew Adams]

> ielm implements its own mechanism for it and it calls it "*", "**", and
> "***", giving access only to the last 3 values.
> I do use these occasionally (contrary to `values' which I've never used).
> 
> So I guess 3 is plenty indeed.  In many circumstances where I 
> could use this
> kind of feature I prefer using (setq sm-tmp <exp>) and then refer to that
> value as `sm-tmp' this way I can reuse this value many times easily
> (whereas with `values' I'd have to keep track of the position within the
> list etc...).

Common Lisp has the same thing: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node181.html

Re: frames vs. weak hash tables and garbage collection

[Richard Stallman]

I don't mind replacing `values' with `*', `**' and `***'.

However, the name `eval-expression-recent-values' is too long
for such a convenience feature.