Dan - thanks for the suggestions.
My existing code uses one file per variable as this makes sense
for nouns, which are often large, and makes it easy to keep track of them.
Also, my code chooses the file names even though it's usually just
<varname>.DAT, so the user specifies only the directory in which to
file variables; part of the idea here is to hide system-dependent
file-name nonsense from the J user and simplify look-up.
Unfortunately for keeping things simple, it may make
sense to handle non-nouns differently and allow multiple definitions
per file. This has the advantage of maintaining the integrity of
existing script files but introduces complexity for finding definitions,
resolving duplicates, etc., possibly forcing me to a two-tier
lookup.
The more I think about this, the more I'm inclined to stick with
the one file per item method. This forces collision-maintenance
onto the user, where it belongs. Also, a user can zip up a directory
into a single file, if needed.
It's not good from a code maintenance perspective but it's for
a different purpose.
On 1/29/07, Dan Bron <[EMAIL PROTECTED]> wrote:
Devon wrote:
> I plan to add this to my "WS.ijs" module at some point unless someone
> else beats me to it.
I would make a couple of suggestions. WS.ijs would be more useful if
you broke up the new code into several utilities.
The primary utility would be a dyad whose RHA is a filename, and whose
LHA is a list of fully-qualifed J names. The dyad would store the
definitions x in the file named by y .
Of course you'll need a second utility monad, which given a list of
FQJNs, produces their definitions.
On top of that, you'll should have a dyad which, given a locale
specification x and a list of nameclasses y , would returns the
FQJNs of all entities in the specified locales with the specified
nameclasses (or '' for all nameclasses).
Another useful utility would be one which produces the FQJNs of the
entities which have changed since its last invocation (i.e. 4!:5).
That way, one could do "incremental" workspace backups.
The last, probably most useful, utility would be a filter a filter to
determine which names were not defined in scripts.
As you, yourself, pointed out: names defined by a script need not and
should not be stored again (except maybe for emergency backup
purposes). An easy way to determine if a name was defined in immex
would be if _1 -: 4!:4 .
I've coded all this up at
http://www.jsoftware.com/svn/DanBron/trunk/environment/fqn.ijs
Feel free to incorportate these definitions into your WS.ijs. Cherry
pick if you so desire. I commented the script a little bit, but I'm
too lazy to put in useful examples (my normal procedure for
"production" code). So if you have questions/concerns/comments,
please just ask.
Here, briefly, is how one could use FQN stand alone (i.e. independent
of WS.ijs). Create a new script, and put these lines at the top:
require 'fqn.ijs'
NB. A "workspace" in which to store names.
NB. Could easily generate a new JWS file
NB. per session, a-la J's temp scripts.
f =: jpath '~temp\session.jws'
NB. Intialize: store all names not defined by the
NB. system (the standard J library). The ^:
NB. is so that we can reload this script without
NB. re-storing all names.
f saveNames^:(verb ~: nc{.;:'incremental')~ 2 allnames ''
NB. Utility verb: Call it to store all the names changed
since it
NB. it was last called (if your code uses 4!:5 , this will be
NB. incomplete).
incremental =: f saveDelta
incremental '' NB. Start observing name changes.
now, whenever you feel the need to take a "snapshot of your
workspace", type incremental '' .
-Dan
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
Devon McCormick
^me^ at acm.
org is my
preferred e-mail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
