• Matthew (7/7) Jul 14 2004 I've just looked at this, and it seems like a waste of time to me, given...
• Regan Heath (10/22) Jul 14 2004 What does recls do on *nix? Does it automatically aquire the stat info? ...
• Matthew (6/25) Jul 14 2004 All states in recls are at the epoch of the API "touching" the operating...
• Regan Heath (11/44) Jul 14 2004 So on *nix when you list a directory you stat all files at the same time...
• Matthew (10/53) Jul 14 2004 Yes
• Matthew Wilson (17/72) Jul 14 2004 Thinking about it, a list of files and sub-directories is just about

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

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?

Regan Heath <regan netwin.co.nz> writes:

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/

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"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.

Regan Heath <regan netwin.co.nz> writes:

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/

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"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. ;)

"Matthew Wilson" <dmd synesis.com.au> writes:

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. ;)