Re: Progress Update

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>Ok, first off, I've coded and fully debugged the hash table part of the
>directory class.

Good.

>Thus, to edit a HashTable, one needs to call ConvertToDynTable(), edit the
>returned DynHashTable, and then call CreateFromDynTable(), passing the
>DynHashTable as its parameter. The DynHashTable can then be deleted.

How costly is the HashTable->DynHashTable conversion?

I'm asking because the current system supports mounting some fs at dir a/
and then mounting another fs at a/b/ (i.e. in the "area" occupied by the
first fs). For that a directory has to be added to the hash of die a/

But I'm not sure anymore if this is really a useful feature....

>I have only implemented the actual Directory class very lightly. The reason
>for this is partly that I'm not entirely sure exactly what the interface
>should be capable of (the same as the old?).

About the same as the old, yes

>Also, on pak-file structuring (talking only format 0 here), I'm having a
>hard time finding out exactly the correct format. This is the fastest and
>easiest way I can think of right now:

Looks good.

>This is easiest done by recursion:
>
>WritePakF0(FILE* pStream)

I didn't see how the Pak writing is done - I assume the hash table calls
some method its entries have to implement? And the directories recursively
trigger the proper writing (first dirs / dir entries recursively, then
file data recursively) ?

>It would be nice if the rest of the PPlay symbols could be changed to the
>new naming and namespace conventions. What's the estimated time frame for
>this?

Unknown. The problem is that there's quite much to do now:

(1) New prefix/namespace convention
(2) New debugging / error message macros (e.g. for API parameter checking)
(3) Improving the headers, including defining the above macros plus some
more
(4) Adding the new URL system to PFile
(5) Adding the new Hash container to PFile
(6) Adding the custom allocators to PFile

(3) requires some more planning, but it's a prerequisite for (2)
(1) and (2) require changes throughout all source files, plus debugging of
    the resulting typos
(1) requires some testing/planning on how to best do the
    export-from-internal-to-pp and export-to-global thing
(4) is almost completed (see below), but has to be combined with the new
    hash stuff & tested
(5) has to be integrated properly with the rest of PFile. Completing (1)
    beforehand makes this easier. An alternative would be to change the
    hash/allocator naming/scoping to the old scheme for testing/integration
(6) well, is this already done (HashTable?) or is the Directory class the
    main user of these allocators? Anyway, use of them is pretty localized,
    so this shouldn't be a too big mess. But it has the same problems with
    (1) as the hash stuff.


Furthermore there are some other things I have to do:
(1) My duties as coordinator of the LGDC
(2) Planning for the library database
(3) Write a good description of it for our homepage
(4) Update the PFile docs (well, I guess I'll wait with that until the
    thing stabilizes)
(5) Update the Coding Standard doc with the changes we discussed
(6) Start the coding guide
(7) Do some preparation for my coming (mid-Oct) physics practical
(8) Do some preparation for my coming (start-Nov) CS test
(9) Do 40h/month of coding for money
(10) live ;)


>How do I read .sgml files?

ASCII editor ;)
SGML looks very similar to HTML (mainly because HTML originally was defined
in SGML)

For converting DocBook (the markup language we use in these .sgml files)
I use sgmltools 2.x (www.sgmltools.org).

BTW - why do you want to read them directly (besides curiosity)?

>Do you want me to implement a more effecient version of the URL processing
>functions? Or will you do that?

I already did it. I also already adapted my code to use it - except for the
DirTree stuff, as it's obsolete anyway. The bad thing with this is that I
couldn't completely compile the things because as soon as the compiler hits
some function accessing the DirTree it aborts because the method prototypes
don't match anymore. I'm uploading my code to ftpspace (same name as
before) now so you can have a look at it. 


Ok, so how do we continue now? I'm not sure, but this looks good IMHO:

(1) convert the PPlay sources to the namespace use
(2) integrate the hash stuff & adapt the PakFile* classes
(3) modify the HashTable thing to use the new URL code
(4) debug. test.

The bad thing here is that during the entire time we can't even compile the
code, let alone run it. At least most of the code (HashTable and the main
URL processing code are more or less exceptions).

As mentioned above we could also leave the namespace conversion for later
and instead change the hash stuff to use the old convention (simple). That
way we have a testable PFile sooner and we have to test less.




Well, now some comments about the code you sent me:

* Why does for example HashTable::IsEmpty () return a ppInt8 instead of a
bool?

* I'm no native english speaker, but I'm sure it's "purpose" instead of
"porpuse" and "such" instead of "suchs" :)

* Many comments lack the short description part ( //: )

* The template types are not documented and I especially was confused
by the role of the MISC one (why the ALL_CAPS btw?).

* Although C++ doesn't require it, methods that may throw std::bad_alloc
should tell the user of that by using a proper exception declaration 
(void MyMethod (...) throw (std::bad_alloc))



	Christian
-- 

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