SV: SV: SV: SV: Progress Update

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

> I see, and this is a good reason. Personally, I'd have named that class
> something more like StaticHashTable, to reflect its immutability and
> leave the name free for a "normal" hash table. But maybe I'm nitpicking
> here.
>
Well, then I'd end up with names like ConstStaticHashTableIterator. I
decided ConstHashTableIterator was long enough... ;)

Not a bad point. Fixing it would be only a matter of a search-and-replace
operation, though.

> They *cannot* all hash to the same location, since I there is a load
> limit. When an entry has to be added to a full bucket, I grow the hash
> table. Of course, pathogen hash patterns (many keys hashing to similar
> values) could cause excessive growing of the table, but that life with
> hash tables.
>
That gives you more space, but still, if every entry in your table hashes to
the value 1, then I don't see what you can do about that, nomatter how large
your table is: the rest of the positions in the table would just be empty.

> By "worth the effort", I meant in programmer-time. You had to program
> two different hash tables and each time you add stuff to one, you have
> to invoke a bunch of methods and juggle conversions around.
>
> I have *one* hash table implementation and I do ht->set("thekey",
> "thevalue") and that's it.
>
DynHashTable<...> dynTable

table.ConvertToDynTable(dynTable);
dynTable.AddEntry(entry);
table.CreateFromDynTable(dynTable);

Well, is this much worse? Again, the requirements to the HashTable is quite
specific.

> Opening of the files? Heck, in Quadra, there is about *10* such file
> opens over all the course of a typical short game, which includes
> reading the configuration (once), reading the highscore file (once),
> loading the resources (once) and loading the highscoring demos (when you
> click on the button).
>
> Per frame, we have an average of zero file opening. Okay, so how would
> you rate the investment in time now for a game such as Quadra?
>
My response is that it would make no sense for a game that opens only 10
files to utilize any kind of advanced IO library, and the Quadra developers
is therefore clearly not in the group of people we are targetting with this
product.

> > We also plan things like dynamic on-demand disk-caching of slower medias
> > like CD-ROMs or DVDs and transparent memory mapping of files.
> This is still
> > a bit far off right now though.
>
> This is better stuff (the CD-ROM caching).
>
Quadra still wouldn't care... ;)

> > Well, yes, but it wouldn't work if they simply said "Well,
> there's much less
> > effort in doing nothing at all, so lets leave it at that"... ;)
>
> You'd be surprised. :-)
>
Well, there *be* no Unix then...

> For example, do you know what Unix does when an interrupt breaks a
> system call in half and messes the internal state of the system call?
> NOTHING! It just returns with EINTR (interrupted system call)!
> Outrageous, isn't it? :-)
>
> But the good news is that this is fixable. You just have the libc, which
> repeats the system calls until they work. :-)
>
> Did they "do it properly"? Nope! But it's fixable...
>
I'd say it isn't fixable if it takes an external codebase to fix it. That's
called a work-around. Like when you don't do something specific in a program
because you know that it'll die if you do, or only do it in a specific way.

> > > Otherwise, you get Lisp and Lisp Machines, and you
> > > know where they are now (in a garbage dump and museums). Nobody cares
> > > that they were the best machines and environments ever
> conceived. Don't
> > > get pedantic with that last 10% of work, Unix is *FINE*
> without it, see?
> >
>
PenguinFile without effecient look-up is like Unix without a commandline...
There just isn't much of a point.


> > I think people *would* have cared if they could've had the best possible
> > solution, while still having the complete free choice of OS and
> everything
> > else... Hmm? :)
>
> Yep, but they did have at least a much better solution and people didn't
> care. NeXT also had a much better system and look where they are now
> (OpenStep programming is a dream come true by the way, simply
> fantastic).
>
In some way, they must've failed, it seems... :)

> And they didn't choose "free choice of OS" or whatever over that, they
> used proprietary Unixes instead. *Cheap* Unixes. On *cheap* boxes.
>
Well, it doesn't matter what OS they choose, PenguinFile will still work.
And PenguinFile doesn't have any competetion. That's why it was started.
There's a gap there, and if there is only one lib to fill it...

> Look at Windows: Unix exist since far longer and is obviously better,
> and yet Windows is prevailing.
>
Not in all aspects. There are things Windows currenlty does much better than
any Unix. Like aid for the disabled or an easy GUI (for beginners, not for
people who are actually serious).