From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Peter Stephenson <pws@ibmth.df.unipi.it>,
zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: Associative arrays and memory
Date: Sat, 14 Nov 1998 10:47:19 -0800 [thread overview]
Message-ID: <981114104719.ZM22940@candle.brasslantern.com> (raw)
In-Reply-To: <9811141526.AA19988@ibmth.df.unipi.it>
On Nov 14, 4:26pm, Peter Stephenson wrote:
} Subject: Re: Associative arrays and memory
}
} "Bart Schaefer" wrote:
} > zagzig<17> HISTSIZE=1000
} > zagzig<18> HISTSIZE=0 echo hello
} > hello
} > zagzig<19> echo $HISTSIZE
} > 2
}
} This seems to be OK after restoring the old behaviour, so I haven't
} look further into what had gone wrong.
I found it ... the assignment "pm = tpm;" was mistakenly deleted from
below the code that was replaced by the call to copyparam(). That is,
in save_params() in exec.c, it should look like
tpm->nam = s;
copyparam(tpm, pm);
pm = tpm;
So copyparam() itself is OK.
} > } There are currently no special assoc arrays, of course, and it should
} > } probably be possible to prevent there being any
} >
} > What about the discussion that started all this -- using an associative
} > array to give user access to shell-internal completion data?
}
} Rats, I just looked at zle_params.c and you're right --- they're
} marked special.
Of course, a non-special associative array can contain special parameters.
That was part of the idea of using a parameter hash as the implementation.
And that would be the way to do it, rather than make the associative array
itself special.
} That doesn't mean assoc arrays need to be the same, though. The case
} that needs worrying about is the following:
}
} hash=(?...?) builtin_or_func
}
} where the ?...? represents whatever we pick for whole array
} assignments.
It doesn't matter that a whole array is being assigned to the hash, does
it? Even creating a scalar with the same parameter name would require
that it be saved/restored.
Or are you talking *about* special parameters within the associative array
that need to be saved, and that's why whole-array assignment would matter?
} There's also no problem if the hash is simply used for storing
} information and is not tied to special variables or functions. You
} only need a special mechanism for restoration for something like
} $path, where there's an internal variable that needs setting; simply
} restoring the struct param won't do that.
That is, you need to call the pm->sets functions when restoring specials,
which is what restore_params() does. But my implementation does not call
anything equivalent to restore_params() on the parameter table stored in
the association, so it isn't helping to have save_params() copy it in the
first place.
} If we can agree that use of
} assoc arrays is simply going to be by direct access to the parameter
} we can avoid ever copying it: the above shell pseudocode simply makes
} the supplied $hash available for the duration of builtin_func.
I'm not entirely sure what you mean about "direct access." If we're
going to put stuff like the present $BUFFER into an association, it needs
to be the case that assignment to (say) zle[BUFFER] actually modifies the
line editor state.
So the question is, should it ever be the case that
zle=(? BUFFER "this is the command line" ... ?) builtin_or_func
causes the old command line to be restored following builtin_or_func?
And if we save and restore such a hash by the simple stacking method, is
$zle[BUFFER] going to give the right thing after builtin_or_func?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1998-11-14 18:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-11 6:44 PATCH: 3.1.5 - sample associative array implementation Bart Schaefer
1998-11-11 13:58 ` Peter Stephenson
1998-11-11 14:43 ` Bruce Stephens
1998-11-11 20:00 ` Timothy Writer
1998-11-11 20:52 ` Bart Schaefer
1998-11-12 8:22 ` Timothy Writer
1998-11-12 9:23 ` Bart Schaefer
1998-11-13 0:04 ` Timothy Writer
1998-11-13 1:32 ` Bart Schaefer
1998-11-14 1:55 ` Timothy Writer
1998-11-14 6:41 ` Bart Schaefer
1998-11-15 8:42 ` Timothy Writer
1998-11-15 20:03 ` Bart Schaefer
1998-11-16 19:16 ` Timothy Writer
1998-11-15 20:47 ` PATCH: 3.1.5 + associative arrays under ksh emulation Bart Schaefer
1998-11-11 18:16 ` PATCH: 3.1.5 - sample associative array implementation Bart Schaefer
1998-11-13 16:16 ` Associative arrays and memory Peter Stephenson
1998-11-13 17:57 ` Bart Schaefer
1998-11-14 15:26 ` Peter Stephenson
1998-11-14 18:47 ` Bart Schaefer [this message]
1998-11-15 15:54 ` Peter Stephenson
1998-11-16 9:54 Sven Wischnowsky
1998-11-16 12:43 ` Bart Schaefer
1998-11-16 13:15 Sven Wischnowsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=981114104719.ZM22940@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=pws@ibmth.df.unipi.it \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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 NNTP newsgroup(s).