http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

Why are there biguintcore.d, biguintnoasm.d and biguintx86.d both in std and std.internal.math?

They should not be in std. Just delete them.

On a somewhat related topic -- Andrei commented out the unit tests in
biguintcore and biguintx86 (search for @@ to find them) stating that
they fail on OSX.
They certainly pass on Windows, and they are unchanged since the last
release. Can someone with access to OSX please uncomment them, and
confirm that they fail? If they're failing, I think it can only mean
we have an OSX-specific wrong-code regression, which we need to solve.

And on another topic: there's a bug here which is a bit hard to believe:
3461 Unittests and assert don't work at all (Mac D1 only)
Has anybody tested D1 on OSX??  That bug is an absolute show-stopper
if it's still current.


On 9 August 2010 11:15, Trass3r <mrmocool at gmx.de> wrote:
> Why are there biguintcore.d, biguintnoasm.d and biguintx86.d both in std and
> std.internal.math?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

Thanks for the release, sorry to bring a bad news, but I still have a bus error (as with the previous beta) when compiling blip.parallel.smp.SmpModels with -O.

I have reduced it to
{{{
module bug;

enum TaskStatus:int{
     Building=-1,
}

/// conversion str -> TaskStatus
TaskStatus taskStatusFromStr(char[] s){
     char[] t="TaskStatus";
     if (s.length>t.length && s[0..t.length]==t){
         long res=0;
         if (s[t.length]=='-') res= -res;
         return cast(TaskStatus)cast(int)res;
     }
     assert(0);
}
}}}

with -O, and keeing something (so that res is not known at compile time) the cast seems to trigger an error in the compiler.

Fawzi
On 9-ago-10, at 08:19, Walter Bright wrote:

>
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Confirmed, that code gives a segfault on D1 Windows too. Works OK with D2.

On 9 August 2010 12:46, Fawzi Mohamed <fawzi at gmx.ch> wrote:
> Thanks for the release, sorry to bring a bad news, but I still have a bus error (as with the previous beta) when compiling blip.parallel.smp.SmpModels with -O.
>
> I have reduced it to
> {{{
> module bug;
>
> enum TaskStatus:int{
> ? ?Building=-1,
> }
>
> /// conversion str -> TaskStatus
> TaskStatus taskStatusFromStr(char[] s){
> ? ?char[] t="TaskStatus";
> ? ?if (s.length>t.length && s[0..t.length]==t){
> ? ? ? ?long res=0;
> ? ? ? ?if (s[t.length]=='-') res= -res;
> ? ? ? ?return cast(TaskStatus)cast(int)res;
> ? ?}
> ? ?assert(0);
> }
> }}}
>
> with -O, and keeing something (so that res is not known at compile time) the cast seems to trigger an error in the compiler.
>
> Fawzi
> On 9-ago-10, at 08:19, Walter Bright wrote:
>
>>
>> http://ftp.digitalmars.com/dmd1beta.zip
>> http://ftp.digitalmars.com/dmd2beta.zip
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

On 9-ago-10, at 12:37, Don Clugston wrote:

> They should not be in std. Just delete them.
>
> On a somewhat related topic -- Andrei commented out the unit tests in
> biguintcore and biguintx86 (search for @@ to find them) stating that
> they fail on OSX.
> They certainly pass on Windows, and they are unchanged since the last
> release. Can someone with access to OSX please uncomment them, and
> confirm that they fail? If they're failing, I think it can only mean
> we have an OSX-specific wrong-code regression, which we need to solve.

On tango, they fail on osx, since like forever, I had told you but
probably I should have made a more formal thing about it.
I sort of submitted a bug in http://dsource.org/projects/tango/ticket/1958

> And on another topic: there's a bug here which is a bit hard to
> believe:
> 3461 Unittests and assert don't work at all (Mac D1 only)
> Has anybody tested D1 on OSX??  That bug is an absolute show-stopper
> if it's still current.

unittest on mac *need* to be explicitly imported by the unittester to
be loaded/accessible.
I had submitted a bug about it, don't know where it went...
Not sure if it is a bug or a feature...

Fawzi

On 9 August 2010 13:23, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>
> On 9-ago-10, at 12:37, Don Clugston wrote:
>
>> They should not be in std. Just delete them.
>>
>> On a somewhat related topic -- Andrei commented out the unit tests in
>> biguintcore and biguintx86 (search for @@ to find them) stating that
>> they fail on OSX.
>> They certainly pass on Windows, and they are unchanged since the last
>> release. Can someone with access to OSX please uncomment them, and
>> confirm that they fail? If they're failing, I think it can only mean
>> we have an OSX-specific wrong-code regression, which we need to solve.
>
> On tango, they fail on osx, since like forever, I had told you but probably
> I should have made a more formal thing about it.
> I sort of submitted a bug in http://dsource.org/projects/tango/ticket/1958

OK, sounds like the unit tests may never have passed on OSX.
BTW you can now assume that none of the Phobos devs will look at
anything related to Tango. Compiler-related bug reports need to be
added to Bugzilla.

>> And on another topic: there's a bug here which is a bit hard to believe:
>> 3461 Unittests and assert don't work at all (Mac D1 only)
>> Has anybody tested D1 on OSX?? ?That bug is an absolute show-stopper
>> if it's still current.
>
> unittest on mac *need* to be explicitly imported by the unittester to be
> loaded/accessible.
> I had submitted a bug about it, don't know where it went...
> Not sure if it is a bug or a feature...

Sounds like a bug, especially when it works on D2.

On 9-ago-10, at 13:46, Don Clugston wrote:

> On 9 August 2010 13:23, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>>
>> On 9-ago-10, at 12:37, Don Clugston wrote:
>>
>>> [...]
>>> On a somewhat related topic -- Andrei commented out the unit tests
>>> in
>>> biguintcore and biguintx86 (search for @@ to find them) stating that
>>> they fail on OSX.
>>> They certainly pass on Windows, and they are unchanged since the
>>> last
>>> release. Can someone with access to OSX please uncomment them, and
>>> confirm that they fail? If they're failing, I think it can only mean
>>> we have an OSX-specific wrong-code regression, which we need to
>>> solve.
>>
>> On tango, they fail on osx, since like forever, I had told you but
>> probably
>> I should have made a more formal thing about it.
>> I sort of submitted a bug in http://dsource.org/projects/tango/ticket/1958
>
> OK, sounds like the unit tests may never have passed on OSX.
> BTW you can now assume that none of the Phobos devs will look at
> anything related to Tango. Compiler-related bug reports need to be
> added to Bugzilla.

I have always tried to reduce compiler bugs to lib independent bugs, and submit them

>>> And on another topic: there's a bug here which is a bit hard to
>>> believe:
>>> 3461 Unittests and assert don't work at all (Mac D1 only)
>>> Has anybody tested D1 on OSX??  That bug is an absolute show-stopper
>>> if it's still current.
>>
>> unittest on mac *need* to be explicitly imported by the unittester
>> to be
>> loaded/accessible.
>> I had submitted a bug about it, don't know where it went...
>> Not sure if it is a bug or a feature...
>
> Sounds like a bug, especially when it works on D2.

here it is
	http://d.puremagic.com/issues/show_bug.cgi?id=2726
Basically only the modules directly or indirectly included by the main
module (and about this I think that I also had issues connected with
the order with which the modules are passed to the compiler, at least
when compiling several at once, but I am not sure anymore) are
initialized.
Thus only those modules are "seen", and an empty main that does not
import anything would not test anything...

sure that it works with D2? It is intrinsically connected with how the module info is stored.

Fawzi

On Aug 9, 2010, at 6:37 AM, Don Clugston <dclugston at googlemail.com> wrote:

> On a somewhat related topic -- Andrei commented out the unit tests in ...

The practice of commenting out unit tests has always irked me. IMHO, it's a sign that D's unit testing framework really isn't good enough.

Code that gets commented out tends to get forgotten. That is exactly the opposite thing you'd want for a failing unit test.

I'm receiving a rather inscrutable compile time error on the following test program:

import std.stdio, std.algorithm, std.string;

void main() {
     auto file = filter!"a.length > 0"(
         File("foo.txt").byLine()
     );
}


Error: function std.algorithm.filter!("a.length > 0").filter!(ByLine!(char,char)).filter cannot access frame of function this

I have no idea what this error message means, but I know I've never seen it before.  AFAIK the only change to Filter since the last release has been adding a save() method.


On 8/9/2010 2:19 AM, Walter Bright wrote:
>
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>