[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LISP Questions - random, random elements and memory management

From: Kevin Rodgers
Subject: Re: LISP Questions - random, random elements and memory management
Date: Thu, 19 Nov 2009 20:52:17 -0700
User-agent: Thunderbird (Macintosh/20090812)

Jeff Clough wrote:
From: Barry Margolin <address@hidden>
Date: Thu, 19 Nov 2009 08:44:24 -0500

How about putting it in a text file that you load into a temporary buffer when you need it? Then kill the buffer when you're done with it.

Isn't the point to read the words into a list?  So assuming the file looks

("word1" "word2" "word3" ... "wordN")

Then this kills the buffer automatically but keeps the list in memory:

(defvar word-list nil)

  (insert-file-contents-literally "wordlist.el")
  (setq word-list (read (current-buffer))))

And when he's done with the data, this should release it:

(setq word-list nil)

I was thinking about this.  The only real issue is with figuring out a
good lifecycle for the buffer that wouldn't leave the user confused
("Hey, where did this buffer come from?") or result in the file being
loaded/unloaded frequently enough to cause delays.

Instead of freeing the data immediately after using it, use run-at-time
to create a timer to do so some time in the future.  If in the meantime,
it needs to be used, just cancel the timer (a new timer will be created
when this use completes).

You can tell whether you need to reload the list or not by testing
whether word-list is nil.

At this point, after dicking around in the Emacs Lisp manual, I'm
going to keep this as a "load" in my .emacs and assume that anyone who
wants to use the code will either do the same, or set up an autoload
expression if they care about memory usage.  When I know more about
provide/require, I'll probably revisit it.

You could use provide/require/unload-feature, but it would be a level
of indirection (the feature symbol) that just hides what you're really
trying to do.

Kevin Rodgers
Denver, Colorado, USA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]