Date: Mon, 11 Jan 1999 07:29:04 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Duncan Barclay <dmlb@ragnet.demon.co.uk>, freebsd-hackers@FreeBSD.ORG Subject: Re: FICL and setting BTX variables Message-ID: <369929B0.7ACC2DED@newsguy.com> References: <51744.915970608@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" wrote:
>
> > This is being worked on. Well, it would be being worked on if I had
> > got a single second opinion on how to proceed, but...
>
> Really? You're waiting for this? I thought we'd already just agreed
> on whatever the last round of discussions produced and were waiting to
> move on. :-)
Really. :-) I proposed an unified flag registering macro, like the
one been used to register the builtins, so that such flags can be
allocated numbers instead of passed as strings at compile-time use
of builtins.
I'm not even sure myself if I still want to do this. Presently (as
you know, of course), all builtins are called just passing it's
parameter string, and they do their own parameter processing. If you
want a new builtin, you can simply plug in another C file. My change
would end up in a big switch() for a parameter processing for all
builtins, which would have to be changed for each new builtin
written (unless a sensible "default:" is used). Using numeric
parameters where possible in ficl seems a great improvement imho,
but I don't know if the change required wouldn't offset the gains.
That's why I really want to hear the opinion of at least one more
person.
> > * Right now, all builtins return 1 if no error happened, 0
> > otherwise (btw, Jordan, ANS specifies all bits 1 as the "true" value
> > :). It is my intention to change this behavior. In fact, I have
> > already submitted the patches. If I have it my way, errors will use
> > THROW instead.
>
> I can live with all that - we're not tied to the builtin return values
> being anything specific, they were chosen arbitrarily.
Well, kern/9412, if you want. :-)
>
> > * Right now, you can't set a variable to the name of another
> > variable. For instance, the default value of prompt is "${currdev}".
>
> Looks like Mike just fixed that.
Yup. So he did. (Do I need to mention I do have other PRs open
concerning the loader? kern/9371, misc/9373 (these two go together),
kern/9398 (this one requires making a choice, I realize), and
kern/9406 (well, this one can easily go ages ignored :), just in
case you were waiting for the numbers :).
> > * Right now (yeah, I'm emphasizing it :), EVALUATE doesn't work
> > according to specs. It will silently ignore the count passed, and
> > say, I hope :-), I intend to fix this too. Alas, I haven't submitted
> > this patch yet. Anyway, if you want to create strings to be
>
> Aye! :)
Yeah, this one won't live another night. At least in *my* tree. :-)
--
Daniel C. Sobral (8-DCS)
dcs@newsguy.com
"Heart like a Gabriel, pure and white as ivory,
soul like a lucifer, black and cold as a piece of lead."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?369929B0.7ACC2DED>