Re: Progress Update

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:
>>>done, the job of the DynHashTable is finished. Then the HashTable needs to
>>>sort the array (it now uses qsort()), and then index it (ie, create a hash
>>>look-up table).
>>
>>>Combined, this is O(n).
>>
>>? qsort is O(n log(n))
>>
>Well, yes, but then qsort() is not the only thing happening. The indexing
>needs to examine the hash value of each entry in the entry array. This is,
>of course, O(n), and thus, the whole thing is, combined O(n).

No ;)

O(n log(n)) > O(n)

So the whole thing is, combined O(n log(n))

>>Well, and the code for importing stuff from pp::internal to pp has to be
>>added etc. But I guess you're right. It's not *that* much, partly because
>>for PFile the code is either only in pp::internal (everything except the
>>API functions) or in global space (the API functions). The picture is
>>different with PSound however.
>>
>I thougth everything was put into ::pp::internal in C++ (including the API).
>I'm not sure what way I like best. Of course, pp::ppFunc() looks a bit
>weird, though.

And it doesn't work. The API functions have to be compiled with C linkage
to be callable from C code, and this means they can not be in any
namespace.

>>>First, I thougth having a header that included all external stuff form
>>>::pp::internal to ::pp was the best way to go. Now, I'm more for simply,
>at
>>>the bottom of each header file, including the external stuff that was
>>>defined in that header.
>>
>>Agreed. Also my preference.
>>
>Then I think that should be part of the, well, coding docs? Well, some docs,
>anyway... :)

Yah...

>>Perceps for the API reference (and internal function references for those
>>wanting to help us - and for ourselves) and DocBook for tutorial / design
>>discussion / background info / ...
>>
>Nice. I'll have a look at DocBook. I think I'll write a little something
>about how to decide wheter or not to sue an allocator, and, if one is used,
                                      ^^^
I didn't know they are *that* evil ;)

>which one is used.

Yup, would be nice.

>>>I don't! I want to view them normally.
>>
>>Ah, ok. The ones I write are always also available in a ton of nice formats
>>on ftpspace and as HTML via the site (not linked yet though - look at
>>/penguinplay/libpplay/doc/ for now)
>>
>Ahh, yes. I was just curious on how to do it, as PPlay docs aren't the only
>thing in .sgml I have trouble viewing. Funny thing is that MS Explorer will
>happily display a .sgml file if I view it form the web. A bit wierd.

Well, .sgml is actually not a single file format - it could contain valid
HTML or linuxdoc-sgml or DocBook or something else. SGML is a language for
defining languages...

>Well, a KEY parameter of this type, and a few changes in MISC, should do the
>trick.
>
>struct Key
>{
>	const char* m_pURL;
>	ppSizeT m_len;
>};
>
>The point is that all that is needed is to change a few lines in MISC, and
>you'r set.
>
>This is extremely slightly ineffecient. If the URL string pointer and the
>length could be stored in a member-struct/class of the URL class. That way,
>a reference can be used as KEY instead, and then only 4 byte is copied,
>instead of 8, as is the case in the implementation mentioned above.

Well, you can also pass a ppf_URLInfo& and an integer, so that the hash can
access the string via UInfo.GetPartStart (int) and its length via
UInfo.GetPartSize (int)

I guess it doesn't matter what is done where - the size of the data to be
passed and the required processing always stay about the same.

>>So here's the new plan:
>>
>>You take the PFile code, make it namespacy, and adapt the Directory stuff
>>for the HashTable. After that compilation should be possible.
>>
>Ok. Can I download the current version of PFile and expect it not to change
>untill I finish the namespace things? (for the things that are not already
>namespaced)

Yes.

>>During that time I do the header update, add the missing DOS-style path
>>support to the URL code and after that if neccessary help you with the
>>other stuff (especially the ppf_PakFile* things are quite some work because
>>the Pak format and the way Paks are written change).
>>
>>Ok?
>>
>Yeah. I think perhaps it would be a good idea to have a preprocessor option
>of either supporting only dos-style paths, unix-style paths, or both.

NO! Then we'd have a situation where game A, which is written for a
dos-style-path using PFile has to be installed on a system with a
unix-style-path using PFile. Chaos.

>We could also implement it so that all paths must be unix-style, and then we
>convert to dos-style strings if on a windows platform, and we need to call
>the operating system with a path.

That's how I planned it. Adding that requires only changes to
ppf_URLInfo::ToPlain () and ppf_URLInfo::ToVirt (). I'll do that after the
namespace adaption.

>>because bool values are internally just perfectly normal ints
>>
>Actually, its only 1 byte.

<checking> Right. Strange - byte processing is AFAIK sometimes slower than
int


	Christian
-- 

Drive A: not responding...Formatting C: instead