On 6/1/2015 5:39 AM, Dicebot wrote:
> - Moving fibers between threads (though there is some hope that Liran managed to
> convince Walter it is a bad idea)

You two have made a good case. I'm on the fence :-)

On Monday, 1 June 2015 at 12:39:13 UTC, Dicebot wrote:
> - Going for kitchen sink Phobos (and distributing vibe.d as part of Phobos)

I thought we agreed to start with just Dub first.

> - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea)

How this isn't a bad idea? AFAIU the Go folks ran into the same problems: https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit

Steven Schveighoffer <schveiguy@yahoo.com> writes:

> On 6/1/15 11:40 AM, Dan Olson wrote:
>> "Dicebot" <public@dicebot.lv> writes:
>>
>>> - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea)
>>
>> I am interesting in this one.  What was the decision, that Fibers should or should not be allowed to migrate between threads?  Is the discussion in one of the recorded talks?
>>
>
> Walter said that fibers must be movable between threads, it was part of the AMA I think (day 1 final talk).

Just listened to it.  I would be interested to know applications where migrating Fibers across threads is a good thing.  I can imagine server load balancing over cores.  What else?

The issue I've been tripped up by with migrating Fibers is that compiler backends like LLVM and GCC do some nice optimizations with thread-locals on some targets that lead to incorrect code when a Fiber yields and comes back on a different thread.  To get it right, the compiler would have to assume that any function call could return on a different thread.

The solutions I can think of today are to: not optimize (not a good solution), or have a special compiler switch to not optimize TLS (not available in backend), or ensure Fibers don't access TLS vars (not sure how that could be done except by being careful), or don't migrate. Inlining makes being careful difficult because a function call before and after a yield may access the same TLS var, and compiler then decides to cache the TLS address in a register.

I have been prototyping a Fiber check that throws an exception on targets with this issue, and the developer can override it by setting a Fiber property, after promising to be careful.

http://forum.dlang.org/thread/onkyxucuuthaqxxbkoir@forum.dlang.org#post-m2d223wqa0.fsf:40comcast.net

On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote:
> DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago.
>
> We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic.
>
> We'll be back with details. See you there!
>
>
> Andrei

I'd like to thank Andrei, Walter and Chuck for the hard work of making this conference happen.
The conference was very well organized, with quality speakers and great atmosphere.

I'm very glad I was able to make it and get to meet parts of the great D community.

Berlin is very convenient for us (3:30 hr direct flight :) ) so I guess next year you'll get to see more of Weka.IO :)

See you, and thanks again!

Liran

On Monday, 1 June 2015 at 18:40:54 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 1 June 2015 at 18:25:02 UTC, Laeeth Isharc wrote:
>> Just out of curiosity, what are the evils of AST macros (or could you point me to something you like on the topic)?
>
> It turns all changes into breaking changes. It is something you only can add to a stable language without collateral damage.

Thanks.  Laeeth

On 2 June 2015 at 12:28, Liran Zvibel via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote:
>
>> DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago.
>>
>> We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic.
>>
>> We'll be back with details. See you there!
>>
>>
>> Andrei
>>
>
> I'd like to thank Andrei, Walter and Chuck for the hard work of making
> this conference happen.
> The conference was very well organized, with quality speakers and great
> atmosphere.
>
> I'm very glad I was able to make it and get to meet parts of the great D community.
>
> Berlin is very convenient for us (3:30 hr direct flight :) ) so I guess
> next year you'll get to see more of Weka.IO :)
>
> See you, and thanks again!
>
> Liran
>

I look forward to meeting you.

Iain

On Monday, 1 June 2015 at 18:25:02 UTC, Laeeth Isharc wrote:
> On Monday, 1 June 2015 at 12:39:13 UTC, Dicebot wrote:
>> On the other hand, AST macros have been officially rejected and that I like a lot :)
>
> Hi.
>
> Just out of curiosity, what are the evils of AST macros (or could you point me to something you like on the topic)?

There was extended discussion in old threads but short summary of my opinion is:

- allows implicit changes to language semantics (== learning new framework is effectively learning new language)
- overlaps in functionality with mixins for majority of use cases
- less intuitive to newcomers (though cleaner/safer to experienced programmers, I admit that)
- requires standard (and stable!) AST format

On Monday, 1 June 2015 at 21:02:17 UTC, Vladimir Panteleev wrote:
> On Monday, 1 June 2015 at 12:39:13 UTC, Dicebot wrote:
>> - Going for kitchen sink Phobos (and distributing vibe.d as part of Phobos)
>
> I thought we agreed to start with just Dub first.

"we"? :P

>> - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea)
>
> How this isn't a bad idea? AFAIU the Go folks ran into the same problems: https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit

Before running into problems they advertised how this is "the right thing to do" and it is very hard to fight Go marketing even if it is completely unreasonable >_<

On 2015-06-02 20:28, Dicebot wrote:

> - requires standard (and stable!) AST format

Is that a negative point? BTW, the compiler doesn't necessarily need to use the same API for the AST internally as exposed externally.

-- 
/Jacob Carlborg

On Tuesday, 2 June 2015 at 19:44:12 UTC, Jacob Carlborg wrote:
> On 2015-06-02 20:28, Dicebot wrote:
>
>> - requires standard (and stable!) AST format
>
> Is that a negative point? BTW, the compiler doesn't necessarily need to use the same API for the AST internally as exposed externally.

Yes, considering current official stance on breaking changes that is huge negative point. We are rather far from being able to tell what good stable AST format could be be in the long run.

Maintaining two different formats is a way to address that but I feel that effort required goes beyond the realm of realistic at that point.