On 7/30/12 11:03 AM, Don Clugston wrote:
> On 30 July 2012 16:28, Andrei Alexandrescu<andrei@erdani.com>  wrote:
>> On 7/30/12 10:27 AM, David Simcha wrote:
>>>
>>> So is http://d.puremagic.com/issues/show_bug.cgi?id=8428  officially a
>>> wontfix for this release?
>>
>>
>> I think it's quite important we fix that one and its ilk.
>
> Bug 5939 seems to be a Phobos design flaw, and this one is probably related.
> Unfortunately, I don't think we can fix the problem other than by
> ripping all Voldemort types out of Phobos. Voldemort Types now appear
> to be a concept that has tragically flawed semantics, and also has
> poor performance (see
> http://d.puremagic.com/issues/show_bug.cgi?id=5939). Removing them
> would be a big change to make this late in a release cycle.
> I don't know what to do here.

OK, let's step back for just a second here.

The first response to https://github.com/D-Programming-Language/phobos/pull/728 is it reflects a problem with the compiler.

My conjecture (and please correct me if I'm wrong) is there should be no difference between a Voldemort static struct (emphasis on STATIC, which is not currently used in map) and a classic struct defined outside map. I'm saying this because I see no difference in what state is available and how code would be generated between the two. It's a simple name visibility issue.

If that's correct, the fix in https://github.com/D-Programming-Language/phobos/pull/728 should simply add "static" to the Voldemorts, and implement the same functionality that it's currently implementing.

Longer term, it has become obvious to me that we need a clear and simple mechanism for a function to save another function passed by alias, even if that function holds state. That must happen regardless of interaction with Voldemort types. We must have a mean do e.g. define a scope delegate that holds the alias function and is able to call it. This has been a long-standing problem that we've avoided in limited cases by relying on the built-in frame pointer.


Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2012/7/31 kenji hara <k.hara.pg@gmail.com>:
> 2012/7/31 Don Clugston <dclugston@gmail.com>:
>> On 30 July 2012 16:28, Andrei Alexandrescu <andrei@erdani.com> wrote:
>>> On 7/30/12 10:27 AM, David Simcha wrote:
>>>>
>>>> So is http://d.puremagic.com/issues/show_bug.cgi?id=8428  officially a wontfix for this release?
>>>
>>>
>>> I think it's quite important we fix that one and its ilk.
>>
>> Bug 5939 seems to be a Phobos design flaw, and this one is probably related.
>> Unfortunately, I don't think we can fix the problem other than by
>> ripping all Voldemort types out of Phobos. Voldemort Types now appear
>> to be a concept that has tragically flawed semantics, and also has
>> poor performance (see
>> http://d.puremagic.com/issues/show_bug.cgi?id=5939). Removing them
>> would be a big change to make this late in a release cycle.
>> I don't know what to do here.
>
> I completely agree. Voldemort type is a good idiom, but cannot control the context pointer.
>
> I think it requires such enhancement for the compiler. http://d.puremagic.com/issues/show_bug.cgi?id=8463
>
> Kenji Hara

I've posted a pull for Phobos. https://github.com/D-Programming-Language/phobos/pull/728

Kenji Hara
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2012/7/31 Andrei Alexandrescu <andrei@erdani.com>:
> On 7/30/12 11:03 AM, Don Clugston wrote:
>>
>> On 30 July 2012 16:28, Andrei Alexandrescu<andrei@erdani.com>  wrote:
>>>
>>> On 7/30/12 10:27 AM, David Simcha wrote:
>>>>
>>>>
>>>> So is http://d.puremagic.com/issues/show_bug.cgi?id=8428  officially a wontfix for this release?
>>>
>>>
>>>
>>> I think it's quite important we fix that one and its ilk.
>>
>>
>> Bug 5939 seems to be a Phobos design flaw, and this one is probably
>> related.
>> Unfortunately, I don't think we can fix the problem other than by
>> ripping all Voldemort types out of Phobos. Voldemort Types now appear
>> to be a concept that has tragically flawed semantics, and also has
>> poor performance (see
>> http://d.puremagic.com/issues/show_bug.cgi?id=5939). Removing them
>> would be a big change to make this late in a release cycle.
>> I don't know what to do here.
>
>
> OK, let's step back for just a second here.
>
> The first response to https://github.com/D-Programming-Language/phobos/pull/728 is it reflects a problem with the compiler.
>
> My conjecture (and please correct me if I'm wrong) is there should be no difference between a Voldemort static struct (emphasis on STATIC, which is not currently used in map) and a classic struct defined outside map. I'm saying this because I see no difference in what state is available and how code would be generated between the two. It's a simple name visibility issue.
>
> If that's correct, the fix in https://github.com/D-Programming-Language/phobos/pull/728 should simply add "static" to the Voldemorts, and implement the same functionality that it's currently implementing.

Unfortunately no. 'static nested struct' never have any frame pointers, so

auto map(alias pred, Range)(Range r) {
  static struct Result {
    .. auto front() { return pred(...); }
  }
}

if pred is a nested function and requires its frame pointer to call it, Result cannot access it.

> Longer term, it has become obvious to me that we need a clear and simple mechanism for a function to save another function passed by alias, even if that function holds state. That must happen regardless of interaction with Voldemort types. We must have a mean do e.g. define a scope delegate that holds the alias function and is able to call it. This has been a long-standing problem that we've avoided in limited cases by relying on the built-in frame pointer.

The fundamental problem is the same as this.

Issue 5710 - cannot use delegates as parameters to non-global template http://d.puremagic.com/issues/show_bug.cgi?id=5710


Kenji Hara
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 7/30/12 12:25 PM, kenji hara wrote:
> Unfortunately no. 'static nested struct' never have any frame pointers, so
>
> auto map(alias pred, Range)(Range r) {
>    static struct Result {
>      .. auto front() { return pred(...); }
>    }
> }
>
> if pred is a nested function and requires its frame pointer to call
> it, Result cannot access it.

Got it. So is it correct to say that global structs templated with alias sometimes save their frame pointers, sometimes not? If so, could you please give a few more details on how that choice is made?

>> Longer term, it has become obvious to me that we need a clear and simple
>> mechanism for a function to save another function passed by alias, even if
>> that function holds state. That must happen regardless of interaction with
>> Voldemort types. We must have a mean do e.g. define a scope delegate that
>> holds the alias function and is able to call it. This has been a
>> long-standing problem that we've avoided in limited cases by relying on the
>> built-in frame pointer.
>
> The fundamental problem is the same as this.
>
> Issue 5710 - cannot use delegates as parameters to non-global template
> http://d.puremagic.com/issues/show_bug.cgi?id=5710

It would be quite a bummer if we can't address this limitation somehow.


Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2012/7/31 Andrei Alexandrescu <andrei@erdani.com>:
> On 7/30/12 12:25 PM, kenji hara wrote:
>>
>> Unfortunately no. 'static nested struct' never have any frame pointers, so
>>
>> auto map(alias pred, Range)(Range r) {
>>    static struct Result {
>>      .. auto front() { return pred(...); }
>>    }
>> }
>>
>> if pred is a nested function and requires its frame pointer to call it, Result cannot access it.
>
>
> Got it. So is it correct to say that global structs templated with alias sometimes save their frame pointers, sometimes not? If so, could you please give a few more details on how that choice is made?

Yes, that's right.
I've post a more detail to explain it.
http://d.puremagic.com/issues/show_bug.cgi?id=8463#c7

>>> Longer term, it has become obvious to me that we need a clear and simple
>>> mechanism for a function to save another function passed by alias, even
>>> if
>>> that function holds state. That must happen regardless of interaction
>>> with
>>> Voldemort types. We must have a mean do e.g. define a scope delegate that
>>> holds the alias function and is able to call it. This has been a
>>> long-standing problem that we've avoided in limited cases by relying on
>>> the
>>> built-in frame pointer.
>>
>>
>> The fundamental problem is the same as this.
>>
>> Issue 5710 - cannot use delegates as parameters to non-global template http://d.puremagic.com/issues/show_bug.cgi?id=5710
>
>
> It would be quite a bummer if we can't address this limitation somehow.

I agree, but it seems to me that is fairly difficult...

Kenji Hara
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 7/30/12, Walter Bright <walter@digitalmars.com> wrote:
> http://ftp.digitalmars.com/dmd2beta.zip

I don't know where I'm getting this error from, it seems to be arbitrarily triggered (but this was in the first beta too):

D:\DMD\dmd2\windows\bin\..\..\src\druntime\import\core\memory.d(33): Error: undefined identifier size_t

Anyone know what that's about, and why it usually compiles fine?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 7/30/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Anyone know what that's about, and why it usually compiles fine?

Nevermind I remember it now, this is unrelated to the beta. When you have a module named 'object', regardless of what package its in (foo.bar.object) it will silently hijack druntime's object.d : http://d.puremagic.com/issues/show_bug.cgi?id=7651

That's closed, but the compiler could at least trigger a better error
message if it finds another object.d laying around..
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 7/30/2012 7:25 AM, Andrej Mitrovic wrote:
> How come this 64bit ABI is so hard to implement right? I'm just curious.
>


It doesn't fit in with the way that dmd generates code. I did not anticipate that structs could be passed in arbitrary combinations of gp and fp registers.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 7/30/2012 7:27 AM, David Simcha wrote:
> So is http://d.puremagic.com/issues/show_bug.cgi?id=8428 officially a wontfix for this release?  (I know there's another bug report relevant to its underlying cause, but the changes made to std.algorithm still expose this and break existing code.)

So far, I don't know what the problem with that one is. I just pushed out another beta because we've fixed the others.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I'm getting a weird error:

Error: function goldie.token.Token.line () is not callable using
argument types ()

A no-arg function isn't callable with no args?

I'm working on getting a small test case.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta