SV: Progress Update

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

> > files the speed gain from this isn't as little as it may seem.
>
> Note that Unix ran for more than 20 years without trees for directories.
> :-)
>
Yes, but I don't think that should be seen as an advantage.

> I'm not saying that you shouldn't use your HashTable for directories.
> I'm just saying that putting so much effort into something so easily
> fixable later on (I'm assuming good modularity here)
>
There are atleast a couple of issues I couldn't have forseen if I had just
implemented HashTable as a linked list. Its not just as simple as "find this
entry for me". HashTable also knows how to serialize itself, its members,
and its DynHashTable alteration technique surely wouldn't have found its way
into a linked list.

If I had used a looong time to sit down and plan how I was going to do this,
I migth have been able to foresee the problems and design my interface
accordingly, even if I was only fooling around with a linked list. But then
I suspect that this would have taken me longer than implementing the
HashTable in the first place.

> is *not* helping
> PenguinPlay as a project. It isn't the first time that PenguinPlay "dies
> out", maybe this is a reason.
>
No. The reason PenguinPlay died out was that there was alot of talk, but no
action. That is not the current situation: we have alot of talk, but we
*also* have action. That's how it IMHO works best.

> PenguinFile is only the tip of the PenguinPlay iceberg!
>
And we are only two people on it, me doing it exclusively, Christian also
running the overall project, but not doing any other major coding than this
(?) (inside of PenguinPlay).

In other words, it doesn't slow down other parts of PenguinPlay, and I
actually think PenguinFile is well ahead.

> and fix it. Heck, it could prove to be totally sufficient and I'd just
> spare me the whole trouble!
>
We knew that wouldn't be the case.

> The *real* problem is where you have stuff that is inherently badly
> designed and unfixable.
>
Agreed.

> > work fine" is often good, but sometimes "doing it properly" is the right
> > way.
>
> Yes, but I gave you the perennial example of a system that "did it
> properly" and went straight to the garbage dump.
>
It obviously must have lacked something that it didn't do properly. Maybe it
didn't do enough, maybe it was too hard to use, or maybe it just wasn't
marketed as well, I have no clue (really), but it must have been inferior in
some way.

> Unix is mostly fixable, *that* is what took it from the 70's right up to
> now. The old filesystem was too slow, they improved on it without
> changes to the applications, and this is about to happen again (with
> ext3/reiserfs/xfs). Note that every spots where we have problems is
> mostly because of compatibility/encapsulation issues, like going from
> /etc/passwd to /etc/shadow to LDAP authentication for example.
>
And that is my point. It is sometimes very hard to predict exactly what you
interface must be able to do, before you need it to do that as an extension
of your implementation.

> > On all Linux, Windows, Irix, BeOs and Mac machines. At the very
> > least. And for that to archieve it has to be good.
> > And PenguinFile is now only about one week from the "debugging and
> > polishing" phase.
>
> Good, but think about *how* you'll get there. Think about how to make a
> "perfect computer virus", such as Unix and C were.
>
Well, its quite simply that PenguinFile offers alot of benefits (which will
improve with time), almost without any drawbacks. All you have to do is
replace the standrad fopen() with the PFile fopen(), fwrite() with the PFIle
fwrite() and so on. Very simple. Only real alteration is the mount/unmount
process, but that can, in some cases, be handeld by ONE line of code (ok, a
little more perhaps, but not much).

Something so simple gives you a whole range of benefits. If you are creating
the right kind of game, PFile will be a given. In many other cases too. I
think even programs that are not games, but use alot of static data, could
benefit from PFile.

> Life and evolution rates success by one factor: population.
>
> The idea isn't to get a perfect design, it is to get the best possible
> design that will *succeed*. Such are engineering compromises.
>
I doubt alot of people would use PFile if it actually degraded their game's
performance...