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
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to