[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SV: Miscellaneous stuff
> Well, In Un*x, directories *do* have sizes, partially because directories
> *are* a special kind of file there. Having GetSize () simply return 0 for
> Dirs is fine IMHO, and it makes querying the basic Dir Entry attributes
> (and the size is a basic thing) easier.
When exactly do we query the basic DirEntry attributes?
If its only in a place where we use those attributes to build a ppFILE or
ppfDIR, I think perhaps it would be more appropiate to place that
functionality in DirEntry, so that Directory and File can themsleves build
respectively ppfDIRs and ppFILEs.
In any other case, you're probably right that it is a good thing to have the
On a related note, can we rename that to GetFileSize() or GetDataSize()? Its
just that IMHO its not clear what exactly you get when calling GetSize().
> In ToPlain you assume that the path is always at least 2 chars long, which
> isn't guaranteed ("/" is a valid absolute path). Fixing that.
> Same method (ToPlain):
> /* Right now the parsing is still valid, but later versions have to
> * set is_parsed to false here */
> // FIX: why that? (Bjarke)
> is_parsed marks whether the part_count, part_start etc fields are valid.
> But native paths aren't neccessarily parsed (because they're only given to
> stdio anyway, which doesn't use that info). I'll take care of that.
The thing is, atleast for dossification, converting to plain does not break
the parsing, so when returning to a virtual path, there is no reason to do
the job again.
> In ToVirt:
> /* Error or undefined behavior in this case
> if (fs == ppfFS_plain)
> ppInternalError ("ToVirt () called for plain URL \"%s\"",
> // FIX: Why that? It works fine for dos-style paths.
> Good question. IIRC the original thought was that converting to Virt
> doesn't make sense for plain paths, but that's wrong. I'll remove
> that code.
> >Why doesn't ToVirt() work for native paths? I made it work for dos-style
> Its sole purpose is to convert native into PFile paths if neccessary.
> What exactly do you mean?
What I meant was that it DID work, but it had code that prevented it from
doing the job it actually could do.
> >ones. Unix-style ones seem to work ok, except the leading / is
> trimmed away
> >for absolute paths (this very much seemed intentional, so I didn't change
> >the behavior).
> It is intentional. The leading '/' isn't needed because
> is_absolute clearly
> identifies the path as absolute anyway. Keeping the leading '/' would only
> make processing code more complex/unintuitive.
> >I have done the dossification with #ifdef's. If you have a good
> reason for
> >implementing this stuff in seperate methods (ie, why does it matter to a
> No, I guess it's fine now. I expected the changes to be more complex.
So did I. Especially the fact that paths doesn't change length when being
dossificated or virtualized made things a whole lot simpler.
> >The source is coming in priv. mail. I included the project file as you
> >requested. If you want it to have another name, or its location is wrong,
> >please tell me, as that matters (well, you CAN rename it, but the project
> Somehow, yes. You and Peter need to get together to make the project files
> cover the *entire* libpenguinplay, i.e. PenguinFile *and* the generics
> *and* PenguinSound.
That's very easy. MSVC has two ways to divide source files: projects and
workspaces. A project is a collection of included files and instructions on
what to do with those files. A workspace is a collection of projects and
information on their dependencies. Its quite flexible, and very very easy.
What would work best, I guess, is to have a project file for PFile in the
PFile directory, a project file for PSound in the PSound directory and a
workspace file that includes both of these project files in /src.
Oh, and don't worry about maintaining project files. It takes about 20
seconds to create one with all files and settings and all.