On Aug 9, 2010, at 8:07 AM, Fawzi Mohamed <fawzi at gmx.ch> wrote:

> 
> On 9-ago-10, at 13:46, Don Clugston wrote:
> 
>> On 9 August 2010 13:23, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>>> 
>>> 
>>> 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
> 

It may have been the link to the Tango site that inspired the comment? Given the recent hard stance on using a Tango-like API, I can't blame anyone that avoids looking at Tango.

The Tango developers have actively isolated themselves. I can't imagine Walter or Sean going out of their way to support Tango again until there is an olive branch from the Tango maintainers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20100809/6dbc94c4/attachment.html>

On 9 August 2010 15:25, Jason House <jason.james.house at gmail.com> wrote:
> On Aug 9, 2010, at 8:07 AM, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>
> On 9-ago-10, at 13:46, Don Clugston wrote:
>
> On 9 August 2010 13:23, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>
> 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
>
> It may have been the link to the Tango site that inspired the comment? Given
> the recent hard stance on using a Tango-like API, I can't blame anyone that
> avoids looking at Tango.
> The Tango developers have actively isolated themselves. I can't imagine
> Walter or Sean going out of their way to support Tango again until there is
> an olive branch from the Tango maintainers.

I wasn't making a political comment, just stating a fact -- using the Tango database was never a terribly good way of reporting compiler bugs, now it's completely ineffective. It's annoying to have to look in multiple places for bug reports, anyway. I suspect there are some compiler and runtime bugs in the Tango database, it'd be great if someone could check through them, and report any missing ones in Bugzilla.

On 9 August 2010 14:07, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>
> 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

Thanks. Seems like this one just didn't copied into Bugzilla. Which is
a shame, because it's important.
Anyway, from looking at the code, I reckon that it's the
position-dependent code that's the problem. Is it possible that OSX
requires position independent code? I had always assumed that if it
did, D_PIC would always be set, but from looking at the compiler
source, it looks as if D_PIC is set only if it was set from the
command line.

Try going into bigintx86, and replacing "D_PIC" with "all". If the failing tests pass, that's the problem. And unless OSX has a concept of PIC, I think OSX should define D_PIC at all times.

Wait a minute, I see what's going on.  Why did someone decide to nest the Filter struct inside the filter() function?  Should this just be changed back?

On 8/9/2010 9:20 AM, David Simcha wrote:
> 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
>>
>

On 9-ago-10, at 15:25, Jason House wrote:

> On Aug 9, 2010, at 8:07 AM, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>
>>
>> On 9-ago-10, at 13:46, Don Clugston wrote:
>>
>>> On 9 August 2010 13:23, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>>>>
>>>> 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
>>
>
> It may have been the link to the Tango site that inspired the comment? Given the recent hard stance on using a Tango-like API, I can't blame anyone that avoids looking at Tango.
>
> The Tango developers have actively isolated themselves. I can't imagine Walter or Sean going out of their way to support Tango again until there is an olive branch from the Tango maintainers.

ok I haven't followed the tango related discussions, but I had my own
disagreements about tango that made me almost branch it (but D has
enough branches as it is, and I am not interested in mantaining yet
another branch).
In the end I just decided to be a tango user, and make a layer in blip
to insulate me from a too strong dependency on tango.
>

I just want to use D, sometime it is more complex than it should be :(. Anyway for D 1 I think that tango is a good choice, actually the only one for 64 bit at the moment...

Fawzi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20100809/c7f7b7d5/attachment-0001.html>

On 9-ago-10, at 15:55, Don Clugston wrote:

> On 9 August 2010 14:07, Fawzi Mohamed <fawzi at gmx.ch> wrote:
>>
>> 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
>
> Thanks. Seems like this one just didn't copied into Bugzilla. Which is a shame, because it's important.

This is a phobos bug, an I don't test phobos, just the compiler :)

> Anyway, from looking at the code, I reckon that it's the position-dependent code that's the problem. Is it possible that OSX requires position independent code? I had always assumed that if it did, D_PIC would always be set, but from looking at the compiler source, it looks as if D_PIC is set only if it was set from the command line.

>
> Try going into bigintx86, and replacing "D_PIC" with "all". If the failing tests pass, that's the problem. And unless OSX has a concept of PIC, I think OSX should define D_PIC at all times.

Yes osx needs position independent code, I have tried to replace D_PIC with IS_PIC and add

version(darwin){
     version=IS_PIC;
}
version(D_PIC){
     version=IS_PIC;
}

at the beginning of the file, but at least the tango version still fails with

tango.core.Exception.AssertException at tango.math.BigInt(406): Assertion failure

Fawzi
>

On 9-ago-10, at 16:29, Fawzi Mohamed wrote:

> [...]
> Yes osx needs position independent code, I have tried to replace
> D_PIC with IS_PIC and add

from experimenting with gdc and the atomic module I remember that I
had to completly free up ebx, as it holds the Position-independent
code base register.
Even pushing & popping it would not satisfy the gdc compiler (not sure
why, maybe becuase signal handlers might need it?)

In any case the abi is here

http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#/ /apple_ref/doc/uid/TP40002492-SW4

Don Clugston wrote:
>
> 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.
>
>
> 

Yes, I run the whole test suite on OSX for D1. assert()s and unittests work.

Don Clugston wrote:
> Try going into bigintx86, and replacing "D_PIC" with "all". If the failing tests pass, that's the problem. And unless OSX has a concept of PIC, I think OSX should define D_PIC at all times.
>
> 

PIC should be always on for OSX, and it's a bug if the version thing is not set for it.

Fawzi Mohamed wrote:
> On 9-ago-10, at 16:29, Fawzi Mohamed wrote:
>
>> [...]
>> Yes osx needs position independent code, I have tried to replace
>> D_PIC with IS_PIC and add
>
> from experimenting with gdc and the atomic module I remember that I
> had to completly free up ebx, as it holds the Position-independent
> code base register.
> Even pushing & popping it would not satisfy the gdc compiler (not sure
> why, maybe becuase signal handlers might need it?)
>
> In any case the abi is here
>
> http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4
>
>

The EBX must be preserved across function calls. That's the only restriction on its use. Whether within a function it is used as a base register or not is relevant only to that function, and is not part of the ABI.

dmd regenerates the base register contents as required.