On Wed, Jan 25, 2006 at 10:24:51PM +, Alberto Sim?es wrote:
> For me, both options are reasonable. Chip's proposal have the advantage
> of caching the info. Using is_dir and is_file to stat everytime, have
> the advantage of not having a specific Stat PMC object.
> Other option, is having one
It is necessary that Parrot's filesystem interface make user-visible the
_event_ of measuring the attributes of a path _or_ an already open
filesystem object (e.g. calling stat() or fstat()). It must also represent
the bundle of measurements returned as some kind of PMC. (handwave handwave)
I
Without -yet- commenting on the File/OS/Filesystem issue, this bit of code
is either substantially wrong or just a convenience wrapper around what's
really going on:
On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:
> $P0 = new .Path("/foo/bar")
[...]
> $P0.is_dir()
> $P0
Nicholas Clark wrote:
Is your implementation going to cope with one OS having several different
types of file systems mounted, that might have different specific behaviours?
I know that HFS+, ufs and ext3 all have various forms of flags/extended
attributes, and in turn I'd assume that a FileSy
On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:
> 2) What it might be.
>
> My first idea is to join both PMCs, and create a FileSystem PMC. The
> main problem is its name. After looking to Python discussion, and
> thinking a little on the PIR syntax, I would call it Path.
> 3)
Hi
After some discussion on #parrot, and after Leo direct me to this link:
http://mail.python.org/pipermail/python-dev/2006-January/060026.html
Follows some discussion on File.pmc.
1) What it is now.
At the moment we have two OS dependent PMCs: OS and File.
OS includes stat, mkdir, remove, li
