I've just looked at this, and it seems like a waste of time to me, given recls. All it returns is strings, requiring stat()-like calls to acquire the other characteristices of the given entries, throwing away this already-aquired information on Win32. Since the kernel operations are the latency in such searches, masking any slight complexity in recls, I wonder whether we're served by having two ways to do the same thing, one of which is considerably crippled compared to the other?

On Thu, 15 Jul 2004 11:08:28 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> I've just looked at this, and it seems like a waste of time to me, given recls.
> All it returns is strings, requiring stat()-like calls to acquire the other
> characteristices of the given entries, throwing away this already-aquired
> information on Win32.

What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..

> Since the kernel operations are the latency in such
> searches, masking any slight complexity in recls, I wonder whether we're served
> by having two ways to do the same thing, one of which is considerably crippled
> compared to the other?

Is recls in Phobos?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa5n28yk5a2sq9@digitalmars.com...
> On Thu, 15 Jul 2004 11:08:28 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > I've just looked at this, and it seems like a waste of time to me, given
> > recls.
> > All it returns is strings, requiring stat()-like calls to acquire the
> > other
> > characteristices of the given entries, throwing away this already-aquired
> > information on Win32.
>
> What does recls do on *nix? Does it automatically aquire the stat info? or do you call a method/fn to get it, meaning on Win32 it simply returns what it already has and on *nix it gets and returns it.. but then, next time you ask for it, does it get it again as it may be stale or..

All states in recls are at the epoch of the API "touching" the operating system. In other words, when a file is located, all the information that will be represented for it by the API is acquired at that time.

> > Since the kernel operations are the latency in such
> > searches, masking any slight complexity in recls, I wonder whether we're
> > served
> > by having two ways to do the same thing, one of which is considerably
> > crippled
> > compared to the other?
>
> Is recls in Phobos?

It most certainly is, and has been for a long time.

On Thu, 15 Jul 2004 11:44:34 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsa5n28yk5a2sq9@digitalmars.com...
>> On Thu, 15 Jul 2004 11:08:28 +1000, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> > I've just looked at this, and it seems like a waste of time to me, 
>> given
>> > recls.
>> > All it returns is strings, requiring stat()-like calls to acquire the
>> > other
>> > characteristices of the given entries, throwing away this 
>> already-aquired
>> > information on Win32.
>>
>> What does recls do on *nix? Does it automatically aquire the stat info? or
>> do you call a method/fn to get it, meaning on Win32 it simply returns what
>> it already has and on *nix it gets and returns it.. but then, next time
>> you ask for it, does it get it again as it may be stale or..
>
> All states in recls are at the epoch of the API "touching" the operating system.
> In other words, when a file is located, all the information that will be
> represented for it by the API is acquired at that time.

So on *nix when you list a directory you stat all files at the same time?
Is this slower than simply listing the directory contents?
If so, shouldn't this be optional.

What if I do not care that file foo is 10k big, I just want a list of existing files.

>> > Since the kernel operations are the latency in such
>> > searches, masking any slight complexity in recls, I wonder whether 
>> we're
>> > served
>> > by having two ways to do the same thing, one of which is considerably
>> > crippled
>> > compared to the other?
>>
>> Is recls in Phobos?
>
> It most certainly is, and has been for a long time.

Shows what I know.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa5oy9jd5a2sq9@digitalmars.com...
> On Thu, 15 Jul 2004 11:44:34 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa5n28yk5a2sq9@digitalmars.com...
> >> On Thu, 15 Jul 2004 11:08:28 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> >> > I've just looked at this, and it seems like a waste of time to me,
> >> given
> >> > recls.
> >> > All it returns is strings, requiring stat()-like calls to acquire the
> >> > other
> >> > characteristices of the given entries, throwing away this
> >> already-aquired
> >> > information on Win32.
> >>
> >> What does recls do on *nix? Does it automatically aquire the stat info?
> >> or
> >> do you call a method/fn to get it, meaning on Win32 it simply returns
> >> what
> >> it already has and on *nix it gets and returns it.. but then, next time
> >> you ask for it, does it get it again as it may be stale or..
> >
> > All states in recls are at the epoch of the API "touching" the operating
> > system.
> > In other words, when a file is located, all the information that will be
> > represented for it by the API is acquired at that time.
>
> So on *nix when you list a directory you stat all files at the same time?

Yes

> Is this slower than simply listing the directory contents?

It might be, but it's not proved to be a problem as yet.

> If so, shouldn't this be optional.

I guess. There's already an option not to deduce the directory parts collection for each entry. I could add this also, but I really don't think it's necessary. Premature optimisation, and all that .. ;)

> What if I do not care that file foo is 10k big, I just want a list of existing files.

listdir() doesn't help you there, does it? You'll get files and directories. To its credit, it does at least elide the dots directories.

> >> > Since the kernel operations are the latency in such
> >> > searches, masking any slight complexity in recls, I wonder whether
> >> we're
> >> > served
> >> > by having two ways to do the same thing, one of which is considerably
> >> > crippled
> >> > compared to the other?
> >>
> >> Is recls in Phobos?
> >
> > It most certainly is, and has been for a long time.
>
> Shows what I know.

No worries, mate. I only know the libs I've written or use regularly. ;)

Thinking about it, a list of files and sub-directories is just about useless. The minimum you'd want to do is differentiate between the two, which means a stat() call. Since this has to be done, better to keep hold of that information, as recls does.

Make sense?


"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd4pf4$1blv$1@digitaldaemon.com...
>
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa5oy9jd5a2sq9@digitalmars.com...
> > On Thu, 15 Jul 2004 11:44:34 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsa5n28yk5a2sq9@digitalmars.com...
> > >> On Thu, 15 Jul 2004 11:08:28 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > >> > I've just looked at this, and it seems like a waste of time to me,
> > >> given
> > >> > recls.
> > >> > All it returns is strings, requiring stat()-like calls to acquire
the
> > >> > other
> > >> > characteristices of the given entries, throwing away this
> > >> already-aquired
> > >> > information on Win32.
> > >>
> > >> What does recls do on *nix? Does it automatically aquire the stat
info?
> > >> or
> > >> do you call a method/fn to get it, meaning on Win32 it simply returns
> > >> what
> > >> it already has and on *nix it gets and returns it.. but then, next
time
> > >> you ask for it, does it get it again as it may be stale or..
> > >
> > > All states in recls are at the epoch of the API "touching" the
operating
> > > system.
> > > In other words, when a file is located, all the information that will
be
> > > represented for it by the API is acquired at that time.
> >
> > So on *nix when you list a directory you stat all files at the same
time?
>
> Yes
>
> > Is this slower than simply listing the directory contents?
>
> It might be, but it's not proved to be a problem as yet.
>
> > If so, shouldn't this be optional.
>
> I guess. There's already an option not to deduce the directory parts colle
ction
> for each entry. I could add this also, but I really don't think it's
necessary.
> Premature optimisation, and all that .. ;)
>
> > What if I do not care that file foo is 10k big, I just want a list of existing files.
>
> listdir() doesn't help you there, does it? You'll get files and
directories. To
> its credit, it does at least elide the dots directories.
>
> > >> > Since the kernel operations are the latency in such
> > >> > searches, masking any slight complexity in recls, I wonder whether
> > >> we're
> > >> > served
> > >> > by having two ways to do the same thing, one of which is
considerably
> > >> > crippled
> > >> > compared to the other?
> > >>
> > >> Is recls in Phobos?
> > >
> > > It most certainly is, and has been for a long time.
> >
> > Shows what I know.
>
> No worries, mate. I only know the libs I've written or use regularly. ;)
>
>
>