www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interesting language comparison on Digg

reply "Walter Bright" <newshound digitalmars.com> writes:
http://www.digg.com/programming/Ruby_Python_C_Java_Side_By_Side_Code_Comparison
Jan 27 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Then there is D which combines strengths of C++ and Java, who wants to 
send him an email? :-P

I made a little comment   digg too.

~ Clay

Walter Bright wrote:

 http://www.digg.com/programming/Ruby_Python_C_Java_Side_By_
ide_Code_Comparison
Jan 27 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 Then there is D which combines strengths of C++ and Java,


I thought that D combined the strengths of *C* and Java,
while providing a simpler alternative to big brother C++ ?

Or maybe that is just me not knowing enough about C++, and
waiting for GDC to support all fancy D templates and so on.

--anders
Jan 28 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Should soft-boiled eggs be opened on the big or little side? :-P

Anders F Björklund wrote:

 clayasaurus wrote:
 

 Then there is D which combines strengths of C++ and Java,


 
 I thought that D combined the strengths of *C* and Java,
 while providing a simpler alternative to big brother C++ ?
 
 Or maybe that is just me not knowing enough about C++, and
 waiting for GDC to support all fancy D templates and so on.
 
 --anders
Jan 28 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 Then there is D which combines strengths of C++ and Java,


 
 I thought that D combined the strengths of *C* and Java,
 while providing a simpler alternative to big brother C++ ? 


 Should soft-boiled eggs be opened on the big or little side? :-P


That depends on if they were laid by an african or european swallow?

:-)

Mixed metaphors aside, I didn't see D *replacing* C++ any time soon...

On the other hand, it (D) is working great for converting some simple
C and Java hacks. As long as none of the advanced features are needed.

But I guess the difference could be perceived as splitting hairs...
Successor, alternative / Child, sibling. All in the family, right ? :-)


It doesn't really matter. What does matter is addressing D's problems.

--anders
Jan 29 2006
prev sibling parent reply "Matthew" <matthew stlsoft.com> writes:
My 2 cents:

    If D can get rid of all the embarassing easily-criticisable warts, &&
        D can be proven to support template programming in the large (and in 
the real), which may or may not require implicit function template 
instantiation, &&
        D can get a good standard library, &&
        D can get a debugger, IDE, and all the other productivity tools, &&
        D has built-in reg-exp, a la Ruby, &&
        D has a number of convincing show-me projects, &&
        D can be administered by person(s) who've enough time to dedicate to 
each of language+compiler+std-library+application-programmers in equal 
measure,
    Then D wins


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dre4ac$2p6i$1 digitaldaemon.com...

 http://www.digg.com/programming/Ruby_Python_C_Java_Side_By_Side_Code_Comparison
Jan 28 2006
parent reply "Charles" <noone nowhere.com> writes:
         D has built-in reg-exp, a la Ruby, &&


Is this really practical in a compiled language ?  Does the D community have
a desperate need for built-in regexes ?

Can you give me an example why built-in would win over a regex library ?
( genuinely curious ).

Charlie

"Matthew" <matthew stlsoft.com> wrote in message
news:drfjgc$128o$1 digitaldaemon.com...

 My 2 cents:

     If D can get rid of all the embarassing easily-criticisable warts, &&
         D can be proven to support template programming in the large (and


in

 the real), which may or may not require implicit function template
 instantiation, &&
         D can get a good standard library, &&
         D can get a debugger, IDE, and all the other productivity tools,


&&

         D has built-in reg-exp, a la Ruby, &&
         D has a number of convincing show-me projects, &&
         D can be administered by person(s) who've enough time to dedicate


to

 each of language+compiler+std-library+application-programmers in equal
 measure,
     Then D wins


 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:dre4ac$2p6i$1 digitaldaemon.com...




http://www.digg.com/programming/Ruby_Python_C_Java_Side_By_Side_Code_Compari
son





 Jan 28 2006



 next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Charles" <noone nowhere.com> wrote in message 
news:drg2mr$1hrg$1 digitaldaemon.com...

         D has built-in reg-exp, a la Ruby, &&


 Is this really practical in a compiled language ?  Does the D community 
 have
 a desperate need for built-in regexes ?

 Can you give me an example why built-in would win over a regex library ?
 ( genuinely curious ).


Not only that, but D's support for regex's is far superior to C++'s (see 
Eric Anderton's regex template library). I don't see that Ruby has more than 
a trivial advantage here, if that. 



 Jan 28 2006



  parent reply "Matthew" <matthew stlsoft.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:drgk9o$22kr$1 digitaldaemon.com...

 "Charles" <noone nowhere.com> wrote in message 
 news:drg2mr$1hrg$1 digitaldaemon.com...

         D has built-in reg-exp, a la Ruby, &&


 Is this really practical in a compiled language ?  Does the D community 
 have
 a desperate need for built-in regexes ?

 Can you give me an example why built-in would win over a regex library ?
 ( genuinely curious ).


 Not only that, but D's support for regex's is far superior to C++'s (see 
 Eric Anderton's regex template library).


So what? Who ever mentioned C++'s regex, which, fwiw, I rate very poorly. 
No-one in their right mind would do regex in C++ unless they had to. D's 
being better than C++'s is a furphy. (As for how good it is, I have no 
opinion, although I'm led to believe it's good.)


 I don't see that Ruby has more than a trivial advantage here, if that.


One man's trivia ...

My point is, D's casting about like a beached fish looking for 
someone/something to be better than. _If_ it wants to be considered as 
looking like an option for hard-core regex, then it needs to be as usable as 
Perl and Ruby in this respect. If it isn't then forget it. Can't bring a 
knife to a gun-fight - go to a knife fight instead.

If that's not what D wants to be, then what does it want to be? (This is not 
rhetorical, I'm genuinely interested in getting an update on this issue.) 
Whatever that may be, can you give me an update on what current/forthcoming 
features will give it the advantage in that arena?



 Jan 29 2006



 next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Matthew wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:drgk9o$22kr$1 digitaldaemon.com...
 

"Charles" <noone nowhere.com> wrote in message 
news:drg2mr$1hrg$1 digitaldaemon.com...


        D has built-in reg-exp, a la Ruby, &&


Is this really practical in a compiled language ?  Does the D community 
have
a desperate need for built-in regexes ?

Can you give me an example why built-in would win over a regex library ?
( genuinely curious ).


Not only that, but D's support for regex's is far superior to C++'s (see 
Eric Anderton's regex template library).


 
 
 So what? Who ever mentioned C++'s regex, which, fwiw, I rate very poorly. 
 No-one in their right mind would do regex in C++ unless they had to. D's 
 being better than C++'s is a furphy. (As for how good it is, I have no 
 opinion, although I'm led to believe it's good.)
 
 

I don't see that Ruby has more than a trivial advantage here, if that.


 
 
 One man's trivia ...
 
 My point is, D's casting about like a beached fish looking for 
 someone/something to be better than. _If_ it wants to be considered as 
 looking like an option for hard-core regex, then it needs to be as usable as 
 Perl and Ruby in this respect. If it isn't then forget it. Can't bring a 
 knife to a gun-fight - go to a knife fight instead.
 
 If that's not what D wants to be, then what does it want to be? (This is not 
 rhetorical, I'm genuinely interested in getting an update on this issue.) 
 Whatever that may be, can you give me an update on what current/forthcoming 
 features will give it the advantage in that arena?
 
 
 


Sorry for my apparent ignorance, but what are regex'es used for?! Who 
uses them?! Can you give me an example scenario or something like that?



 Jan 29 2006



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Hasan Aljudy wrote:


 Sorry for my apparent ignorance, but what are regex'es used for?! Who 
 uses them?! Can you give me an example scenario or something like that?


http://www.regular-expressions.info/

"You can think of regular expressions as wildcards on steroids."

http://en.wikipedia.org/wiki/Regex

--anders



 Jan 30 2006



prev sibling  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Charles" <noone nowhere.com> wrote in message
news:drg2mr$1hrg$1 digitaldaemon.com...


        D has built-in reg-exp, a la Ruby, &&


Is this really practical in a compiled language ?  Does the D community
have
a desperate need for built-in regexes ?

Can you give me an example why built-in would win over a regex library








?

( genuinely curious ).


Not only that, but D's support for regex's is far superior to C++'s (see
Eric Anderton's regex template library).



 So what? Who ever mentioned C++'s regex, which, fwiw, I rate very




poorly.

 No-one in their right mind would do regex in C++ unless they had to. D's
 being better than C++'s is a furphy. (As for how good it is, I have no
 opinion, although I'm led to believe it's good.)



I don't see that Ruby has more than a trivial advantage here, if that.



 One man's trivia ...

 My point is, D's casting about like a beached fish looking for
 someone/something to be better than. _If_ it wants to be considered as
 looking like an option for hard-core regex, then it needs to be as




usable as

 Perl and Ruby in this respect. If it isn't then forget it. Can't bring a
 knife to a gun-fight - go to a knife fight instead.

 If that's not what D wants to be, then what does it want to be? (This is




not

 rhetorical, I'm genuinely interested in getting an update on this




issue.)

 Whatever that may be, can you give me an update on what




current/forthcoming

 features will give it the advantage in that arena?


 Sorry for my apparent ignorance, but what are regex'es used for?! Who
 uses them?! Can you give me an example scenario or something like that?


Don't apologise! Ignorance is just a gap in your brain waiting to be filled.
;-)

Regular Expressions are a very powerful syntax for expressing search
strings, and reg ex libraries define mechanisms for applying that syntax and
retrieving results. Here are some sample expressions from some of my
scripts:




This matches "line" against a format whereby the begins (^ anchors the

string equal to the "projectName" variable, followed by "/", followed by the
string equal to the "projectName", followed by ".h>". In other words it


include "stlsoft/stlsoft.h""

        elsif line =~ /(^.*?Updated\:\W+)(.*)/
            new_lines << $1 + currentDate + "\n"

This matches any line containing the word "Updated:" followed by one or more
whitespace token, and returns two variables (in Ruby and Perl these are
returned in the implicit variables $1 and $2) containing all the text up to
and including the matched tokens, and everything afterwards. This is used to
form a new line with the current date, which is then inserted into the
new_lines array.

Those are pretty rudimentary reg-exps, but that's about as far as I go.
There's a lot more to learn, but I find this "level" affords one incredible
productivity.

For example, using regexp and recls/Ruby, I can effect wholesale changes to
the thousands of source files in my libraries with reasonably simple
scripts. Examples including updating date/version, changing licence info,
changing layout, fixing common bugs, etc. etc.

HTH



 Jan 30 2006



 next sibling parent reply Don Clugston <dac nospam.com.au>  writes:


Matthew wrote:

"Charles" <noone nowhere.com> wrote in message
news:drg2mr$1hrg$1 digitaldaemon.com...



       D has built-in reg-exp, a la Ruby, &&


Is this really practical in a compiled language ?  Does the D community
have
a desperate need for built-in regexes ?

Can you give me an example why built-in would win over a regex library








 
 ?
 

( genuinely curious ).


Not only that, but D's support for regex's is far superior to C++'s (see
Eric Anderton's regex template library).



So what? Who ever mentioned C++'s regex, which, fwiw, I rate very




 
 poorly.
 

No-one in their right mind would do regex in C++ unless they had to. D's
being better than C++'s is a furphy. (As for how good it is, I have no
opinion, although I'm led to believe it's good.)




I don't see that Ruby has more than a trivial advantage here, if that.



One man's trivia ...

My point is, D's casting about like a beached fish looking for
someone/something to be better than. _If_ it wants to be considered as
looking like an option for hard-core regex, then it needs to be as




 
 usable as
 

Perl and Ruby in this respect. If it isn't then forget it. Can't bring a
knife to a gun-fight - go to a knife fight instead.

If that's not what D wants to be, then what does it want to be? (This is




 
 not
 

rhetorical, I'm genuinely interested in getting an update on this




 
 issue.)
 

Whatever that may be, can you give me an update on what




 
 current/forthcoming
 

features will give it the advantage in that arena?


