On 12/27/11 9:51 AM, Torarin wrote:
> 2011/12/27 Joshua Reusch<yoschi@arkandos.de>:
>> Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
>>>
>>>
>>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>>
>>>
>>> Andrei
>>
>>
>> -------------
>> import std.algorithm;
>>
>> void main() {
>>         auto arr = [0, 5, 4, 3, 2, 1];
>>         sort!((a, b) =>  a<  b)(arr);
>> }
>> -------------
>> $ ./dmd lambda_test
>> dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *)
>> &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
>> fd))))&&  old_size == 0) || ((unsigned long) (old_size)>= (unsigned
>> long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
>> (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t))) - 1)))&&
>> ((old_top)->size&  0x1)&&  ((unsigned long)old_end&  pagemask) == 0)'
>> failed.
>> $
>>
>>
>> This also "works" with other functions from std.algorithm.
>
> Did you do a clean before compiling? I forgot, and got the same error.
>
> Torarin

I confirm the new syntax works after a rebase and clean rebuild.

Andrei

On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu wrote:
> On 12/27/11 9:51 AM, Torarin wrote:
>> 2011/12/27 Joshua Reusch<yoschi@arkandos.de>:
>>> $ ./dmd lambda_test
>>> dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *)
>>> &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
>>> fd))))&&  old_size == 0) || ((unsigned long) (old_size)>= (unsigned
>>> long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
>>> (sizeof(size_t))) - 1))&  ~((2 * (sizeof(size_t))) - 1)))&&
>>> ((old_top)->size&  0x1)&&  ((unsigned long)old_end&  pagemask) == 0)'
>>> failed.
>>
>> Did you do a clean before compiling? I forgot, and got the same error.
>
> I confirm the new syntax works after a rebase and clean rebuild.

I've always wondered how dmd manages to do that.
It's well known that dmd gives you a nut kick if you try to compile D code incrementally.
But even the dmd source itself has to be rebuilt every time if you don't want strange errors and that's C++.

I don't even know if it's a laughing matter or not.

"Alex Rønne Petersen" <xtzgzorex@gmail.com> wrote in message news:jdckl1$1hfb$1@digitalmars.com...
>
> Or perhaps even better, when we get fully working UFCS:
>
> auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);
>

That is just beautiful.

On 12/27/11 10:50 AM, Trass3r wrote:
> On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu wrote:
>> On 12/27/11 9:51 AM, Torarin wrote:
>>> 2011/12/27 Joshua Reusch<yoschi@arkandos.de>:
>>>> $ ./dmd lambda_test
>>>> dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
>>>> (((char *)
>>>> &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
>>>> malloc_chunk,
>>>> fd))))&& old_size == 0) || ((unsigned long) (old_size)>= (unsigned
>>>> long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
>>>> (sizeof(size_t))) - 1))& ~((2 * (sizeof(size_t))) - 1)))&&
>>>> ((old_top)->size& 0x1)&& ((unsigned long)old_end& pagemask) == 0)'
>>>> failed.
>>>
>>> Did you do a clean before compiling? I forgot, and got the same error.
>>
>> I confirm the new syntax works after a rebase and clean rebuild.
>
> I've always wondered how dmd manages to do that.
> It's well known that dmd gives you a nut kick if you try to compile D
> code incrementally.
> But even the dmd source itself has to be rebuilt every time if you don't
> want strange errors and that's C++.
>
> I don't even know if it's a laughing matter or not.

I think it's a makefile matter.

Andrei

Wouldn't it be great if Santa were to give us named arguments this year too? :)

On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
> On 12/27/11 10:50 AM, Trass3r wrote:
>> But even the dmd source itself has to be rebuilt every time if you don't
>> want strange errors and that's C++.
>>
>> I don't even know if it's a laughing matter or not.
>
> I think it's a makefile matter.

The makefile for dmd doesn't have the dependencies on .h files set up properly. If a .h file is changed, the thing to do is make clean and then build.

(Even when I do set up the .h file dependencies right, bit rot creeps in and wastes my time trying to figure out what went wrong. I just make clean and rebuild.)

On 12/27/2011 2:51 AM, deadalnix wrote:
> Maybe I'll seem bitter, but I do not think this changement was really that
> important. This is nice, ok, but we have some other really serious flaw, like
> shared not doing what it is supposed to do.

Technically, it is not important at all. It adds zero power and functionality. All it is is a simple syntactical rewrite within the compiler to the old syntax.

However, and this is a big however, aesthetically it is a large improvement. People using many diverse languages have made it clear that this is the preferred syntax for lambdas. They expect to see it, or else they mark D as "not having lambdas" and "not supporting functional programming".

Syntax matters.

On 12/27/11 12:03 PM, Walter Bright wrote:
> On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
>> On 12/27/11 10:50 AM, Trass3r wrote:
>>> But even the dmd source itself has to be rebuilt every time if you don't
>>> want strange errors and that's C++.
>>>
>>> I don't even know if it's a laughing matter or not.
>>
>> I think it's a makefile matter.
>
> The makefile for dmd doesn't have the dependencies on .h files set up
> properly. If a .h file is changed, the thing to do is make clean and
> then build.
>
> (Even when I do set up the .h file dependencies right, bit rot creeps in
> and wastes my time trying to figure out what went wrong. I just make
> clean and rebuild.)

Problem is lack of automation (in this case makdepend). As usual, I have an optimistic view on the help that automation can bring to our project.

Andrei

On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:
> Imagine how bitter I am that the string lambda syntax didn't catch on!

As I told Andrei last night, I think it was a great experiment. Sure, it failed, but it was a great idea, technically sound, and the fact that it worked is a testament to D's power.

If we're not willing to try things like that, we've failed in a much grander sense.

So I have no regrets at all about that.

On 12/27/2011 7:21 AM, dsimcha wrote:
> On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
>> On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu wrote:
>>> Imagine how bitter I am that the string lambda syntax didn't catch on!
>>>
>>> Andrei
>>
>> Please tell me they're not going anywhere. I **really** don't want to deal
>> with those being deprecated.
>
> ...and they were kind of useful in that you could introspect the string and
> apply optimizations depending on what the lambda was. I wrote a sorting function
> that introspected the lambda that was passed to it. If it was "a < b", "a<b", "a
>  > b", etc., and the array to be sorted was floating point, it punned and bit
> twiddled the floats/doubles to ints/longs, sorted them and bit twiddled and
> punned them back.

It's not going anywhere, though it likely will disappear from the sample code.