February 13, 2006 Re: Why it's the libraries, the libraries, the libraries. (And good design ...) [was Re: Interesting language comparison on Digg] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | "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; } |
February 13, 2006 std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 |
February 13, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to jcc7 | "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)? |
February 13, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 13, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to jcc7 | "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. |
February 13, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | >> 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? |
February 14, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 14, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander | "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. |
February 14, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
February 14, 2006 Re: std.recls docs don't match what's in Phobos (was Re: Why it's the libraries...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | "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? |
Copyright © 1999-2021 by the D Language Foundation