Sorry for my apparent ignorance, but what are regex'es used for?! Who
uses them?! Can you give me an example scenario or something like that?


 
 
 Don't apologise! Ignorance is just a gap in your brain waiting to be filled.
 ;-)
 
 Regular Expressions are a very powerful syntax for expressing search
 strings, and reg ex libraries define mechanisms for applying that syntax and
 retrieving results. Here are some sample expressions from some of my
 scripts:
 
 

 
 This matches "line" against a format whereby the begins (^ anchors the

 string equal to the "projectName" variable, followed by "/", followed by the
 string equal to the "projectName", followed by ".h>". In other words it


 include "stlsoft/stlsoft.h""
 
         elsif line =~ /(^.*?Updated\:\W+)(.*)/
             new_lines << $1 + currentDate + "\n"
 
 This matches any line containing the word "Updated:" followed by one or more
 whitespace token, and returns two variables (in Ruby and Perl these are
 returned in the implicit variables $1 and $2) containing all the text up to
 and including the matched tokens, and everything afterwards. This is used to
 form a new line with the current date, which is then inserted into the
 new_lines array.
 
 Those are pretty rudimentary reg-exps, but that's about as far as I go.
 There's a lot more to learn, but I find this "level" affords one incredible
 productivity.


Matthew,

Evidently you find std.regexp from Phobos to be unsatisfactory. Can you 
explain what's wrong with it (and exactly how the Ruby one is better)?
And what's wrong with boost.regex, for that matter.
Eric and I are developing a compile-time regexp parser, and it would 
help to know what the ideal would be. We can certainly get syntax that 
is quite close to the examples you've shown above... but the subtle 
details can be crucial.

eg, would this be acceptable?

char [] projectname;
...
if ( matches!("^#include

}


which is eminently possible right now, or do we need to go further?

if (line.matches!("^#include
}

or even something like:

if (matches!("^#include
}

(this last one isn't currently possible, but I _think_ it could be done 
with a small language change -- would be easier to argue for it, if it 
was believed to be necessary).



 Jan 30 2006



 next sibling parent reply John Reimer <terminal.node gmail.com>  writes:


Don Clugston wrote:


 
 Evidently you find std.regexp from Phobos to be unsatisfactory. Can you 
 explain what's wrong with it (and exactly how the Ruby one is better)?
 And what's wrong with boost.regex, for that matter.
 Eric and I are developing a compile-time regexp parser, and it would 
 help to know what the ideal would be. We can certainly get syntax that 
 is quite close to the examples you've shown above... but the subtle 
 details can be crucial.
 
 eg, would this be acceptable?
 
 char [] projectname;
 ....
 if ( matches!("^#include
 
 }
 

 which is eminently possible right now, or do we need to go further?
 
 if (line.matches!("^#include
 }
 
 or even something like:
 
 if (matches!("^#include
 }
 
 (this last one isn't currently possible, but I _think_ it could be done 
 with a small language change -- would be easier to argue for it, if it 
 was believed to be necessary).
 



My trivial opinion: this looks great, Don.  I don't think everything has 
to be in the language in order for it to compete with scripting 
languages like Ruby and Perl.  The best that can be done for D, at the 
moment, is to complete the powerful and flexibile template system.

Walter has already decided D's fate; there's little to be done to change 
the foundations now; but there's still much that can be done to decorate 
the exterior.

The argument/debate phase for D feature adoption is rapidly grinding to 
a halt.

-JJR



 Jan 30 2006



  parent reply Don Clugston <dac nospam.com.au>  writes:


John Reimer wrote:

 Don Clugston wrote:
 

 Evidently you find std.regexp from Phobos to be unsatisfactory. Can 
 you explain what's wrong with it (and exactly how the Ruby one is 
 better)?
 And what's wrong with boost.regex, for that matter.
 Eric and I are developing a compile-time regexp parser, and it would 
 help to know what the ideal would be. We can certainly get syntax that 
 is quite close to the examples you've shown above... but the subtle 
 details can be crucial.

 eg, would this be acceptable?

 char [] projectname;
 ....
 if ( matches!("^#include

 }


 which is eminently possible right now, or do we need to go further?

 if (line.matches!("^#include
 }

 or even something like:

 if (matches!("^#include
 }

 (this last one isn't currently possible, but I _think_ it could be 
 done with a small language change -- would be easier to argue for it, 
 if it was believed to be necessary).


 
 
 My trivial opinion: this looks great, Don.  I don't think everything has 
 to be in the language in order for it to compete with scripting 
 languages like Ruby and Perl.  The best that can be done for D, at the 
 moment, is to complete the powerful and flexibile template system.


The language change I'm thinking of is the __identifier() keyword, and 
nothing to do with regular expressions.
Essentially identical to the one in recent versions of MSVC, where it is 
used to allow you to have identifier names with the same names as 
keywords. eg
int __identifier("abstract") = 2 ;
creates an integer called abstract -- even though "abstract" is normally 
a reserved word. In C++, it's not very exciting.
But in D, with the existing template system, this would allow all kinds 
of crazy stuff, like extracting variable names from strings as in the 
last example above. Would help with compile-time reflection, too.
I'm trying to come up with some good use cases to justify it, and prove 
that the idea would work (I fear that the case above would require a 
mixin, which would defeat the purpose).


 Walter has already decided D's fate; there's little to be done to change 
 the foundations now; but there's still much that can be done to decorate 
 the exterior.



 
 The argument/debate phase for D feature adoption is rapidly grinding to 
 a halt.
 
 -JJR





 Jan 30 2006



  parent reply John Reimer <terminal.node gmail.com>  writes:


Don Clugston wrote:


 The language change I'm thinking of is the __identifier() keyword, and 
 nothing to do with regular expressions.
 Essentially identical to the one in recent versions of MSVC, where it is 
 used to allow you to have identifier names with the same names as 
 keywords. eg
 int __identifier("abstract") = 2 ;
 creates an integer called abstract -- even though "abstract" is normally 
 a reserved word. In C++, it's not very exciting.
 But in D, with the existing template system, this would allow all kinds 
 of crazy stuff, like extracting variable names from strings as in the 
 last example above. Would help with compile-time reflection, too.
 I'm trying to come up with some good use cases to justify it, and prove 
 that the idea would work (I fear that the case above would require a 
 mixin, which would defeat the purpose).



I'm almost to the point where I would love to see anything added that 
improves compile-time relflection in D.  It's one area that I think 
could really strengthen D's position in multiple aspects.

 From my limited point of view, your suggestion seems reasonable 
(although I dislike any keyword that must be prefixed with __).

Please continue to make these useful suggestions, Don! :)

You're getting your way more than most of us! Must be more of that 
ninjitsu. ;)

-JJR



 Jan 30 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"John Reimer" <terminal.node gmail.com> wrote in message 
news:drlk6u$fq0$1 digitaldaemon.com...

 You're getting your way more than most of us! Must be more of that 
 ninjitsu. ;)


It's because Don and Eric have made some really eye-popping templates that 
are well beyond what can be done with C++ templates. I'll be showing off 
their work at SDWest in March. 



 Jan 30 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:drlk6u$fq0$1 digitaldaemon.com...

 You're getting your way more than most of us! Must be more of that 
 ninjitsu. ;)


 
 It's because Don and Eric have made some really eye-popping templates that 
 are well beyond what can be done with C++ templates. I'll be showing off 
 their work at SDWest in March. 


For what it's worth, here's a link to the session Walter is giving:

https://www.cmpevents.com/SDw6/a.asp?option=G&V=3&id=228826


Sean



 Jan 30 2006



prev sibling  parent  "Matthew" <matthew stlsoft.com>  writes:


 Evidently you find std.regexp from Phobos to be unsatisfactory. Can you 
 explain what's wrong with it (and exactly how the Ruby one is better)?


Not really. It's been an age since I tried to use it. As it was, it was not 
substantially better or worse than a C++ one, which is to say: not very 
appealing.

If it's changed, great. I've heard good things here and there, and I have no 
reason to doubt them.

But my point was that people were discussing whether D might be an 
alternative to Python/Perl/Ruby and that without built-in support it wasn't 
going to qualify. I stand by that.


 And what's wrong with boost.regex, for that matter.


I'm not touching that one.


 Eric and I are developing a compile-time regexp parser, and it would help 
 to know what the ideal would be. We can certainly get syntax that is quite 
 close to the examples you've shown above... but the subtle details can be 
 crucial.

 eg, would this be acceptable?

 char [] projectname;
 ...
 if ( matches!("^#include

 }


 which is eminently possible right now, or do we need to go further?

 if (line.matches!("^#include
 }

 or even something like:

 if (matches!("^#include
 }

 (this last one isn't currently possible, but I _think_ it could be done 
 with a small language change -- would be easier to argue for it, if it was 
 believed to be necessary).


All of those look reasonably nice. Until I get chance and a reason to use 
them, I can't attempt to give any kind of comparative opinion. (But who says 
my opinion's worth having on this point, anyway? I ain't no regex expert. 
<g>)



 Jan 30 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:drkk9b$290u$1 digitaldaemon.com...

 Regular Expressions are a very powerful syntax for expressing search
 strings, and reg ex libraries define mechanisms for applying that syntax 
 and
 retrieving results. Here are some sample expressions from some of my
 scripts:





In D:

    import std.regexp;


        ...



    elsif line =~ /(^.*?Updated\:\W+)(.*)/
           new_lines << $1 + currentDate + "\n"


    new_lines = sub(line,
        r"(^.*?Updated\:\W+)(.*)",
        "$`$&" ~ currentDate ~ "\n"
       );

Note that $` is the string preceding the match, and $& is the matched 
substring. 



 Jan 30 2006



  parent reply "Matthew" <matthew stlsoft.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:drm62v$13rf$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
 news:drkk9b$290u$1 digitaldaemon.com...

 Regular Expressions are a very powerful syntax for expressing search
 strings, and reg ex libraries define mechanisms for applying that syntax 
 and
 retrieving results. Here are some sample expressions from some of my
 scripts:





 In D:

    import std.regexp;


        ...


I think you've erred here. D doesn't support intra-literal code evaluation, 
does it?



 Jan 30 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew stlsoft.com> wrote in message
news:drmhon$1m79$2 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:drm62v$13rf$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:drkk9b$290u$1 digitaldaemon.com...

 Regular Expressions are a very powerful syntax for expressing search
 strings, and reg ex libraries define mechanisms for applying that syntax
 and
 retrieving results. Here are some sample expressions from some of my
 scripts:





 In D:

    import std.regexp;


        ...


 I think you've erred here. D doesn't support intra-literal code
 evaluation, does it?


I see what you mean. It should be:


!= -1)

using string concatenation. Or:





 Jan 30 2006



  parent reply Tom S <h3r3tic remove.mat.uni.torun.pl>  writes:


Walter Bright wrote:

 using string concatenation. Or:
 



I think you meant:

projectName)) != -1)




-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/



 Jan 30 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message 
news:drmma0$1p9i$1 digitaldaemon.com...

 Walter Bright wrote:

 using string concatenation. Or:




 I think you meant:

 != -1)


Oops! 



 Jan 30 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Mon, 30 Jan 2006 20:36:09 -0800, Walter Bright wrote:


 "Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message 
 news:drmma0$1p9i$1 digitaldaemon.com...

 Walter Bright wrote:

 using string concatenation. Or:




 I think you meant:

 != -1)


 
 Oops!


This is why I have a function that does this ...



its found (and poorly documented) in Build's util/str.d

Regular expression comparisons are very useful when processing string
inputs. The Build utility needed a lot of them I found, so I wrote
'IsLike', 'begins', 'ends', 'Tokenize' and 'Expand' as general purpose
functions that meet my needs so far.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
31/01/2006 4:47:03 PM



 Jan 30 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:62turl0f9xkr.1g1pit4wbvmqs.dlg 40tude.net...

 This is why I have a function that does this ...



 its found (and poorly documented) in Build's util/str.d


The whole std.regexp in Phobos is poorly documented as well. 



 Jan 30 2006



prev sibling  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew stlsoft.com> wrote in message 
news:drkd1u$1tnk$2 digitaldaemon.com...

 If that's not what D wants to be, then what does it want to be? (This is 
 not rhetorical, I'm genuinely interested in getting an update on this 
 issue.) Whatever that may be, can you give me an update on what 
 current/forthcoming features will give it the advantage in that arena?


What D offers is improved productivity (as much as 30% faster development) 
over C++ but with equivalent performance to C++.

C++ isn't used because it supports OOP, or templates, etc. It's used because 
it offers performance, performance, performance. D offers that performance, 
but in a much easier to use and more productive package. 



 Jan 30 2006



prev sibling  parent reply "Matthew" <matthew stlsoft.com>  writes:


         D has built-in reg-exp, a la Ruby, &&


 Is this really practical in a compiled language ?


I'm not an expert, but I can see no practical impediment. Obviously there's 
the theoretical issue whereby one likes to avoid gratuitous mixing of 
language and libraries. I am usually a very strong advocate against, but in 
this case would make an exception because of the incredible utility.


  Does the D community have
 a desperate need for built-in regexes ?

 Can you give me an example why built-in would win over a regex library ?
 ( genuinely curious ).


Look, it's like this. I use the 2000 boot of my Windows machine in 
preference to the XP for basically one reason: I can select text from 
command boxes without first having to do Alt-Space E K, which I find 
incredibly tiresome when I've already been incovenienced by having to use 
the damn mouse. The other influencing factor is the fact that XP is a 
steaming heap of omni-crashing shite, but it's really just the usability of 
the command-box. I know it's crazy, but it's the truth.

By the same token, I always reach for Ruby in preference to Python or Perl. 
It's built-in regex means it pantses Python every time, and the fact that I 
can read it and write extensions (recls/Ruby, OpenRJ/Ruby, and other 
proprietary ones) for it (which I've thus far found impossible to do for 
Perl) rules out Perl. I don't care how much more comprehensive Python's 
libraries are. Anytime I find a missing Ruby library, even if Python has it, 
I'll write one or write an extension, just so I can keep using that built-in 
regex and recls/Ruby.

So, if D wants to be considered a viable alternative to Python and Ruby, 
then I believe it needs built-in regex. If it doesn't, then it doesn't. 
Simple as that. Since it seems like D's not yet decided what it wants to be, 
or who it wants to serve (apart from people interested in language design 
and compiler implementation, of course), then the potential of being a 
scripting alternative raises this point. If that's not a viable option, then 
so be it. It can't be everything to everyone. It's just that as such it 
will, just like C/C++/Java/.NET, always be a poor cousin to Ruby and Perl 
for hardcore regex processing.

As I said in another thread the other day, the lack of libraries/track 
record/tools/v1.1 rules out D for things I'd use C/C++/.NET.Java for, so 
it's just not a competitor there. It's not even an issue. (I can't comment 
on when/if that'll change, as I've not been around enough, but I'd be 
interested to hear if/when people think it will ever reach this point.) 
Second, it's not, as yet, suitable as an alternative for scripting for most 
things I, for one, write scripts for.

Unfortunately, at least for me, the things that D _would_ be useful for, 
writing small utilities with short-medium term lifespans, is also not an 
option because Walter's not updated std.recls in Phobos since ~2003/4, and I 
use recls in just about every such utility I write, meaning that they're 
always done in C++ or in Ruby and never in D. I consider this to be a real 
shame, even if, perhaps, that's only for me. There was a time, a couple of 
years ago, when I used D a lot for such things, but now it's barely more 
than a passing fancy - there's just nothing useful that I can use D for any 
more. I'm hoping (1) that someone will come along and take Phobos out of 
Walter's hands and make it into something coherent and useful, and (2) that 
I can squeeze the time this year to do some DTL (and to put include some of 
that in the next volume of my book, which I'll be starting work on in 
Mar/Apr). Absent such changes, I guess I'll continue to be a part-timer. ;-/

Matthew

P.S. Sorry to sound so negative. I still have high hopes for D, just my 
glass-half-empty side is beginning to "Show me the money" on all my 
non-paying activities.



 Jan 29 2006



 next sibling parent reply "Charles" <noone nowhere.com>  writes:


Yea I feel your pain.  I've kind of given up actively plugging D, its just
taking so long.  Hopefully before 2009 ( C++0x ) we will have a 1.0.

Id like to see the compile time regex lib before I say yes or no to built in
regex's , but I guess builtin couldnt really hurt the language.

On a side note I read that article in one of the other posts comparing
ruby/c++/python/java -- and after looking at the source code for the
examples, ruby looks uber!  I definetly want to give it a try now -- having
retired perl long ago.



"Matthew" <matthew stlsoft.com> wrote in message
news:drkd1t$1tnk$1 digitaldaemon.com...

         D has built-in reg-exp, a la Ruby, &&


 Is this really practical in a compiled language ?


 I'm not an expert, but I can see no practical impediment. Obviously


there's

 the theoretical issue whereby one likes to avoid gratuitous mixing of
 language and libraries. I am usually a very strong advocate against, but


in

 this case would make an exception because of the incredible utility.


  Does the D community have
 a desperate need for built-in regexes ?

 Can you give me an example why built-in would win over a regex library ?
 ( genuinely curious ).


 Look, it's like this. I use the 2000 boot of my Windows machine in
 preference to the XP for basically one reason: I can select text from
 command boxes without first having to do Alt-Space E K, which I find
 incredibly tiresome when I've already been incovenienced by having to use
 the damn mouse. The other influencing factor is the fact that XP is a
 steaming heap of omni-crashing shite, but it's really just the usability


of

 the command-box. I know it's crazy, but it's the truth.

 By the same token, I always reach for Ruby in preference to Python or


Perl.

 It's built-in regex means it pantses Python every time, and the fact that


I

 can read it and write extensions (recls/Ruby, OpenRJ/Ruby, and other
 proprietary ones) for it (which I've thus far found impossible to do for
 Perl) rules out Perl. I don't care how much more comprehensive Python's
 libraries are. Anytime I find a missing Ruby library, even if Python has


it,

 I'll write one or write an extension, just so I can keep using that


built-in

 regex and recls/Ruby.

 So, if D wants to be considered a viable alternative to Python and Ruby,
 then I believe it needs built-in regex. If it doesn't, then it doesn't.
 Simple as that. Since it seems like D's not yet decided what it wants to


be,

 or who it wants to serve (apart from people interested in language design
 and compiler implementation, of course), then the potential of being a
 scripting alternative raises this point. If that's not a viable option,


then

 so be it. It can't be everything to everyone. It's just that as such it
 will, just like C/C++/Java/.NET, always be a poor cousin to Ruby and Perl
 for hardcore regex processing.

 As I said in another thread the other day, the lack of libraries/track
 record/tools/v1.1 rules out D for things I'd use C/C++/.NET.Java for, so
 it's just not a competitor there. It's not even an issue. (I can't comment
 on when/if that'll change, as I've not been around enough, but I'd be
 interested to hear if/when people think it will ever reach this point.)
 Second, it's not, as yet, suitable as an alternative for scripting for


most

 things I, for one, write scripts for.

 Unfortunately, at least for me, the things that D _would_ be useful for,
 writing small utilities with short-medium term lifespans, is also not an
 option because Walter's not updated std.recls in Phobos since ~2003/4, and


I

 use recls in just about every such utility I write, meaning that they're
 always done in C++ or in Ruby and never in D. I consider this to be a real
 shame, even if, perhaps, that's only for me. There was a time, a couple of
 years ago, when I used D a lot for such things, but now it's barely more
 than a passing fancy - there's just nothing useful that I can use D for


any

 more. I'm hoping (1) that someone will come along and take Phobos out of
 Walter's hands and make it into something coherent and useful, and (2)


that

 I can squeeze the time this year to do some DTL (and to put include some


of

 that in the next volume of my book, which I'll be starting work on in
 Mar/Apr). Absent such changes, I guess I'll continue to be a part-timer.


;-/

 Matthew

 P.S. Sorry to sound so negative. I still have high hopes for D, just my
 glass-half-empty side is beginning to "Show me the money" on all my
 non-paying activities.





 Jan 30 2006



  parent reply "Matthew" <matthew stlsoft.com>  writes:


"Charles" <noone nowhere.com> wrote in message 
news:drlds5$7a1$1 digitaldaemon.com...

 Yea I feel your pain.  I've kind of given up actively plugging D, its just
 taking so long.  Hopefully before 2009 ( C++0x ) we will have a 1.0.


;-/


 Id like to see the compile time regex lib before I say yes or no to built 
 in
 regex's , but I guess builtin couldnt really hurt the language.


Sure. My position is not that D has to have built-in regex, just that if it 
doesn't then it can't hope to be a serious alternative to Perl and Ruby.


 On a side note I read that article in one of the other posts comparing
 ruby/c++/python/java -- and after looking at the source code for the
 examples, ruby looks uber!  I definetly want to give it a try now --  
 having
 retired perl long ago.


It is indeed great. The thing that "worries" me is that I learned everything 
I know about it in the first two days, and that I've not learned anything 
since. This either means I'm missing out on a huge amount of stuff, or it's 
just as simple and easy as it seems.

Most of my scripts use recls/Ruby, which is as simple as:


require 'recls'

fs = Recls::FileSearch::new("h:/stlsoft", "*.hpp|*.h", Recls::FILES | 
Recls::RECURSIVE)

fs.each \
{ |fe|

    lines = IO::readlines(fe.path)

    lines.each_with_index \
    { |line, index|
            line.chomp!
            if line =~ / blah blah blah /
                lines[index] = blah2 blah2 blah2
            end
    }

    if bChanged
        f = File::new(fe.path, "w")
        lines.each { |line| f << line << "\n" }
        f.close

    end
}

This is the basic form of my scripts, with which I can effect changes to 
hundreds/thousands of source files in one go. It's really really useful.

(I'd love to be doing the same in D, but ...)



 Jan 30 2006



 next sibling parent  "Charles" <noone nowhere.com>  writes:


$_ ?!  Oh the horror.



"Matthew" <matthew stlsoft.com> wrote in message
news:drlua3$r7j$1 digitaldaemon.com...

 "Charles" <noone nowhere.com> wrote in message
 news:drlds5$7a1$1 digitaldaemon.com...

 Yea I feel your pain.  I've kind of given up actively plugging D, its




just

 taking so long.  Hopefully before 2009 ( C++0x ) we will have a 1.0.


 ;-/


 Id like to see the compile time regex lib before I say yes or no to




built

 in
 regex's , but I guess builtin couldnt really hurt the language.


 Sure. My position is not that D has to have built-in regex, just that if


it

 doesn't then it can't hope to be a serious alternative to Perl and Ruby.


 On a side note I read that article in one of the other posts comparing
 ruby/c++/python/java -- and after looking at the source code for the
 examples, ruby looks uber!  I definetly want to give it a try now --
 having
 retired perl long ago.


 It is indeed great. The thing that "worries" me is that I learned


everything

 I know about it in the first two days, and that I've not learned anything
 since. This either means I'm missing out on a huge amount of stuff, or


it's

 just as simple and easy as it seems.

 Most of my scripts use recls/Ruby, which is as simple as:


 require 'recls'

 fs = Recls::FileSearch::new("h:/stlsoft", "*.hpp|*.h", Recls::FILES |
 Recls::RECURSIVE)

 fs.each \
 { |fe|

     lines = IO::readlines(fe.path)

     lines.each_with_index \
     { |line, index|
             line.chomp!
             if line =~ / blah blah blah /
                 lines[index] = blah2 blah2 blah2
             end
     }

     if bChanged
         f = File::new(fe.path, "w")
         lines.each { |line| f << line << "\n" }
         f.close

     end
 }

 This is the basic form of my scripts, with which I can effect changes to
 hundreds/thousands of source files in one go. It's really really useful.

 (I'd love to be doing the same in D, but ...)





 Jan 31 2006



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


Matthew wrote:

 
 This is the basic form of my scripts, with which I can effect changes to 
 hundreds/thousands of source files in one go. It's really really useful.


I tend to use UltraEdit for this sort of thing, though scripting it 
seems a nice alternative.


Sean



 Jan 31 2006



  parent  "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Sean Kelly" <sean f4.ca> wrote in message
news:drolf7$1tae$1 digitaldaemon.com...

 Matthew wrote:

 This is the basic form of my scripts, with which I can effect changes to
 hundreds/thousands of source files in one go. It's really really useful.


 I tend to use UltraEdit for this sort of thing, though scripting it
 seems a nice alternative.


I've never tried UltraEdit. Although I'm sure it would work for most things
I do, inevitably it would fall down on some, e.g. moving all the unit-test
blocks out of any library headers and into newly created
./unittest/blahblah_unittest_.h files.



 Jan 31 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew stlsoft.com> wrote in message 
news:drlua3$r7j$1 digitaldaemon.com...

 Most of my scripts use recls/Ruby, which is as simple as:


 require 'recls'

 fs = Recls::FileSearch::new("h:/stlsoft", "*.hpp|*.h", Recls::FILES | 
 Recls::RECURSIVE)

 fs.each \
 { |fe|

    lines = IO::readlines(fe.path)

    lines.each_with_index \
    { |line, index|
            line.chomp!
            if line =~ / blah blah blah /
                lines[index] = blah2 blah2 blah2
            end
    }

    if bChanged
        f = File::new(fe.path, "w")
        lines.each { |line| f << line << "\n" }
        f.close

    end
 }

 This is the basic form of my scripts, with which I can effect changes to 
 hundreds/thousands of source files in one go. It's really really useful.

 (I'd love to be doing the same in D, but ...)


Ruby, 18 lines.
D, 16 lines, including declarations and bug fix for bChanged.
-----------------------------------------
import std.file;
import std.stdio;
import std.string;

void main()
{
    char[][] fs = listdir("h:/stlsoft", "*.h") ~ listdir("h:/stlsoft", 
"*.hpp");

    foreach (char[] fe; fs)
    { bool bChanged;
      char[] buffer = cast(char[]) read(fe);
      char[][] lines = splitlines(buffer);

      foreach (inout char[] line; lines)
     {
        if ("blah blah blah" ~~ chomp(line))
        { line = "blah2 blah2 blah2" ~ newline;
           bChanged = true;    // missing in Ruby version
        }
     }

     if (bChanged)
    {
       write(fe, join(lines, null));
       writefln("Processed %s", fe);
     }
    }
}



 Feb 11 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsmlv7$mh2$1 digitaldaemon.com...

 "Matthew" <matthew stlsoft.com> wrote in message
 news:drlua3$r7j$1 digitaldaemon.com...

 Most of my scripts use recls/Ruby, which is as simple as:


 require 'recls'

 fs = Recls::FileSearch::new("h:/stlsoft", "*.hpp|*.h", Recls::FILES |
 Recls::RECURSIVE)

 fs.each \
 { |fe|

    lines = IO::readlines(fe.path)

    lines.each_with_index \
    { |line, index|
            line.chomp!
            if line =~ / blah blah blah /
                lines[index] = blah2 blah2 blah2
            end
    }

    if bChanged
        f = File::new(fe.path, "w")
        lines.each { |line| f << line << "\n" }
        f.close

    end
 }

 This is the basic form of my scripts, with which I can effect changes to
 hundreds/thousands of source files in one go. It's really really useful.

 (I'd love to be doing the same in D, but ...)


 Ruby, 18 lines.
 D, 16 lines, including declarations and bug fix for bChanged.
 -----------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 void main()
 {
     char[][] fs = listdir("h:/stlsoft", "*.h") ~ listdir("h:/stlsoft",
 "*.hpp");

     foreach (char[] fe; fs)
     { bool bChanged;
       char[] buffer = cast(char[]) read(fe);
       char[][] lines = splitlines(buffer);

       foreach (inout char[] line; lines)
      {
         if ("blah blah blah" ~~ chomp(line))
         { line = "blah2 blah2 blah2" ~ newline;
            bChanged = true;    // missing in Ruby version
         }
      }

      if (bChanged)
     {
        write(fe, join(lines, null));
        writefln("Processed %s", fe);
      }
     }
 }


And the recursion?

I don't want to add to the ill-humour that's been exchanged of late, but
seriously, wh-ha-at the?!?

I scratch my head - considering the bChanged "correction" (!) and the reuse
of "blah blah blah" - and wonder why you've bothered. You've spent some
effort here in attempting to prove that D doesn't have a problem which it
most certainly does have, and you will only convince those few people who
are not yet sufficiently knowledgeable/experienced in D. You might have only
spent five minutes, but now you've eaten 5 of mine, and to counter this
you're going to have to spend a lot more than those first 5 to get a correct
equivalent to my example. (The main purpose of recls is, er, recursion, you
know.
<g>)

Surely all that effort would have been far better spent upgrading the
standard library with the latest version of recls. That way, when someone on
c.l.c.m gives you a similar criticism as my example did, you'll be able to
trot out a genuine rejoinder, rather than shooting yourself in the foot.


Matthew

P.S. What's your example doing to do if you find a directory with a H or HPP
extension?



 Feb 12 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dsn1fp$14hc$1 digitaldaemon.com...

 And the recursion?


std.file.listdir does recursion.


 I don't want to add to the ill-humour that's been exchanged of late, but
 seriously, wh-ha-at the?!?

 I scratch my head - considering the bChanged "correction" (!) and the 
 reuse
 of "blah blah blah" - and wonder why you've bothered. You've spent some
 effort here in attempting to prove that D doesn't have a problem which it
 most certainly does have,
 and you will only convince those few people who
 are not yet sufficiently knowledgeable/experienced in D. You might have 
 only
 spent five minutes, but now you've eaten 5 of mine, and to counter this
 you're going to have to spend a lot more than those first 5 to get a 
 correct
 equivalent to my example. (The main purpose of recls is, er, recursion, 
 you
 know.
 <g>)


I think you'll find that the D version does the same thing.


 Surely all that effort would have been far better spent upgrading the
 standard library with the latest version of recls. That way, when someone 
 on
 c.l.c.m gives you a similar criticism as my example did, you'll be able to
 trot out a genuine rejoinder, rather than shooting yourself in the foot.

 Matthew

 P.S. What's your example doing to do if you find a directory with a H or 
 HPP
 extension?


Directories don't get added to the list of files, though they get searched. 
Only files are affected by the pattern match. There isn't much to listdir's 
implementation:

char[][] listdir(char[] pathname, char[] pattern)
{   char[][] result;

    bool callback(DirEntry* de)
    {
        if (de.isdir)
            listdir(de.name, &callback);
        else
        {   if (std.path.fnmatch(de.name, pattern))
                result ~= de.name;
        }
        return true; // continue
    }

    listdir(pathname, &callback);
    return result;
}

That version uses the simple fnmatch which does * and ?, but one could as 
easilly use std.regexp and use full regular expressions on the filenames. 



 Feb 12 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsn3ca$165g$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dsn1fp$14hc$1 digitaldaemon.com...

 And the recursion?


 std.file.listdir does recursion.


Truly? Well, I didn't know that. It's been a while. I stand corrected.

Of course, that's a ghastly proposition. Read on for why this is so.


 Directories don't get added to the list of files, though they get


searched.

 Only files are affected by the pattern match. There isn't much to


listdir's

 implementation:

 char[][] listdir(char[] pathname, char[] pattern)
 {   char[][] result;

     bool callback(DirEntry* de)
     {
         if (de.isdir)
             listdir(de.name, &callback);
         else
         {   if (std.path.fnmatch(de.name, pattern))
                 result ~= de.name;
         }
         return true; // continue
     }

     listdir(pathname, &callback);
     return result;
 }

 That version uses the simple fnmatch which does * and ?, but one could as
 easilly use std.regexp and use full regular expressions on the filenames.


If this is an example of the quality of D's libraries, then it paints s a
sad picture. Perhaps someone needed a shoulder buddy when it was being
designed? ;-)

If a user wants to use multi-part pattern matching, your client code will
have to execute N calls to listdir(). That's simply bad design. First, it
makes client code unnecessarily complicated - your taking my example as
literal in this respect to have a two-part pattern was quite disengenuous -
as you're going to have to do the pattern splitting and loop on listdir()
when the utility passes in a pattern (as mine do, of course, in the real
world; I was simplifying to make a point).

Second, and at least as importantly (but less obviously), it fails to
reflect the fact that directory enumeration is an I/O bound operation: Code
using listdir() is going to have poor performance; very poor in fact. And I
*know* this because I've done comparative studies that quantified this for
recls a couple of years ago that tested out the difference between handling
patterns at the level of the search or the level of the individual
directory. (It's also going to wait a _long_ time on a big search doing
apparently nothing, though I note listdir appears to support some kind of
callbacks, so I assume that that can be avoided.) Further, it seems to have
been conceived absent any thought to the complexity implications involved in
doing really large searches - continually resizing very large arrays is not
a good idea. This will significantly add to the poor performance.

(Anyone that cares to verify this can simply write a couple of simple progs
with recls to search multi-patterns. (You'll have to write it in
C/C++/.NET/Ruby/Python/Java, though, as you can't use D, since the version
of std.recls is too old.) Write one to split in the client code and issue N
single-part patterns to recls. Write the second to pass multi-part patterns
into a single call to recls. Time the two. (You'll need to run each a few
times to get a fair comparison, since the OS will cache things up in
response.)

Looking through the docs for listdir() it seems like it tries to do some of
the things that recls does, albeit far less well. But it does have fewer
lines of code, and that's all that counts, surely?. Except it's wrongheaded.
Putting aside the performance issues, those fewer lines of code in the
library - to be sure, a boon in and of itself - will be *far* outweighed by
the increased number of lines of client code. And since number of errors are
proportional to numbers of lines of code, moderated by how many "eyes" /
executions have covered that code, again D loses out to Ruby (or any other
language that uses recls or any similar recursive file-system searching that
supports multi-part pattern matching).

I know you'll continue to argue the toss, and you'll doubtless fashion a way
to appear to win this argument in this forum, but D continues to stack up
poorly against Ruby/X/Y/Z in reality. I haven't tested it, but I wouldn't be
the least bit surprised that a Ruby script using recls/Ruby would outperform
an equivalent program using D.

... <some eight hours later ...> ...

I decided that facts would be more powerful than conjecture. Enumerating
source files - something I commonly do - using both a D program using
listdir and a Ruby script using recls/Ruby, I get the following results for
one of my main work directories H:/Dev. The search pattern is
"*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc". The
programs are timed using ptime (http://synesis.com.au/systools.html), and
run directly one after the other, to obviate any OS caching (i.e. you can
ignore the first couple, but the rest should be pretty representative).
Neither do any output, since that'd skew the times, they merely count the
number of entries obtained (and were verified to detect the same numbers, of
course).

D:      time: elapsed: 7,484ms, kernel: 3,593ms, user: 3140ms
Ruby: time: elapsed: 3,781ms, kernel: 3,031ms, user: 500ms
D:      time: elapsed: 8,906ms, kernel: 3,187ms, user: 3,671ms
Ruby: time: elapsed: 3,687ms, kernel: 2,734ms, user: 703ms
D:      time: elapsed: 8,953ms, kernel: 3,640ms, user: 3296ms
Ruby: time: elapsed: 3,718ms, kernel: 2,890ms, user: 593ms
D:      time: elapsed: 7,500ms, kernel: 4,093ms, user: 2,734ms
Ruby: time: elapsed: 3,750ms, kernel: 3,031ms, user: 531ms
D:      time: elapsed: 8,828ms, kernel: 3,906ms, user: 2,937ms
Ruby: time: elapsed: 3,687ms, kernel: 3,093ms, user: 390ms

and the following for my entire work drive H:/. Ruby had to come first here,
as I kept losing my nerve/patience and pressing Ctrl-C on the D version, so
I ran Ruby ver first to get a ballpark for how long I might have to wait for
the D version. I was misled. Again, you can ignore the first couple of runs,
as they are somewhat affected by the OS scrabbling to eat a last bit of
toast and some juice before it has to run out to work.

Ruby: time: elapsed: 475,609ms, kernel: 44,640ms, user: 7,218ms
D:      time: elapsed: 4,224,625ms, kernel: 92,421ms, user: 48,625ms
Ruby: time: elapsed: 80,359ms, kernel: 41,781ms, user: 6,484ms
D:      time: elapsed: 2,540,203ms, kernel: 79,515ms, user: 47,031ms
Ruby: time: elapsed: 83,656ms, kernel: 40,484ms, user: 6,984ms
D:      time: elapsed: 2,733,218ms, kernel: 80,078ms, user: 47,203ms
Ruby: time: elapsed: 88,062ms, kernel: 40,578ms, user: 6,812ms
D:      time: elapsed: 2,630,031ms, kernel: 76,890ms, user: 47,609ms
Ruby: time: elapsed: 86,809ms, kernel: 42,000ms, user: 7,093ms
D:      time: elapsed: 2,864,390ms, kernel: 81,046ms, user: 47,765ms

(btw, during the execution of the full-drive search, the ruby.exe process
stayed at a constant 4MB. listdir_test.exe didn't behave quite so well ....
when I stopped watching it was at 65MB, and VMM was crying before it
completed but I didn't get to peak at it as I had wandered off for a sleep.)

For reference, I ran one of my C++ programs, whereis, with the same
patterns. It is not (yet) written with recls, but rather uses "manual"
recursion. (It ran at a constant 1MB.) It gave:

    "time: elapsed: 275,328ms, kernel: 40,921ms, user: 8,984ms"
    "time: elapsed: 257,343ms, kernel: 41,609ms, user: 8,171ms"
    "time: elapsed: 271,656ms, kernel: 41,546ms, user: 8,875ms"

Somewhat unexpectedly, it appears that Ruby+recls/Ruby is faster than a
plain-old-C++ program. <g> (Note that whereis and Ruby+recls/Ruby both spend
similar amounts of time in the kernel, whereas D clearly does something
quite different.)

The "H:/" result clearly shows what a horrible idea it is to return en bloc
elements from what is an "Input Iterator" collection (if you'll pardon my
C++ parlance). (btw, these and many other issues are covered in my new book,
Extended STL, vol 1. Just thought I'd drop that one in, even though I know
most D-people couldn't care less about the crusty old has been C++. <g>)

Before I went back and did these tests, I'd written a hang-dog final
paragraph:

    "As for std.recls, maybe the best thing to do would be simply to drop it
from Phobos forthwith, since you're clearly not in the slightest bit
interested in updating it, and it's doing no one any good being 2-3 years
behind the game. That way anyone that does want to use it can do so without
all the conflicts and bother that are currently incurred."

However, in light of the concrete results shown above, I now feel quite
justified in urging that you again treat recls as a first-class Phobos
library and update it forthwith, since it seems to do its job rather well
despite it's unmentionable implementation in C/C++. Further, I strongly
suggest you toss out listdir() as the ill-conceived and badly performing
mess that I've just demonstrated it to be. (You know, there's a reason there
hasn't been much progress in writing recursive search libraries before
recls: it's not actually as easy as it sounds.)

<anachronistic-aside>I can't help but smile when I recall the criticisms
made of newer languages that make programming too easy, as they often lead
to very poor performance despite having had features deliberately designed
in to aid performance. </anachronistic-aside>

Matthew



 Feb 12 2006



 next sibling parent reply AgentOrange <AgentOrange_member pathlink.com>  writes:


Excuse me if I missed this part, but why dont we just update std.recls?



 Feb 12 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"AgentOrange" <AgentOrange_member pathlink.com> wrote in message
news:dso6f5$2ee0$1 digitaldaemon.com...

 Excuse me if I missed this part, but why dont we just update std.recls?


I have no idea. As I've explained on the bugs ng, Walter and I had an
agreement that recls 1.6 (released March 05) would be the point at which it
was updated, but before we got to that point I'd mentioned that I planned
(and still plan) to implement a recls2 (which is more of a recursion engine,
supporting recursion of a whole lot of other things including file-system,
FTP, XML docs, Win32 registry, etc. etc.), and that it would likely be
primarily in C (which would mean it would be smaller). Walter then changed
his mind and said he'd rather wait for recls2.

Alas, real life has got in the way - my book, and paying the bills, and
other libs - so recls2 has not yet got past the core engine stage. My book
is almost ready for review, after which recls2 will be one of the things
I'll be doing. But it's still likely to be some months out.

I'm afraid this situation is representative a real problem that many
engineers have, especially when it comes to issues of languages and/or
libraries.

From Walter's perspective recls is flawed because it is large - in object
it's not so bad, e.g. 20KB with VC++, but in source it's quite a lot of
files ~200KB IIRC. However, the point is apparently missed that it's got a
Good Design. It scales to any conceivable search scope, a la my recent
tests, and is mapped to other many languages with ease.

Conversely, D's syntax and apparent power means that listdir() is very
succinct. In source size it's probably ~1% that of recls, if that. However,
this succinctness is specious, misleading the author(s) of listdir() into a
Bad Design. Simply put, if listdir() wants to be recursive, it cannot return
en bloc. If it wants to return en bloc, it cannot be recursive. One can
equivocate as much as one wishes, but that equation cannot be avoided. (This
is the reason why I shot off half-cocked about Walter's counter example not
supporting recursion. It never entered my head that anyone would combine
these two features.)

It's far easier to re-implement a fat implementation of a good design, than
it is to fix a bad design. Since D's many months away, and I've demonstrated
just how bad listdir() is, I can't see any sensible justification why
std.recls is not updated now. I'm very confident that recls2 will be ready
before D 1.0, but even were it not, the current version of std.recls isn't
going to put the rest of D to shame.

In the spirit of kicking someone while they're down, I would again, as I
have many times over the years in which I've been involved with D, observe
that being a good compiler designer/writer doesn't make you a good library
designer/writer, and being a good library designer/writer doesn't make you a
good application designer/writer, and so on and so forth. What D needs is a
combination of talents in all such areas. Since there is hardly an overall
lack of all such in this NG, perhaps we might consider organising for the
common purpose of making D good and ready, rather than attempting to shoot
each other's feet off?

Matthew



 Feb 12 2006



 next sibling parent  nick <nick.atamas gmail.com>  writes:


Matthew wrote:

 <SNIP>
 I would again, as I
 have many times over the years in which I've been involved with D, observe
 that being a good compiler designer/writer doesn't make you a good library
 designer/writer, and being a good library designer/writer doesn't make you a
 good application designer/writer, and so on and so forth. What D needs is a
 combination of talents in all such areas. Since there is hardly an overall
 lack of all such in this NG, perhaps we might consider organising for the
 common purpose of making D good and ready, rather than attempting to shoot
 each other's feet off?
 
 Matthew
 


Matthew, your argument is very persuasive. There does seem to be a
certain amount of shooting at each other's feet, and it does get in the
way of the goal - a successful D 1.0. It would really help to have some
sort of a community structure organized at a common goal.



 Feb 12 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dsod2v$2o1s$1 digitaldaemon.com...

 Conversely, D's syntax and apparent power means that listdir() is very
 succinct. In source size it's probably ~1% that of recls, if that. 
 However,
 this succinctness is specious, misleading the author(s) of listdir() into 
 a
 Bad Design. Simply put, if listdir() wants to be recursive, it cannot 
 return
 en bloc. If it wants to return en bloc, it cannot be recursive. One can
 equivocate as much as one wishes, but that equation cannot be avoided.


I believe listdir() shows that it can be done both ways, and done well. 
There are two essential versions of listdir() - one visits each file and 
directory in the path, and passes the results *as they are found* to a 
delegate. The delegate, of course, can execute arbitrary user-supplied code 
to do anything desired at each point in the search.

The second listdir(), which I posted the listing for, calls the first 
listdir() with a delegate that assembles the results into one large array, 
in a way that is likely the most common way listdir() would be used. If what 
it does is not what is desired, it's a simple thing to provide a delegate to 
do *whatever* is desired, as I showed with the rewritten benchmark. All that 
did was replace the call to fnmatch with one to RegExp.test. (I could also 
extend fnmatch to accept '|', and the results would be the same without 
expanding the code size by 100x, but I wanted to show how this could be done 
by the user without changing library code.)

Does this flexibility, which can be achieved without modification of any 
library code, mean that listdir() is a Bad Design? I disagree. I tend to 
believe in the "building block" idea of library design, that rather than 
build one large function with a lot of options, that one builds smaller 
functions that can be assembled together as needed. In listdir()'s case, 
it's the ability of it to call user-supplied code via the delegate that 
lends itself to this approach. Instead of relying on flags passed to one 
do-it-all function, the decision on what to do with each entry is determined 
by user-supplied code.

You commented in another post that the way listdir() appends filenames to an 
array is also a bad design. I'll reply that, ideally, the array would be 
preallocated based on the number of entries that will be put into it, and 
then simply filled in. Unfortunately, there is *no way* to even guess how 
big the array will be unless 2 passes are made over the disk. As you 
correctly pointed out, however, this will be unacceptably slow (and also 
buggy, as the disk contents can change between passes). A very reasonable 
way is to assemble the array as the pieces come in. Under the hood, the 
array is resized in powers of 2, so there aren't that many alloc/copy 
operations going on. I think the results speak for themselves - it's plenty 
fast enough.

So now I'll comment a bit on recls (this is based on the recls shipping with 
D now, your later versions might correct any or all of these problems).

First the good stuff:

1) It works (never underestimate this feature!)

2) It's fast

3) It's a fine example of how to adapt a C++ library to be accessible from D 
(and other languages)

4) It uses unittests and contract programming (double plus good!)

Now the not as good stuff, most of which I've emailed to you in one form or 
another:

1) It's gigantic. Something is just not right when something that should be 
simple, a recursive directory lister, winds up being 250K of source. 
Subsequent recls versions got much larger than that. Even the adapter code 
std/recls.d is far larger than the entire D code to support listdir().

2) It's written (necessarilly, because it's in C++) in the C++ style of 
doing things. C++ style code adapts rather poorly to D. A D standard library 
component should be written in the D style of doing things.

3) The D style, for example, makes use of delegates, because it adds a lot 
of flexibility with essentially no overhead. Doing delegates in C++ is 
horrible, so what people do instead is write do-it-all high level functions 
that accept lots of flags adjusting the behavior. The designer tries to 
anticipate every way the function might be used, and adds flags and 
arguments for each. Even if the behavior of some of the options is rarely 
needed, the bloat to implement it gets added on to every user of the 
function. Consider, for example, if one needs recls to skip directories 
named "fred". The choices are all unattractive - petition the standards 
committee to add the feature, fork the library source, or build one's own 
from the ground up. With delegates, just write a simple delegate filter, and 
the library is unmodified.

Modern C++ has tried to deal with this problem by using templates, with 
technical success, but acceptance by the general C++ community of this 
technique has been poor due to its complexity. Even if they were accepted, 
templates just ain't going to cross language boundaries.

4) recls, by its nature of being self-contained, duplicates functionality 
found in other D standard library packages (like std.path). Standard library 
components should be orthogonal, not redundant.

5) recls, because it's in C++, can't deal with UTF.

6) It makes sense to put a D shell around C++ code when there is no other 
reasonable way to proceed (wxD is an example of that). But this isn't the 
case with recls - it's designed to be C++ code callable from other 
languages. That makes sense as a demonstration project, but it doesn't make 
sense as a standard language component, when just the work writing the D 
wrapper exceeds the work to do a 100% D implementation.

I won't argue that I'm a great library designer, or that every module I 
wrote in Phobos is the cat's meow. Far from it. I'll just leave it at 
listdir() being a pretty good design. 



 Feb 12 2006



  parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsonub$5l1$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
 news:dsod2v$2o1s$1 digitaldaemon.com...

 Conversely, D's syntax and apparent power means that listdir() is very
 succinct. In source size it's probably ~1% that of recls, if that. 
 However,
 this succinctness is specious, misleading the author(s) of listdir() into 
 a
 Bad Design. Simply put, if listdir() wants to be recursive, it cannot 
 return
 en bloc. If it wants to return en bloc, it cannot be recursive. One can
 equivocate as much as one wishes, but that equation cannot be avoided.


 I believe listdir() shows that it can be done both ways, and done well. 
 There are two essential versions of listdir() - one visits each file and 
 directory in the path, and passes the results *as they are found* to a 
 delegate. The delegate, of course, can execute arbitrary user-supplied 
 code to do anything desired at each point in the search.

 The second listdir(), which I posted the listing for, calls the first 
 listdir() with a delegate that assembles the results into one large array, 
 in a way that is likely the most common way listdir() would be used. If 
 what it does is not what is desired, it's a simple thing to provide a 
 delegate to do *whatever* is desired, as I showed with the rewritten 
 benchmark. All that did was replace the call to fnmatch with one to 
 RegExp.test. (I could also extend fnmatch to accept '|', and the results 
 would be the same without expanding the code size by 100x, but I wanted to 
 show how this could be done by the user without changing library code.)

 Does this flexibility, which can be achieved without modification of any 
 library code, mean that listdir() is a Bad Design? I disagree. I tend to 
 believe in the "building block" idea of library design, that rather than 
 build one large function with a lot of options, that one builds smaller 
 functions that can be assembled together as needed. In listdir()'s case, 
 it's the ability of it to call user-supplied code via the delegate that 
 lends itself to this approach. Instead of relying on flags passed to one 
 do-it-all function, the decision on what to do with each entry is 
 determined by user-supplied code.

 You commented in another post that the way listdir() appends filenames to 
 an array is also a bad design. I'll reply that, ideally, the array would 
 be preallocated based on the number of entries that will be put into it, 
 and then simply filled in. Unfortunately, there is *no way* to even guess 
 how big the array will be unless 2 passes are made over the disk. As you 
 correctly pointed out, however, this will be unacceptably slow (and also 
 buggy, as the disk contents can change between passes). A very reasonable 
 way is to assemble the array as the pieces come in. Under the hood, the 
 array is resized in powers of 2, so there aren't that many alloc/copy 
 operations going on. I think the results speak for themselves - it's 
 plenty fast enough.


This is total crap. You were the one that demonstrated the usage. Now 
somehow you're telling us that in order to be able to use listdir() in a 
non-pathalogical way one must not only be cognisant of the leaks in its 
abstraction but also be knowledgeable to, say, the level of someone who's 
expert in writing their own recursive search libraries. It's just rubbish. 
The library is bad, and that's plain because I used it in a bad way 
following your code sample that was presented as a rejoinder to a criticism 
of D's current inadequacies at recursive file processing. If you can't see 
the problem there, I really do shudder.


 So now I'll comment a bit on recls (this is based on the recls shipping 
 with D now, your later versions might correct any or all of these 
 problems).

 First the good stuff:

 1) It works (never underestimate this feature!)

 2) It's fast

 3) It's a fine example of how to adapt a C++ library to be accessible from 
 D (and other languages)

 4) It uses unittests and contract programming (double plus good!)

 Now the not as good stuff, most of which I've emailed to you in one form 
 or another:

 1) It's gigantic. Something is just not right when something that should 
 be simple, a recursive directory lister, winds up being 250K of source. 
 Subsequent recls versions got much larger than that.


Three things:
 - and yet you agreed to take 1.6, assuming it shrank
 - I put in a lot of work to shrink it.
 - why do you focus on source size, not code size? As I said, with VC7.1 
it's ~20KB, and many other compilers are around the same.


 Even the adapter code std/recls.d is far larger than the entire D code to 
 support listdir().


This is a complete furphy.

First, you're hardly comparing like with like. Does listdir() handle reparse 
points, ~ (home), follow/not-follow links, provide a full suite of entry 
attributes (incl. Drive, Directory, File, FileName, FileExt, ShortFile, 
OS-independent directory (i.e. incl drive on Win), 
SearchDirectoryRelativePath, times, size, attributes, a collection of 
directory parts, etc.) and so on and on.

Second, since I've not been afforded the facility for changing this in 2.5 
years, how can it possibly be judged as representative of an inate 
characteristic of the library. This is some medieval reasoning you've got 
going.


 2) It's written (necessarilly, because it's in C++) in the C++ style of 
 doing things. C++ style code adapts rather poorly to D. A D standard 
 library component should be written in the D style of doing things.


This contradicts point 3) above. And it's quite wrong.


 3) The D style, for example, makes use of delegates, because it adds a lot 
 of flexibility with essentially no overhead. Doing delegates in C++ is 
 horrible, so what people do instead is write do-it-all high level 
 functions that accept lots of flags adjusting the behavior. The designer 
 tries to anticipate every way the function might be used, and adds flags 
 and arguments for each. Even if the behavior of some of the options is 
 rarely needed, the bloat to implement it gets added on to every user of 
 the function. Consider, for example, if one needs recls to skip 
 directories named "fred". The choices are all unattractive - petition the 
 standards committee to add the feature, fork the library source, or build 
 one's own from the ground up. With delegates, just write a simple delegate 
 filter, and the library is unmodified.


"Kick 'im in. If he sinks he's innocent, if he floats we'll hang 'im!"

How am I supposed to keep up with the D way of doing things when I cannot 
update the code for 2.5 years.


 Modern C++ has tried to deal with this problem by using templates, with 
 technical success, but acceptance by the general C++ community of this 
 technique has been poor due to its complexity. Even if they were accepted, 
 templates just ain't going to cross language boundaries.


Completely irrelevant.

How come I've been able to adapt recls to delegates in .NET then, eh?


 4) recls, by its nature of being self-contained, duplicates functionality 
 found in other D standard library packages (like std.path). Standard 
 library components should be orthogonal, not redundant.


Arguable. I'm pretty sure that a fair amount of the duplication was added 
into std.path _after_ std.recls first entered Phobos. Cuckoo, cuckoo


 5) recls, because it's in C++, can't deal with UTF.


Furphy.

This was raised and addressed. A couple of years ago. (Though may be true in 
phobos version.)


 6) It makes sense to put a D shell around C++ code when there is no other 
 reasonable way to proceed (wxD is an example of that). But this isn't the 
 case with recls - it's designed to be C++ code callable from other 
 languages. That makes sense as a demonstration project, but it doesn't 
 make sense as a standard language component, when just the work writing 
 the D wrapper exceeds the work to do a 100% D implementation.


Is this the closest I'm going to get to a straight answer?

You're wrong, since listdir is most certainly bad design, but since you 
don't agree, may I interpret the above to mean "recls is not sufficiently 
good/feature-unique to be a non-100% D library, and therefore is not 
acceptable in Phobos"?

I presume this also means that you're no longer interested in recls2. As 
well as the file-system and (WIndows only) FTP recursive enumerations (for 
which there's no Phobos "ftp_listdir()", AFAIK), will you be adding in 
recursive searching of the registry, XML docs, LDAP, etc. etc. etc. ? If so, 
great. I look forward to using them. If not, why the reversal now of another 
agreement that we made a year or so ago?

Or maybe you're keeping a crippled recls(1) in now to motivate me to do 
recls2? If so, great. I'm very motivated.


 I won't argue that I'm a great library designer, or that every module I 
 wrote in Phobos is the cat's meow. Far from it. I'll just leave it at 
 listdir() being a pretty good design.


It's not. It's a pretty bad design. But all the rationale for that opinion 
are in previous posts, so I'll save my breath.

But if you acknowledge problems with the library, and I'm offering to help 
you fix one of them, why knock it back? I'd far rather you just remove 
std.recls than leave it in its crippled state.


Well, that's me done. I guess I've had the closest I'm going to get to a 
straight, if erroneously reasoned, answer. Thanks. Please remove std.recls 
at the next release cycle, and we can all take a load off.

You see, I told you if you tried hard enough you'd convince yourself you're 
right! <g>

Matthew



 Feb 12 2006



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


On Mon, 13 Feb 2006 13:08:50 +1100, Matthew <nowhere noaddress.co.us>  
wrote:

 6) It makes sense to put a D shell around C++ code when there is no  
 other
 reasonable way to proceed (wxD is an example of that). But this isn't  
 the
 case with recls - it's designed to be C++ code callable from other
 languages. That makes sense as a demonstration project, but it doesn't
 make sense as a standard language component, when just the work writing
 the D wrapper exceeds the work to do a 100% D implementation.


 Is this the closest I'm going to get to a straight answer?

 You're wrong, since listdir is most certainly bad design, but since you
 don't agree, may I interpret the above to mean "recls is not sufficiently
 good/feature-unique to be a non-100% D library, and therefore is not
 acceptable in Phobos"?


IMO this is the crux of the matter. It's not really about whether listdir  
or recls is good or bad, it's about the eventual goal, which is to have a  
coherent standard library written in D. Further, I think one of Walters  
comments highlights the process:


 4) recls, by its nature of being self-contained, duplicates functionality 
 found in other D standard library packages (like std.path). Standard  
 librarycomponents should be orthogonal, not redundant.


Phobos has has grown since recls was added, it can now support it's own  
implementation of (many of the/the basic) features that recls provides.

Regan



 Feb 12 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dso4rh$2d2u$1 digitaldaemon.com...

 I decided that facts would be more powerful than conjecture. Enumerating
 source files - something I commonly do - using both a D program using
 listdir and a Ruby script using recls/Ruby, I get the following results 
 for
 one of my main work directories H:/Dev. The search pattern is
 "*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc".


Please post the code of the benchmark you're using, as I can't comment on it 
until I see exactly what it's doing. 



 Feb 12 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsobqi$2mgg$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dso4rh$2d2u$1 digitaldaemon.com...

 I decided that facts would be more powerful than conjecture. Enumerating
 source files - something I commonly do - using both a D program using
 listdir and a Ruby script using recls/Ruby, I get the following results
 for
 one of my main work directories H:/Dev. The search pattern is
 "*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc".


 Please post the code of the benchmark you're using, as I can't comment on


it

 until I see exactly what it's doing.


Go wild



begin 666 listdir.zip


M=M!+D)[>LZ0X4CO3HF/653.I&I'%PPR%:J]3J/0GY2BK'=OE2B>C.#K%$91U
MCF\?`"\/F\WC>OD*"^#C69V-9U
M0] &Q)*379K^ZJ]7JPUX\>=Y6HF#K_Y9^Z=-HA"-*FS:&J%QFY9[1*'=0(HZ
M:!].H/4]UC3*)?U 4\8S/O)<6 $`:/"<^[ 4D"V*O*R3BPPSN2,1G;%.C78%
MI_ N^$+EA&QTPCO2G-U9/NU;1A>]P7LL6[!&^:- XJ>YH5YY2T&VP;&W'' ^


D;&ES=&1I<E]T97-T+F102P4&``````$``0`\````9P$`````
`
end

begin 666 recls-ruby.zip


M,_,$)_SJ:T)8$.JF6P NN*]VNY2QB'DO,BQP\ 3_V_'^.4I";.J\"X\M&CJ$
MNB="<[*VM\<TC=4V<<9E4*V7`>465=M:'K(ALT]AJ_VQ&/+.4KN:_O7Y;%D7
MC>5Q(FG/Q2L[8!$PY?)*^5PWF&!&NI+2X/>-2[:"^?(*9MOF-4Y G*6*G_8J
MV;S'MVNWTMB$]VYS )FNX$/P"XPECB X8P8B,' '#T[X;7_JH$3!KVYP4MZV
M_\R1)/ 7<YTB_ )02P,$% ```` `+W":,U_7\G'I6P``0M ``` ```!R96-L
M<RYS;^Q:?WQ457:_DPSA$2;D(0D,F)4!0A<KT&A0PR> 01A,5[*\F3 $-/Q0

MMA<SW1V7+(PZ\GK.N>\7`=;]I__E?9AWSSWGO.\]Y]QSS[WOA9K[6UDN8\P)
M/TUCK(.)JXI]\Y6!WZB)[XYB[2,^G-3A6/3AI"7!1S=ZUF]XXI$-#S[F>?C!
MQQ]_(N1Y:(UG0_AQSZ./>Q8LKO4\]D3#FID%!?FE.L;6YA5MQWO++QB_5[6*
M"R> O2\[]\(IZL^^<)+:.ZE]3?-0B[I)^%T^5G'A?>K?=N%%ZL^^\ &T=R:%
MOO_1AX.H.]AVQ<O8(H>3C5CQQGR#U
MQ LOHV5G=#VX<G15T9=-/C;[7V!L);0[G /?V1^XDHQ)$ S;S%C)'](;?$48

M"C4VYR:XM>EZ;5?I)6=N6+/NB8<9^Q)\0M]HS.15>O>PH6OH&KJ&KJ%KZ!JZ
MAJZA:^ :NH:NH>O_Y0JHJ0Y\75QQQ,5.P 5]W]*Z:)/$PB.ZO-G<*A;IGZYZ
M)56J+/"T,3F$W#HV/-(_]IUA\-QA9*I-TH4]P$= U9M=M5+]]8HC3 .O.87O
MQHV.QN&-CF#P928GO#L4K7A+A,G1HT5V?J),TS2?*0JN!B;_S03&HD>=+Z</
M 49 AY__0C"4H +B7<A6^"'BN70$WFZH5(.*6HPZ?O[W0J?1P>.&N,)">$:7
MYO#O
M>KS08,S!^&?C=8V>EZP1/C8U<A _;F <?<D<Y%U3P<GXJX;"/ML .TP-B?&8


M($0/&1K3;(/4"HU&%I2G,CE88J'/((D,R>Q!B6R#O4$7L6 9BB0;WJ5QAJ 5
M10.[3+Q?FI+]*.G;9>$=,45G4'1NEX7WJB[2 FD4G;3P$N9#Z[\-DJ,VO U"
MI!8O:P9FCA)LMPD7D]#U\L A'&6UKK'7IC%#UV"'4:-!:* %V/7Q?!)*C;G!
MU3?!L#O)5A3Y^?FQAD6]*-J&MJ)$X:=-2=H#DJTTF,!K-T00Z( -;+N-O\E"
M^H&-O=X&\\A8W67#H0:;0_5CA4.90U<XE!%Y/E8XE!?LG60ZE*' NTVSDY,-

ML-4"\G^T/UAM9<J*8N%^%MTO" F%75F2518+[Q&NBH;/TO#C3 ?;W.! &5F0
M)0MR3)%G/"X9'$B \2++MB(;V <&/[ >GY!L8 =,4>L$$&7:3+!_,"6]*$FU
M67 14U1V(XAZVBR\-383SEE U=83"';<!E9NBA04';2!N2V[4=1NX5T>8X8'

M;Z4I68V2:AO>?%/4BJ(J&]XTRSX455AXHW2)(YA&R2P;WH4;2$39(Q:"CG:*

MT27\9P0I69!XOFF<3&"[=%F-I/KD>"!;GHPEPY_"^<5NP)7C'X;3Q77&/S3N
M6N/?>8WQ&]V$=0/Y(ME\U>71E*1;J(V^IH4UV=P:5[PFHP8R?CY2A,08`9['

M1 \R$NUWD<A/L;B&_8T>DM]V7?DTX?_UY+9X?_?R=>.]=NRUXMTE7QUO&][E
MKZ^+5W=-O*>N 1=-R03VI $VP!\"M; WK=8,J+ZR> ` !M3J6?&:;/\(F*3H




M'!1JT_]NT_^K4P;EGQKRWUZ^IMQ\_O0UY3Z2??J5D1JPOE3?$K\Z3U'X\Z.N
MGG]2;Q?J<"BFDN^\U'UC,MJ;,RB;+?T60_^V/TY_B:'O^N/T2PW]7XWY)GTC
M?S__TO+8Y>.?&%VL*^H]D)L8!Z=?*UX&=0&R/-HTP)K ]2\-LZ#UCRE/(J/P
MQ60UC!--.C#OKIF_C<-5KPL<+Z!00J\&-H%2O9>O!HK\?*SHH5YP+[Y6U4 ^
M/K% ; <!V1_<^;(^A?DZLZ;(%]R&3*A4_/<NP?0.KB:ZOT4"%)__.:E*D, "

M^H[5>/!^LLP)HB87V^Q+>+,*V= OZS:X^L<DH!Z1L2F32=KCT C^--/''"<&

M[U ;U [SG1Q>H['O4XL':%_>"WN(;7_Q!<_ F;R1*JJQI__-2-W_+&X[D#S\
MUI'"S& WA1D,7TP<>+D$E> 1F/4)Q)"4X!F:G:S"IX_49Q<VO.E^VL \/E[]
M!2U;)7B<9 >*M5/7NW*O-NR#Y


M3RMNI7DJ$6M55-4/1Y!]B37=JP;EF[[^WA(*^OK;;?9P_6TW>UXW^&9IED"^
MZ3U8J1X_7S="SVI8J56[]7B%1XCIP)4Z:[<>V-4Z$U?JM-UZ%._3F3",M=#O
M,!XOL2WT2<;C'MM"=QF/2U?,IT>8 H]=E/1I&A"6(/XG!B]M&7+*X/5:J?"N
MP>NS4N$5 \<M*_Y6\/3:D-)K`^Q^&R61\PEOG\+7&IV:7A]?;G2PA"PRU084

MC$\8O-X$'DK:AQM)G CT^/D>HYM.>,\I?+O1[2./_LKHV +S_>%68 :E.^;_


M"O&_R,,S3&OC!/R6R:>X]3AN[?)NPY,6'/MJMD7?<\1KMJF!;96!K1LGJMYM
MB46Q'3[NSA,3K 9:_7R*, -JN+>5[ !\OA0*N\+3PTCOZO,QGT/R,]>53R;Y
M_NO)X?V"*F0FVI1QA"2XYX3&]]\.FP2\Y:M>>'F[E^G^9 4;3 &PX%7)ARN<

MQ+N\&8R[V'M=5 3Y1\.-D:--6;:Y$"LD;_S".+< LZFNN2E+.^!WQ0Z8:/O*

M^51/EX >!.CLE_X$RM<Z=0]OMI]:R;^=8!B?"?)XK &.I%VQ(-SW_HS)7;%U
M0#D/([4>J'KBA4S>)J 6$6\S4!)1$: ._A-2+4!M(FH+4&5$;04J>P"I5J".
M$K4-J"U$[0!J`5$[ <JT(]4&U'&B=IOC[L4GB+</J"JB]IO2=AR->!U ];Z-
MU$& ]A&5!*J!J*- N8DZ#M2YMY ZB<A$G4%;B#IG
M[6\BQ8&*$)4RI6F 0L0;`*J>J Q0U41E 2HABL'T=.]'R G4%J(DH"J(< %5
M2I0,5,\;2!4!M8\H-U"KB2H!JH H#U!.HDJ!:G\=J6E M1 U':A91.%?*DJ(


M[]VV 'H[W-3L//X:-FUMU.Q>0LU>1LV^]A]CLU_(VH/4ZYA%S<&^O= DMU%S
MM)Z:XRYJ3AY]%9LS$6K.S:&F>^ 5;'IV4].[C)H^%S7\X!YL4B%JTM.H&>C9
MC8=A7(U03F!/M-[ G=8;O ?V9RQTB_6#N$J+6.%UHI+UGQ8,K!;:U JHBMK4
M]71?1_< W>OIOH3N"MT7T;V:[ OH7D7W.71WT7T6W<OH/IWNT^A>2G</W4OH
M[J9[$=Y#I?AUDT'K-G[<2;:Z.SN&/<UD_E0-8\VILES&:M45KJ5J6*J+KTEK


MUJ188V4M:.1HQ3L!9GDLN3QTNW8`'ZS5#B

M[,':`>QJQ158_C-:84N,_F2I&[<PS]89GF\:/0->1M6,&D-8]=(MA+%40"FZ



M<A%_?O=]H-T_%8\%#DW
M%^"AZ($3G>=[(,< `9W\#A 49U=297 A/*[=T-GQ)YB*J>] *D[/ 2E:6 ?.
M4AY*Y1\+P^(3XRNR_&:G,6'J[1 X-%?[.4Y;[!/ZK.6:JA5*;"[^$:^PY30S
MYZL)#ANWT

MH=$B8_+!:TB&.8Y^2:=RPC.:#R$0>G(]W%;$S<?D6:DO";X\UUP>_$8X<-5I

MH!RX;10\*R\'6H(,\$N"6W(EUR6X9V\`0#Q]80J#T7
M_.*R'"C(:A=_C3YWR"LZRT]T[,6CJ5RYI-0)X4I*\^9.>Y;)&_ZW`P\*G:KS

M`)8) #V
MEB=%I\H9J: /YT<V.>K#SD;',A(L`L&\"M4W1R>K5-\"G:Q6?8LZ.]#QSH[I


M_";&B^%1F%/8MLJTXFH8Z00.6Z=^SB.0O( HQ[3X81D00W(=;G':':+B8JW-
MBY16,*P\1R0H(_ ,GI+4^E)7]!5\ L4^#I5 ,2RFK4K-X*-5^(V3\%;U#P,`

MR_Q_4.W82O2 8R$6N>$+L<A-RR'01 +K`?\Q*A&IYB4":=QJ_3[MP!DL4_P9
MVJYEL? 444'X;X".-$FTHX9&ZBNV7,*O?CVZ83Z;8:D(0!K&I?1Z*O/O0!.M
MR6JZ&967::V"N?IB/:'/"AH$IP-IJ1&X2.5D-5,8^PC+ZWQ'XV3%VK,+6]X!

M#A>H-46P)N*.\]M1^I4C/$U=452K*'6XSM\P' X]<RQO<G0*O"MF<5K//X>U
M,5R4F*]%NRXK>/* 55=5I_ F\XD_3U0[X*'*?]U8E'"5P;B5G<?F.29OG!9Y
M,(?U3\8#GZ

M9QW"%Q 6+FT<):":!0-' 'I,NF_/QYT[V;\*]G>5LA$,CI2601!D"+/0,I>%
MPI_4\"Q29"&I:1/K$<2"2CY&G!40H8Z/%C[;BS?XLA%]F3_?\ 6RPHU9 76W
MB&(Q"SW/E%^LO%S8TH5;7U N;#D,1&534>$/#V


M*,C*BRBC0  T<R]B"4T+&,-MRNW;VW[7RMVMS=VM77M==C,7PH V5^W-I;5M
MK=RZ[%AA&6*2\W^><^Z\ ,CV_?W^O\_O\_E]NG6YYY[SG.<\YYSG/&_GW/$,
M=^DB,F#F?M<,T%W27H_4)P56FJ+QO)OIR$3P`V0 UH5&X D<">/-.!+VV=1D
M.5OL]:*3[&DY*63AON,]9,59]^&D>KU/?N7WOR78!3L6I?&/(2 N8'=&*6=U
MMX(PS_3:I%WR]C?8.>ZS2UBY^VPI*\WR?9[%#W8QH.AC+$O8F992-JHK6Y+M
M^R)[T2$VG>_MFM,Y:ZDMESOCTQ0)ZT&PM(-MI>J*ZI1VV21+;<&'+\:?)JC%
M\LA^:>E2F\X/AKRG922F_6GHE.Z-KBC^_(1V<B0YOB]R^(>0='Y 4;]'-I?O
MP!</*Y'15%N51,[0I+275]["9MW"7G4+9W-G)''9T*LDSMQ5%.'^MI15N;]=

M3$<9S* .)G6$CJ6P!FH:7]V#Y+2,--G!CJ5D]/.Y\N7LXN5<(I\WPA\Q'XYI
M1^.P[=^*Y<8[Y-R71A/K\QB\LN4\P>.QW.V+\!BPJ7X%;QTQ=R!*Y_.Z4>-+

MT&#B3GI)),4.JO-9S"!BF<_;=S>ICNSGN4_D&^1#TM/7,X$/J: FF':.B:(Z
MC"5!6'=99Q5[\S[HM'[ G[<>*-Q_' RR(N'/6-M>!"7^>55N/(3Y 3>OQTZ=
MK6J2T5.]_AX,=_TW *+1T"6!^;\$^&!. :! ",]P4C ST-HHXL$^*Q(U`?!N
M%/(N>V7;6$337$B:N%E=M BH+H?J,EU/.58J[T-E7,RGNZ%2;2D?90<W<8B/

MC&802XFH>F(>A-LREP=L&:\LJ_=XA%W8FW%QB^;N;3)220YF2RG"B;2"H?%'
M(BEM,O. :XVYMVENL=V?"O-V%X/V&U?ON]I\MJEV<EO+``<_5(*=T?;X[)3J
M2\12?VJA8*:D>Q;XD #I3>:S6Z_O\+/SO+*[$ )H]*?:A<LH$/1T$+R9$D*Y
MIU6V5U)!;!,P!$&>B<T6D78/IJ-4+P$Y>#TM956!1L$F+1(.I%.,,'L"FTX$

MP.LF-N!*F7FP:8;1)MLZUSRX]7)(-*7PA_GS_"G?)_P</MH3XXGRW4['82[V
MS^[-D=L%/:4'RJ/ W1/MRZ< * I"(G9V88X(E2/6AII8+(Q::'Z " 4GB(^)
M1?DRJ.59*8.9KB 7C1G>J :EI2IJ4S/%8 M&NLT,%_F*ZA58SBVQ'7XN\L]*

MGMHCT?7 ?)7UD1 ,#KU"C+\0UZ#M9!RH:K3^3] %Z"?4&8-J\HXWV$2P$LSG
M71'\&=W;':--5[7U1G0MFW>B,_M\?[;?U"\I=5=*F)O;>F7FH\Y/^0'H'_4U


MM7;&1>?XB6UTI;,+:0&K!^1#HIM$H.3\B'^>`.FN%?'R6LF9H2M[XH_+*A<-
MKGWG^+7]Y; :SPSU\;UMZV5,VWHY,\ 8T#L9D.
M3N',HL>9CFZQQR;GYD)."*YM$ZP/F[P<00D!%%P.D $/)I2K^ ](<*UER_NZ

M]5=4:2^1BC'((C0=%GMZ) 1P`*TGDBQAYXAYWQB11T8*B_E7AXC5!"[5+6CV


M!)XY-=F'H"[KH-O L NRW4:&^];<ZU)U%?A1X2M X;/1R,K T6&0\X.0<T7(

MQ&"$U8^V&'\(YL5C4PBOHO&X)H[/BP6'BU-Y;& I*CWYL>CFVU2>HKB!*#MP
MH=W?I!"NG(EJ^C2.(M$<0;T;AQPES(/TZ+)XN81%W4BHH^IE0((HAA.1`E$&
M$#F0-C,H!T270&4^XP+3%86*/.31]OMN1.<+Y41A,!=$ W+1&>D_BVJ90N%,
M&I5W`^LJRLMHS.1 &NHQ')VV'FG\. D$ 'L%*Y!5=,TUK8Y7<)(LL"'IF*-9

M`+:D;4P"KI4G;^R/>%2?4W7D*= ;T)Y;V#T':[R%LF\L IN%>7/0.O2=`$=P
MQQ\ ?_]Z$+S>EI&?E\+SJ2?Y% 6?<M"-QX_&KSW;6?9U9]E(9]GYSK)QT*76
M[VHC,.[C/TK-^I][K:=JI>$Y]X-&O=)K'0<X<L[BO%TLB6F_'1UXZPC DY+O
M0B7%R XIW>C;^=E+,1A!,!*_ML-$JX5GW8 &:0^1=SB.16T]<G&M871'IAOU
MJ0;0 F"JE?NA;XT "Q90O4OA <X;O8UC8*$MH $AI< Z`[)XK.&+K%;!0]B-

MU<P^R/U3(E0K`<:O'H$Q%WXKOL96'\?778D84%67E.B.%186UDJJ#T*N)]8_
M;QR-WQ0+\?3,Y\#VYB+\1R%1-LY=X3]JKWX&:Y<CLOUXE+)D> >TJ^L9M2Y0
MLI'X*R/R0CN(6*(\:^<!-<7 YF*<;LS3(OB/ I RGR-[!9?;J^]%7)<07+,(
MKD04:N *%A9B6%OXL82&M%5>+XEPVL 0NO9S<.Z^1O.6FU?=C C>6H0(2#P6
MI1RJ;QH1];]T DAIP&20H.C%3.$SHJ)C11!BZ/(C/-E^K%T"0M>KB/)852!O




M071B<B^ V[O$%,V652N!`XL'K HT(?WSXLD8HUE"+;DS'^)"FS]J\\\;(^N)

MM*TEE %3*X5X)4L*_4=K2S$H>!35]1 87V- $>+!J&L,OBAXY' ,O%417.^B
MXHD+4SP:7&S7:D.*)Q[]% P JU#Q ,X!!,#Y1-
M JI C=P$_RN%O 6BRE%.4CFQ1.6H BHGNDC K:Z28( 69I1,MTU)<8*DD:++
M95,$4H>$_Q[U^V'N> ED1=LI?_05KN'KP%GHLDHL)B[2:XWPK:DM76<H8[A;
M37U<#IU=R"ZTTPEEKROV-DL*87IANODA,G0=QRI8.2"-,O>YJ%<W:PV=$.GK
M,(Y]O C^]?*R=:)2:OM(TOX&*ZU5K\7WMH\BX"U"H>R#GD5EU2K7<I'=Z(#T
M=:_$L1W0P-BV.49(^%\,_GFM2B[*V[$=C9\\L/]/S(*\/*50IL#M'\P65BG(
M2,),A#B?QHXIHZ#S.%+$1Z/:(U&TM""/ ,"]FH_V+M,`P^$OXJ K/">0<35,
M;XF-K(%PM[BCIVEN%P" %RRS+.$BB0>,DKF["CL1H2%A(PP"%Y/84,>3&.OU
MYL4*C^ 6"!%*(BI8B<"1\Y!#O5X$RRK #P.++!J4'BJP%Q>%?)"4FU!J)7J]

MG^1I!5-(Z2U7"?-G,$P6_Z9=N$X H344T87"2U1^>G;$HS7 C&$8SXX$2!:C
M5/,^CN):2#Y/[ BH6XT;Q;CS>-L,'((ZG+(W^0,>A]Q.-F3GSIR8C5[*N$PX

MD'<, 8L&H%%V_DUA!^*SQL*H>'8L(^DXSXY<2 Q$=>( A.]<PF(;D.PB&R:P
MYC*D86LN*4GTHF5,]]]Q0&],PI5?O0(P">FD<-"31P+ZX%C,!R40C+"*<\:2

MRXB*NT="-E#XJY


M^1JW8' Q>*QR<?$4"4\0K:UH[^%D;0XY&10N?<*.,)OT/5IL5HC[K;Z;B_SO

MTY.X!2"JJ6)8K$^?]/M)8+;MO&SK%<7"UM"[=.N,MO,1,3MP/\2[+..\7?C)
M.5(8T]Z&639HDNK#F
M^A,ZU5FJ\0<*XMST4,(,F$PUI%^0A&%3B-B6(+:N/A_NBA8'ZY"H5Z >"5>]
M059.WR=D*ZRO>\UV8%[_34$=2=><OTD&XAS6*",</XVJ+%\><L:]]^'J%>Z%
M/][[R$I_)A*3* 6$)I*[+((L[PCAFQGXJD>Y4X--$FF$LHJH.2$/I&$)V0_+

MJ>%_&85?04S[0\BC1[P=[;C-3PBU"QGPU],R[MV/7;#SAX4RD)%=0UXO`HT>
MN_(8<L[Y/N'W`-=^C'6![ =I6_TB&NA77(,D5*$X/.AQC!0+,P`(G%&L0ALM

MD$ P"FN[X(4>>_<3`<L?ACG!^+RP![\Q('X^ G8-"0PA-Z9C+X,Q;!SC5V[<
M3PP-4/GTJP+^L%T8B,;AP4'BW5D2/-LYCK\YZ'\9A[(0R4;?>O^W-(H`1C>U



M!::WYTQ >M'^ 2GVS<( 53B-':GH#I&5LR L0F8=X>+$Q>*0! ""<2[YY/F/
MF&K^%9/GGW9!(38_O ^E+\Q63,?STW/$2Y'?AR.>&9N"(W[Z3R+?RN5L)+A(
MX  =%A["/:!R.9<UD4?>D 2H)RSR[UE3LH8E K)&OI]&K:PCX1S!9V-H>0XZ
MTW;!/0+S7.*[G%^.8S<+!A=];+O<1YD)+ !Z*J(; \4!FUHXCI/7UWT666LV

M.' ^Y$QRZ F,AY_ Z;67XXBV5P0L5N(OJ/A^L1\H?E]3,MU7M0`)76 ]%?"4


MB6>I[.NGO!VY:.WPN80E?O<OF.2.M2 =V_ OWU%*TJ4DO9ZD\6]7!\K;SC8B
M=3NJ23[^Y9<B.TC]6;**<KZO;!UUM&C,.%)X`+\IO0];$K[^`#O6K<,1CXU'
M>:(4-?Y9_AYLS?L$_G4;&"Z&OV<]3<:TWXL+^RY<Q&X`[[H?V_>2X )[H?#U

M//40LN3V J"7(P9"Q%A'K21_K;G?FW]^?L^UO5*"P2[H_HUJ>19MFG\(,Q?U

M3/,]XEL/N(I1D&/P4?=Q"-U'BH._G\SE'_#OHJ
M^/^ LR4:<TEX"F8(/?US_IB.UX ?9UC'Q>&Z]1 (LGNJ A-BIZ-M'[X/V\/]
MIICV6S')D-!\%AJ*6^5%T+E88MZR#GX.W]MV7&E1LC&C]V"KZIB.UZ$-G\5]

MV9DC(TUR#PZ3,T$K0<M K]LVRYCA5S#C?L(^QB0NF<Z%MT!B?HU5N$U)W-7>
M  CS:USLHEY^Q)NC+RJP!V?8796A9VKEPE/7T..7LSRQ`UDHK4 4BLIV'!=/
MCDS0_)T*Q(%)QBM9AL#UJ&S8+'X'#CX:&GQ4,=\<,&?1!V_KEQ<7";]FR%JM


M+QNO*.;?K[67\.= >KR U( [-A/IV1X?"YT$H1^+!\S"3IQY<_P=_JUX0&2.


MI_QV`1C=+TY%7ZG8VPJFD?L&QG<YW8(H%AY ""MEGB Y2?:-X7 />!94(-? 
MUB;=9!BS"^JK&7I.L^UD++]&WO$V&^DV,5SDGY:]"B.-6QS>%CDL&9NLN,"^

MW)\J/ GRO 3W/;MS4=+^; %U*%"U^N<-`;Z!J'TTH$'&;*M"^ )EN4W1MDD)
M:TQ5 MZ_3340M7>BQT_.ZN6^*OK[$V)L&0N"_K[_N ]0VY=BT[J+-DUT:+'7
MAKZ^7:A!?D+M2$CPM$[5MIPJ%24M`M5R.8G9 <V*MA2XXM$ ^50X_224!S;&
M]O,HE _YYR%!Y;ADSGJW*H!O/Y7AXF1C^%12%^9Y%M]/C"8IT<M];=N43)'W
M=B67Q"]7W7UV#A/M9N/:SLYA+R^J90J$*QAQOYN;T\V^BKB[J\B#CZ+1+F61

M]OGN;V>VQKB_G8UG?]2XRY?$1;NO8?A>W[L> /4=HLPKU[UAS%.P<O>)+]T'

MJS&F?3>2">\Q[0\3^:0P]\6T\Y TQ%*/NL N_(:8S0JO=<13-F['C7YAIE_D



M?A^MC)[O,>]^%-V>*/ZPIUPFG'T'!N=Q8DD]3FRHQU$+=3Y>1=+$5HJNZ(P5

M0<PQJ\JS ^+G#P
MA%5P2=N OJU77UQ =QV OV5[);X(;0\Y2434 *JXB&R"DI &/];F][-Y?&F\

M!:ZWF&J=ML-^HEG)"+L-2=QE7;D8`Y_E/IN$Q[HCF-"Q;IAM(MUYN6<.+^^:
M`;Z"3 M2OFMUO-+T%B?S1_D97NXV,K"XY::Y["79'KEOA)^C>]LL+X]YZ+6N

M&P]&*?%T(#EA2\ZFT$4"PJW#SVX'F\W?--=MD3-L9)9YP/F->0#W37C
M`<I^K-"[4L*7RQ;UF7M="[TR,SV]\Q% **&;I'[?+#YOW,,IO(UC'DFQ=YE.
M3J3E/) _DE89J NB?S1R$O)?1U?*B['(_'C"%D4FNEN<I(_/&L<.%!*/0*?S

M<XQY<F>TM-]HE3==ACNF!>*OQH&=F0&R>]P76TQ.).\>0Z.;'Q%.CQ'YX-$1
M55]&)#F>NR*;_;AQ4&(>*8&QZ;=CEE+83. 5Y60;! 3]9<"M,-M-2C*8,[/,




M0_]2'G1Z K#W7V1/PMN:Z '1V:+P7"U\.DJ,65 19 _A;^153HX"Q_7G*,Q[
M-.CU>G*47ANZMKB-(%3 (8\RK!!56'W QRA-#V)P4I04,1VKB;.K%#RCR#I6
ML%*0IFAA&XAF&.<[=,>,94HB_F-JQQ!PKA(P9LE*P-Q0NK?+_4NXM>8W"<#L
MVK$"X:N84+&G3.Y=)O?;"[Q &+^'.U8M<D "?KEP!0:8BG%7ZTI(&<LP-YJ=
MC1QX)Y("0OL8H/ SL1+>Y"+XP[!PO&ODJPH+"^Q"Z<?D]+<W3^4I4]6J[<(B
M$)9&TL\9(6)50E48-12+=XTB:Q44 </5)!-4(I[\X!:&2GAV#EDWYG-4Z14+

M*[8!TNHFC-4=%FQRE++<57PT>N&PU/D8,ISLK-HEM1(`^$J!7W=0( J%-U6(
MI!")&#XWQ6

M%\R2"A5R$HJ6B=E>ECC6*\ZBK\Y5>#N.?!O*Y8$5(U%B(V/:A=C3A.%47O _
M3[![K=#X2;*?)=P?%9C,2#K


MVU  :[=)/ `C R+TG _(QH(B%/WD\Y?A")$0SK.X<9"?*)AP/R$_CLPAA ]Y

M]K9F8:0X!P\*>'>=Q^!J*$1)"%/-H-%B;X=]G,90&S"LD:\2][\[WN B_X +
M'X.G!<)VAN ID*& %:/)'H"O%%;%6MZ68+:IV5N)D(!>\8=);'80\MMZY#QZ

M% P*>.],U/6X,Y> :L$OWHX6>ZRG_4?Q<QI^A+T2CXJ0^!!(GD&O;,&BWK:>
M12!=?9$>D ']",9"< QC!J>EO>2'4A3=^%NNUPZ"WKL"?R8%" 9KEX"P4Q+'

M.9%O'9&>EPY TU"-?"_(2?%+OF*Z;>9=FHA)].VA 6+I0'4/N 2>5M1=0B6)

M%'Q^K,>6Z+4U>VP:KV7,/.!IU;/7F/_BD;/SO=LD;N,2;K:G&=QON=FF9R,\
MANP<\U\X 6\9\;:A71< %EI7B"<P!O#HB11,^:5 J8%?"HK6PB\%%9O%+X7&
MEO%+ 7-R^:5 X0I^:9S'MII?JO;8[$1\`E=_A5R='1/.U<5_IAL0^,GM_3"N
MP-' T"^0[0RY<,G[9(<$&9_P_;JP[9%5IR_*]%='$:8WAIB>_+K(Q9C^GN\"


MR46<KUX07>.SY:'=ADN&`KL-BHOL-F"4( IZT=&S?18DT$,X! "!#RGI_C*8
M!*>ZH L+.Z.$IQBR*^ IE_,5,J '%HS9?(Z]S L6T2'0)N/$YK;B&&7Z/J63

MY!*6OTO&GRT4$ `20V?\B,>%!KU'0YR :!2NR^)C_3GRDA*/IH($R&H5 G0V
M: =B%</8#GKDD):+Z5P9_; 3+& DS";CY_ +`"**SY=!(8]"#Z7RIL]A!(N$
M>Q6D"95_I;RDPA,++< 9X:\ PS%XF-77'7T7<+-+(?JF>$(8%0=XI+\^B5M.
M8#P2]U/X;_(*QJ/*O4G!E.S1E*#M2

M'T9#U+-C+6K3Y3AK 1E;0W\%3?>V9\VX1^ZQRSP[2>6=I/).4GDGJ;P3*V,5
M>L ^<OB9"#QF%8]#LAY_9>VD`FD\Q>_ JE[2.MVTV&&7B)L6[TEPUP\W+?!4


MYHT(!CR#WG(2<7YRBEK-(\*UF&D="4;2O/GR`O_+. )V6#X:H1SW1<<PON./

MJ3^B7= JQT.*(\218%>,1BNY&:-D`M6^)*]-#YEJ
MA)*K1,9'??WL<#DVDB

MT,^2^SOMB9T[-83GLB3!+XJ)F4<LO<8(_/<'Y$QW!G(=?DQ= *?,,4*$!M8H
M.QO/2VH$'2YG4%IYIT,&%OF\(U_&Q0*8BH_J")UB+!(>Q$,1Y6((2XSICV!4



MI]HR&&ZV.+Y+`;>/+::$8D;T_X^T'OX\G-:*(*F7!TD-IY1^YZ JQA^D*:+D
M^>>=)O&U#C^;04)KX 5%C5J5:E\LB:PE,C2RAGERGPS^*KEY&%"CBXA[LYC.


M\>UBU*S^GU,S>G)*:EHCIZ2&&.PJ\F& 2CB'H=BR6 "+!T,]9&-?#KIOD54M
M[;/[N7'AM(0A'ZN!3/%[ETKLPD_^BO8S/]![7%H;X^%.>ZRQ0 OD2:VQ7E:S
MK4 X=BC,P/X=Z>AI[_;SS6"06D_K>CRV:H^MSF-K]-A81$ .RHOG">1>V=72
MP]2T]N2O]]BJNF+<9TMKD\"9R+VVM].FX <6`74M:BF&BV(!W.ZQ >D:-+=5
MU-R>R^>IB;D-A5:5M-<W%U+XF1Z^B$9W7BPX+M3HYEMCT>Y62="VR%\K?=/\
MFJ=([\DO9:\UMZ \!C;.NU+BSBP%&SPW9(/+<[*AE/N,;TD`O9Y7"R[T6+%=



MB5X/_<9 <5&ACNQ]SNII4>7PJ^.59X;._+UMB/% G =>H2PN4!8;*HN#LMA9
M/=#V"C 1`5;W]IE38 6!F0G/=WS9D,:2U?$JS'O+]];[;_W[K:%9Q[C34#YR
MIBH^#GQ8L

M]LIM^;Y"0K"*IUU63")X$ B._0G\48G4*H':.4"MHDF^"'H_'T8#G IX*E=N
M"Q!>L2Y(=^!RG\URS7.?5;NB8IYZ[9WC??P1T.\?7?W.QR#D=&_W'2Q(QW]I



M,Z:VZS '-#J(<"JPR.^1T,_F\-=%9K2E(W[&=WW;>0D>FHW %O[<0!N9`8SI
M/P()!22$>7X,U!*"\_%]]&% X_,2CU7!89PCK=A>*)PZC]^9D+.WW/4(A ?0

MZN<H ^W()56>ZS#MJ8M7


MAS!?P/SOSHOY^%L&PY^\ %7Q9PZ&G3T8*_W ?UT=$-_=> _ OA6 Q<]+A__P


M(]*;%SO\(68^BID*DHEXGC],O)BV7M6P[WF2O+L73TH._^5OXAN>7QP^-(1O





MZ\0\) !W=R_ZNL,G]B):+/GT'.WH?7\-SLN+[XG)V.%?!Y)QPYN_P*2BK5<V
M_%^!W,3AMB_%9-;PHA'*EMQ[^)0/;R%/U; #J1C"MO"7=W MQ'U!=B>&;5\&
M-AZ&OR!)W)\8_H0D<5-B^/ZO*(J%V*#U1-MQ"?JU*-J03]\#Z[>O._=>P*P^


M-V-FC8 W[^1PYKO8U9'A-"S<C84KOJ5]DF.W.DYA;*ZO^PB6:+\-RKV77 'P



MW'5PN^'>"?<S<+\,=S/ R^$^#NF3<(_"?1[N2R O#N[KX=; G0MWG=B6XK_H


M7XI///9R<R#S"'TDB:^7`?NJ_L0H\=LN!IXH54;^R"AQ8^<X/"^!YQ%XX ^!
MO A/)3P?A"?^]N)Z>.*7]_'PG(WUNADE?I-]`)[X/?63\,3? &R')WYE50U/

M?6$^] &_DNN&\E=S+BR7MS/*Y%N!Q )&J2X$F-L8I;V=MA%^R\%*^5T9HSRZ
MCE%V0ODU\)R_CN)?"V5YFQAE2BVCO.\VB -/5^Z&_&*H&_L*VKOTPF,( ;3P
MXU ^7A C8]HFYF%=N9AG +1$S _'HX'RR;CPPCG-G80/<:P5\V+W38W//0V^

M?9'VJR?E#T

ML.&X3VRC,%]NHV/S+3S#RW$,\ L9A(D5\:!2Q[''W_TR)$%?H3V$R=U!<55/

M,#CY
MYS1TN$4Z>'$<'[XC-"Z#T

MI/3_!)XX%T^(SZ?AB6OJI;#V
M\ZKME+Y%\,2Y,FZG=.9LIW Q?7P:O.NWTW5XF_ATB<]6\>D)PY/0=7$\NT7X

M\5_*0O5&)I7C^<S!']$\'.\Q:&.H*[26'UE'G[%\B(ZU_,7IR JCUST-W.HP
MN#W3P


MT\!_(,)_%M:O1Z>!'P_#VS
M,+CJ:>":P^!V3 .W$^ T.T-Y]>B#W
M!_]O.^2UA^4E 6^Z'O+BP_(>!O^6<3-37C_XR/_W?.3/&.>&BBK'IIIZ1T5E

M%60V5'%0]46"RUK/;7&(N)["FAM7;JAU;&1A%,+P;*RK=+DJN/HJAY.Y!.LY




M<35M=+*+G=R&;<F&I*JZ.J:(65[/.ISU#G9I78/+D5M97P6=_5$HMZ&^'A!F

M-J/&&IAEJW&ZQ+SBY?G+\ZVK"2UMDN6NI=65SC6-C0XGM+BFT+I*IR5%S/,1
MKD88&'83LYNI`$9P.%GF=Y(*5[V8JV0R,W59)=EK[=EKLW[$,+T1,)#U&QNW
M,7_ U,9JZ/URIJ)B:7.SS5FY1>RHDXF!>EJH!]668STYO&L<S1L=C< X65D%
MV=:L[)N+-%E0N!\QU3GJ&2:;042KJYT-6ZT!6(;IPW+2U",16QQ;L''F`0EP
M!(P,3 CSDX MXKR41VQR.F .?XIP./7,ZUC7A6NGAU*^I9&Y/:+&55G76%W)



M$%/O=+3\K[9 NJ"690)/U6RNS_K?)30[NRA9FV6_>1GAIC%I9L7JFJIM_WMH
ML[.M:RORL\39M*=JR'3Z(^J0L;<TUF0SLR4Y#KJ 0/S6;.!8APO6CUQ:1QD6
MTBQ"%#F
MTL6*TN3VB,()[Y<1*D"TV2O9ZGQ89-DH 2!OF;.FR;$:F MD`,&!<UA91[)=




M/O&VI&<P-:XU^6B$U+A6U-3?AL^ `P;I58[*JI7U=>!_N&KN<" ><)[90K:2

M=8.3&&)B.>95!2BR5SI9,&[ &R<FWZ0RMCK\'=,BD,M1"=[4*D<=M-[DH( T
M+]371EJ=L=:SI"X'GF&]2%-U`SCV<('764BJ(6UUE9O1SH)ZZ*(&VFAH`$BV

M>D0:"QT8+F'13";O.&[A>4Z P$7'<>MJ9^5&1WI8&O*765=G+U]16+$B>[5U
M%;XO7V5=NGKEJI(*>_:JU85,_LH*V\H5*U865ZQ8GG]K(0.E:U85+B^R`NSJ
M$KLU+[OP5H; *5J^U%K(4* 0GN609UN^PHIYD ,MV2HFMQG,G]1V('\*&DA^

M3;W:DJYVU)-W8GM78% D:2.^9XE,DA5 $LP+8Q3*!^I-E< 352;U=2Y2AS)]

M$IP5QN19(I,'V FP>K 9+*<X`[4"S5%\].U_1,Q-<.&8;'4VU&]6UW-;-CB<

MU0Z8'5C2:AK0"N(B<F]*7. ,HMQRN-1;JQU0WQE"<H,+.U0-E=4H-4.X4';^
M#W$ADDIU'0K=$)Z //J?X D7>V'X`O)[`KK_C _D=-7B!B+W`W50_JNGN!:3

M3-M$?"$TE:1&.)[).NL_XJ$5$$401[B.4X==%\5!*A 401P7OURP[-10"86$

M")^HK]63K\43ILO1S#KJ24 BO![JJ>GKA;7N:,;H/J[C(+(;F8ET3,8U+3ZZ
M6W!1?!>_`KA"RRM0,M$F"=58K*ZL!P'FK-P6&%5<:TTU55QE'0 /A*7Y8>T'
M[!GUI(OV!^445IRPO *2*$&<_2"N"?;0!;B"I>I%:J) +HHYG!^KII1*%^+\

M+6K 3<1WH6R?/'ZN1L=&(D\">,*,Q4"=QHG3. G7)JZN[D("`^._%'>^3&IK
M>-[T%]G3<G(;J6T9R T8`).A*0W!TE!WP$K"DG!L 3IH5DS&$\)%2O\SL E]



MF+[ <9 2/UDSI/3[\I<XN!?!%2B='ML%E2^\IH0/3?)$8-HV>GY3"A-*0K /
MH:T=TX0YFWJ4%HOYP).5=:QH*&YP5%<VU31PSHFL,'D=3C52B\-9)P"2X$C:
MG*1>>%.2<X/9Q=:Y&C:Q-R55+YRHHZ?N_91]GT15`):LH6E72 !V:6#XP5(P
MD;S ^ ESWQDQUQ'.:]-<FT%#U!/IO(0ZAIB)QJTZ 8CL=2(=93<&:I %"+9S

MV+7PIH6DS37YR]<FXHR)[Z+"I?H[/&YQ`8:04,$>+:RLJUL8JA 0,X0AF OJ


MW6<,K"X2[5BRB .9OJ6RL1&F+3!&$V(GWP\/.,(;G)5A-M TEXMK; 37Q5$5
M&,L)\:7)T(O550ZVL ::J'2"L'>P&ZM!)H*]!K(LH1[$QD9Z[J2.MCTI)G4!


M*7H9CB?4WXM 0;"PF-Q4.,+B"/^9'A++NQ!+`!>NB?] #Y'_E?4LE8O9'% 4

M;HE++,?OF/+(*3"3FL39$H-K(3DI+2DY26LD<F8-&'CJC97U&QUU=> ,A!1F

M".A?H+.QH1X6 1I/_CA #F
MDKAW#E



MXMA"HGR!=SRLAVTMI_4F! +%^'(UH*UO", Y2%;!9)P0OTE+RLPN"CONQ02W


M<WB[I#QDX05A,I,RX88_S,1QGSG5N$.FC7 I$MG0Z* /8WGH:QTW,ZR<!O^ 
M"5PN8H71<M+NXH#O0_V/L$ Z&4]<<;"6 ^\T/ ^7^![XWO3"_ 4\P&#W+ (7
M'(> R, 'SIE8ZZ+C>]$Z)I 44RG#X'>H>.8J$'2N%PD/IZ/!51%B3=$OF(K>

M' DW!98 ,S'RJG;0TVO0/_5TXS[UT)!A",[FQ/IAQRF9'ZX?KBDOX)8]$H9)
MU&1K&C5W:#HU#VD>T_Q&LT_3J_FGYE^:\QII<ESRPF1S<G;RCY(KDN],OCOY
ML>1?)O\Y^4#R\>1/DR.T<NTUVNNUF5JKMEQ;I6W1_EC[N/9);8^V7_NQ]C.M

MCNO^I?M&]ZV.T<?H+]=?I5^D3]8;]9GZ/'VAOE1?I[]=OU5_C_Y>_4_T/]?_
M2O^,?K_^ /ZH_IC^<_W7^HB4F2G*E 4I\2F+4])3;D[)35F;4I:R(<69LC6E
M)>7^E(=2GDYY)F5_RH&4HRD?I'R1\G5*1.K,U)C4JU*O35V4FIZZ-+4P=6UJ
M>6I]JBNU.;4K=6?J[M2G4G^;^DIJ3^KKJ>^E_CWU>.I(ZC>IYU)GIUV2MC#M
MAK3%:>EI-Z?EIJU-*TO;D.9,VYK6DN9->R#MT;0]:<^F/9_V6MI VE_3_I'V
M<9J0-I;V75J$X1+#Y8
MI/E)RP'+"4M\Q ,93V?LR_ LXUQ&3":C9I JF">)9HYF 28%9FN#ID/SK&9,
MHTA6)^])?CG9HBW0;M+>J=VI?4H[H#VF_1+&_G(8^6[=01C7T[IE^G[]W_3_
MTB]+O255FJ9,NSJM*^W!M,>!UN?3]J7UIQU)^WO:B;0O -(( \)PF4%MN,F 

M-,8;DXP&X\W&%<8BXWICK9$UMAH[C0\8=QE_9=QK_)/Q /&0<<CXL?&D<=3(


M;-YE_H5YC_EWYA?-?S+WF/O-!\UOFX?,'YH9RS66I985EE66GUJ>M\2DKTN_

M-\:F6%*6IZQ+J4[Y5<J)%'WJFM3/4C/2+,8/C9\8OS%&F>:8LDR<:5;ZY>FS

M8W5K=76Z1W2/P[KHAUG[3/>=3J&?+ZZ"$KU7_Y3^4_V-*3]*V9/R<<I(RFS 

M.!?HNLR<:,XWOV+^V*RR&"V9EELMZRPUEF9+8GI'NC0C+B,APPY4-V=T92 R
MYV<^GLG8&09_3[Q $Y.\45N J]7]5O>V[G-=(JS*BI2HU'FI*U++4AMAG9B 


MJ>3SR;.T\[0+M(NT%FV)MEE[K_8:W0VZQ;KW=$Q*9DHMC,0GJ05IZ],.I7V;
M5F/8:5AL-!FM1KNQR?B9\90QU=1G2C7+TG>D7Y[1EW$VHPFMLT:&Z6;P^W.O
MYJAF5O+5R8G)_<GMVE= AIW5WJ/[):R:GI2_I%QAN,9P`ZS=3$..88WA1X8*

MRC&5`G?_S+3;=-#TD2G.G&RVFQWF`^9CYA%SD>4ARWN6;RT+TO7IR]/+TF]/

M^=WD#Y)/))],/IT\GBS3*K0J;9PV7JO7&F"LLK3+M+G:%5J[=K5VK;94NUY;
MIVW4LC""V[5N;;NV$T9RI_9!X,-=VMT P?=HG]'NU;ZH[=;N`VD^J#VH/:)]

MIE?I8_5JO4&_`N3W>GTUR/!V_8/Z1_6[]=WZ(WI!?U(_HI>EJ%)B4]0I!EA5
MJU.J8%4UIG2F[ )IO3>E)V405MC)E-,IRM2XU/A43:HA=75J*4CH]M1[4Q]-
M?3%U7^I Z F0S(HT55I"FA[D\6J0R%5I=6G-L!)VI3V9MC?M8-J[:<?3QM/D

M?!"DUY/&9V V]QD'C2= =ITVCAME)J4IT:0'R;7,M +D%FO:;NHT/0F2JMOT
M+O#ZB&G<I 1N5YOC8;7IS5GF4G,U\/Q.\S/F;O.[YN/F<;/,HK"H+'&6>$NB
M16^Q6)99[)8Z"VO9;FFWW&MYT+++L <TP1'+2<MIR[A%EJY(5Z6KTRWIR]+M
MZ77I;+H[?5?ZGO0#Z0?3A])/IS-DY2Z#M5L
MT9AZ3+%F SG6D 4K?M R8MF9?B3]`JO A^N'ZX?KA^N'ZX?KA^O_X2O_YF2T
M#IC]G2N6XC_4F6LJQ4^#ZVHVN$I)C*E4C/^6BIMUKE+<NJ-E28U5&YC_#U!+
M`0(4`!0````(`+,R332T9/]9\ ```%<!```)``````````$`( "V 0````!S
M96%R8V N<F)02P$"% `4````" `O<)HS7]?R<>E;``!"T ``" ``````````
G`"$`)($9`0``<F5C;',N<V]02P4&``````(`` !M````*%T`````
`
end



 Feb 12 2006



 next sibling parent  "Matthew" <matthew hat.stlsoft.dot.org>  writes:


Had to split the post, as attachments combined exceeded NG limit. Latest
whereis.exe can be obtained from
http://synesis.com.au/downloads/recls/whereis.zip



 Feb 12 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dsod98$2o63$1 digitaldaemon.com...

 Go wild


Thanks. Let's have some fun with the analysis! Here's your version:
-------------------------------------------------
import std.file;
import std.stdio;
import std.string;

int main()
{
 char[]  PATTERNS = 
"*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc";
// char[]  ROOT  = "H:/dev";
 char[]  ROOT  = "H:/";
// char[]  ROOT  = "H:/freelibs/openrj/current";
 char[][] filters  = split(PATTERNS, ";");
 int   n   = 0;

 foreach(char[] pattern; filters)
 {
//  writefln("pattern: %s", pattern);

  char[][] fs = listdir(ROOT, pattern);

  foreach(char[] fe; fs)
  {
//   writefln("File: %s", fe);
   ++n;
  }
 }

 printf("Number: %d\n", n);

 return 0;
}
--------------------------------------------------
There are 13 patterns searched for, so 13 trips through listdir. Taking your 
numbers, the D version takes roughly 6 times longer to run than the Ruby 
one. I adapted it slightly to my system so I could run it, and set it up for 
8 patterns:
--------------------------------------------------
import std.file;
import std.stdio;
import std.string;

int main()
{
    char[]   PATTERNS = "*.h;*.hpp;*.bak;*.d;*.vbs;*.c;*.cpp;*.exe";
    char[]   ROOT     = r"c:\cbx";
    char[][] filters  = split(PATTERNS, ";");
    int n             = 0;

    foreach(char[] pattern; filters)
    {
//      writefln("pattern: %s", pattern);

        char[][] fs = listdir(ROOT, pattern);

        foreach(char[] fe; fs)
        {
//          writefln("File: %s", fe);
            ++n;
        }
    }

    printf("Number: %d\n", n);

    return 0;
}
--------------------------------------------------
As I think I said previously, the listdir one used in D just does the 
(primitive) fnmatch to do the pattern match, which is intended to behave 
like the operating system wildcard matching behavior. It does not support 
"OR" patterns. But we can write our own to use regular expressions, as in:
---------------------------------------------------
import std.file;
import std.stdio;
import std.string;

int main()
{
    char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
    char[] ROOT = r"c:\cbx";
    int    n    = 0;

//  writefln("pattern: %s", pattern);

    char[][] fs = listdir(ROOT, pattern);

    foreach(char[] fe; fs)
    {
//      writefln("File: %s", fe);
        ++n;
    }

    printf("Number: %d\n", n);

    return 0;
}

import std.regexp;

char[][] listdir(char[] pathname, char[] pattern)
{   char[][] result;
    auto r = new RegExp(pattern);

    bool callback(DirEntry* de)
    {
        if (de.isdir)
            std.file.listdir(de.name, &callback);
        else
        {   if (r.test(de.name))
                result ~= de.name;
        }
        return true; // continue
    }

    std.file.listdir(pathname, &callback);
    return result;
}
----------------------------------------------------
There's only one trip through listdir(). What are the numbers?

Matthew's: 2.67
Walter's: 0.36

Interestingly, that shows a 7.4 times speedup, but 8 patterns. This implies 
that the D version might be perhaps twice as fast as the Ruby one on your 
system. (I don't have Ruby on my system.) This post is long enough, I'll 
provide more design commentary in another post. 



 Feb 12 2006



 next sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsogst$2u8b$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dsod98$2o63$1 digitaldaemon.com...

 Go wild


 Thanks. Let's have some fun with the analysis! Here's your version:
 -------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
  char[]  PATTERNS =
 "*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc";
 // char[]  ROOT  = "H:/dev";
  char[]  ROOT  = "H:/";
 // char[]  ROOT  = "H:/freelibs/openrj/current";
  char[][] filters  = split(PATTERNS, ";");
  int   n   = 0;

  foreach(char[] pattern; filters)
  {
 //  writefln("pattern: %s", pattern);

   char[][] fs = listdir(ROOT, pattern);

   foreach(char[] fe; fs)
   {
 //   writefln("File: %s", fe);
    ++n;
   }
  }

  printf("Number: %d\n", n);

  return 0;
 }
 --------------------------------------------------
 There are 13 patterns searched for, so 13 trips through listdir. Taking


your

 numbers, the D version takes roughly 6 times longer to run than the Ruby
 one. I adapted it slightly to my system so I could run it, and set it up


for

 8 patterns:
 --------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
     char[]   PATTERNS = "*.h;*.hpp;*.bak;*.d;*.vbs;*.c;*.cpp;*.exe";
     char[]   ROOT     = r"c:\cbx";
     char[][] filters  = split(PATTERNS, ";");
     int n             = 0;

     foreach(char[] pattern; filters)
     {
 //      writefln("pattern: %s", pattern);

         char[][] fs = listdir(ROOT, pattern);

         foreach(char[] fe; fs)
         {
 //          writefln("File: %s", fe);
             ++n;
         }
     }

     printf("Number: %d\n", n);

     return 0;
 }
 --------------------------------------------------
 As I think I said previously, the listdir one used in D just does the
 (primitive) fnmatch to do the pattern match, which is intended to behave
 like the operating system wildcard matching behavior. It does not support
 "OR" patterns. But we can write our own to use regular expressions, as in:
 ---------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
     char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
     char[] ROOT = r"c:\cbx";
     int    n    = 0;

 //  writefln("pattern: %s", pattern);

     char[][] fs = listdir(ROOT, pattern);

     foreach(char[] fe; fs)
     {
 //      writefln("File: %s", fe);
         ++n;
     }

     printf("Number: %d\n", n);

     return 0;
 }

 import std.regexp;

 char[][] listdir(char[] pathname, char[] pattern)
 {   char[][] result;
     auto r = new RegExp(pattern);

     bool callback(DirEntry* de)
     {
         if (de.isdir)
             std.file.listdir(de.name, &callback);
         else
         {   if (r.test(de.name))
                 result ~= de.name;
         }
         return true; // continue
     }

     std.file.listdir(pathname, &callback);
     return result;
 }
 ----------------------------------------------------
 There's only one trip through listdir(). What are the numbers?

 Matthew's: 2.67
 Walter's: 0.36

 Interestingly, that shows a 7.4 times speedup, but 8 patterns. This


implies

 that the D version might be perhaps twice as fast as the Ruby one on your
 system. (I don't have Ruby on my system.) This post is long enough, I'll
 provide more design commentary in another post.


LOL! So you've shown that you can rewrite what is essentially your own -
please don't call it Matther's code; I wouldn't write something like that in
a blue fit - code faster than you did previously after someone points out
that it was not done well in the first place? Well, I guess we'll have to
take some comfort in that.

But questions abound: How many matching files are under c:\cbx? What is
2.67? What is 0.36? How were these times taken? Why have you changed the
number of patterns? Hey, why not just use 1? What do you think you've
proved/demonstrated by a test of some D against some other D? Why haven't
you installed Ruby and done a comparison? Where is the comparison of the
memory hit? Why offer conjecture ("perhaps twice as fast as the Ruby one")
when I spent a lot of time and effort producing cold hard facts?

Aside: I have little doubt that you will find a way to convince yourself
that listdir() is perfectly good enough and that you can code-tweak its
_design flaws_ into irrelevance, and that std.recls is therefore not worth
it. But I wonder why you spend all this effort to convince yourself/the NG
of something that is false, when just a portion of all that effort could
have just been spent in upgrading std.recls? I have to suspect something
more is at work? Is it that it is C/C++? Is it the download size? What?
Really, I'm keen to know, as then I can stop working hard to present facts,
and be content to shut up in the knowledge that no facts will be adequate.


Matthew

P.S. I recall a certain debate about openrj, in which you ended up having to
convince me that I could not legitimately claim performance supremacy of the
C version because I am an experienced (I think you said "expert") C
programmer, and that writing efficient code is something that's largely
unconscious. I look forward to your logical leaps in this case.



 Feb 12 2006



 next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


Forgive me, but from reading the samples in this argument, I see:

Matthew says the standard library should do as much of the task as 
conceivably possible, within reasonable bounds.  He says D's Phobos does 
not do this.

Walter says that the standard library should be simple, and support 
normal options with the option of adding code on the user-side for 
complex tasks.

Anyway, if I were to take a very large array, and run through it 8 times 
- each time pulling out just 1/16th of the array (half of what I want), 
I would clearly be a moron.  If, on the other hand, I went through it 
once and pulled out the 8/16ths (half) of the array all in one blow, it 
would seem I regained my senses.

This is not rocket science, and I fail to see why it was necessary to 
develop a testcase to show this.  Or why anyone might be surprised that 
doing it the better way would take a small fraction of the time. 
Obviously, really.

But, yes, the question is in the implementation.  And from my 
description above, if it is so correct... this is more of a 
philosophical question than one about performance.

This just seems like an awful amount of commotion for the relatively 
uncommon task of building a full-tree list of all files matching some 
extensions.  I can count the number of programs I'd consider useful that 
do that on one hand (and grep, which does not do this, is the first 
one.)  What a great measure of a library's design!

I wonder which better supports VESA.  That used to be big, didn't it?

-[Unknown]



 Feb 12 2006



  parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dsokf0$3d$1 digitaldaemon.com...

 Forgive me, but from reading the samples in this argument, I see:

 Matthew says the standard library should do as much of the task as 
 conceivably possible, within reasonable bounds.  He says D's Phobos does 
 not do this.


I don't think that's an accurate representation of my position. In many 
cases I like a minimalist approach.

The point here is that the underlying operations are I/O bound, so any 
decent library needs to minimise the amount of I/O. (And avoid non-linear 
user-mode behaviour as well, of course.)


 Walter says that the standard library should be simple, and support normal 
 options with the option of adding code on the user-side for complex tasks.


Great. In which case listdir() shouldn't be recursive. There's a good reason 
why no operating systems provide such recursive facilities, as the 
designer(s) of listdir() have failed to recognise. (Note: UNIX does have 
glob(), which is effectively what listdir() is trying to be, and that has 
the same caveats, but that's not a system call, and it's got a different, 
and generally more limited, kind of recursion.)


 Anyway, if I were to take a very large array, and run through it 8 times - 
 each time pulling out just 1/16th of the array (half of what I want), I 
 would clearly be a moron.  If, on the other hand, I went through it once 
 and pulled out the 8/16ths (half) of the array all in one blow, it would 
 seem I regained my senses.

 This is not rocket science, and I fail to see why it was necessary to 
 develop a testcase to show this.  Or why anyone might be surprised that 
 doing it the better way would take a small fraction of the time. 
 Obviously, really.


True, but there's another flaw in the design. By combining recursion and en 
bloc results it can lead to huge latencies and memory consumption, suffering 
from non-linear behaviour. (Perhaps I didn't stress that aspect enough in my 
previous rants. The two aspects are not commensurate, and if listdir() is 
preserved then it needs to stop being recursive.)


 But, yes, the question is in the implementation.  And from my description 
 above, if it is so correct... this is more of a philosophical question 
 than one about performance.


Well, the question is in the design. If that tallies with your point, then 
ok. If not, then I disagree.


 This just seems like an awful amount of commotion for the relatively 
 uncommon task of building a full-tree list of all files matching some 
 extensions.  I can count the number of programs I'd consider useful that 
 do that on one hand (and grep, which does not do this, is the first one.) 
 What a great measure of a library's design!


It's horses for courses, surely? I do such things many many times a day. You 
do it rarely. Both are valid. A standard library needs general facilities, 
and all of those facilities should be well designed and implemented.

My point is that this case is but one example of bad design in the Phobos 
libraries. Yet Walter will refuse to acknowledge this until our bones are 
dry and dusty. And there's a library already in Phobos that does such things 
well. Yet Walter refuses to update it.

I cannot fathom either. To me, the three words "I am wrong" are perhaps the 
three most useful in the lexicon. So very liberating. So engendering of 
mutual respect, since if you admit your flaws to me, I can admit mine to 
you, and we each have much smaller and more manageable facades to project.

Broadly, I want to know why Phobos appears little more than a fetid stagnant 
heap. Nobody likes it. I'm sure contributors would like to be able to 
revise/remove/rework their contributions. (apart from std.recls, I'd like to 
junk / rewrite all mine.) But Walter neither appears to do much about it, 
nor will he cede its control to people who might be more expert in library 
design and/or have more time to work on it. (I am not meaning me, here, in 
case anyone thinks this is a sideways auto-backslap.)


 I wonder which better supports VESA.  That used to be big, didn't it?


No idea. It impacts not one whit on my programming life.



 Feb 12 2006



 next sibling parent reply "Regan Heath" <regan netwin.co.nz>  writes:


I have a simple question, for Matthew largely.

Lets assume the latest version of recls is packaged with the latest  
version of the D compiler.

I download the latest D compiler, extract all the files and am at the  
stage where I can write a D program and compile with "dmd <file>" at  
command prompt.

I want to write a program which uses recls, what further steps do I have  
to take in order to do so?

I ask because I just tried to use the one which is currently part of the D  
compiler distribution and failed to get anything working, missing symbols.  
I suspect I need to build a recls library. I found some makefiles but I  
failed to get those to compile even after modifying them to find the DMC  
tools dmc, lib, link, etc as opposed to the microsoft ones I have install  
with VC6.0. FYI the error reported a duplicate symbol in my Microsoft  
headers. I wonder if it is including the wrong files or if I have old  
files.

Either way, that is not the point of this post, rather, I simply want to  
know what a user has to do in an ideal situation in order to use the  
latest recls with D. I suspect the C library is a requirement that is not  
going to vanish in the future?

If so, I would prefer not to have that requirement. In other words I would  
prefer the solution to be a native D/phobos one that does not rely on  
external libraries.

I am not making an argument _for_ "listdir" in it's current form. I am  
making an argument for a solution that does not use an external library,  
unless (there is always one of these) that solution has a clear advantage  
that the "non-external lib" solution cannot match.

Of course if I am wrong about the external library requirement, lemme know  
and we'll ignore this point :)

Regan

On Mon, 13 Feb 2006 11:55:41 +1100, Matthew <nowhere noaddress.co.us>  
wrote:

 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message
 news:dsokf0$3d$1 digitaldaemon.com...

 Forgive me, but from reading the samples in this argument, I see:

 Matthew says the standard library should do as much of the task as
 conceivably possible, within reasonable bounds.  He says D's Phobos does
 not do this.


 I don't think that's an accurate representation of my position. In many
 cases I like a minimalist approach.

 The point here is that the underlying operations are I/O bound, so any
 decent library needs to minimise the amount of I/O. (And avoid non-linear
 user-mode behaviour as well, of course.)


 Walter says that the standard library should be simple, and support  
 normal
 options with the option of adding code on the user-side for complex  
 tasks.


 Great. In which case listdir() shouldn't be recursive. There's a good  
 reason
 why no operating systems provide such recursive facilities, as the
 designer(s) of listdir() have failed to recognise. (Note: UNIX does have
 glob(), which is effectively what listdir() is trying to be, and that has
 the same caveats, but that's not a system call, and it's got a different,
 and generally more limited, kind of recursion.)


 Anyway, if I were to take a very large array, and run through it 8  
 times -
 each time pulling out just 1/16th of the array (half of what I want), I
 would clearly be a moron.  If, on the other hand, I went through it once
 and pulled out the 8/16ths (half) of the array all in one blow, it would
 seem I regained my senses.

 This is not rocket science, and I fail to see why it was necessary to
 develop a testcase to show this.  Or why anyone might be surprised that
 doing it the better way would take a small fraction of the time.
 Obviously, really.


 True, but there's another flaw in the design. By combining recursion and  
 en
 bloc results it can lead to huge latencies and memory consumption,  
 suffering
 from non-linear behaviour. (Perhaps I didn't stress that aspect enough  
 in my
 previous rants. The two aspects are not commensurate, and if listdir() is
 preserved then it needs to stop being recursive.)


 But, yes, the question is in the implementation.  And from my  
 description
 above, if it is so correct... this is more of a philosophical question
 than one about performance.


 Well, the question is in the design. If that tallies with your point,  
 then
 ok. If not, then I disagree.


 This just seems like an awful amount of commotion for the relatively
 uncommon task of building a full-tree list of all files matching some
 extensions.  I can count the number of programs I'd consider useful that
 do that on one hand (and grep, which does not do this, is the first  
 one.)
 What a great measure of a library's design!


 It's horses for courses, surely? I do such things many many times a day.  
 You
 do it rarely. Both are valid. A standard library needs general  
 facilities,
 and all of those facilities should be well designed and implemented.

 My point is that this case is but one example of bad design in the Phobos
 libraries. Yet Walter will refuse to acknowledge this until our bones are
 dry and dusty. And there's a library already in Phobos that does such  
 things
 well. Yet Walter refuses to update it.

 I cannot fathom either. To me, the three words "I am wrong" are perhaps  
 the
 three most useful in the lexicon. So very liberating. So engendering of
 mutual respect, since if you admit your flaws to me, I can admit mine to
 you, and we each have much smaller and more manageable facades to  
 project.

 Broadly, I want to know why Phobos appears little more than a fetid  
 stagnant
 heap. Nobody likes it. I'm sure contributors would like to be able to
 revise/remove/rework their contributions. (apart from std.recls, I'd  
 like to
 junk / rewrite all mine.) But Walter neither appears to do much about it,
 nor will he cede its control to people who might be more expert in  
 library
 design and/or have more time to work on it. (I am not meaning me, here,  
 in
 case anyone thinks this is a sideways auto-backslap.)


 I wonder which better supports VESA.  That used to be big, didn't it?


 No idea. It impacts not one whit on my programming life.





 Feb 12 2006



 next sibling parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Regan Heath" <regan netwin.co.nz> wrote in message 
news:ops4v0euuc23k2f5 nrage.netwin.co.nz...

I have a simple question, for Matthew largely.

 Lets assume the latest version of recls is packaged with the latest 
 version of the D compiler.

 I download the latest D compiler, extract all the files and am at the 
 stage where I can write a D program and compile with "dmd <file>" at 
 command prompt.

 I want to write a program which uses recls, what further steps do I have 
 to take in order to do so?


AFAIK there are no a priori reasons why std.recls would not be as seamlessly 
integrated as std.zlib. IIRC, that was exactly how it started out.

I can't recall why the stagnation meant it stopped being like that. I do 
recall some issues with STLport, but they were solved. (They probably 
haven't been folded in to what's in Phobos, of course.)

One thing: I implemented a special part of it for D which does a kind of 
"delay-load" thing with WININET.DLL, so no user is required to actually link 
to anything other than the standard DMD libs in order to use the recursive 
FTP searching functionality. (<playful>... can listdir search FTP sites ... 
</playful>)


 I ask because I just tried to use the one which is currently part of the D 
 compiler distribution and failed to get anything working, missing symbols. 
 I suspect I need to build a recls library. I found some makefiles but I 
 failed to get those to compile even after modifying them to find the DMC 
 tools dmc, lib, link, etc as opposed to the microsoft ones I have install 
 with VC6.0. FYI the error reported a duplicate symbol in my Microsoft 
 headers. I wonder if it is including the wrong files or if I have old 
 files.

 Either way, that is not the point of this post, rather, I simply want to 
 know what a user has to do in an ideal situation in order to use the 
 latest recls with D. I suspect the C library is a requirement that is not 
 going to vanish in the future?


Do you mean the latest that is in Phobos, or the real latest version of 
recls (1.7.2 from http://recls.org/)?


 If so, I would prefer not to have that requirement. In other words I would 
 prefer the solution to be a native D/phobos one that does not rely on 
 external libraries.


Well, since it's still std.recls, I think that's a pretty reasonable 
requirement. ;-)


 I am not making an argument _for_ "listdir" in it's current form. I am 
 making an argument for a solution that does not use an external library, 
 unless (there is always one of these) that solution has a clear advantage 
 that the "non-external lib" solution cannot match.

 Of course if I am wrong about the external library requirement, lemme know 
 and we'll ignore this point :)


IMO. It depends. There are arguments both for and against the external C 
library approach. Obviously, these include a balance between the 
inconvenience to the producer(s) of D against the advantage of having the 
library. There're also ancillary reasons. For example, the Open-RJ library 
has advanced beyond the capabilities of std.openrj. Since std.openrj is pure 
D, integrating the new capabilities is a lot more effort than will be the 
case with updating std.recls, which is pretty much a no-brainer.

HTH

Matthew


 Regan

 On Mon, 13 Feb 2006 11:55:41 +1100, Matthew <nowhere noaddress.co.us> 
 wrote:

 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message
 news:dsokf0$3d$1 digitaldaemon.com...

 Forgive me, but from reading the samples in this argument, I see:

 Matthew says the standard library should do as much of the task as
 conceivably possible, within reasonable bounds.  He says D's Phobos does
 not do this.


 I don't think that's an accurate representation of my position. In many
 cases I like a minimalist approach.

 The point here is that the underlying operations are I/O bound, so any
 decent library needs to minimise the amount of I/O. (And avoid non-linear
 user-mode behaviour as well, of course.)


 Walter says that the standard library should be simple, and support 
 normal
 options with the option of adding code on the user-side for complex 
 tasks.


 Great. In which case listdir() shouldn't be recursive. There's a good 
 reason
 why no operating systems provide such recursive facilities, as the
 designer(s) of listdir() have failed to recognise. (Note: UNIX does have
 glob(), which is effectively what listdir() is trying to be, and that has
 the same caveats, but that's not a system call, and it's got a different,
 and generally more limited, kind of recursion.)


 Anyway, if I were to take a very large array, and run through it 8 
 times -
 ach time pulling out just 1/16th of the array (half of what I want), I
 would clearly be a moron.  If, on the other hand, I went through it once
 and pulled out the 8/16ths (half) of the array all in one blow, it would
 seem I regained my senses.

 This is not rocket science, and I fail to see why it was necessary to
 develop a testcase to show this.  Or why anyone might be surprised that
 doing it the better way would take a small fraction of the time.
 Obviously, really.


 True, but there's another flaw in the design. By combining recursion and 
 en
 bloc results it can lead to huge latencies and memory consumption, 
 suffering
 from non-linear behaviour. (Perhaps I didn't stress that aspect enough 
 in my
 previous rants. The two aspects are not commensurate, and if listdir() is
 preserved then it needs to stop being recursive.)


 But, yes, the question is in the implementation.  And from my 
 description
 above, if it is so correct... this is more of a philosophical question
 than one about performance.


 Well, the question is in the design. If that tallies with your point, 
 then
 ok. If not, then I disagree.


 This just seems like an awful amount of commotion for the relatively
 uncommon task of building a full-tree list of all files matching some
 extensions.  I can count the number of programs I'd consider useful that
 do that on one hand (and grep, which does not do this, is the first 
 one.)
 What a great measure of a library's design!


 It's horses for courses, surely? I do such things many many times a day. 
 You
 do it rarely. Both are valid. A standard library needs general 
 facilities,
 and all of those facilities should be well designed and implemented.

 My point is that this case is but one example of bad design in the Phobos
 libraries. Yet Walter will refuse to acknowledge this until our bones are
 dry and dusty. And there's a library already in Phobos that does such 
 things
 well. Yet Walter refuses to update it.

 I cannot fathom either. To me, the three words "I am wrong" are perhaps 
 the
 three most useful in the lexicon. So very liberating. So engendering of
 mutual respect, since if you admit your flaws to me, I can admit mine to
 you, and we each have much smaller and more manageable facades to 
 project.

 Broadly, I want to know why Phobos appears little more than a fetid 
 stagnant
 heap. Nobody likes it. I'm sure contributors would like to be able to
 revise/remove/rework their contributions. (apart from std.recls, I'd 
 like to
 junk / rewrite all mine.) But Walter neither appears to do much about it,
 nor will he cede its control to people who might be more expert in 
 library
 design and/or have more time to work on it. (I am not meaning me, here, 
 in
 case anyone thinks this is a sideways auto-backslap.)


 I wonder which better supports VESA.  That used to be big, didn't it?


 No idea. It impacts not one whit on my programming life.


 





 Feb 12 2006



 next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


Since nothing else in Phobos can do anything with them, I should hope 
not.  The last thing I would want is a lopsided library.

Of course, I have the opinion that basic FTP support should, indeed, be 
in the library, along-side some basic HTTP support, but it doesn't seem 
like that's an opinion enjoyed by many other than me.

-[Unknown]



 (<playful>... can listdir search FTP sites ... 
 </playful>)





 Feb 12 2006



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


On Sun, 12 Feb 2006 18:03:03 -0800, Unknown W. Brackets  
<unknown simplemachines.org> wrote:

 Of course, I have the opinion that basic FTP support should, indeed, be  
 in the library, along-side some basic HTTP support, but it doesn't seem  
 like that's an opinion enjoyed by many other than me.


I think it should be too. But I think there remains some basics that need  
to be done and done properly first.

Regan



 Feb 12 2006



prev sibling  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Mon, 13 Feb 2006 12:35:06 +1100, Matthew <nowhere noaddress.co.us>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:ops4v0euuc23k2f5 nrage.netwin.co.nz...

 AFAIK there are no a priori reasons why std.recls would not be as  
 seamlessly integrated as std.zlib. IIRC, that was exactly how it started  
 out.


How is std.zlib seamlessly integrated? Is the .lib file prebuilt or  
something like that?


 Either way, that is not the point of this post, rather, I simply want to
 know what a user has to do in an ideal situation in order to use the
 latest recls with D. I suspect the C library is a requirement that is  
 not
 going to vanish in the future?


 Do you mean the latest that is in Phobos, or the real latest version of
 recls (1.7.2 from http://recls.org/)?


The real latest 1.7.2.


 If so, I would prefer not to have that requirement. In other words I  
 would
 prefer the solution to be a native D/phobos one that does not rely on
 external libraries.


 Well, since it's still std.recls, I think that's a pretty reasonable
 requirement. ;-)


So.. the real latest recls (1.7.2) requires a C/C++ library to be built  
and linked for use with D?


 I am not making an argument _for_ "listdir" in it's current form. I am
 making an argument for a solution that does not use an external library,
 unless (there is always one of these) that solution has a clear  
 advantage
 that the "non-external lib" solution cannot match.

 Of course if I am wrong about the external library requirement, lemme  
 know and we'll ignore this point :)


 IMO. It depends. There are arguments both for and against the external C
 library approach. Obviously, these include a balance between the
 inconvenience to the producer(s) of D against the advantage of having the
 library. There're also ancillary reasons. For example, the Open-RJ  
 library
 has advanced beyond the capabilities of std.openrj. Since std.openrj is  
 pure
 D, integrating the new capabilities is a lot more effort than will be the
 case with updating std.recls, which is pretty much a no-brainer.


All valid points. It is, as you say a balance of pro's and con's. One more  
to think about:

[external library]
con: little/no power over changes, some of which may not be to our liking.

I agree we want to leverage existing C libraries but I believe the  
eventual goal should be an implementation in D where possible.

Regan


 On Mon, 13 Feb 2006 11:55:41 +1100, Matthew <nowhere noaddress.co.us>
 wrote:

 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message
 news:dsokf0$3d$1 digitaldaemon.com...

 Forgive me, but from reading the samples in this argument, I see:

 Matthew says the standard library should do as much of the task as
 conceivably possible, within reasonable bounds.  He says D's Phobos  
 does
 not do this.


 I don't think that's an accurate representation of my position. In many
 cases I like a minimalist approach.

 The point here is that the underlying operations are I/O bound, so any
 decent library needs to minimise the amount of I/O. (And avoid  
 non-linear
 user-mode behaviour as well, of course.)


 Walter says that the standard library should be simple, and support
 normal
 options with the option of adding code on the user-side for complex
 tasks.


 Great. In which case listdir() shouldn't be recursive. There's a good
 reason
 why no operating systems provide such recursive facilities, as the
 designer(s) of listdir() have failed to recognise. (Note: UNIX does  
 have
 glob(), which is effectively what listdir() is trying to be, and that  
 has
 the same caveats, but that's not a system call, and it's got a  
 different,
 and generally more limited, kind of recursion.)


 Anyway, if I were to take a very large array, and run through it 8
 times -
 ach time pulling out just 1/16th of the array (half of what I want), I
 would clearly be a moron.  If, on the other hand, I went through it  
 once
 and pulled out the 8/16ths (half) of the array all in one blow, it  
 would
 seem I regained my senses.

 This is not rocket science, and I fail to see why it was necessary to
 develop a testcase to show this.  Or why anyone might be surprised  
 that
 doing it the better way would take a small fraction of the time.
 Obviously, really.


 True, but there's another flaw in the design. By combining recursion  
 and
 en
 bloc results it can lead to huge latencies and memory consumption,
 suffering
 from non-linear behaviour. (Perhaps I didn't stress that aspect enough
 in my
 previous rants. The two aspects are not commensurate, and if listdir()  
 is
 preserved then it needs to stop being recursive.)


 But, yes, the question is in the implementation.  And from my
 description
 above, if it is so correct... this is more of a philosophical question
 than one about performance.


 Well, the question is in the design. If that tallies with your point,
 then
 ok. If not, then I disagree.


 This just seems like an awful amount of commotion for the relatively
 uncommon task of building a full-tree list of all files matching some
 extensions.  I can count the number of programs I'd consider useful  
 that
 do that on one hand (and grep, which does not do this, is the first
 one.)
 What a great measure of a library's design!


 It's horses for courses, surely? I do such things many many times a  
 day.
 You
 do it rarely. Both are valid. A standard library needs general
 facilities,
 and all of those facilities should be well designed and implemented.

 My point is that this case is but one example of bad design in the  
 Phobos
 libraries. Yet Walter will refuse to acknowledge this until our bones  
 are
 dry and dusty. And there's a library already in Phobos that does such
 things
 well. Yet Walter refuses to update it.

 I cannot fathom either. To me, the three words "I am wrong" are perhaps
 the
 three most useful in the lexicon. So very liberating. So engendering of
 mutual respect, since if you admit your flaws to me, I can admit mine  
 to
 you, and we each have much smaller and more manageable facades to
 project.

 Broadly, I want to know why Phobos appears little more than a fetid
 stagnant
 heap. Nobody likes it. I'm sure contributors would like to be able to
 revise/remove/rework their contributions. (apart from std.recls, I'd
 like to
 junk / rewrite all mine.) But Walter neither appears to do much about  
 it,
 nor will he cede its control to people who might be more expert in
 library
 design and/or have more time to work on it. (I am not meaning me, here,
 in
 case anyone thinks this is a sideways auto-backslap.)


 I wonder which better supports VESA.  That used to be big, didn't it?


 No idea. It impacts not one whit on my programming life.









 Feb 12 2006



  parent  "Matthew" <nowhere noaddress.co.us>  writes:


"Regan Heath" <regan netwin.co.nz> wrote in message 
news:ops4v21ohr23k2f5 nrage.netwin.co.nz...

 On Mon, 13 Feb 2006 12:35:06 +1100, Matthew <nowhere noaddress.co.us> 
 wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:ops4v0euuc23k2f5 nrage.netwin.co.nz...

 AFAIK there are no a priori reasons why std.recls would not be as 
 seamlessly integrated as std.zlib. IIRC, that was exactly how it started 
 out.


 How is std.zlib seamlessly integrated? Is the .lib file prebuilt or 
 something like that?


AIUI, the .libs are first built, and then linked into phobos.lib, and 
therefore there's no need to do anything at all.


 Either way, that is not the point of this post, rather, I simply want to
 know what a user has to do in an ideal situation in order to use the
 latest recls with D. I suspect the C library is a requirement that is 
 not
 going to vanish in the future?


 Do you mean the latest that is in Phobos, or the real latest version of
 recls (1.7.2 from http://recls.org/)?


 The real latest 1.7.2.


Not sure. It's been a long while since I gave up trying.

At a guess, I'd say the following:
    - build recls.1.dm.lib. This should be nothing more than defining the 
requisite environment vars, and executing the makefile from build/dm
    - compile std/recls.d
    - compile your D program, and link them together.

If std.recls gets deleted, I would want to make a binary available, so that 
none of this would be necessary. One would just have the source and a 
pre-built lib, probably combining the core recls lib and the D binder.

To their detriment, I've tended not to offer binaries in my libs, purely 
because of the effort involved. I've wagered on other developer's tenacity 
and skill over their impatience and lack of time. (A foolish bet of course, 
since I tend to be dominated by lack of time when tossing up whether to use 
a third-party library.)

If I ever get the time, or ever get an installer expert owing me a favour, 
I'd like to have an installer for recls that installs all the binaries (and 
headers, if any) for COM, Ruby, Python, Java, .NET and D to their 
appropriate places. But time's a factor, of course.


 If so, I would prefer not to have that requirement. In other words I 
 would
 prefer the solution to be a native D/phobos one that does not rely on
 external libraries.


 Well, since it's still std.recls, I think that's a pretty reasonable
 requirement. ;-)


 So.. the real latest recls (1.7.2) requires a C/C++ library to be built 
 and linked for use with D?


If std.recls does not get updated, yes.


 I am not making an argument _for_ "listdir" in it's current form. I am
 making an argument for a solution that does not use an external library,
 unless (there is always one of these) that solution has a clear 
 advantage
 that the "non-external lib" solution cannot match.

 Of course if I am wrong about the external library requirement, lemme 
 know and we'll ignore this point :)


 IMO. It depends. There are arguments both for and against the external C
 library approach. Obviously, these include a balance between the
 inconvenience to the producer(s) of D against the advantage of having the
 library. There're also ancillary reasons. For example, the Open-RJ 
 library
 has advanced beyond the capabilities of std.openrj. Since std.openrj is 
 pure
 D, integrating the new capabilities is a lot more effort than will be the
 case with updating std.recls, which is pretty much a no-brainer.


 All valid points. It is, as you say a balance of pro's and con's. One more 
 to think about:

 [external library]
 con: little/no power over changes, some of which may not be to our liking.


Indeed. But that's what open-source licenses are for, I guess. "Permission 
to modify ..." and all that. ;-)

(Again, I'm a realist. I've altered very few OS libs myself.)


 I agree we want to leverage existing C libraries but I believe the 
 eventual goal should be an implementation in D where possible.


I don't have a problem with that. But equally, I don't believe in Dogma over 
common sense. Cases should be judged on their merits alone.

The current state of std.recls is untennable. Either it needs to be updated 
or deleted. Walter's case for the latter is, imo, pretty parlous, but he 
doesn't think so; certainly not enough to update it, it seems. Hence, I say 
slice it out of there, and let it run free. Just save a care for the poor 
souls who're going to have to wait around for an hour or two in D/-listdir() 
for what takes 10 mins in Ruby. =P

Matthew



 Feb 12 2006



prev sibling  parent reply jcc7 <jcc7_member pathlink.com>  writes:


In article <ops4v0euuc23k2f5 nrage.netwin.co.nz>, Regan Heath says...

I have a simple question, for Matthew largely.

Lets assume the latest version of recls is packaged with the latest  
version of the D compiler.

I download the latest D compiler, extract all the files and am at the  
stage where I can write a D program and compile with "dmd <file>" at  
command prompt.

I want to write a program which uses recls, what further steps do I have  
to take in order to do so?

I ask because I just tried to use the one which is currently part of the D  
compiler distribution and failed to get anything working, missing symbols.  
I suspect I need to build a recls library. I found some makefiles but I  
failed to get those to compile even after modifying them to find the DMC  
tools dmc, lib, link, etc as opposed to the microsoft ones I have install  
with VC6.0. FYI the error reported a duplicate symbol in my Microsoft  
headers. I wonder if it is including the wrong files or if I have old  
files.


It's never been fun for me to build Phobos, so I avoid doing so. ;)

I'm not sure what your problem is, but it could be related to the fact that the
documentation for std.recls (http://www.digitalmars.com/d/phobos/std_recls.html)
doesn't match the actual std.recls included with Phobos. The documentation
provided by Digital Mars is newer (some of the objects have been renamed, and it
includes features that are only available if you download it from MW's website).
And since Walter seems disinclined to update std.recls, it's just a tease for
things that aren't available from Phobos (and may never be available). :(

jcc7



 Feb 13 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"jcc7" <jcc7_member pathlink.com> wrote in message 
news:dsqj2c$2l6q$1 digitaldaemon.com...

 I'm not sure what your problem is, but it could be related to the fact 
 that the
 documentation for std.recls 
 (http://www.digitalmars.com/d/phobos/std_recls.html)
 doesn't match the actual std.recls included with Phobos. The documentation
 provided by Digital Mars is newer (some of the objects have been renamed, 
 and it
 includes features that are only available if you download it from MW's 
 website).
 And since Walter seems disinclined to update std.recls, it's just a tease 
 for
 things that aren't available from Phobos (and may never be available). :(


What features do you need that aren't in Phobos (besides ftp search)? 



 Feb 13 2006



  parent reply jcc7 <jcc7_member pathlink.com>  writes:


In article <dsqpnl$2r23$1 digitaldaemon.com>, Walter Bright says...

"jcc7" <jcc7_member pathlink.com> wrote in message 
news:dsqj2c$2l6q$1 digitaldaemon.com...

 I'm not sure what your problem is, but it could be related to the fact 
 that the
 documentation for std.recls 
 (http://www.digitalmars.com/d/phobos/std_recls.html)
 doesn't match the actual std.recls included with Phobos. The documentation
 provided by Digital Mars is newer (some of the objects have been renamed, 
 and it
 includes features that are only available if you download it from MW's 
 website).
 And since Walter seems disinclined to update std.recls, it's just a tease 
 for
 things that aren't available from Phobos (and may never be available). :(


What features do you need that aren't in Phobos (besides ftp search)? 


I really wanted to use calcDirectorySize a while back. Since I didn't feel like
compiling a new version of std.recls myself, I think I just used
FileSystemObject from VBScript instead. Oh, well. I got the job done.

The point isn't so much that something is missing that I would use every day.
But it's annoying to find the feature you want in the docs and then realize that
the docs are for some cool new version that aren't built into Phobos (and all of
the names of the identifiers have been changed to make it even harder to use the
built-in version). 

Can you just run "dmd recls.d -D" and post that? I'm not saying it's a lot of
effort me to run DDoc, but the online docs shouldn't be falsely advertising some
new version of std.recls that you're never going to even adopt. All of these
mistakes that never get corrected make std.recls (or maybe Phobos itself) seem
to be the abandoned child of the Digital Mars houshold.

jcc7



 Feb 13 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"jcc7" <jcc7_member pathlink.com> wrote in message 
news:dsqssj$2udj$1 digitaldaemon.com...

 I really wanted to use calcDirectorySize a while back. Since I didn't feel 
 like
 compiling a new version of std.recls myself, I think I just used
 FileSystemObject from VBScript instead. Oh, well. I got the job done.


Here's one that'll do the job (it's another illustration of the flexibility 
of the delegate approach <g>):
-------------------------------
import std.file;
import std.stdio;

void main()
{
    char[] root = r"c:\dm";

    ulong n = dirsize(root, true);
    writefln("%s : %d", root, n);
}

ulong dirsize(char[] pathname, bool recurse)
{
    ulong n;

    bool callback(DirEntry* de)
    {
        if (de.isdir)
       {   if (recurse)
              std.file.listdir(de.name, &callback);
       }
        else
        {
             n += de.size;
        }
        return true; // continue
    }

    std.file.listdir(pathname, &callback);
    return n;
}
-----------------------------------------------
One caveat about directory sizes, though, which is why I am a little 
reluctant to put such capability into Phobos. Many people get tripped up by 
assuming that if the directory size on volume A is less than the available 
disk space on volume B, that it will fit. It often won't because of 
different block sizes, and various disk spaces consumed by bookkeeping data.


 The point isn't so much that something is missing that I would use every 
 day.
 But it's annoying to find the feature you want in the docs and then 
 realize that
 the docs are for some cool new version that aren't built into Phobos (and 
 all of
 the names of the identifiers have been changed to make it even harder to 
 use the
 built-in version).


I know. I don't know how the doc for recls got unhinged from the code, but 
it did. I could go back through my email archives and figure it out, but it 
doesn't seem worth the effort.


 Can you just run "dmd recls.d -D" and post that? I'm not saying it's a lot 
 of
 effort me to run DDoc, but the online docs shouldn't be falsely 
 advertising some
 new version of std.recls that you're never going to even adopt. All of 
 these
 mistakes that never get corrected make std.recls (or maybe Phobos itself) 
 seem
 to be the abandoned child of the Digital Mars houshold.


It acquired that status because Matthew and I simply do not agree on just 
about any aspect of it. I don't see much prospect for that changing. 



 Feb 13 2006



 next sibling parent  "Matthew" <nowhere noaddress.co.us>  writes:


 The point isn't so much that something is missing that I would use every 
 day.
 But it's annoying to find the feature you want in the docs and then 
 realize that
 the docs are for some cool new version that aren't built into Phobos (and 
 all of
 the names of the identifiers have been changed to make it even harder to 
 use the
 built-in version).


 I know. I don't know how the doc for recls got unhinged from the code, but 
 it did. I could go back through my email archives and figure it out, but 
 it doesn't seem worth the effort.


We made an agreement to update the docs and code. I supplied both. You 
updated one and not the other.

No-one has been happy with it since.


 Can you just run "dmd recls.d -D" and post that? I'm not saying it's a 
 lot of
 effort me to run DDoc, but the online docs shouldn't be falsely 
 advertising some
 new version of std.recls that you're never going to even adopt. All of 
 these
 mistakes that never get corrected make std.recls (or maybe Phobos itself) 
 seem
 to be the abandoned child of the Digital Mars houshold.


 It acquired that status because Matthew and I simply do not agree on just 
 about any aspect of it. I don't see much prospect for that changing.


Then why don't you remove it?

It's truly a very poor show that you leave it as is. Not to mention the 
message this debacle sends to other contributors.

Having one's hard work disrespected in this way is hardly a great 
encouragement to contribute. A day has passed, and I'm back concentrating on 
things that will benefit my career, so I am able to say the following 
soberly and without gratuitous attempt to cause offence: Given the 
experience with recls (and the way you mangled some of my other 
contributions without checking with me) it's really hard to conceive of my 
contributing again to any library that you have control of.

Whatever anyone might think of recls, or the proportionality of my 
dissatisfaction with the way you've bungled this issue, I would hazard that 
this may engender similar cautions in other potential contributors. How is 
anyone helped by this? What have you achieved by this mess, other than 
demotivating someone who was formerly a stauch advocate for D?



 Feb 13 2006



prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com>  writes:


Walter Bright escribió:

 "jcc7" <jcc7_member pathlink.com> wrote in message 
 news:dsqssj$2udj$1 digitaldaemon.com...

 I really wanted to use calcDirectorySize a while back. Since I didn't feel 
 like
 compiling a new version of std.recls myself, I think I just used
 FileSystemObject from VBScript instead. Oh, well. I got the job done.


 
 Here's one that'll do the job (it's another illustration of the flexibility 
 of the delegate approach <g>):
 -------------------------------
 import std.file;
 import std.stdio;
 
 void main()
 {
     char[] root = r"c:\dm";
 
     ulong n = dirsize(root, true);
     writefln("%s : %d", root, n);
 }
 
 ulong dirsize(char[] pathname, bool recurse)
 {
     ulong n;
 
     bool callback(DirEntry* de)
     {
         if (de.isdir)
        {   if (recurse)
               std.file.listdir(de.name, &callback);
        }
         else
         {
              n += de.size;
         }
         return true; // continue
     }
 
     std.file.listdir(pathname, &callback);
     return n;
 }
 -----------------------------------------------
 
 [snip]
 

 Can you just run "dmd recls.d -D" and post that? I'm not saying it's a lot 
 of
 effort me to run DDoc, but the online docs shouldn't be falsely 
 advertising some
 new version of std.recls that you're never going to even adopt. All of 
 these
 mistakes that never get corrected make std.recls (or maybe Phobos itself) 
 seem
 to be the abandoned child of the Digital Mars houshold.


 
 It acquired that status because Matthew and I simply do not agree on just 
 about any aspect of it. I don't see much prospect for that changing. 
 
 


Walter, after reading so much about this, I just have to ask: if you're so sold 
on the delegate approach (which I think is fine) and if you and Matthew just 
don't agree, why don't you take recls out of Phobos? As it has been been 
mentioned before, the current status not only makes recls (and Matthew) look 
bad, but also Phobos (which means D, Digital Mars, and you), so right now it's
a 
lose-lose situation.

As a personal note, I like recls even in its current form: a couple of weeks
ago 
I wrote a really small program which uses it. I had forgotten about the docs 
issue, so I got compiling errors, so I had to go to the source to check what I 
had wrong, but eventually got the job done. That said, if it's for the good of
D 
(ie, people having a better opinion about it), I'm all for getting rid of 
std.recls, and instead let people know that they can go to recls.org (if I'm
not 
mistaken) and get a really fine library. Result: everybody wins.

-- 
Carlos Santander Bernal



 Feb 13 2006



 next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:dsrdse$eqm$1 digitaldaemon.com...

 Walter, after reading so much about this, I just have to ask: if you're so 
 sold on the delegate approach (which I think is fine) and if you and 
 Matthew just don't agree, why don't you take recls out of Phobos? As it 
 has been been mentioned before, the current status not only makes recls 
 (and Matthew) look bad, but also Phobos (which means D, Digital Mars, and 
 you), so right now it's a lose-lose situation.

 As a personal note, I like recls even in its current form: a couple of 
 weeks ago I wrote a really small program which uses it. I had forgotten 
 about the docs issue, so I got compiling errors, so I had to go to the 
 source to check what I had wrong, but eventually got the job done. That 
 said, if it's for the good of D (ie, people having a better opinion about 
 it), I'm all for getting rid of std.recls, and instead let people know 
 that they can go to recls.org (if I'm not mistaken) and get a really fine 
 library. Result: everybody wins.


I agree, and I've just proposed that to Matthew. Recls needs to be 100% 
under Matthew's control. 



 Feb 13 2006



  parent reply Brad Anderson <brad dsource.dot.org>  writes:


Walter Bright wrote:

 "Carlos Santander" <csantander619 gmail.com> wrote in message 
 news:dsrdse$eqm$1 digitaldaemon.com...

 Walter, after reading so much about this, I just have to ask: if you're so 
 sold on the delegate approach (which I think is fine) and if you and 
 Matthew just don't agree, why don't you take recls out of Phobos? As it 
 has been been mentioned before, the current status not only makes recls 
 (and Matthew) look bad, but also Phobos (which means D, Digital Mars, and 
 you), so right now it's a lose-lose situation.

 As a personal note, I like recls even in its current form: a couple of 
 weeks ago I wrote a really small program which uses it. I had forgotten 
 about the docs issue, so I got compiling errors, so I had to go to the 
 source to check what I had wrong, but eventually got the job done. That 
 said, if it's for the good of D (ie, people having a better opinion about 
 it), I'm all for getting rid of std.recls, and instead let people know 
 that they can go to recls.org (if I'm not mistaken) and get a really fine 
 library. Result: everybody wins.


 
 I agree, and I've just proposed that to Matthew. Recls needs to be 100% 
 under Matthew's control. 


I'd be happy to set up recls at dsource.org

BA



 Feb 13 2006



  parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Brad Anderson" <brad dsource.dot.org> wrote in message 
news:dsreo6$fgh$1 digitaldaemon.com...

 Walter Bright wrote:

 "Carlos Santander" <csantander619 gmail.com> wrote in message 
 news:dsrdse$eqm$1 digitaldaemon.com...

 Walter, after reading so much about this, I just have to ask: if you're 
 so sold on the delegate approach (which I think is fine) and if you and 
 Matthew just don't agree, why don't you take recls out of Phobos? As it 
 has been been mentioned before, the current status not only makes recls 
 (and Matthew) look bad, but also Phobos (which means D, Digital Mars, 
 and you), so right now it's a lose-lose situation.

 As a personal note, I like recls even in its current form: a couple of 
 weeks ago I wrote a really small program which uses it. I had forgotten 
 about the docs issue, so I got compiling errors, so I had to go to the 
 source to check what I had wrong, but eventually got the job done. That 
 said, if it's for the good of D (ie, people having a better opinion 
 about it), I'm all for getting rid of std.recls, and instead let people 
 know that they can go to recls.org (if I'm not mistaken) and get a 
 really fine library. Result: everybody wins.


 I agree, and I've just proposed that to Matthew. Recls needs to be 100% 
 under Matthew's control.


 I'd be happy to set up recls at dsource.org


That'd be great! (It'll have to wait a short while, as I've *got* to finish 
this damn book this week or I'll be singing castrato next week.)

What module name would you suggest? org.recls?



 Feb 13 2006



  parent reply Brad Anderson <brad dsource.dot.org>  writes:


Matthew wrote:

 That'd be great! (It'll have to wait a short while, as I've *got* to finish 
 this damn book this week or I'll be singing castrato next week.)
 
 What module name would you suggest? org.recls?


org.dsource.recls

stlsoft.recls

Or just ask in the (soon to be Recls) forum over there.  As with this 
NG, opinions abound ;)

Will this be a stlsoft project with multiple libs, or recls only?  I'm 
asking, because I'll need a project name and a brief description.

BA



 Feb 14 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Brad Anderson" <brad dsource.dot.org> wrote in message
news:dsss5g$1pql$1 digitaldaemon.com...

 Matthew wrote:

 That'd be great! (It'll have to wait a short while, as I've *got* to




finish

 this damn book this week or I'll be singing castrato next week.)

 What module name would you suggest? org.recls?


 org.dsource.recls

 stlsoft.recls

 Or just ask in the (soon to be Recls) forum over there.  As with this
 NG, opinions abound ;)

 Will this be a stlsoft project with multiple libs, or recls only?  I'm
 asking, because I'll need a project name and a brief description.


Not sure about the module name.

recls is not a sub-project of STLSoft, it just uses STLSoft, in the same way
that the PNG project uses ZLIB, etc.

Similarly for Open-RJ, b64, and some of my other libraries that are not yet
released but that may be if I can get myself a good process for doing so.
One of these, shwild, which Sean and I have worked on together, is a nice
little platform-independent shell compatible wildcard matcher, and I think
that'd be nice to have D-ised.

So, it'd be great to have a good naming scheme that they all can conform to,
if/when they are d-sourced. What do other projects do? Do they all start
with dsource.* ?

As for the project name/description, perhaps "recls/D" - "A D binding of the
recls recursive search library"


Cheers

Matthew



 Feb 15 2006



  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


Brad

Any movement on the recls / dsource thingy? I'm about to get my head above
water, and would like to get this started so Walter can remove it from
Phobos (assuming he's not done so already).

Also, any advice you can give on the other projects / loosely related
projects and their naming would be useful.

Cheers

Matthew

P.S. Should I bug you about this on dsource? If so, where?

P.P.S. No rush. I'm still "not quite there" (which probably translates to
another two weeks at least <g>)


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message
news:dt0io2$26km$1 digitaldaemon.com...

 "Brad Anderson" <brad dsource.dot.org> wrote in message
 news:dsss5g$1pql$1 digitaldaemon.com...

 Matthew wrote:

 That'd be great! (It'll have to wait a short while, as I've *got* to




 finish

 this damn book this week or I'll be singing castrato next week.)

 What module name would you suggest? org.recls?


 org.dsource.recls

 stlsoft.recls

 Or just ask in the (soon to be Recls) forum over there.  As with this
 NG, opinions abound ;)

 Will this be a stlsoft project with multiple libs, or recls only?  I'm
 asking, because I'll need a project name and a brief description.


 Not sure about the module name.

 recls is not a sub-project of STLSoft, it just uses STLSoft, in the same


way

 that the PNG project uses ZLIB, etc.

 Similarly for Open-RJ, b64, and some of my other libraries that are not


yet

 released but that may be if I can get myself a good process for doing so.
 One of these, shwild, which Sean and I have worked on together, is a nice
 little platform-independent shell compatible wildcard matcher, and I think
 that'd be nice to have D-ised.

 So, it'd be great to have a good naming scheme that they all can conform


to,

 if/when they are d-sourced. What do other projects do? Do they all start
 with dsource.* ?

 As for the project name/description, perhaps "recls/D" - "A D binding of


the

 recls recursive search library"





 Feb 27 2006



  parent reply Brad Anderson <brad dsource.dot.org>  writes:


Matthew wrote:

 Brad
 
 Any movement on the recls / dsource thingy? I'm about to get my head above
 water, and would like to get this started so Walter can remove it from
 Phobos (assuming he's not done so already).
 
 Also, any advice you can give on the other projects / loosely related
 projects and their naming would be useful.
 
 Cheers
 
 Matthew
 
 P.S. Should I bug you about this on dsource? If so, where?
 
 P.P.S. No rush. I'm still "not quite there" (which probably translates to
 another two weeks at least <g>)


sent you a mail.

BA



 Feb 28 2006



  parent reply Brad Anderson <brad dsource.dot.org>  writes:


Brad Anderson wrote:

 Matthew wrote:
 

Brad

Any movement on the recls / dsource thingy? I'm about to get my head above
water, and would like to get this started so Walter can remove it from
Phobos (assuming he's not done so already).

Also, any advice you can give on the other projects / loosely related
projects and their naming would be useful.

Cheers

Matthew

P.S. Should I bug you about this on dsource? If so, where?

P.P.S. No rush. I'm still "not quite there" (which probably translates to
another two weeks at least <g>)


 
 
 sent you a mail.
 
 BA


and it bounced.  Where can I reach you?



 Feb 28 2006



  parent  "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Brad Anderson" <brad dsource.dot.org> wrote in message
news:du1roh$1sh0$1 digitaldaemon.com...

 Brad Anderson wrote:

 Matthew wrote:


Brad

Any movement on the recls / dsource thingy? I'm about to get my head






above

water, and would like to get this started so Walter can remove it from
Phobos (assuming he's not done so already).

Also, any advice you can give on the other projects / loosely related
projects and their naming would be useful.

Cheers

Matthew

P.S. Should I bug you about this on dsource? If so, where?

P.P.S. No rush. I'm still "not quite there" (which probably translates






to

another two weeks at least <g>)



 sent you a mail.

 BA


 and it bounced.  Where can I reach you?


Use my first name, and synesis and com and au. ;-)



 Feb 28 2006



prev sibling  parent  John Reimer <terminal.node gmail.com>  writes:


Carlos Santander wrote:


 Walter, after reading so much about this, I just have to ask: if you're 
 so sold on the delegate approach (which I think is fine) and if you and 
 Matthew just don't agree, why don't you take recls out of Phobos? As it 
 has been been mentioned before, the current status not only makes recls 
 (and Matthew) look bad, but also Phobos (which means D, Digital Mars, 
 and you), so right now it's a lose-lose situation.
 
 As a personal note, I like recls even in its current form: a couple of 
 weeks ago I wrote a really small program which uses it. I had forgotten 
 about the docs issue, so I got compiling errors, so I had to go to the 
 source to check what I had wrong, but eventually got the job done. That 
 said, if it's for the good of D (ie, people having a better opinion 
 about it), I'm all for getting rid of std.recls, and instead let people 
 know that they can go to recls.org (if I'm not mistaken) and get a 
 really fine library. Result: everybody wins.
 



Well said, Carlos.  This was a solution I was personally mulling over 
during the last few days as I read over this painful thread... yet I was 
reluctant to make the suggestion...  I'm glad you spoke up.  I 
completely agree that this would be the ultimate solution.

-JJR



 Feb 13 2006



prev sibling  parent  J C Calvarese <technocrat7 gmail.com>  writes:


In article <dsqvfk$1av$1 digitaldaemon.com>, Walter Bright says...

"jcc7" <jcc7_member pathlink.com> wrote in message 
news:dsqssj$2udj$1 digitaldaemon.com...

 I really wanted to use calcDirectorySize a while back. Since I didn't feel 
 like
 compiling a new version of std.recls myself, I think I just used
 FileSystemObject from VBScript instead. Oh, well. I got the job done.


Here's one that'll do the job (it's another illustration of the flexibility 
of the delegate approach <g>):


Thanks. I don't know when I'll want to do something like this again, but I'll
put this in my toolbox so that I might remember it when I need it.


-----------------------------------------------
One caveat about directory sizes, though, which is why I am a little 
reluctant to put such capability into Phobos. Many people get tripped up by 
assuming that if the directory size on volume A is less than the available 
disk space on volume B, that it will fit. It often won't because of 
different block sizes, and various disk spaces consumed by bookkeeping data.


Right. And also there's the confusion due to the hard drive manufactures using
a different definition for megabyte/gigabyte/etc. than the classical definition
(1,000,000 bytes vs. 1,048,576 bytes/1,000,000,000 bytes vs. 1,073,741,824
bytes). The rule of thumb is there's never as much space actually available as I
expect. :)

jcc7



 Feb 13 2006



prev sibling  parent  "Unknown W. Brackets" <unknown simplemachines.org>  writes:


Well, the best approach would be, I think, to call a callback on every 
match, but this is contrary to common usage.  That said, in any case 
where I expect large sets of data I either use a callback or stateful (I 
do realize that's not a word) method of retrieving the data.

This also is not rocket science, although it is contrary to how most 
programmers think and are taught.

Of course, it does appear to me that listdir supports callbacks, and 
this doesn't appear to complicate user-code too much (although it isn't 
quite as simple as a foreach.)  Still, that only seems like a trivial 
design-choice difference to me.

I don't know much about recls, but if it's just a class that provides 
incremental searching (e.g. like you might with a callback to listdir.) 
I'd imagine it can't be too long or complicated.

-[Unknown]



 True, but there's another flaw in the design. By combining recursion and en 
 bloc results it can lead to huge latencies and memory consumption, suffering 
 from non-linear behaviour. (Perhaps I didn't stress that aspect enough in my 
 previous rants. The two aspects are not commensurate, and if listdir() is 
 preserved then it needs to stop being recursive.)





 Feb 12 2006



prev sibling  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew hat.stlsoft.dot.org> wrote in message
news:dsoi09$2v9i$1 digitaldaemon.com...

 But questions abound: How many matching files are under c:\cbx?


It's 8107 results, about 800 Mb.


 What is 2.67? What is 0.36?


Seconds.


 How were these times taken?


Using the timer.exe program I use for all program timings.


Why have you changed the number of patterns?


I don't have java, vbs, etc., files, so I modified it so it would find files
that actually were there.


 Hey, why not just use 1?


Because the issue was how many sweeps over the filesystem. It's pretty
obvious, by both your results and mine, that that's the determinant of the
time.


 What do you think you've proved/demonstrated by a test of some D against
 some other D?
 Why haven't you installed Ruby and done a comparison?


Because if:
    A = 6 * B
    B = 3 * C
therefore, I don't need to compare A with C to deduce that:
    A = 18 * C

Of course, there will be other differences since your hard disk setup is
different than mine, but the ratios should hold.


 Where is the comparison of the memory hit?


I didn't do one. I don't think it would provide that useful of information,
because one can get wildly different results depending on how the garbage
collector is tuned.


 Why offer conjecture ("perhaps twice as fast as the Ruby one")
 when I spent a lot of time and effort producing cold hard facts?


Because I don't have Ruby on my system. But you can compile/run the example
I gave you, modifying it back to reflect your directory structure, in a 
couple minutes. Why not give it a try? 



 Feb 12 2006



prev sibling next sibling parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsogst$2u8b$1 digitaldaemon.com...

 There are 13 patterns searched for, so 13 trips through listdir. Taking


 your

 numbers, the D version takes roughly 6 times longer to run than the Ruby
 one. I adapted it slightly to my system so I could run it, and set it up


 for

 8 patterns:





Where does this 6 come from? (Ignoring the first times for each to give a 
fair comparison) the D version takes 31 times longer than the Ruby version!

      80359 2540203
      83656 2733218
      88062 2630031
      86809 2864390

      84721.5 2691961 31.77423



 Matthew's: 2.67
 Walter's: 0.36

 Interestingly, that shows a 7.4 times speedup, but 8 patterns. This


 implies

 that the D version might be perhaps twice as fast as the Ruby one on your
 system. (I don't have Ruby on my system.) This post is long enough, I'll
 provide more design commentary in another post.




So with your speed up of 8, it's still 4 times slower.

Reason: Design is bad.
Solution: Ditch listdir(), or remove its recursive abilities.



 Feb 12 2006



 next sibling parent reply Derek Parnell <derek psych.ward>  writes:


Now settle down, kiddies. You're only getting yourself all upset.

All we have gained from this unsightly tantrum is that listdir is not
optimised and recls is optimised. 

I have a gut feeling that optimising listdir is not going to be all that
hard to do. I even had a 10-minute go at doing that and got a huge
performance improvement. 

BTW, this might just be a documentation 'bug', but the docs for DirEntry
say that ...

  char[] name; 
     file or directory name

but it is actually the name *plus* full path to the name. I tripped up on
this when using the pattern "test.*" and it failed to find any files. It
seems I needed to use the pattern "*\test.*" to find JUST files that
started with 'test'.

For somebody's amusement I've included an expanded and better performing
listdir() (though I'm sure it can be improved and also its not a comparison
to either recls or Ruby)...

//------------------------
private
{
    import std.string;
    import std.path;
    import std.file;
}

char[][] filelist(char[] pPathname, char[] pPatterns, bool pRecurse = true)
{   char[][] lResults;
    char[][] lPatterns;
    int lSpot;

    // Pre-assign a large buffer for finds.
    lResults.length = 1000;

    bool callback(DirEntry* de)
    {
    	if (de.isdir)
    	{
    	    // sometimes I don't want recursion :-)
    	    if (pRecurse)
    	        listdir(de.name, &callback);
	    }
    	else
    	{
            bool lUsePath; // true: include path names else just file names
            bool lExtOnly;  // true: the patterns are file extentions only

    	    foreach(char[] lThisPattern; lPatterns)
    	    {
     	        char[] lBase;
     	        // First check for 'special' pPatterns qualifiers
        	    if (lThisPattern == "_P")
        	    {
            	    lUsePath = true;
        	    }
        	    else if (lThisPattern == "!P")
        	    {
            	    lUsePath = false;
        	    }
        	    else if (lThisPattern == "_E")
        	    {
            	    lExtOnly = true;
        	    }
        	    else if (lThisPattern == "!E")
        	    {
            	    lExtOnly = false;
        	    }
        	    else
        	    {
            	    // Are we testing the full name or just the file name?
            	    if (lUsePath)
            	    {
        	            lBase = de.name;
            	    }
            	    else
            	    {
            	        lBase = std.path.getBaseName(de.name);
        	        }

        	        // Is the current pattern only for extentions?
        	        if (lExtOnly)
        	            lThisPattern = "*." ~ lThisPattern;

        	        if (std.path.fnmatch(lBase, lThisPattern))
        	        {
        		        // Expand buffer if needed
        		        if (lSpot >= lResults.length)
        		            lResults.length = lResults.length + 1000;

        		        // capture the name
        		        lResults[lSpot] = de.name;
        		        lSpot++;
        		        // Stop looking at patterns; a file is use only once.
        		        break;
        		    }
                }
    		}
    	}
    	return true; // continue
    }

    // Cater for multiple patterns delimited by a semi-colon.
    lPatterns = std.string.split(pPatterns, ";");

    // Start searching.
    listdir(pPathname, &callback);

    // trim the buffer back to size before returning.
    lResults.length = lSpot;
    return lResults;
}
//-----------------

The 'special' pattern qualifier "_E" makes it easier to type a set of
extents.

  _E;d;exe;map;obj;h;c;cpp;tst;tmp

And by default, only file names are examined, but if you use "_P" pattern
qualifier then path names are also examined.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
13/02/2006 11:25:20 AM



 Feb 12 2006



  parent reply "Matthew" <nowhere noaddress.co.us>  writes:


"Derek Parnell" <derek psych.ward> wrote in message
news:1f861fnt3wbv4.2uxo6i97eesd$.dlg 40tude.net...


Beep! Next, please. <g>


 Now settle down, kiddies. You're only getting yourself all upset.

 All we have gained from this unsightly tantrum is that listdir is not
 optimised and recls is optimised.



Get your hand off it, Derek. I know you're not an idiot, so why
affect this patronising and disingenuous position?


 I have a gut feeling that optimising listdir is not going to be all that
 hard to do. I even had a 10-minute go at doing that and got a huge
 performance improvement.


Gotta love those gut feelings.

Sorry mate, but you're again returning en bloc from a recursive
function. Perhaps you weren't paying attention. (Easy to ignore,
these kiddies, eh?) Big delays. Non-linear behaviour.
Going to have to run that one through the night as well. ;-)

Basically, to get a sensibly recursive library, the basic design of recls
will have to be approximated. Given that, why not use std.recls?

This is not a rhetorical question, Walter. I want to know why. Please do me
the courtesy of answering this question, perhaps in one of the stream of
listdir()-tweaks posts I'm expecting to see over the next 24 hours or so.
Then I can give up this point once and for all. Otherwise, I'm just going
to keep asking until I get an answer.



 Feb 12 2006



 next sibling parent  nick <nick.atamas gmail.com>  writes:


Matthew wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1f861fnt3wbv4.2uxo6i97eesd$.dlg 40tude.net...
 
 Beep! Next, please. <g>
 

 Now settle down, kiddies. You're only getting yourself all upset.

 All we have gained from this unsightly tantrum is that listdir is not
 optimised and recls is optimised.


 
 
 Get your hand off it, Derek. I know you're not an idiot, so why
 affect this patronising and disingenuous position?


I think a less temperamental discussion would benefit everyone nonetheless.


Given this capability:


 I believe listdir() shows that it can be done both ways, and done well. 
 There are two essential versions of listdir() - one visits each file and 
 directory in the path, and passes the results *as they are found* to a 
 delegate. The delegate, of course, can execute arbitrary user-supplied code 
 to do anything desired at each point in the search.


what's wrong with using listdir(). I am not trying to instigate, I
really just want to know.



 Feb 12 2006



prev sibling  parent reply Derek Parnell <derek psych.ward>  writes:


On Mon, 13 Feb 2006 12:36:45 +1100, Matthew wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1f861fnt3wbv4.2uxo6i97eesd$.dlg 40tude.net...


 
 Beep! Next, please. <g>
 

 Now settle down, kiddies. You're only getting yourself all upset.

 All we have gained from this unsightly tantrum is that listdir is not
 optimised and recls is optimised.


 
 Get your hand off it, Derek. I know you're not an idiot, so why
 affect this patronising and disingenuous position?


You two are behaving like little kids in the kindergarten playground. I'm
sorry if that sounds patronizing to you, but that's how I'm seeing it. And
disingenuous!?!?! Are you saying that I'm lying? About what????


 I have a gut feeling that optimising listdir is not going to be all that
 hard to do. I even had a 10-minute go at doing that and got a huge
 performance improvement.


 
 Gotta love those gut feelings.


I assume by this you are saying that "gut feelings" don't prove anything
and are thus worthless. Well tough shit mate, get over it. Maybe I should
have said "suspicions based on my D experiences to date" rather than adopt
a more colloquial (and non-confrontational) language.


 Sorry mate, but you're again returning en bloc from a recursive
 function. 
 Perhaps you weren't paying attention. (Easy to ignore,
 these kiddies, eh?) Big delays. Non-linear behaviour.
 Going to have to run that one through the night as well. ;-)


Yeah, so what? That's what I was trying to do. I could have chosen to do
otherwise but for a ten-minute muck-about version who the hell cares! 

It took me another few minutes to convert it to your personal idea of
what's sensible for this operation.

// -----------------
long filelist(char[] pPathname, char[] pPatterns, 
              bool delegate(char[]) pAction, bool pRecurse = true)
{
    char[][] lPatterns;
    long lCnt;

    bool callback(DirEntry* de)
    {
    	if (de.isdir)
    	{
    	    // sometimes I don't want recursion :-)
    	    if (pRecurse)
    	        listdir(de.name, &callback);
	    }
    	else
    	{
            bool lUsePath; // true: include paths too else just file names
            bool lExtOnly;  // true: the patterns are file extentions only

    	    foreach(char[] lThisPattern; lPatterns)
    	    {
     	        char[] lBase;
     	        // First check for 'special' pPatterns qualifiers
        	if (lThisPattern == "_P")
        	{
            	    lUsePath = true;
        	}
        	    else if (lThisPattern == "!P")
        	{
            	    lUsePath = false;
        	}
        	else if (lThisPattern == "_E")
        	{
            	    lExtOnly = true;
        	}
        	else if (lThisPattern == "!E")
        	{
            	    lExtOnly = false;
        	}
        	else
        	{
            	    // Are we testing the full name or just the file name?
            	    if (lUsePath)
            	    {
        	            lBase = de.name;
            	    }
            	    else
            	    {
            	        lBase = std.path.getBaseName(de.name);
        	        }

        	        // Is the current pattern only for extentions?
        	        if (lExtOnly)
        	            lThisPattern = "*." ~ lThisPattern;

        	        if (std.path.fnmatch(lBase, lThisPattern))
        	        {
        		        // capture the name
        		        lCnt++;
        		        if (pAction(de.name) == false)
        		            return false;
        		        // Stop looking at patterns,a file is included only once.
        		        break;
        		    }
                    }
    		}
    	}
    	return true; // continue
    }

    // Cater for multiple patterns delimited by a semi-colon.
    lPatterns = std.string.split(pPatterns, ";");

    // Start searching.
    listdir(pPathname, &callback);

    return lCnt;
}

// -----------------

And a test program for it ...

//------------------
import std.stdio;
import std.file;
import dirlist;

int main(char[][] pParm)
{
    char[][] res;
    long lCnt;
    long lRes;

    bool TestFunc(char[] pName)
    {
        lCnt++; // just to do something with the name.
        return true;
    }


    if (pParm.length < 3)
        return 0;

    lRes = dirlist.filelist(pParm[1], pParm[2], &TestFunc);
    writefln("Found: %d %d", lCnt, lRes);
    return 0;


}

//------------------


 Basically, to get a sensibly recursive library, the basic design of recls
 will have to be approximated. Given that, why not use std.recls?


Because it ain't written in D! Write recls in D and I'll have another look
at it. If you can't use D to create it then we have got bigger problems to
solve first.

If this attitude makes me look stupid, then I'll just have to put up with
that. But I seriously think that the low-level libraries for D can be
written in D now. We no longer have to rely on C-libraries. If D is so much
better to maintain code in, then porting C libraries to D is cost effective
in the long run.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
13/02/2006 12:45:09 PM



 Feb 12 2006



  parent reply "Matthew" <nowhere noaddress.co.us>  writes:


I've snipped the foregoing. Seems you like to give, but not receive. Each to 
their own, I guess.


 Basically, to get a sensibly recursive library, the basic design of recls
 will have to be approximated. Given that, why not use std.recls?


 Because it ain't written in D! Write recls in D and I'll have another look
 at it. If you can't use D to create it then we have got bigger problems to
 solve first.


Then why is it in Phobos? It is, er, _std_.recls.

If it shouldn't be in there because it's written in non-D, then fair enough. 
Will you be removing (and rewriting??) std.zlib for consistency. If not, is 
it the case that there're other criteria to a std library than just the 
language in which it's written. That begin so, why should it not be 
discussed?


 If this attitude makes me look stupid, then I'll just have to put up with
 that.


Mate, you jumped in from the touchline and started the name calling, and now 
you're carrying on. What gives?


 But I seriously think that the low-level libraries for D can be
 written in D now. We no longer have to rely on C-libraries. If D is so 
 much
 better to maintain code in, then porting C libraries to D is cost 
 effective
 in the long run.


It's a point of view. There are many pros and cons - not to mention the 
veracity of "If D is so much better to maintain code in" - and I hazard to 
suggest that they don't simply boil down to an all-D-now-or-nothing pov.



 Feb 12 2006



 next sibling parent  "Regan Heath" <regan netwin.co.nz>  writes:


On Mon, 13 Feb 2006 13:39:39 +1100, Matthew <nowhere noaddress.co.us>  
wrote:

 Basically, to get a sensibly recursive library, the basic design of  
 recls
 will have to be approximated. Given that, why not use std.recls?


 Because it ain't written in D! Write recls in D and I'll have another  
 look
 at it. If you can't use D to create it then we have got bigger problems  
 to
 solve first.


 Then why is it in Phobos? It is, er, _std_.recls.


I reckon it was added to solve a problem, one that was not solved by  
phobos at the time.


 If it shouldn't be in there because it's written in non-D, then fair  
 enough.
 Will you be removing (and rewriting??) std.zlib for consistency.


Perhaps, but there are many criteria upon which to base such a decision.


 If not, is
 it the case that there're other criteria to a std library than just the
 language in which it's written. That begin so, why should it not be
 discussed?


I believe there are other criteria and that it's a balance (as you  
mentioned earlier)

Regan



 Feb 12 2006



prev sibling  parent  Derek Parnell <derek psych.ward>  writes:


On Mon, 13 Feb 2006 13:39:39 +1100, Matthew wrote:


 I've snipped the foregoing. Seems you like to give, but not receive. Each to 
 their own, I guess.


Huh? Now what are you talking about?


 Basically, to get a sensibly recursive library, the basic design of recls
 will have to be approximated. Given that, why not use std.recls?


 Because it ain't written in D! Write recls in D and I'll have another look
 at it. If you can't use D to create it then we have got bigger problems to
 solve first.


 
 Then why is it in Phobos? It is, er, _std_.recls.


Because that's where Walter put it. I don't know why and I certainly don't
have any influence about which libraries go where. But back to the question
you asked "why not use std.recls?" and my answer, which of course only
applies to my reasons for not using it, "Because it ain't written in D".
The placement of the library has got no bearing on why I might or might not
use a library.
 

 If it shouldn't be in there because it's written in non-D, then fair enough. 


How has said this? I've not brought up the placement of non-D sourced
libraries as an issue. 


 Will you be removing (and rewriting??) std.zlib for consistency.


I don't think so. I won't be personally re-tiling my house's roof either,
but that doesn't mean I think it shouldn't get done.


 If not, is 
 it the case that there're other criteria to a std library than just the 
 language in which it's written.


Yes, of course. Never said otherwise. My point of view is that if it is
possible to write the D standard library modules in D, then that should be
an goal to aim for. I also accept that 'nothing happens overnight' and thus
such a goal might take many years to achieve. My 'gut feel' is that those
modules that are not currently written in D are that way because nobody has
gotten around to it yet.


 That begin so, why should it not be discussed?


Has somebody suggested that this topic not be discussed? I know I haven't.


 If this attitude makes me look stupid, then I'll just have to put up with
 that.


 
 Mate, you jumped in from the touchline and started the name calling, and now 
 you're carrying on. What gives?


Huh? Are we having a language problem here. Am I speaking in too strong an
Aussie (Melbourne) accent or something? What do you mean by "carrying on"?
My interpretation of that phrase is that you think I'm being unreasonable
and talking nonsense. Am I? And what is a "touchline" anyway? 

When I said "If this attitude makes me look stupid" I meant that I can
envision that some people may assume that the attitude of 'if one cannot
use D to create the recls library, then we have some serious problems with
D in general' is one of dogma and of seeing the world in D-coloured
glasses. And if that be the case, then I will just have to put up with
people thinking that of me. 


 But I seriously think that the low-level libraries for D can be
 written in D now. We no longer have to rely on C-libraries. If D is so 
 much
 better to maintain code in, then porting C libraries to D is cost 
 effective
 in the long run.


 
 It's a point of view. There are many pros and cons - not to mention the 
 veracity of "If D is so much better to maintain code in" - and I hazard to 
 suggest that they don't simply boil down to an all-D-now-or-nothing pov.


Agreed.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
13/02/2006 2:08:11 PM



 Feb 12 2006



prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <nowhere noaddress.co.us> wrote in message 
news:dsoiul$305p$1 digitaldaemon.com...

 Where does this 6 come from? (Ignoring the first times for each to give a 
 fair comparison) the D version takes 31 times longer than the Ruby 
 version!

      80359 2540203
      83656 2733218
      88062 2630031
      86809 2864390

      84721.5 2691961 31.77423


I was looking at user time:

From your post:
--------------------
D:      time: elapsed: 7,484ms, kernel: 3,593ms, user: 3140ms
Ruby: time: elapsed: 3,781ms, kernel: 3,031ms, user: 500ms
D:      time: elapsed: 8,906ms, kernel: 3,187ms, user: 3,671ms
Ruby: time: elapsed: 3,687ms, kernel: 2,734ms, user: 703ms
D:      time: elapsed: 8,953ms, kernel: 3,640ms, user: 3296ms
Ruby: time: elapsed: 3,718ms, kernel: 2,890ms, user: 593ms
D:      time: elapsed: 7,500ms, kernel: 4,093ms, user: 2,734ms
Ruby: time: elapsed: 3,750ms, kernel: 3,031ms, user: 531ms
D:      time: elapsed: 8,828ms, kernel: 3,906ms, user: 2,937ms
Ruby: time: elapsed: 3,687ms, kernel: 3,093ms, user: 390ms
-------------------- 



 Feb 12 2006



  parent  "Matthew" <nowhere noaddress.co.us>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsopmo$7ce$1 digitaldaemon.com...

 "Matthew" <nowhere noaddress.co.us> wrote in message 
 news:dsoiul$305p$1 digitaldaemon.com...

 Where does this 6 come from? (Ignoring the first times for each to give a 
 fair comparison) the D version takes 31 times longer than the Ruby 
 version!

      80359 2540203
      83656 2733218
      88062 2630031
      86809 2864390

      84721.5 2691961 31.77423


 I was looking at user time:

 From your post:
 --------------------
 D:      time: elapsed: 7,484ms, kernel: 3,593ms, user: 3140ms
 Ruby: time: elapsed: 3,781ms, kernel: 3,031ms, user: 500ms
 D:      time: elapsed: 8,906ms, kernel: 3,187ms, user: 3,671ms
 Ruby: time: elapsed: 3,687ms, kernel: 2,734ms, user: 703ms
 D:      time: elapsed: 8,953ms, kernel: 3,640ms, user: 3296ms
 Ruby: time: elapsed: 3,718ms, kernel: 2,890ms, user: 593ms
 D:      time: elapsed: 7,500ms, kernel: 4,093ms, user: 2,734ms
 Ruby: time: elapsed: 3,750ms, kernel: 3,031ms, user: 531ms
 D:      time: elapsed: 8,828ms, kernel: 3,906ms, user: 2,937ms
 Ruby: time: elapsed: 3,687ms, kernel: 3,093ms, user: 390ms
 -------------------- 


So you used the less unfavourable test. Understandable. 



 Feb 12 2006



prev sibling  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <nowhere noaddress.co.us> wrote in message 
news:dsoiul$305p$1 digitaldaemon.com...

the D version takes 31 times longer than the Ruby version!


[...]

 So with your speed up of 8, it's still 4 times slower.


Let's do the math right first. It's a speedup of 8 with 8 patterns, whereas 
your 31 is with 13 patterns. Assuming the ratios apply across systems, 
that's 31/13 or 2.3. No need to assume, though, run it and see.


 Reason: Design is bad.


We'll see. Run the one I gave you.


 Solution: Ditch listdir(), or remove its recursive abilities.


listdir() itself isn't recursive - it's the delegate that adds recursion.

BTW, I made a delegate that only counted matches, it didn't build an array 
of them. The run time didn't change beyond the random variation from run to 
run. The array building time, then, didn't seem to have much contribution 
relative to the I/O time. It also shows how flexible the library listdir() 
can be by just changing the delegate.

P.S. It's also possible to provide a set of "stock" delegates via a template 
mixin.
------------------------------------------
import std.file;
import std.stdio;

int main()
{
    char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
    char[] ROOT = r"c:\cbx";

    int n = mylistdir(ROOT, pattern);

    printf("Number: %d\n", n);

    return 0;
}

import std.regexp;

int mylistdir(char[] pathname, char[] pattern)
{
    auto r = new RegExp(pattern, "i");
    int n;

    bool callback(DirEntry* de)
    {
        if (de.isdir)
            std.file.listdir(de.name, &callback);
        else
        {   if (r.test(de.name))
                n++;
        }
        return true; // continue
    }

    std.file.listdir(pathname, &callback);
    return n;
}



 Feb 12 2006



prev sibling  parent reply "Matthew" <matthew hat.stlsoft.dot.org>  writes:


Please post a full working example program. What's below doesn't compile:

    listdir_test2.d(32): constructor std.regexp.RegExp.this (char[],char[])
does not match argument types (char[])
    listdir_test2.d(32): Error: expected 2 arguments, not 1

"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsogst$2u8b$1 digitaldaemon.com...

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dsod98$2o63$1 digitaldaemon.com...

 Go wild


 Thanks. Let's have some fun with the analysis! Here's your version:
 -------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
  char[]  PATTERNS =
 "*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc";
 // char[]  ROOT  = "H:/dev";
  char[]  ROOT  = "H:/";
 // char[]  ROOT  = "H:/freelibs/openrj/current";
  char[][] filters  = split(PATTERNS, ";");
  int   n   = 0;

  foreach(char[] pattern; filters)
  {
 //  writefln("pattern: %s", pattern);

   char[][] fs = listdir(ROOT, pattern);

   foreach(char[] fe; fs)
   {
 //   writefln("File: %s", fe);
    ++n;
   }
  }

  printf("Number: %d\n", n);

  return 0;
 }
 --------------------------------------------------
 There are 13 patterns searched for, so 13 trips through listdir. Taking


your

 numbers, the D version takes roughly 6 times longer to run than the Ruby
 one. I adapted it slightly to my system so I could run it, and set it up


for

 8 patterns:
 --------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
     char[]   PATTERNS = "*.h;*.hpp;*.bak;*.d;*.vbs;*.c;*.cpp;*.exe";
     char[]   ROOT     = r"c:\cbx";
     char[][] filters  = split(PATTERNS, ";");
     int n             = 0;

     foreach(char[] pattern; filters)
     {
 //      writefln("pattern: %s", pattern);

         char[][] fs = listdir(ROOT, pattern);

         foreach(char[] fe; fs)
         {
 //          writefln("File: %s", fe);
             ++n;
         }
     }

     printf("Number: %d\n", n);

     return 0;
 }
 --------------------------------------------------
 As I think I said previously, the listdir one used in D just does the
 (primitive) fnmatch to do the pattern match, which is intended to behave
 like the operating system wildcard matching behavior. It does not support
 "OR" patterns. But we can write our own to use regular expressions, as in:
 ---------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
     char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
     char[] ROOT = r"c:\cbx";
     int    n    = 0;

 //  writefln("pattern: %s", pattern);

     char[][] fs = listdir(ROOT, pattern);

     foreach(char[] fe; fs)
     {
 //      writefln("File: %s", fe);
         ++n;
     }

     printf("Number: %d\n", n);

     return 0;
 }

 import std.regexp;

 char[][] listdir(char[] pathname, char[] pattern)
 {   char[][] result;
     auto r = new RegExp(pattern);

     bool callback(DirEntry* de)
     {
         if (de.isdir)
             std.file.listdir(de.name, &callback);
         else
         {   if (r.test(de.name))
                 result ~= de.name;
         }
         return true; // continue
     }

     std.file.listdir(pathname, &callback);
     return result;
 }
 ----------------------------------------------------
 There's only one trip through listdir(). What are the numbers?

 Matthew's: 2.67
 Walter's: 0.36

 Interestingly, that shows a 7.4 times speedup, but 8 patterns. This


implies

 that the D version might be perhaps twice as fast as the Ruby one on your
 system. (I don't have Ruby on my system.) This post is long enough, I'll
 provide more design commentary in another post.



begin 666 listdir_test2.d


M5$523E,)/0DB*BYH.RHN<F([*BYH<' [*BYJ879A.RHN9#LJ+G!Y.RHN=F)S
M.RHN8SLJ+F-P<#LJ+F-X>#LJ+FED;#LJ+F]D;#LJ+G)C(CL-"B  ("!C:&%R
M6UT)"7!A='1E<FX /2!R(EPN*&A\<F)\:'!P?&IA=F%\9'QP>7QV8G-\8WQC



M; D)"3T),#L-" T*("  (&-H87);75M=(&9S(#T ;&ES=&1I<BA23T]4+"!P



M;7!O<G0 <W1D+G)E9V5X<#L-" T*8VAA<EM=6UT ;&ES=&1I<BAC:&%R6UT 
M<&%T:&YA;64L(&-H87);72!P871T97)N*0T*>R  (&-H87);75M=(')E<W5L
M=#L-






M871H;F%M92P )F-A;&QB86-K*3L-"B  ("!R971U<FX <F5S=6QT.PT*?0T*
`
end



 Feb 12 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


I'm sorry, I was working from the current version of regexp where I did some 
minor improvements. The second argument is now defaulted to null. I added 
null in below. You might also consider making it "i" which will make the 
regex case insensitive, which is appropriate for Windows filesystems.

"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dsoq4l$8nb$1 digitaldaemon.com...

 Please post a full working example program. What's below doesn't compile:

    listdir_test2.d(32): constructor std.regexp.RegExp.this (char[],char[])
 does not match argument types (char[])
    listdir_test2.d(32): Error: expected 2 arguments, not 1

 "Walter Bright" <newshound digitalmars.com> wrote in message

 ---------------------------------------------------
 import std.file;
 import std.stdio;
 import std.string;

 int main()
 {
     char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
     char[] ROOT = r"c:\cbx";
     int    n    = 0;

 //  writefln("pattern: %s", pattern);

     char[][] fs = listdir(ROOT, pattern);

     foreach(char[] fe; fs)
     {
 //      writefln("File: %s", fe);
         ++n;
     }

     printf("Number: %d\n", n);

     return 0;
 }

 import std.regexp;

 char[][] listdir(char[] pathname, char[] pattern)
 {   char[][] result;
     auto r = new RegExp(pattern, null); // <<<======

     bool callback(DirEntry* de)
     {
         if (de.isdir)
             std.file.listdir(de.name, &callback);
         else
         {   if (r.test(de.name))
                 result ~= de.name;
         }
         return true; // continue
     }

     std.file.listdir(pathname, &callback);
     return result;
 }







 Feb 12 2006



prev sibling  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Mon, 30 Jan 2006 17:47:31 +1100, Matthew <matthew stlsoft.com> wrote:

 Look, it's like this. I use the 2000 boot of my Windows machine in
 preference to the XP for basically one reason: I can select text from
 command boxes without first having to do Alt-Space E K, which I find
 incredibly tiresome when I've already been incovenienced by having to use
 the damn mouse. The other influencing factor is the fact that XP is a
 steaming heap of omni-crashing shite, but it's really just the usability  
 of the command-box. I know it's crazy, but it's the truth.


Have you tried "QuickEdit mode"?
(left-click the upper left corner of a cmd window, choose properties,  
choose options, tick "QuickEdit mode")

Now you can select and paste with the mouse, left-click-drag highlights,  
right-click copies (deselects) and then pastes (multiple times). I've come  
to like it, despite having to remove my right hand from the keyboard to do  
it.

Regan



 Jan 30 2006



 next sibling parent  Sean Kelly <sean f4.ca>  writes:


Regan Heath wrote:

 On Mon, 30 Jan 2006 17:47:31 +1100, Matthew <matthew stlsoft.com> wrote:

 Look, it's like this. I use the 2000 boot of my Windows machine in
 preference to the XP for basically one reason: I can select text from
 command boxes without first having to do Alt-Space E K, which I find
 incredibly tiresome when I've already been incovenienced by having to use
 the damn mouse. The other influencing factor is the fact that XP is a
 steaming heap of omni-crashing shite, but it's really just the 
 usability of the command-box. I know it's crazy, but it's the truth.


 
 Have you tried "QuickEdit mode"?
 (left-click the upper left corner of a cmd window, choose properties, 
 choose options, tick "QuickEdit mode")
 
 Now you can select and paste with the mouse, left-click-drag highlights, 
 right-click copies (deselects) and then pastes (multiple times). I've 
 come to like it, despite having to remove my right hand from the 
 keyboard to do it.


Wow, I'd never seen this option for some reason.  Makes my life much 
easier.  Thanks!


Sean



 Jan 30 2006



prev sibling  parent reply "Matthew" <matthew stlsoft.com>  writes:


----- Original Message ----- 
From: "Regan Heath" <regan netwin.co.nz>
Newsgroups: digitalmars.D
Sent: Tuesday, January 31, 2006 7:41 AM
Subject: OT: copy/paste XP cmd



 On Mon, 30 Jan 2006 17:47:31 +1100, Matthew <matthew stlsoft.com> wrote:

 Look, it's like this. I use the 2000 boot of my Windows machine in
 preference to the XP for basically one reason: I can select text from
 command boxes without first having to do Alt-Space E K, which I find
 incredibly tiresome when I've already been incovenienced by having to use
 the damn mouse. The other influencing factor is the fact that XP is a
 steaming heap of omni-crashing shite, but it's really just the usability
 of the command-box. I know it's crazy, but it's the truth.


 Have you tried "QuickEdit mode"?
 (left-click the upper left corner of a cmd window, choose properties,
 choose options, tick "QuickEdit mode")

 Now you can select and paste with the mouse, left-click-drag highlights,
 right-click copies (deselects) and then pastes (multiple times). I've come
 to like it, despite having to remove my right hand from the keyboard to do
 it.


ROFL!!!!!!!!!!!!!!

Wow. Don't you just love life. Always another way to make a galah of
oneself.

Thanks for that. Now I can just hate XP because it crashes, and three months
after each re-install it decides that some COM object somewhere is missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


(Of course, I'll have to do this every time I'm using a cmd box with a 
different title, so it's not a complete panacea for what ails me.) 



 Jan 30 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Matthew wrote:

 
 Thanks for that. Now I can just hate XP because it crashes, and three months
 after each re-install it decides that some COM object somewhere is missing
 so it can no longer save Word or Excel documents (or let you copy their
 contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


 (Of course, I'll have to do this every time I'm using a cmd box with a 
 different title, so it's not a complete panacea for what ails me.) 


True.  I have a bunch of shortcuts to different command configurations, 
so for it it was simply a matter of setting this option for each one. 
I'm not sure if this would work for command windows popped up by visual 
studio, however.


Sean



 Jan 30 2006



 next sibling parent reply "Ameer Armaly" <ameer_armaly hotmail.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drm2bl$vtf$1 digitaldaemon.com...

 Matthew wrote:

 Thanks for that. Now I can just hate XP because it crashes, and three 
 months
 after each re-install it decides that some COM object somewhere is 
 missing
 so it can no longer save Word or Excel documents (or let you copy their
 contents).


 Weird.  XP has turned out to be at least as stable as 2000 for me.


Same here; I've gotten it to hold up since June of 04 with no problems 
whatsoever.  But then again, I've been known for beeing a complete Nazi as 
to what goes in and out of my computer.

 (Of course, I'll have to do this every time I'm using a cmd box with a 
 different title, so it's not a complete panacea for what ails me.)


 True.  I have a bunch of shortcuts to different command configurations, so 
 for it it was simply a matter of setting this option for each one. I'm not 
 sure if this would work for command windows popped up by visual studio, 
 however.


 Sean 





 Jan 30 2006



  parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Ameer Armaly wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:drm2bl$vtf$1 digitaldaemon.com...
 

Matthew wrote:


Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


 
 Same here; I've gotten it to hold up since June of 04 with no problems 
 whatsoever.  But then again, I've been known for beeing a complete Nazi as 
 to what goes in and out of my computer.
 


XP is perfectly stable .. the only time it crashes on me is due to 
hardware faults.



 Jan 31 2006



  parent reply "Matthew" <matthew stlsoft.com>  writes:


----- Original Message ----- 
From: "Hasan Aljudy" <hasan.aljudy gmail.com>
Newsgroups: digitalmars.D
Sent: Wednesday, February 01, 2006 12:11 PM
Subject: Re: copy/paste XP cmd



 Ameer Armaly wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:drm2bl$vtf$1 digitaldaemon.com...


Matthew wrote:


Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


 Same here; I've gotten it to hold up since June of 04 with no problems 
 whatsoever.  But then again, I've been known for beeing a complete Nazi 
 as to what goes in and out of my computer.


 XP is perfectly stable .. the only time it crashes on me is due to 
 hardware faults.


Well, I have it on two machines. It lasted one year on the laptop before
going totally squiffy and requiring a reinstall. On the desktop it's been
installed for 3 years, but every few months one less things works - I just
can't face the reinstallation headache, so I use the Win2K boot.

While I'm happy for you and Sean that you have no major issues, 3 does not
make a statistical sample, and in any case 33% of users thinking your
product is a stinking pile of overengineered crap might make your sales
manager happy, but it sure shouldn't make the head of development proud.



 Jan 31 2006



 next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Matthew" <matthew stlsoft.com> wrote in message 
news:drp4ao$2d8o$1 digitaldaemon.com...

 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


I've had fewer problems with XP than any of the previous Windows systems. 



 Jan 31 2006



 next sibling parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Tue, 31 Jan 2006 18:30:44 -0800, Walter Bright  
<newshound digitalmars.com> wrote:

 "Matthew" <matthew stlsoft.com> wrote in message
 news:drp4ao$2d8o$1 digitaldaemon.com...

 While I'm happy for you and Sean that you have no major issues, 3 does  
 not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


 I've had fewer problems with XP than any of the previous Windows systems.


+1 :)

Regan



 Jan 31 2006



  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Regan Heath wrote:

 On Tue, 31 Jan 2006 18:30:44 -0800, Walter Bright  
 <newshound digitalmars.com> wrote:
 

 "Matthew" <matthew stlsoft.com> wrote in message
 news:drp4ao$2d8o$1 digitaldaemon.com...


 While I'm happy for you and Sean that you have no major issues, 3 
 does  not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.



 I've had fewer problems with XP than any of the previous Windows systems.


 
 
 +1 :)
 
 Regan


One more here. I very, very rarely have a system crash, and my computer 
is on 24/7 and I use it for usual web browsing, gaming, development, 
samba file server, game server.
It is still bloated, and some user-level programs still crash sometimes 
(like file explorer and Internet explorer), but the system itself is 
much more stable.
In fact blue screens now freak the hell out of me, since they now 
probably imply a hardware problem :(
-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 01 2006



prev sibling next sibling parent reply John Reimer <terminal.node gmail.com>  writes:


Walter Bright wrote:

 "Matthew" <matthew stlsoft.com> wrote in message 
 news:drp4ao$2d8o$1 digitaldaemon.com...

 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


 
 I've had fewer problems with XP than any of the previous Windows systems. 
 
 



I think it depends on what you use XP for and how intensely you use it. 
  If you just use it for the same thing all the time... like mere text 
editing and software development :), XP likely stays rock solid and 
probably will remain that way for a long time as long as you don't 
install new programs every month.

On the other hand, if you try to use it for any sort of multimedia, 
gaming, video-editing, or other system-intensive application, I think 
you will begin to see that XP isn't very stable at all.  Graphics 
drivers can be horribly unstable.

Video editing software and games are particularly hard on XP.

Frankly though, I find XP hugely more stable than the previous OSes 
offered by Microsoft... but still far too bloated with unnecessary 
background services.

-JJR



 Jan 31 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"John Reimer" <terminal.node gmail.com> wrote in message 
news:drpe9p$2ov1$1 digitaldaemon.com...

 I think it depends on what you use XP for and how intensely you use it. If 
 you just use it for the same thing all the time... like mere text editing 
 and software development :), XP likely stays rock solid and probably will 
 remain that way for a long time as long as you don't install new programs 
 every month.


IExplorer used to crash regularly. It's not so bad lately.


 On the other hand, if you try to use it for any sort of multimedia, 
 gaming, video-editing, or other system-intensive application, I think you 
 will begin to see that XP isn't very stable at all.  Graphics drivers can 
 be horribly unstable.


I don't install games on my work PC - there's a separate one for that. One 
reason is I don't care for the gaming rootkits being installed (like 
starforce) or other spyware nonsense. With the gaming PC, it just gets a 
disk wipe and a fresh install of the OS now and then <g>.

I still have to regularly reboot in order to get the printer to work.


 Video editing software and games are particularly hard on XP.


Funny you should say that. I once tried to edit video on my PC. I tried 
several packages - NONE of which would work. All kinds of wierd crashes 
would happen, and all I tried doing was the *simplest* things like just 
importing a video clip. Since each package would crash on a different part 
of the process, I was able to edit my video together using bits and pieces 
from each video suite. I finally concluded that video editting simply wasn't 
ready for prime time and abandoned it. 



 Jan 31 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "Matthew" <matthew stlsoft.com> wrote in message 
 news:drp4ao$2d8o$1 digitaldaemon.com...

 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


 
 I've had fewer problems with XP than any of the previous Windows systems. 


That's it exactly.  It's not that XP is a "good" OS in some abstract 
sense so much as that it's at least marginally better than previous 
versions.  It still suffers from creeping bloat, etc, that's plagued all 
versions of Windows since 3.1.


Sean



 Jan 31 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drph57$2rr5$1 digitaldaemon.com...

 Walter Bright wrote:

 I've had fewer problems with XP than any of the previous Windows systems.


 That's it exactly.  It's not that XP is a "good" OS in some abstract sense 
 so much as that it's at least marginally better than previous versions. 
 It still suffers from creeping bloat, etc, that's plagued all versions of 
 Windows since 3.1.


Microsoft would make me happy if they made a version of Windows that I could 
reinstall without having to reinstall all my apps. 



 Jan 31 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:drph57$2rr5$1 digitaldaemon.com...

 Walter Bright wrote:

 I've had fewer problems with XP than any of the previous Windows systems.


 That's it exactly.  It's not that XP is a "good" OS in some abstract sense 
 so much as that it's at least marginally better than previous versions. 
 It still suffers from creeping bloat, etc, that's plagued all versions of 
 Windows since 3.1.


 
 Microsoft would make me happy if they made a version of Windows that I could 
 reinstall without having to reinstall all my apps. 


If they did that I'd go back to a multi-partition system in a heartbeat. 
  As it is, I've abandoned that in favor of a single partition and 
frequent data backups.  I suppose it's some consolation that PCs now 
ship with hardware RAID support, though I couldn't resist the 
performance boost of a RAID 0 on my gaming rig :-p  Since the reinstalls 
will happen regularly anyway...


Sean



 Jan 31 2006



prev sibling next sibling parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 1 Feb 2006 12:54:10 +1100, Matthew wrote:

[snip]
 

 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample ...


I've been using XP on a variety of machines (laptops, desktops, and
servers) for a few years now and love its stability in comparison to other
earlier Windows editions. I'm think I've had a blue-screen twice and both
times it was a bad RAM chip. The biggest reason for rebooting now is to
finish a software install.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/02/2006 2:08:35 PM



 Jan 31 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Derek Parnell wrote:

 
 I've been using XP on a variety of machines (laptops, desktops, and
 servers) for a few years now and love its stability in comparison to other
 earlier Windows editions. I'm think I've had a blue-screen twice and both
 times it was a bad RAM chip. The biggest reason for rebooting now is to
 finish a software install.


I used to bluescreen XP like crazy, but since I removed Windows Services 
for Unix and turned off a few irritating services that IT installed the 
problem has disappeared.  Overall, I think XP is the most stable Windows 
so far, even if it is only a marginal improvement over 2000.


Sean



 Jan 31 2006



prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Matthew wrote:

 ----- Original Message ----- 
 From: "Hasan Aljudy" <hasan.aljudy gmail.com>
 Newsgroups: digitalmars.D
 Sent: Wednesday, February 01, 2006 12:11 PM
 Subject: Re: copy/paste XP cmd
 
 
 

Ameer Armaly wrote:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drm2bl$vtf$1 digitaldaemon.com...



Matthew wrote:



Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


Same here; I've gotten it to hold up since June of 04 with no problems 
whatsoever.  But then again, I've been known for beeing a complete Nazi 
as to what goes in and out of my computer.


XP is perfectly stable .. the only time it crashes on me is due to 
hardware faults.


 
 
 Well, I have it on two machines. It lasted one year on the laptop before
 going totally squiffy and requiring a reinstall. On the desktop it's been
 installed for 3 years, but every few months one less things works - I just
 can't face the reinstallation headache, so I use the Win2K boot.
 
 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.
 
 
 
 
 


I think there are far more people unhappy with linux than there are 
people unhappy with windows.

Go to any computer science lecture room/theater, and ask students who 
uses windows and who uses linux! I think windows will always win, at 
least in my university!

Even better, ask how many people have linux installed, then ask those 
people, how many of you actually use it?
One prof asked us this question once; about 13 people raised their hands 
for "I installed linux on my machine", and only _one_ person raised his 
hand for "I actually use it!".



 Jan 31 2006



 next sibling parent reply "Matthew" <matthew stlsoft.com>  writes:


"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:drpbgo$2lpe$1 digitaldaemon.com...

 Matthew wrote:

 ----- Original Message ----- 
 From: "Hasan Aljudy" <hasan.aljudy gmail.com>
 Newsgroups: digitalmars.D
 Sent: Wednesday, February 01, 2006 12:11 PM
 Subject: Re: copy/paste XP cmd




Ameer Armaly wrote:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drm2bl$vtf$1 digitaldaemon.com...



Matthew wrote:



Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy 
their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


Same here; I've gotten it to hold up since June of 04 with no problems 
whatsoever.  But then again, I've been known for beeing a complete Nazi 
as to what goes in and out of my computer.


XP is perfectly stable .. the only time it crashes on me is due to 
hardware faults.



 Well, I have it on two machines. It lasted one year on the laptop before
 going totally squiffy and requiring a reinstall. On the desktop it's been
 installed for 3 years, but every few months one less things works - I 
 just
 can't face the reinstallation headache, so I use the Win2K boot.

 While I'm happy for you and Sean that you have no major issues, 3 does 
 not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


 I think there are far more people unhappy with linux than there are people 
 unhappy with windows.

 Go to any computer science lecture room/theater, and ask students who uses 
 windows and who uses linux! I think windows will always win, at least in 
 my university!

 Even better, ask how many people have linux installed, then ask those 
 people, how many of you actually use it?
 One prof asked us this question once; about 13 people raised their hands 
 for "I installed linux on my machine", and only _one_ person raised his 
 hand for "I actually use it!".


Sorry, but at what point did I even intimate that Linux was a preferred 
alternative, never mind mention it? You appear to be picking an argument 
with someone and supplying both sides of it.

Surely a person has a right to say "Windows XP is shite" without being 
accused of having any opinion whatsoever on other operating system families, 
no?

Or has moral relativism crept into IT? Bob, forfend ...



 Jan 31 2006



 next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Matthew wrote:

 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:drpbgo$2lpe$1 digitaldaemon.com...
 

Matthew wrote:


----- Original Message ----- 
From: "Hasan Aljudy" <hasan.aljudy gmail.com>
Newsgroups: digitalmars.D
Sent: Wednesday, February 01, 2006 12:11 PM
Subject: Re: copy/paste XP cmd





Ameer Armaly wrote:



"Sean Kelly" <sean f4.ca> wrote in message 
news:drm2bl$vtf$1 digitaldaemon.com...




Matthew wrote:




Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy 
their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


Same here; I've gotten it to hold up since June of 04 with no problems 
whatsoever.  But then again, I've been known for beeing a complete Nazi 
as to what goes in and out of my computer.


XP is perfectly stable .. the only time it crashes on me is due to 
hardware faults.



Well, I have it on two machines. It lasted one year on the laptop before
going totally squiffy and requiring a reinstall. On the desktop it's been
installed for 3 years, but every few months one less things works - I 
just
can't face the reinstallation headache, so I use the Win2K boot.

While I'm happy for you and Sean that you have no major issues, 3 does 
not
make a statistical sample, and in any case 33% of users thinking your
product is a stinking pile of overengineered crap might make your sales
manager happy, but it sure shouldn't make the head of development proud.


I think there are far more people unhappy with linux than there are people 
unhappy with windows.

Go to any computer science lecture room/theater, and ask students who uses 
windows and who uses linux! I think windows will always win, at least in 
my university!

Even better, ask how many people have linux installed, then ask those 
people, how many of you actually use it?
One prof asked us this question once; about 13 people raised their hands 
for "I installed linux on my machine", and only _one_ person raised his 
hand for "I actually use it!".


 
 
 Sorry, but at what point did I even intimate that Linux was a preferred 
 alternative, never mind mention it? You appear to be picking an argument 
 with someone and supplying both sides of it.
 
 Surely a person has a right to say "Windows XP is shite" without being 
 accused of having any opinion whatsoever on other operating system families, 
 no?
 
 Or has moral relativism crept into IT? Bob, forfend ...
 
 
 
 


I just assumed that Window$ haters will try to promote linux at the end 
of the day, since it's usually the case! I don't think there is anything 
wrong with that, nor anything to take offence for.

Sorry if I offended anyone.



 Feb 01 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Hasan Aljudy wrote:

 
 I just assumed that Window$ haters will try to promote linux at the end 
 of the day, since it's usually the case! I don't think there is anything 
 wrong with that, nor anything to take offence for.


OS/2 was darn nice.  If there had been more apps for it than VisualAge 
C++ I might never have uninstalled it ;-)


Sean



 Feb 01 2006



prev sibling  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


     OT

(This message contains no Serious content. It's just full of rants and 
debris.)

"You on duty? Skip this!" Or at least mark it unread for now, and check 
it out only tonight, if ever. You've been warned.



Matthew wrote:

 wrote in message 

 Matthew wrote:

 From: "Hasan Aljudy"

 Ameer Armaly wrote:

 "Sean Kelly" <sean f4.ca> wrote

 Matthew wrote:












I know this constitutes digging in old archives.


 Thanks for that. Now I can just hate XP because it
 crashes, and three months after each re-install it
 decides that some COM object somewhere is missing so it
 can no longer save Word or Excel documents (or let you
 copy their contents).














BT,DT.


 Same here; I've gotten it to hold up since June of 04 with no
 problems whatsoever.  But then again, I've been known for
 beeing a complete Nazi as to what goes in and out of my
 computer.










Yup. I do that too. On W2k. And I take it that "since June of 04" means 



 XP is perfectly stable .. the only time it crashes on me is due
 to hardware faults.








(See a couple of paragraphs down in this mail.) This is a glaring 
example of what's been discussed there.


 I think there are far more people unhappy with linux than there are
 people unhappy with windows.




OK, in a university class, granted. Then again, taken all computer users 
together, let's just say that the number of people forced to use Linux 
is smaller than the number of people forced to use Windows.

Outside these two forced groups, most Linux users use it out of Free 
Will. It's their own choice, and the day they'd get fed up with Linux, 
they'd switch back to Windows. No need to explain or tell anyone.


 Go to any computer science lecture room/theater, and ask students
 who uses windows and who uses linux! I think windows will always
 win, at least in my university!




And?


 Even better, ask how many people have linux installed, then ask
 those people, how many of you actually use it? One prof asked us
 this question once; about 13 people raised their hands for "I
 installed linux on my machine", 




I think folks have grown up with Windows. Shute, by this time, those 
starting university have seen Windows everywhere for the last 10 to 15 
years. Many of them don't honestly see a difference between Computer and 
Windows.

So, trying out Linux means noticing any differences as "aw, lame copy", 
instead of understanding that there really are "a million" ways of doing 
the GUI. THINK, most of us live in countries with RH drive. So, you fly 
to Ireland, go to Avis rent-a-car, and off you go. After the 3rd 
crossing your blood pressure is high enough to not let you come to think 
that these Natives may feel the same about driving in your country.

We: "Heck, 'round my place there's a Right side to the road. Here it 
seems there's a right and a "right" side. Geez, who the hell ever gave 
them permission to buy cars here in the first place before they got 
their sides Right???"


 and only _one_ person raised his hand for "I actually use it!".


 
 Sorry, but at what point did I even intimate that Linux was a
 preferred alternative, never mind mention it? You appear to be
 picking an argument with someone and supplying both sides of it.


:-)


 Surely a person has a right to say "Windows XP is shite" without


 From Wikipedia, the free encyclopedia:

The word shite may refer to various things

     * A synonym for shit which originated from Ireland.
     * A shi'ite, that is, a believer in Shi'a Islam
     * The shite, the principal character in a Japanese Noh play
     * Shite, the person who performs the technique in Aikido.
     * Shite the Industrial band with strong Techno roots.


I suggest to spell it "shitt". Bit less of a chance to offend various 
Aliens. By Bob! (If one wants to avoid adult filters, that is. Other 
"filter safe" synonyms may be: dung, manure, stool, dropping, excrement, 
feces, ... But I do admire your stamina in keeping this a Family Grade 
Shite. Except for Friday Nights I can pull this off too, to some 
extent.) ((( No offense, Matthew, I just had to say this, 't was too 
tempting. ;-) )))


 being accused of having any opinion whatsoever on other operating
 system families, no?


What I particularly have a PROBLEM with, is the universal psychosis that 
interprets Windows problems as "Gee, my computer is behaving again" 
(subconsciously incriminating the hardware), or "Oh, manure! It's the 
application, Bob, they're dung!", or "Bob-damned graphics drivers, I 
think _microcomputers_aren't_ready_for_video_editing_" (this one 
(paraphrased)(C) Walter, recently).

Never, ever, is it Windows or Microsoft.

((( I _hate_ their products, but I (grudginly must admit, in the name of 
honesty,) that I don't have a problem with Bill Gates. )))

I too use W2k. Probably the last M$ "OS" I'll ever install.

Additionally I've got RH 9, 8, 7, 6, FC 4, Sun Java Desktop System (man, 
if there ever was a more solid lie in a product name...!!!!), and W98 
and W95 running. (I have 26 computers[sic] at home. And I haven't yet 
listed all the operating systems currently in use. ;-) )

So, whenever anything crashes, "[Whatever happens to be the OS or 
application] is sh.. er, excrement!" -- Unless it's W*, then one blames 
whatever else -- without even noticing _themselves_. And *that's* what 
I've a problem with.


 Or has moral relativism crept into IT? Bob, forfend ...


PC-IT: pick _your_ interpretation of _this_!

--- Footnontes:



means "last powered down, or rebooted" the machine.


corresponds to make-file-system on Unix. The Unix Format concept is 
comparable to Windows "low level format". These two forget the "real" 
low level format, which (on modern IDE and SATA drives) is something 
that only a Qualified repair workshop should do. (Things were different 
with RLL and MFM drives, in the good Old Days. Oh, and anybody remember 
hard- and soft-sectored floppies?)



 Mar 07 2006



  parent reply Don Clugston <dac nospam.com.au>  writes:


Georg Wrede wrote:

 Surely a person has a right to say "Windows XP is shite" without


 
  From Wikipedia, the free encyclopedia:
 
 The word shite may refer to various things
 
     * A synonym for shit which originated from Ireland.
     * A shi'ite, that is, a believer in Shi'a Islam
     * The shite, the principal character in a Japanese Noh play
     * Shite, the person who performs the technique in Aikido.
     * Shite the Industrial band with strong Techno roots.


FYI:
"shite" is a very common term in Australia (excluding recent migrants, 
most Australians have some Irish ancestry). It's not just a less 
offensive spelling, there's a definite nuance. If you drop off the 'e', 
the meaning would be different, it would convey a lot more anger.



 Mar 08 2006



  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Don Clugston wrote:

 Georg Wrede wrote:
 

 Surely a person has a right to say "Windows XP is shite" without



  From Wikipedia, the free encyclopedia:

 The word shite may refer to various things

     * A synonym for shit which originated from Ireland.
     * A shi'ite, that is, a believer in Shi'a Islam
     * The shite, the principal character in a Japanese Noh play
     * Shite, the person who performs the technique in Aikido.
     * Shite the Industrial band with strong Techno roots.


 
 
 FYI:
 "shite" is a very common term in Australia (excluding recent migrants, 
 most Australians have some Irish ancestry). It's not just a less 
 offensive spelling, there's a definite nuance. If you drop off the 'e', 
 the meaning would be different, it would convey a lot more anger.


How does one pronounce it?



 Mar 08 2006



 next sibling parent  "Derek Parnell" <derek psych.ward>  writes:


On Wed, 08 Mar 2006 22:14:27 +1100, Georg Wrede <georg.wrede nospam.org>  
wrote:


 Don Clugston wrote:

 Georg Wrede wrote:


 Surely a person has a right to say "Windows XP is shite" without



  From Wikipedia, the free encyclopedia:

 The word shite may refer to various things

     * A synonym for shit which originated from Ireland.
     * A shi'ite, that is, a believer in Shi'a Islam
     * The shite, the principal character in a Japanese Noh play
     * Shite, the person who performs the technique in Aikido.
     * Shite the Industrial band with strong Techno roots.


   FYI:
 "shite" is a very common term in Australia (excluding recent migrants,  
 most Australians have some Irish ancestry). It's not just a less  
 offensive spelling, there's a definite nuance. If you drop off the 'e',  
 the meaning would be different, it would convey a lot more anger.


 How does one pronounce it?


It rhymes with "light".

-- 
Derek Parnell
Melbourne, Australia



 Mar 08 2006



prev sibling  parent  John C <johnch_atms hotmail.com>  writes:


Georg Wrede wrote:

 Don Clugston wrote:
 

 Georg Wrede wrote:


 Surely a person has a right to say "Windows XP is shite" without




  From Wikipedia, the free encyclopedia:

 The word shite may refer to various things

     * A synonym for shit which originated from Ireland.
     * A shi'ite, that is, a believer in Shi'a Islam
     * The shite, the principal character in a Japanese Noh play
     * Shite, the person who performs the technique in Aikido.
     * Shite the Industrial band with strong Techno roots.




 FYI:
 "shite" is a very common term in Australia (excluding recent migrants, 
 most Australians have some Irish ancestry). It's not just a less 
 offensive spelling, there's a definite nuance. If you drop off the 
 'e', the meaning would be different, it would convey a lot more anger.


 
 
 How does one pronounce it?


"shight" - it rhymes with height, light, fight.

Synonymous, I would say, with "crap".



 Mar 08 2006



prev sibling  parent reply Lars Ivar Igesund <larsivar igesund.net>  writes:


Hasan Aljudy wrote:

 
 I think there are far more people unhappy with linux than there are
 people unhappy with windows.
 
 Go to any computer science lecture room/theater, and ask students who
 uses windows and who uses linux! I think windows will always win, at
 least in my university!
 
 Even better, ask how many people have linux installed, then ask those
 people, how many of you actually use it?
 One prof asked us this question once; about 13 people raised their hands
 for "I installed linux on my machine", and only _one_ person raised his
 hand for "I actually use it!".


Sorry, but this is the wrong way around the issue.

Those who use Linux are seldomly unhappy about it, because most of them
chose it themselves. The rest won't even try because they know Windows (not
necessarily to be a good system, just know), and don't like change. And
most people, even if they heard of Linux, have no idea what it do, so how
can they be unhappy about it?

My workplace clearly shows that even with major efforts to create stable
images for large organizations, standard PC configurations, etc, Windows is
not what you would call a stable system. It works fine for most, and
servers seldomly crash, but seeing it every day at work, I'm now quite
positive that I won't ever use it at home again for anything but games.

How stable we as ppl confident in our computer skills thinks windows is, has
absolutely no bearing whatsoever. My Windows systems, from Windows 3.10 and
upto Windows XP SP1, have all been stable (admittedly, I've never had
Windows ME), but I believe that is because I can act relatively sensible
when something unexpected happen. Most users don't act sensible.



 Feb 01 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Lars Ivar Igesund wrote:

 
 My workplace clearly shows that even with major efforts to create stable
 images for large organizations, standard PC configurations, etc, Windows is
 not what you would call a stable system. It works fine for most, and
 servers seldomly crash, but seeing it every day at work, I'm now quite
 positive that I won't ever use it at home again for anything but games.


I've never much liked the way IT does Windows configurations at work--I 
find my home setup to be far more stable.  But then I also seem to be 
the only one in the company with stability issues.  Go figure.


 How stable we as ppl confident in our computer skills thinks windows is, has
 absolutely no bearing whatsoever. My Windows systems, from Windows 3.10 and
 upto Windows XP SP1, have all been stable (admittedly, I've never had
 Windows ME), but I believe that is because I can act relatively sensible
 when something unexpected happen. Most users don't act sensible.


True enough.


Sean



 Feb 01 2006



prev sibling next sibling parent  "Tony" <ignorethis nowhere.com>  writes:


"Matthew" <matthew stlsoft.com> wrote in message 
news:drp4ao$2d8o$1 digitaldaemon.com...

 ----- Original Message ----- 
 From: "Hasan Aljudy" <hasan.aljudy gmail.com>
 Newsgroups: digitalmars.D
 Sent: Wednesday, February 01, 2006 12:11 PM
 Subject: Re: copy/paste XP cmd



 Ameer Armaly wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:drm2bl$vtf$1 digitaldaemon.com...


Matthew wrote:


Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


 Same here; I've gotten it to hold up since June of 04 with no problems 
 whatsoever.  But then again, I've been known for beeing a complete Nazi 
 as to what goes in and out of my computer.


 XP is perfectly stable .. the only time it crashes on me is due to 
 hardware faults.


 Well, I have it on two machines. It lasted one year on the laptop before
 going totally squiffy and requiring a reinstall. On the desktop it's been
 installed for 3 years, but every few months one less things works - I just
 can't face the reinstallation headache, so I use the Win2K boot.

 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


I used Ghost to create a series of partition images immediately after 
installing XP and my standard suite of apps.

Every now and then I use Ghost to restore a pristine XP image (which takes 
about 15 minutes at the most).

I haven't experienced any stability problems with XP and I believe it is due 
to this.  It also means that I don't hesitate to install software 
temporarily, as I know I can easily revert to a known good Windows XP image.

Tony
Melbourne, Australia 



 Jan 31 2006



prev sibling  parent reply Don Clugston <dac nospam.com.au>  writes:


Matthew wrote:

 ----- Original Message ----- 
 From: "Hasan Aljudy" <hasan.aljudy gmail.com>
 Newsgroups: digitalmars.D
 Sent: Wednesday, February 01, 2006 12:11 PM
 Subject: Re: copy/paste XP cmd
 
 
 

Ameer Armaly wrote:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drm2bl$vtf$1 digitaldaemon.com...



Matthew wrote:



Thanks for that. Now I can just hate XP because it crashes, and three 
months
after each re-install it decides that some COM object somewhere is 
missing
so it can no longer save Word or Excel documents (or let you copy their
contents).


Weird.  XP has turned out to be at least as stable as 2000 for me.


Same here; I've gotten it to hold up since June of 04 with no problems 
whatsoever.  But then again, I've been known for beeing a complete Nazi 
as to what goes in and out of my computer.


XP is perfectly stable .. the only time it crashes on me is due to 
hardware faults.


 
 
 Well, I have it on two machines. It lasted one year on the laptop before
 going totally squiffy and requiring a reinstall. On the desktop it's been
 installed for 3 years, but every few months one less things works - I just
 can't face the reinstallation headache, so I use the Win2K boot.
 
 While I'm happy for you and Sean that you have no major issues, 3 does not
 make a statistical sample, and in any case 33% of users thinking your
 product is a stinking pile of overengineered crap might make your sales
 manager happy, but it sure shouldn't make the head of development proud.


I'm with you. I find XP to be completely unstable. XP-SP2, anyway (The 
original XP Pro was OK). It seems less stable than even Win95 
(admittedly, the hardware now is much more sophisticated).
Particularly annoying about SP2 is the fact that Ctrl-Alt-Delete no 
longer kills programs instantly.

I never get blue screens, though. It just freezes.

Maybe it's only the Australian XP that's a disaster :-)



 Feb 01 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Don Clugston wrote:

 
 I'm with you. I find XP to be completely unstable. XP-SP2, anyway (The 
 original XP Pro was OK). It seems less stable than even Win95 
 (admittedly, the hardware now is much more sophisticated).
 Particularly annoying about SP2 is the fact that Ctrl-Alt-Delete no 
 longer kills programs instantly.
 
 I never get blue screens, though. It just freezes.


This sounds like a hardware problem to me.  The freezes I've had in the 
past have been in games and are typically attributable to the video or 
audio drivers.  I've also had spontaneous resets, though not with my 
latest PC setup.


Sean



 Feb 01 2006



 next sibling parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:drqpmf$1cj5$1 digitaldaemon.com...

 This sounds like a hardware problem to me.  The freezes I've had in the 
 past have been in games and are typically attributable to the video or 
 audio drivers.  I've also had spontaneous resets, though not with my 
 latest PC setup.


The last time I had big problems with XP randomly failing, freezing, 
mysterious messages, replacing the memory card fixed it. 



 Feb 01 2006



prev sibling  parent  Don Clugston <dac nospam.com.au>  writes:


Sean Kelly wrote:

 Don Clugston wrote:
 

 I'm with you. I find XP to be completely unstable. XP-SP2, anyway (The 
 original XP Pro was OK). It seems less stable than even Win95 
 (admittedly, the hardware now is much more sophisticated).
 Particularly annoying about SP2 is the fact that Ctrl-Alt-Delete no 
 longer kills programs instantly.

 I never get blue screens, though. It just freezes.


 
 
 This sounds like a hardware problem to me.  The freezes I've had in the 
 past have been in games and are typically attributable to the video or 
 audio drivers.  I've also had spontaneous resets, though not with my 
 latest PC setup.


No, these seem related to networking. The way it handles wireless 
networks and VPNs is particularly bad. I think that most of the problems 
lie in Internet Explorer; the timeouts in that program are just insane. 
In fact, the shell is still using the same ridiculous algorithm they 
used in Windows 3.0 in the days of floppy disks, where it insists on 
confirming that each drive still exists before doing anything (instead, 
that should be done in a background thread; you only need to wait for 
the disk to respond if you are actually using that disk).

When I say "it freezes", it's usually not a complete system hang. It 
does actually recover -- eventually. Oddly, hitting ctrl-alt-delete to 
bring up the task manager usually seems to reset the timeouts, the 
'dead' programs revive about 5 seconds after exiting task manager (even 
when I haven't done anything).



 Feb 02 2006



prev sibling  parent reply Tom S <h3r3tic remove.mat.uni.torun.pl>  writes:


Sean Kelly wrote:

 Matthew wrote:

 (Of course, I'll have to do this every time I'm using a cmd box with a 
 different title, so it's not a complete panacea for what ails me.) 


 
 
 True.  I have a bunch of shortcuts to different command configurations, 
 so for it it was simply a matter of setting this option for each one. 
 I'm not sure if this would work for command windows popped up by visual 
 studio, however.


Oh come on... After less than a single minute of googling I've found this:
http://windows.about.com/library/tips/bltip130.htm


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/



 Jan 30 2006



  parent  "Matthew" <matthew stlsoft.com>  writes:


"Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message 
news:drm9o4$18tj$1 digitaldaemon.com...

 Sean Kelly wrote:

 Matthew wrote:

 (Of course, I'll have to do this every time I'm using a cmd box with a 
 different title, so it's not a complete panacea for what ails me.)



 True.  I have a bunch of shortcuts to different command configurations, 
 so for it it was simply a matter of setting this option for each one. I'm 
 not sure if this would work for command windows popped up by visual 
 studio, however.


 Oh come on... After less than a single minute of googling I've found this:
 http://windows.about.com/library/tips/bltip130.htm


Nice one. :-)



 Jan 30 2006