From owner-freebsd-hackers Sun Jan 10 15:32:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA28501 for freebsd-hackers-outgoing; Sun, 10 Jan 1999 15:28:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA28489 for ; Sun, 10 Jan 1999 15:28:48 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id IAA07504; Mon, 11 Jan 1999 08:27:59 +0900 (JST) Message-ID: <369929B0.7ACC2DED@newsguy.com> Date: Mon, 11 Jan 1999 07:29:04 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Duncan Barclay , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL and setting BTX variables References: <51744.915970608@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "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