I'm back

[Christian Reiniger <warewolf@mayn.de>]

Ok, I'm back home, things seem to work fine again, so I can catch up with
all that mail.

Here's some answers to some older mails + some more things:

>Christian Reiniger writes:
> > Ok, the 2 (two!) responses I got up to now regardibg this topic have been
> > relatively positive on the "distro + own code" model, so I'll detail a bit
> > more on that:
> >
>OK, sorry I took _so_ long to reply to this thread, I was just in one
>of my afraid-of-email phases.  That and I didn't disagree wit the
>way things were going on it.  I didn't _like_ it, but I didn't
>dissagree.
>
>Basically I have to say (reluctantly) yes I agree with this.  Further

_WHOMP_
(sound of the stone falling from my heart)

Puh, great. I feared your answer a little.

>it should be
>        distro THEN own code.
>(also road-test with some demos before our own code).

Yes.
I saw that propably the only thing in the "at least useful" category I
did *not* take with me is the new homepage draft, but I'll  more work on
it the next days (especially make it suit the new PPlay "structure"). I
think I can also detail the new goals etc a bit (things to do, how to do it
etcetc). After that real work can start (from my side at least).

> >     a setting. Adrian, what do you think?
>Well, no one has to listen to what we say, do they:)

Right ;)

> > PS: GCC 2.95 is out! Hoooray!
>Agreeeeeed.  Now I have to be bothered downloading it.

*grin* Uni machines with CD writers are a nice thing ;)

Ok, different thing. Two questions I stumbled across:
(1) Will all of our own code go into *one* library or should each part
have its own one? I'd prefer the one lib approach since it makes things
easier  for the user (just one -l switch) and it also makes
dependencies between PPlay parts less problematic. I'm also playing
with the idea of moving the build system to automake (thanks for the
hint, Peter) which also requires some thoughts about how the parts are
related.

(2) When we apply the "distro + own addons" model the "hard"
distinction between PGraphics/PSound/PInput/PNet/everything else is
mostly obsolete. A simple distinction between our existing/planned
subpackages would be better, and they should also be listed as such -
as packages like any other, instead of "project parts". Comments?



Some even other things:

* What about "suspending" use of the parts' mailing list for now,
moving all traffic to the main list? Having one creek is better than
many trickles, especially in a restructuring phase as we are in now.
Having everything on one list should make it harder to miss important
pieces (some people might be only subscribed to one of the lists) and
improve communication between the "parts" (not that it would be bad
now, but each part's progress tends to be a bit too "non-public" IMHO).

* PFile is progressing nicely, PakFile construction is almost completely
implemented (only some comfort code is missing). I however encountered
more problems than I expected (e.g. access permissions for VFS contents were
completely ignored, which is completely infeasible when Pak construction
enters the play). I've also had major problems implementing ppfCopy(), in
part due to problems with the current URL processing code. So I now
implemented just a very minimal version (can only copy one file, and both
the source file name and the destination *filename* have to be specified).
That avoids most of the problems while still allowing us to construct
smaller PakFiles. 
Some statistics: The code size is now 215633 bytes (compared to 146361
bytes before), the diff from the old to the current code is 106367 bytes in
size. The changelog has 24 entries. I'm committing the stuff now.
Side note: I think PFile is not really affected by
the switch to the "Distro++" model. I haven't seen anything with
similar capabilities yet. So I'll just continue with it for now.

* I feel more and more that PFile needs some period of stabilization
as soon as PakFile construction is implemented. No more adding of
features for some time, just intensive testing, bugfixing, smoothing
the implementation, making it more robust, improving the documentation,
perhaps adding the Win32 portability fixes. As mentioned above,
especially the URL processing code needs major work (most likely
a complete rewrite). Bjarke, you said the addition of hashing to the
dir lookups doesn't require big changed to existing code, right? Then
we can perhaps add that as well.

* The coding stds doc is finished (as promised). I don't know if I'll
really get aroud to uploading it already, but it will appear the next days
(I'll send another mail then). I'm committing the SGML source to CVS now
however (/Documentation/CondingStandard.sgml)

* Bjarke, an AVL tree is just a depth-balanced binary search tree,
exactly the thing we use in PFile (ppf_DirTree) ;)
BTW thanks for the benchmarks, It's a good feeling to see that the
thing is *really* that fast. And that without some of the optimizations
in place (e.g. the elimination of unneccessary string copying). Cool :)

* I'm now doing a ppWarning ("Invalid Arguments"); when an API function
in PFile is called with an invalid parameter and ppWarning ("Out of
Memory"); when "new" fails. We should standardize on such messages so
that the user can just grep over the debug output and get meaningful
results. Ideas for more standard messages?

* How well is RTTI supported by Win32 compilers? AFAIK gcc 2.95 doesn't
have problems with it (and some little tests have been positive here),
but if it opens up portability problems we should ban it for now.



        Christian

--

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