Re: Sv: Sv: PenguinFile

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

(btw - can you please tell your Outlook to use "normal" quoting, i.e. a
single ">" at the beginning of each line?)

[VFS]
><< I guess I'll have to write a detailed description of this for the
docs, but >that will take a bit (The last doc update was a real
rewriting/adding >orgy and I need a little break now ;) >>
>
>I don't mind writing docs... I'm sure how good an idea that is just now,
>as you *very* probably have a better understanding on how PenguinFile
>works... :)

Yesssss, that *could* be ;)

BTW - the code for this VFS hierarchy is only in my local copy yet, which
isn't compileable etc yet - just in case you wonder.

[Pakfile writing]
><< I think I will use derivatives of the existing classes for this -
>ppf_PakFileDir / ppf_PakFileFile versions specialized for being written at
>once. I think that's a relatively clean solution and it shouldn't be
>difficult. I just have to decide on what's the "nicest" way to implement
>it. Ad I have to overcome my laziness ;) >>
>
>I think the functions MapDirToImage(), MapDirStructureToImage() and
>MapFileStructureToImage() (as described in my orevious Email (also on the
>mailing list) would make it somewhat easier to work with these classes. If
>you are not going to call the class something with the word "image" in it,
>you may want to call these functions something different if you plan on
>using them... :)

Hmm, I think I'll use memory mapping for this (as well as Pak directory
reading) - that amounts about to the same (and, as it is directly supported
by the OS it's faster). Can you check if Win32 also supports memory mapping
(IIRC I sent you the description of mmap() with the POSIX stuff)?

Setting some place in memory just makes for nicer code than all those
fputc() & fwrite () calls...

><< << << Not yet. The memory mapping stuff will be however.  >> >> >>
>
><< << Well, I implemented all the POSIX directory handling functions used by
>PenguinFile, and it still doesn't compile. I've noticed that all over
>the code, delete is rutinely called on const pointers. I don't know
>about your compiler, but my compiler does not accept this. What about >> >>
>
><< Why not? There's nothing wrong with it. "const" just means "please don't
>modify that thing" - it does *not* mean that the memory isn't dynamically
>allocated. >>
>
>const does not mean "please don't modify that thing", it means "DON'T
>MODIFY THAT THING!", and a const pointer means "DON'T MODIFY WHATEVER THAT
>THING IS POINTING TO!". If I pass something to a function and the pointer
>parameter is declared as const, I expect that it hasn't changed when the
>function returns. This is exactly what the compiler is expecting too. When
>you do something like this:

Yes, but I only delete[] a const pointer that I myself declared some lines
above - not a pointer that was passed to me.

>const char* pString;
>strcpy(pString, pWhatever);
>DoWhatever(pString)
>delete pString
>
>A compiler shouldn't compile the delete line here: it's not proper C++.
>This would be valid:

I'm still not convinced - but looking at the code I think that this
situation usually doesn't usually come up. IIRC the use of const there was
just a bad hack to avoid a warning. It'll change anyway.

>I have an example from your code where you do this const deletion:
>
>---------------
>
> const char *RelPath = ppf_GenRelativePath (PakPath, Path);
> delete[] Path;
> if (RelPath == 0) return 0;
>
> ppf_Directory *RootDir = ppf_GlobalData.GetDirTree (ppfAM_pakfile);
> if (RootDir == 0)
> {
>  delete[] RelPath;
>  return 0;
> }
>
> ppf_Directory *TheDir = RootDir->SearchDir (RelPath);
> delete[] RelPath;
>
>---------------

That's from ppf_Open.cc, right?

>I'm somewhat surprised you don't know this. Actually, I'm EXTREMELY
>surprised. That along with the fact that your compiler obviously doesn't
>consider this an error indicates to me that there's something weird going
>on here I don't know about...

Perhaps it is intelligent enough to see that it doesn't matter 
*in this case*...

>btw, what is endianess? It isn't even a word in my neither my normal nor
>computer-specific dictionary (ok, perhaps the computer-specific one isn't
>really a dictionary, but anyhow).

Byte order. if you have some integer, say 123456789 (hex 75BCD15),
little-endian machines (like the x86) store it as 15CD5B07 (i.e. least
significant byte first) while big-endian machines (e.g. PPC) store it as
075BCD15 (most significant byte first). That sometimes makes reading binary
data portably a real hassle.

><< << MS VC++ has an *EXCELLENT* text editor. I simply couldn't imagine one
>better. It places 2 project files in you source dir, and a temporary >> >>
>
><< Well, I'm using a better one. Do a search for "FTE", there's also a Win32
>version of it. You might have to do some minor adjustments to the config
>files first, but once you have that it's just plain wonderful :) >>
>
>Does it do things like track your current indentation and automaticly
>create it when you press enter? 

Sure.

>Does it do this with virtual spaces (or
>tabs) (ie, they go away if you don't use them) ?

Yup.

>Does it also track all
>your code and gives you a sidebar where you can get information on all your
>classes and functions, and click on any functions, or method of a class, to
>jump to it's implementation? (if you click a class, it goes to it's
>definition, btw) (EXTREMELY nice feature).

No. Actually I haven't needed that yet....
Update - yes, it *is* supported. I just found out ;)

>I don't believe your editor is better, but perhaps it's equally good, I
>don't know. I'll check it out, though; Perhaps it'll surprise me :)

>Believe me, you use the documentation much more if it's so easily accessable.

I believe you - I use JBuilder at work which also has that feature. I
noticed that this often makes me simply look at the help *before* I really
think about my problem, slowing me down ;)

>Did I mention that clickling any error message instantly brings up the
>window that the code where the line that generated the error is in and
>scrolls to and highlights that specific line of code? What about the fact

Also supported. Also for grep (reqular expression search in files)

>that you can have two seperate projects open at once, viewing them both at
>the same time (no seperation of any kind, except that they are in different
>directories, of course)? Handy when you need to check out some code and

Of course. (well, there's no "project" thing, but you can open as many
files as you want)

>btw, setting breakpoints is as simple as putting the cursor on a line
>and pressing F9. It works that way too even when debugging is going on.

Well, FTE doesn't provide an interface to the debugger - that's what DDD is
for.

><< << btw, why are you testing the return value of strcpy() to make sure
>that it is the same as the destination string? It would seem to me that
>that there is no case in which these would not be the same... >> >>

><< Except when strcpy() fails. In such a case it returns something else.
>It's unlikely, ok, but return values *should* be checked. >>

>Let me give you a quite from my documentation: [on strcpy(), wspcpy() and _mbscpy()]

<checking> Ooops, you're right. I just had that fixed in my mind... Thanks
for pointing it out. Fixed it here.

>had to delete the linux partitions and install linux again. It's working
>now, but it still can't mount the swapdrive... btw, how do you get to the

Did you set up one? 

>consol from Gnome? Right now I just start in the consol and restart when I
>want to go there..

Press ctrl-alt-F1 (or -F2 or ... or -F6) and press ctrl-F7 to switch
back. You can also open a console window anytime (called "terminal" or so).


	Christian
--

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