On 9-ago-10, at 23:44, Walter Bright wrote:

> changeset 609

now the compiler seems to work well for me, it passes all tests...

Thanks
Fawzi
>
> Walter Bright wrote:
>> It's the negass. Working on a fix.
>>
>> Don Clugston wrote:
>>> 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.

I can't fix it for this release.

Andrei Alexandrescu wrote:
> I think that shouldn't be changed back; it is one of the first applications of a useful idiom.
>
> The compiler bugs and limitations making that example uncompilable should be addressed.
>
> Walter, could you please take a look and assess the situation? We discussed the matter briefly on the phone and you agreed that the code is correct.
>
>
> Andrei
>
> David Simcha wrote:
>> 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
>>>>
>>>
>>
>> _______________________________________________
>> 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 Monday, August 09, 2010 15:55:40 Walter Bright wrote:
> I can't fix it for this release.

Then it sounds like the changes to filter() should be reverted for this release and then restored before the next release with the compiler bug having been fixed. Personally, I found it _highly_ disruptive to have most of the forward ranges break with 2.047, and I sure don't want to have to tell my co-workers who are trying out D that they have to use the svn version of Phobos (and in this case, telling them to use the svn version wouldn't even fix the problem since it's an as-yet unfixed compiler bug). I have no problem with improvements to filter() or anything else in Phobos, but I think that we should avoid changes that break things in releases.

- Jonathan M Davis

Three choices:
  1) fix the compiler
  2) revert the changes in phobos
  3) release an ugly regression

I hope #3 isn't on the table..  #1 is obviously the better long term answer (assuming it's a compiler bug, I've not followed this thread much). #2 might be the better short term path.

I object to the use of "can't" though. :)

On Mon, 9 Aug 2010, Walter Bright wrote:

> Date: Mon, 09 Aug 2010 15:55:40 -0700
> From: Walter Bright <walter at digitalmars.com>
> Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Subject: Re: [dmd-beta] dmd 1.063 and 2.048 beta
> 
> I can't fix it for this release.
> 
> Andrei Alexandrescu wrote:
> > I think that shouldn't be changed back; it is one of the first applications of a useful idiom.
> > 
> > The compiler bugs and limitations making that example uncompilable should be addressed.
> > 
> > Walter, could you please take a look and assess the situation? We discussed the matter briefly on the phone and you agreed that the code is correct.
> > 
> > 
> > Andrei
> > 
> > David Simcha wrote:
> > > 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
> > > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> > 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 

On Monday, August 09, 2010 16:52:42 Brad Roberts wrote:
> I object to the use of "can't" though. :)

Well, if you assume that it has been decided that the release will go out within a certain time frame and that fixing the bug would take longer than that time frame, "can't" would indeed be correct. However, what you're probably looking for is something more along the lines of

"Given everything else that's on my plate which has higher priority and the fact that I'm going to take care of the higher priority issues first, I can't fix this bug in the time that I have prior to the release."

That's a lot more verbose though.

- Jonathan M Davis

On Mon, 9 Aug 2010, Jonathan M Davis wrote:

> On Monday, August 09, 2010 16:52:42 Brad Roberts wrote:
> > I object to the use of "can't" though. :)
> 
> Well, if you assume that it has been decided that the release will go out within a certain time frame and that fixing the bug would take longer than that time frame, "can't" would indeed be correct. However, what you're probably looking for is something more along the lines of
> 
> "Given everything else that's on my plate which has higher priority and the fact that I'm going to take care of the higher priority issues first, I can't fix this bug in the time that I have prior to the release."
> 
> That's a lot more verbose though.
> 
> - Jonathan M Davis

It's that I know that the release points are essentially completely arbitrary most of the time and that pushing it back a day or two is almost always a non-issue, other than just the desire to call it done and move onto the next cycle.

But if there's really a timing issue, then sure.

Agreed.  Tons of code would break for me if Filter stopped working.  I'd have to either skip this release or manually patch Phobos on all 4 of the DMD installations I have on various work and personal machines. Doing without Filter for a release is simply not an option for me.

On 8/9/2010 7:18 PM, Jonathan M Davis wrote:
> On Monday, August 09, 2010 15:55:40 Walter Bright wrote:
> 
>> I can't fix it for this release.
>> 
> Then it sounds like the changes to filter() should be reverted for this release and then restored before the next release with the compiler bug having been fixed. Personally, I found it _highly_ disruptive to have most of the forward ranges break with 2.047, and I sure don't want to have to tell my co-workers who are trying out D that they have to use the svn version of Phobos (and in this case, telling them to use the svn version wouldn't even fix the problem since it's an as-yet unfixed compiler bug). I have no problem with improvements to filter() or anything else in Phobos, but I think that we should avoid changes that break things in releases.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
> 

On 9 August 2010 22:41, Walter Bright <walter at digitalmars.com> wrote:
> Walter Bright wrote:
>> 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.
>>
>
> I checked, D_PIC is always set under OSX. In mars.c:
>
> #if TARGET_OSX
> ? global.params.pic = 1;
> #endif
>
> [...]
>
> ? if (global.params.pic)
> ? ? ? VersionCondition::addPredefinedGlobalIdent("D_PIC");

Good. Then there's some other problem, but it's not going to get fixed in this release. (I'm assuming that the unit tests never passed in previous releases). I've created bug 4610 for it. Would be great if someone could attach a disassembly listing of bigintx86.obj to that bug report, and I'll try to get it fixed for the next release.

Brad Roberts wrote:
>
> It's that I know that the release points are essentially completely arbitrary most of the time and that pushing it back a day or two is almost always a non-issue, other than just the desire to call it done and move onto the next cycle.
>
> But if there's really a timing issue, then sure.
>
> 

Dealing with nested function issues is one that's fraught with risk of breaking other things. It really should not be a last minute patch.

Can you please revert the change? I thought we were good by passing the unit tests.

Andrei Alexandrescu wrote:
> I think that shouldn't be changed back; it is one of the first applications of a useful idiom.
>
> The compiler bugs and limitations making that example uncompilable should be addressed.
>
> Walter, could you please take a look and assess the situation? We discussed the matter briefly on the phone and you agreed that the code is correct.
>
>
> Andrei
>
> David Simcha wrote:
>> 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
>>>>
>>>
>>
>> _______________________________________________
>> 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
>
>