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

 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

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


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


 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


 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


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


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


 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: if line =~ /^# include <#{projectName}/#{projectName}.h>/ This matches "line" against a format whereby the begins (^ anchors the search at the start of the line) with "# include <" and then contains the string equal to the "projectName" variable, followed by "/", followed by the string equal to the "projectName", followed by ".h>". In other words it matches includes such as "# include <stlsoft/stlsoft.h>" and "# include <comstl/comstl.h>" but not "# include <comstl/error_functions.h>" nor "# 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: if line =~ /^# include <#{projectName}/#{projectName}.h>/ This matches "line" against a format whereby the begins (^ anchors the search at the start of the line) with "# include <" and then contains the string equal to the "projectName" variable, followed by "/", followed by the string equal to the "projectName", followed by ".h>". In other words it matches includes such as "# include <stlsoft/stlsoft.h>" and "# include <comstl/comstl.h>" but not "# include <comstl/error_functions.h>" nor "# 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<#{1}/#{1}.h>")(projectname, line) ) { } (not sure about the syntax for #{1} ). which is eminently possible right now, or do we need to go further? if (line.matches!("^#include<#{1}/#{1}.h>")(projectname) ){ } or even something like: if (matches!("^#include<#{projectname}/#{projectname}.h>")(line) ){ } (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<#{1}/#{1}.h>")(projectname, line) ) {
 
 }
 
 (not sure about the syntax for #{1} ).
 which is eminently possible right now, or do we need to go further?
 
 if (line.matches!("^#include<#{1}/#{1}.h>")(projectname) ){
 }
 
 or even something like:
 
 if (matches!("^#include<#{projectname}/#{projectname}.h>")(line) ){
 }
 
 (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<#{1}/#{1}.h>")(projectname, line) ) {

 }

 (not sure about the syntax for #{1} ).
 which is eminently possible right now, or do we need to go further?

 if (line.matches!("^#include<#{1}/#{1}.h>")(projectname) ){
 }

 or even something like:

 if (matches!("^#include<#{projectname}/#{projectname}.h>")(line) ){
 }

 (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<#{1}/#{1}.h>")(projectname, line) ) {

 }

 (not sure about the syntax for #{1} ).
 which is eminently possible right now, or do we need to go further?

 if (line.matches!("^#include<#{1}/#{1}.h>")(projectname) ){
 }

 or even something like:

 if (matches!("^#include<#{projectname}/#{projectname}.h>")(line) ){
 }

 (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:


    if line =~ /^# include <#{projectName}/#{projectName}.h>/

In D: import std.regexp; if (find(line, r"^# include <#{projectName}/#{projectName}.h>") != -1) ...
    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:


    if line =~ /^# include <#{projectName}/#{projectName}.h>/

In D: import std.regexp; if (find(line, r"^# include <#{projectName}/#{projectName}.h>") != -1) ...

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:


    if line =~ /^# include <#{projectName}/#{projectName}.h>/

In D: import std.regexp; if (find(line, r"^# include <#{projectName}/#{projectName}.h>") != -1) ...

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

I see what you mean. It should be: if (find(line, "^# include <" ~ projectName ~ "/" ~ projectName ~ ".h>") != -1) using string concatenation. Or: if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)
Jan 30 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 using string concatenation. Or:
 
     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)

I think you meant: if (find(line, format("^# include <%s/%s.h>", projectName, 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:

     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)

I think you meant: if (find(line, format("^# include <%s/%s.h>", projectName, projectName)) != -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:

     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)

I think you meant: if (find(line, format("^# include <%s/%s.h>", projectName, projectName)) != -1)

Oops!

This is why I have a function that does this ... Expand("# include <{pn}/{pn}.h>", "pn=" ~ projectName) 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 ...

   Expand("# include <{pn}/{pn}.h>", "pn=" ~ projectName)

 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

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

 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

 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

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

 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

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

 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

 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,

 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

 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

 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

 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)

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

 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 puts "Processed #{fe.path}" 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


 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


 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

 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

 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

 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
         puts "Processed #{fe.path}"
     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
        puts "Processed #{fe.path}"
    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
        puts "Processed #{fe.path}"
    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

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

 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

 until I see exactly what it's doing.

Go wild
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

 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

 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

 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


 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


 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

 that the PNG project uses ZLIB, etc.

 Similarly for Open-RJ, b64, and some of my other libraries that are not

 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

 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

 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



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



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

 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

 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

 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

 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

 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

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

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.

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 no harddisk wipes and reinstalls since then. (See footnote #1)
 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: (#1) In discussions of Windows one usually means the time one last "formatted the hard drive"((#2)), whereas in Linux discussions this means "last powered down, or rebooted" the machine. (#2) The concept of "formatting" in Windows (or MSDOS) roughly 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.

"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