On Saturday, 15 February 2014 at 20:31:07 UTC, Andrei Alexandrescu wrote:
>> Not a DIP, it's more like a direction/focus thing. In my opinion we must
>> focus this year on:
>>
>> * Less garbage
>>
>> * Address null pointers at language level
>>
>> * Finish the language, in particular shared & comp
>>
>> * Do something about this(this) that is less complicated than the Space
>> Shuttle
>>
>> * And of course quality, quality, quality
>
> Slipped my mind:
>
> * Finalize portable shared lib support on Unixen, OSX, and Windows
>
>
> Andrei

So how do we communicate/achieve these?
I think having a newsgroup thread about this year's goals would be a good start, to get everyone on the same page.

On Sunday, 16 February 2014 at 18:02:24 UTC, Martin Nowak wrote:

> So how do we communicate/achieve these?
> I think having a newsgroup thread about this year's goals would be a good start, to get everyone on the same page.

Maybe with some additional reflection i.e. in the Wiki? You know how these threads can be derailed or otherwise become a mess to search for anything :)

On 2/16/14, 10:02 AM, Martin Nowak wrote:
> On Saturday, 15 February 2014 at 20:31:07 UTC, Andrei Alexandrescu wrote:
>>> Not a DIP, it's more like a direction/focus thing. In my opinion we must
>>> focus this year on:
>>>
>>> * Less garbage
>>>
>>> * Address null pointers at language level
>>>
>>> * Finish the language, in particular shared & comp
>>>
>>> * Do something about this(this) that is less complicated than the Space
>>> Shuttle
>>>
>>> * And of course quality, quality, quality
>>
>> Slipped my mind:
>>
>> * Finalize portable shared lib support on Unixen, OSX, and Windows
>>
>>
>> Andrei
>
> So how do we communicate/achieve these?
> I think having a newsgroup thread about this year's goals would be a
> good start, to get everyone on the same page.

Feel free to paste these in a wiki page. Experience suggests that me telling people what I think is important and must be done has very limited impact.

I've made no secret about what I think are important topics for D at any time, and often each had one or a few people who'd be obviously best positioned to work on. Yet each person continued to work on whatever itch they wanted scratched, which is entirely understandable.


Andrei

Am 11.02.2014 06:58, schrieb Sean Kelly:
> On Saturday, 8 February 2014 at 16:46:26 UTC, Stanislav Blinov wrote:
>> Also, on a related note, is there any benefit in having core.sync
>> primitives not final? What would be a use case to inherit from e.g.
>> Mutex or Condition? GC does that with Mutex, but only to devirtualize
>> all methods :)
>>
>> Maybe we should also consider making them final along the way?
>
> Probably.  The new std.concurrency patch overrides Condition, but mostly
> for convenience.  I think those methods not being virtual was an
> oversight on my part.

vibe.d currently (ab)uses this fact to be able to use its own mutex class as object monitors and for use in synchronized blocks. I agree that they should generally be final, but please let's add another way to plug in there when doing such a change.

On Monday, 17 February 2014 at 02:22:10 UTC, Andrei Alexandrescu wrote:

> Feel free to paste these in a wiki page. Experience suggests that me telling people what I think is important and must be done has very limited impact.

I'd hazard a guess that this is in part because whatever consensus reached at any given point doesn't always find its way to publicity and only stays in mind of people involved in the discussion and buried in NG postings. Wiki at least can help in that regard.

> I've made no secret about what I think are important topics for D at any time, and often each had one or a few people who'd be obviously best positioned to work on. Yet each person continued to work on whatever itch they wanted scratched, which is entirely understandable.

Not everyone is fond of taking initiative, that's a known fact. Me, I'm tired of seeing new big features and ideas popping up when there's so much unfinished business in the language, runtime and Phobos. When I left this NG (two years ago?) 'shared' was an infant, today it's just a tad more than that. Without clearly defined (and supported by the runtime) 'shared' I can't see how allocators can be finalized, which in turn also influences that GC/ARC/whatever shennanigans... So I'm willing to help make it better to the extent of my mental capacity. But again, this thread will soon be buried deep, a more concrete and focused discussion begs for another type of media.

On Monday, 17 February 2014 at 08:29:41 UTC, Sönke Ludwig wrote:

> vibe.d currently (ab)uses this fact to be able to use its own mutex class as object monitors and for use in synchronized blocks. I agree that they should generally be final, but please let's add another way to plug in there when doing such a change.

I'd suggest putting this on hold until the time for that transition to default-final starts. It'd be an ideal moment to re-evaluate this need of inheritance. :)

>
> Not everyone is fond of taking initiative, that's a known fact. Me, I'm tired of seeing new big features and ideas popping up when there's so much unfinished business in the language, runtime and Phobos. When I left this NG (two years ago?) 'shared' was an infant, today it's just a tad more than that. Without clearly defined (and supported by the runtime) 'shared' I can't see how allocators can be finalized, which in turn also influences that GC/ARC/whatever shennanigans... So I'm willing to help make it better to the extent of my mental capacity. But again, this thread will soon be buried deep, a more concrete and focused discussion begs for another type of media.

Let me tell you the people why that is happening. It is because we are trying to solve problems without dividing into small chunks. This is a problem in my life, many people lives, and also businesses. If we just say that let's solve X problems (shared, GC, etc. whatever it is), without properly "defining" what small steps to be taken, what are trying to achieve, who will work on which part, people will continue talking without any achievement, and same topics come front of us again and again. The reason why project managers exist is this.

We need better documentation as Todo's, charts etc. Exempli gratia, I haven't seen any gantt chart like thing. It is not obvious where we are going. If a ship doesn't have a destination, no wind can help it.

Am Sat, 08 Feb 2014 08:46:47 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> We should add finalizing shared to our H1 goals.

Yes.

Am Sat, 15 Feb 2014 06:55:46 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> I meant first half of the year. I don't think it fits the Agenda, which is release-focused.
> 
> Andrei

I take your word on it!

I am really trying to _use_ shared, but when not even a Mutex or Condition is shared and making it so leads to horrible head-aches few people will use it, even fewer will understand it and there is no one there to do something about it.

-- 
Marco

Am Sat, 08 Feb 2014 16:46:25 +0000
schrieb "Stanislav Blinov" <stanislav.blinov@gmail.com>:

> Also, on a related note, is there any benefit in having core.sync primitives not final? What would be a use case to inherit from e.g. Mutex or Condition? GC does that with Mutex, but only to devirtualize all methods :)
> 
> Maybe we should also consider making them final along the way?

I did once inherit from Mutex to add a reentrancy counter.
This can be used in a Logger, to prevent one thread to
endlessly recurse into logging functions. Like when logging
causes and error that is logged which causes the same error
again, which is logged, ...
If the reentrancy counter is > 1 after locking, you can
special case around that and just print something to stderr
directly or delegate to a less error prone logger.

-- 
Marco