[Toybox] bc, etc.
Rob Landley
rob at landley.net
Thu Apr 4 11:32:54 PDT 2013
On 04/03/2013 10:38:28 PM, Isaac Dunham wrote:
> Hello,
> After seeing that the "ifconfig" storm was because someone had
> implemented it I read the development log again, and this email is in
> response to a couple things on there.
>
> First, regarding bc:
> https://github.com/libtom/libtomfloat/blob/master/mpf_pow.c
> might be useful if and when you go for arbitrary precision exponents
> (implementing
> "raised to the power of .3176252" ).
> In fact, I wonder if bc is best handled as a essentially a wrapper
> around libtomfloat.
> (FYI, libtom{crypt,math,float} are all essentially public domain.)
I was looking at the copy of libtommath in dropbear.
> But, I'd be inclined to put bc on a back burner, and temporarily keep
> the C
> replacement with a "TODO: drop this and implement bc" note.
That's what I'm doing for now, but a lot of the bc plumbing is the same
as $((1+2)) in the shell, so it does serve multiple purposes.
> Second, on the whole question of cleaning up stuff...
> These are only my own thoughts, and as such far less relevant to your
> project than your own thoughts!
I'm picky. I know I'm picky. I also polish things I have no real reason
to polish.
> If it looks good but you can squeeze a kilobyte or so off, I'd think
> of the
> kilobyte as lower priority (ie, "can improve this later, but it's
> suitable").
> If it's 2-3kb that you can squeeze out, putting it in pending is
> justifible.
> If it's 5-10kb bloated, it may be more useful as a sample
> implementation (ie:
> pending/, but...it might need a full rewrite). But those are rough
> approximations that vary with effort, projects remaining, and size of
> the toy.
It's not actually _size_ I'm going for, per se. It's reducing the
number of lines it takes to perform a task so you can see more of it on
the screen at once. Making it so that it does each thing _once_, so
that there's a single point where this fact lives rather than having an
implicit relationship between two points that could potentially
disagree in some subtle way. Replacing large magic tables with code
that calculates those tables so you can see what it _means_ and where
it came from...
> In other words, by the comments you made about uu{en,de}code and this
> rule,
> I would be putting uuencode in posix/ with minimal changes and
> uudecode might
> take a bit more time.
I have a continuum between commands which aren't started yet and
commands which are done. There are commands that are just "help text
and a vague plan", commands that don't work, commands that sort of
work, commands that are almost done but have issues...
I like being able to put commands in the "done" category. When I go
back to commands that have issues I have to study them for a while to
remember the details of the issues. And if I confuse done commands with
commands that work but have issues, I tend to get bit by it later.
(Sometimes the issues are just 'this works fine but I can factor this
out and re-use it to avoid duplication of code in other commands'...
And then I wind up with two implementations I have to merge.)
> But please don't take that as me recommending a course of action, I'm
> just
> mentioning my thoughts in case you find something useful there. ;)
It's nice to have more perspectives.
Basically what I want to do is figure out how to leverage other
developers who want to help out to do some of this _cleanup_ work. I
should be having more design discussions here, I expect. (I blog about
it, but that's not quite the same thing. Mostly I blog about it because
I can append to a text file all day if necessary. Harder to do that in
email.)
Also, I used to email into previous incarnations of this mailing list,
and then when the list moved to a different server the archive was
lost. That's happened something like 3 times now. Shouldn't happen
again, but I don't have backups of dreamhost's archive because I can't
just grab a big mbox and archive it. (That I know of.) And the horror
that is gmail filters out MY messages from my subscription to the list,
so my local mbox file of it is not a complete record and the
threading's broken. Grrr.
Rob
More information about the Toybox
mailing list