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

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

Please post a full working example program. What's below doesn't compile:

    listdir_test2.d(32): constructor std.regexp.RegExp.this (char[],char[])
does not match argument types (char[])
    listdir_test2.d(32): Error: expected 2 arguments, not 1

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsogst$2u8b$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dsod98$2o63$1@digitaldaemon.com...
> > Go wild
>
> Thanks. Let's have some fun with the analysis! Here's your version:
> -------------------------------------------------
> import std.file;
> import std.stdio;
> import std.string;
>
> int main()
> {
>  char[]  PATTERNS =
> "*.h;*.rb;*.hpp;*.java;*.d;*.py;*.vbs;*.c;*.cpp;*.cxx;*.idl;*.odl;*.rc";
> // char[]  ROOT  = "H:/dev";
>  char[]  ROOT  = "H:/";
> // char[]  ROOT  = "H:/freelibs/openrj/current";
>  char[][] filters  = split(PATTERNS, ";");
>  int   n   = 0;
>
>  foreach(char[] pattern; filters)
>  {
> //  writefln("pattern: %s", pattern);
>
>   char[][] fs = listdir(ROOT, pattern);
>
>   foreach(char[] fe; fs)
>   {
> //   writefln("File: %s", fe);
>    ++n;
>   }
>  }
>
>  printf("Number: %d\n", n);
>
>  return 0;
> }
> --------------------------------------------------
> There are 13 patterns searched for, so 13 trips through listdir. Taking
your
> numbers, the D version takes roughly 6 times longer to run than the Ruby one. I adapted it slightly to my system so I could run it, and set it up
for
> 8 patterns:
> --------------------------------------------------
> import std.file;
> import std.stdio;
> import std.string;
>
> int main()
> {
>     char[]   PATTERNS = "*.h;*.hpp;*.bak;*.d;*.vbs;*.c;*.cpp;*.exe";
>     char[]   ROOT     = r"c:\cbx";
>     char[][] filters  = split(PATTERNS, ";");
>     int n             = 0;
>
>     foreach(char[] pattern; filters)
>     {
> //      writefln("pattern: %s", pattern);
>
>         char[][] fs = listdir(ROOT, pattern);
>
>         foreach(char[] fe; fs)
>         {
> //          writefln("File: %s", fe);
>             ++n;
>         }
>     }
>
>     printf("Number: %d\n", n);
>
>     return 0;
> }
> --------------------------------------------------
> As I think I said previously, the listdir one used in D just does the (primitive) fnmatch to do the pattern match, which is intended to behave like the operating system wildcard matching behavior. It does not support "OR" patterns. But we can write our own to use regular expressions, as in:
> ---------------------------------------------------
> import std.file;
> import std.stdio;
> import std.string;
>
> int main()
> {
>     char[] pattern = r"\.(h|hpp|bak|d|vbs|c|cpp|exe)$";
>     char[] ROOT = r"c:\cbx";
>     int    n    = 0;
>
> //  writefln("pattern: %s", pattern);
>
>     char[][] fs = listdir(ROOT, pattern);
>
>     foreach(char[] fe; fs)
>     {
> //      writefln("File: %s", fe);
>         ++n;
>     }
>
>     printf("Number: %d\n", n);
>
>     return 0;
> }
>
> import std.regexp;
>
> char[][] listdir(char[] pathname, char[] pattern)
> {   char[][] result;
>     auto r = new RegExp(pattern);
>
>     bool callback(DirEntry* de)
>     {
>         if (de.isdir)
>             std.file.listdir(de.name, &callback);
>         else
>         {   if (r.test(de.name))
>                 result ~= de.name;
>         }
>         return true; // continue
>     }
>
>     std.file.listdir(pathname, &callback);
>     return result;
> }
> ----------------------------------------------------
> There's only one trip through listdir(). What are the numbers?
>
> Matthew's: 2.67
> Walter's: 0.36
>
> Interestingly, that shows a 7.4 times speedup, but 8 patterns. This
implies
> that the D version might be perhaps twice as fast as the Ruby one on your system. (I don't have Ruby on my system.) This post is long enough, I'll provide more design commentary in another post.
>
>

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

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.

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

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

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;
>> }

"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

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