Fixed several reported bugs.

ftp://ftp.digitalmars.com/dmdalpha.zip

Walter asked me to post this part of a private response here.

Phobos compiles nicely now, thanks.

I converted the Python random module over to D [and attached it]. Observations coming out of this.

If the private keyword is attached to a module symbol, that symbol shouldn't be included in import.  This would be useful to keep namespace pollution down and minimise the necessity for obfuscated symbol names.  This would also be very useful for linking to the CRT without exporting the otherwise useless symbols.  In fact, this is necessary to avoid conflicts: date and math conflict with one another; they both export floor.

swap(a, b) would be nice as a kind of compile-time statement.

Default arguments would be nice.  Most of the time I can get around them (and most of the time I couldn't use them even if they were there), but there's that 1% that is really a pain to deal with.

Some kind of printf that returns the result would be very nice.
fmt(), say.  Such as: [snip code]

shuffle is missing [from the class I converted].  This randomizes the entries of an array in place.  I think this should wait for a kind of template system; for example, choice could be implemented as:

    $type choice($type[] array) { return array[range(array.length)]; }

Much shorter than anything you can do in C++, and I think clearer. Not to mention it being impossible in C++ to my knowledge.  Such methods, of course, cannot be virtual or overloaded.

As to structs and classes, C++'s facility isn't too bad.  Isn't too great either (much too much ugly), but I can't think of a better way.

I collided with a bunch of array problems that caused internal errors. I'll collect a couple of test cases and pipe them to you.

(4 % 1.0) returns -nan.  The documentation is ambiguous as to whether modulus should work here, but it sure doesn't, and there's no facility for doing it otherwise.  I pull in fmod for the interim.

Suddenly have a need for bignums.  It can wait, not really an important part of the RNG.

Not right now, but my later use of D will be conditional on operator overloading.  It's too important for 3D games work.  Just in case you thought that games programmers could accept a language without operator overloading; we can't, period, full stop.  I'm sure mathematics programmers are even more adamant about it.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:mcercusasglvehmssbnrhq475h7ashsh51@4ax.com...
> If the private keyword is attached to a module symbol, that symbol shouldn't be included in import.  This would be useful to keep namespace pollution down and minimise the necessity for obfuscated symbol names.  This would also be very useful for linking to the CRT without exporting the otherwise useless symbols.  In fact, this is necessary to avoid conflicts: date and math conflict with one another; they both export floor.

Not sure what you mean.
    private import foo;
??

> swap(a, b) would be nice as a kind of compile-time statement.

I'd rather reserve that as a test case for implementing generics.

> Default arguments would be nice.  Most of the time I can get around them (and most of the time I couldn't use them even if they were there), but there's that 1% that is really a pain to deal with.

There was a looong thread about that!


> Some kind of printf that returns the result would be very nice.
> fmt(), say.  Such as: [snip code]

Yes, a D-ized version of printf is needed.


> I collided with a bunch of array problems that caused internal errors. I'll collect a couple of test cases and pipe them to you.

Ok, I want to fix them.

> (4 % 1.0) returns -nan.  The documentation is ambiguous as to whether modulus should work here, but it sure doesn't, and there's no facility for doing it otherwise.  I pull in fmod for the interim.

Ak! (It should work.)

> Not right now, but my later use of D will be conditional on operator overloading.  It's too important for 3D games work.  Just in case you thought that games programmers could accept a language without operator overloading; we can't, period, full stop.  I'm sure mathematics programmers are even more adamant about it.

A lot of people have asked for it. You're probably right.

"Walter" <walter@digitalmars.com> wrote in message news:aal1h8$23cc$2@digitaldaemon.com...

> Not sure what you mean.
>     private import foo;
> ??

Import foo for your own use (other modules don't see it).

> > swap(a, b) would be nice as a kind of compile-time statement.
>
> I'd rather reserve that as a test case for implementing generics.

Earlier, I suggested a swap operator:

    a <-> b

On Mon, 29 Apr 2002 20:01:49 -0700, "Walter" <walter@digitalmars.com> wrote:

>"Burton Radons" <loth@users.sourceforge.net> wrote in message news:mcercusasglvehmssbnrhq475h7ashsh51@4ax.com...
>> If the private keyword is attached to a module symbol, that symbol shouldn't be included in import.  This would be useful to keep namespace pollution down and minimise the necessity for obfuscated symbol names.  This would also be very useful for linking to the CRT without exporting the otherwise useless symbols.  In fact, this is necessary to avoid conflicts: date and math conflict with one another; they both export floor.
>
>Not sure what you mean.
>    private import foo;
>??

Whoops, I forgot all about static.  All I meant was static in the C source file tradition, but applicable to any symbol.

>> swap(a, b) would be nice as a kind of compile-time statement.
>
>I'd rather reserve that as a test case for implementing generics.

Sure.  In my style that would be, I think:

void swap(inout $what a, inout $what b) { $what c = a; a = b; b = c; }

>> Default arguments would be nice.  Most of the time I can get around them (and most of the time I couldn't use them even if they were there), but there's that 1% that is really a pain to deal with.
>
>There was a looong thread about that!

Okay, I'll search the archives.  4639 messages takes awhile to get through.  :-)

>> Some kind of printf that returns the result would be very nice.
>> fmt(), say.  Such as: [snip code]
>
>Yes, a D-ized version of printf is needed.

Speak of the devil.  Working on it this very moment.  It's going to be wchar through and through if you don't mind.

>> I collided with a bunch of array problems that caused internal errors. I'll collect a couple of test cases and pipe them to you.
>
>Ok, I want to fix them.

    class gap
    {
        this(char[3] cad) { }
    }

    unittest
    {
        char[3] foo;
        gap g;

        g = new gap(foo);
    }

Reports "Internal error: ..\ztc\cod1.c 2390" using 0.30.  Uh... I'll have to do more testing, I got a couple others, but I think it was always the same internal error.  Note that normal functions take the array just fine.

[snip]

On Mon, 29 Apr 2002 20:57:44 -0700, Burton Radons <loth@users.sourceforge.net> wrote:

>On Mon, 29 Apr 2002 20:01:49 -0700, "Walter" <walter@digitalmars.com> wrote:
>>"Burton Radons" <loth@users.sourceforge.net> wrote in message news:mcercusasglvehmssbnrhq475h7ashsh51@4ax.com...
>>> Some kind of printf that returns the result would be very nice.
>>> fmt(), say.  Such as: [snip code]
>>
>>Yes, a D-ized version of printf is needed.
>
>Speak of the devil.  Working on it this very moment.  It's going to be wchar through and through if you don't mind.

This demands a little more explanation since a feature this affecting deserves a debate.  I'd like to hear what people want from this thing.

Internally the class structure is such.  FormatFlags holds code data, such as for a "%4d", including all the information.  FormatType handles the code types, such as a class for "%s" and "%S". FormatParser brings it together, and there's an instance of that class used internally by fmt (a variant of printf that returns the parsed result).  Only FormatFlags is public, the rest are internal.

Restricted compilation won't have any troubles; just do the same checking that GCC does of the arguments in printf.  It's a super handy feature that I really miss while working in Windows.

I think that "%s" and "%S" should expect char[] and wchar[] respectively by default, since we rarely deal with char* and wchar*. If necessary you can force one of those by using "%+s" and "%+S". Perhaps even that should be removed.

For printing objects we use "%o".  This calls the new toFormat (?) method of the object, sending it the FormatFlags so that it can do tricky things to it.  Normally this would just call toString.

Oh, and a string without any other limits on it defaults to (wchar*);
I was kind of expecting (wchar[]).  So this is incorrect in the
current release:

    fmt ("%d blue borg%S", count, count == 1 ? "" : "s");

Instead it would have to be:

    fmt ("%d blue borg%+S", count, count == 1 ? "\0" : "s\0");

or:

    fmt ("%d blue borg%S", count, (wchar[]) (count == 1 ? "" : "s"));

Uh, that is, if you can do that cast.  Perhaps it would have to be:

    fmt ("%d blue borg%S", count, count == 1 ? (wchar[]) "" :
(wchar[]) "s");

In any case, none of these are as convenient as the first version.

"%ld" is our long (64-bit) in my implementation, rather than C's weird mechanism.  I don't handle short or bit, ideas?  What about byte and ubyte?  What about complex and extended?

I'm currently done except for floating point and lots and lots of unittesting.  I'll have to get DJGPP's source for FP, tricky stuff.

On Mon, 29 Apr 2002 23:51:35 -0700, Burton Radons <loth@users.sourceforge.net> wrote:

>On Mon, 29 Apr 2002 20:57:44 -0700, Burton Radons
><loth@users.sourceforge.net> wrote:
>"%ld" is our long (64-bit) in my implementation, rather than C's weird
>mechanism.  I don't handle short or bit, ideas?  What about byte and
>ubyte?  What about complex and extended?

Whoops, short, bit, byte, and ubyte should be casted into 32-bit integers by dmd so never mind.

I think that extended could be supported using l, so "%lg" is an extended.  I have no idea what to do with complex; perhaps it should be a flag, such as #, so "%#f" is a complex using f formatting.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:5jascu4ff6rrdbhd5iptdo81mgvvoao4cj@4ax.com...

> I think that "%s" and "%S" should expect char[] and wchar[] respectively by default, since we rarely deal with char* and wchar*.

Agreed. D strings are char[] and wchar[].

> If necessary you can force one of those by using "%+s" and "%+S". Perhaps even that should be removed.

I'd leave it for some sort of compatibility (just when you need
to print an LPSTR =))

> For printing objects we use "%o".  This calls the new toFormat (?) method of the object, sending it the FormatFlags so that it can do tricky things to it.  Normally this would just call toString.

Format flags on object - how'd this look?..

    Apple apple;
    fmt("%o", apple);

Where do I put those flags here?

> Oh, and a string without any other limits on it defaults to (wchar*);
> I was kind of expecting (wchar[]).  So this is incorrect in the
> current release:
>
>     fmt ("%d blue borg%S", count, count == 1 ? "" : "s");
>
> Instead it would have to be:
>
>     fmt ("%d blue borg%+S", count, count == 1 ? "\0" : "s\0");

Hm... I thought string literals are of type char[] (or wchar[])...

> "%ld" is our long (64-bit) in my implementation, rather than C's weird mechanism.  I don't handle short or bit, ideas?  What about byte and ubyte?  What about complex and extended?

byte and short are converted to int when passing to vararg-functions, so
no need to worry about it. You could add a bit type (%b?), so
it'd print "true" and "false", but I guess it is passed as
int as well.

extended should be %lf, %lg, or %le, I think. imaginary could be %If, %Ig and %Ce, and complex - %Cf, %Cg and %Ce.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:5jascu4ff6rrdbhd5iptdo81mgvvoao4cj@4ax.com...
> I'll have to get DJGPP's source for FP, tricky stuff.

Be careful about the copyright/license status of DJGPP's source.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:mcercusasglvehmssbnrhq475h7ashsh51@4ax.com...
> (4 % 1.0) returns -nan.  The documentation is ambiguous as to whether modulus should work here, but it sure doesn't, and there's no facility for doing it otherwise.  I pull in fmod for the interim.

Ok, I have it fixed now. Will go out in the next update.