On 7/10/2014 6:55 AM, Andrei Alexandrescu wrote:
> On 7/10/14, 12:21 AM, Walter Bright wrote:
>> On 7/10/2014 12:03 AM, deadalnix wrote:
>>> So runtime error or php style better anything than nothing for
>>> something that
>>> can be checked statically...
>>
>> I don't understand your comment.
>
> It's very simple. The semantics you propose is move with the syntax of copy.
> Following the implicit move, the source of it is surprisingly modified (emptied).

Right, that is what I proposed.

> That doesn't work. There is a humongous body of knowledge accumulated in C++
> with std::auto_ptr. That artifact has been quite the show, including people who
> swore by it (!). We'd do good to simply draw from that experience instead of
> reenacting it.

I accept that you're right, but I don't know why. I perused the link you provided earlier, and wasn't too enlightened.

It was clear from those links that unique_ptr<T> is working successfully - what is different about that?

On Thursday, 10 July 2014 at 16:55:34 UTC, H. S. Teoh via Digitalmars-d wrote:
>
> Since we're on this topic, I wish somebody would review this PR:
>
> 	https://github.com/D-Programming-Language/phobos/pull/2276

I'm not familiar enough with algoFormat to say that I've "reviewed it."
In retrospect, adding that as comment would have been better than silence.

> Some of these bugs have been
> around for a while, and only recently have I found the time to actually
> do something about it... only to get ignored. Other than some comments
> from bearophile, I've seen no comments from anyone else, and it's been
> almost 2 weeks, so right now I don't even know what else to do.
>
> I suspect this is one of the problems (perceived or otherwise) with the
> current PR process. A lot of work is just sitting there without even an
> acknowledgement from a bystander, so to speak, and the few that do get
> some attention, after comments have been addressed, continue to sit
> there with no indication of whether the change is unacceptable, or
> uninteresting, or interesting but people are too busy to look at it, or
> what. Sometimes I just stare at the PR page day after day asking, is
> something missing? Do people expect any other changes?  Are people too
> busy to even look at it? Even a casual remark as "I'll get around to
> this on the weekend (or next month, or, for that matter, next *year*)"
> would help bolster morale significantly. Letting things sit in limbo
> without so much as a comment, says, intentionally or not, that we just
> don't care, and that's very discouraging to potential contributors.

This is exactly the typical contributor experience.

> Now I'm not saying this with any bitterness, and, having a full-time job
> myself plus countless other responsibilities with family, etc., I
> totally understand that sometimes people are just too busy to respond.

It's difficult to believe that everybody is too busy to review PRs yet have ample time to invest in the most futile of forum discussions.

On 7/10/2014 9:00 AM, Nick Treleaven wrote:
> On 09/07/2014 20:55, Walter Bright wrote:
>>> here's the first one,
>>> to disable postblit:
>>>
>>> https://github.com/D-Programming-Language/phobos/pull/2308
>
> BTW I updated that pull, should be less muddled now ;-)
>
>> More things that need to happen with Unique:
> ...
>>    Unique!(int*) u = new int;   // must work
>
> That works, it's spelled:
>
> Unique!int u = new int;

I'm unconfortable with that design, as T can't be a class ref or a dynamic array.


>>    int* p = new int;
>>    Unique!(int*) u = p;         // must fail
>
> The existing design actually allows that, but nulls p:
> [...]
> If there are aliases of p before u is constructed, then u is not the sole owner
> of the reference (mentioned in the docs):
> http://dlang.org/phobos-prerelease/std_typecons.html#.Unique

Exactly. It is not checkable and not good enough.

Note that as of 2.066 the compiler tests for uniqueness of an expression by seeing if it can be implicitly cast to immutable. It may be possible to do that with Unique without needing compiler modifications.


> Also related is whether we use alias this to expose the resource (allowing
> mutation but not replacement) or if we use opDispatch. Currently, it uses opDot,
> which AFAICT is basically opDispatch. If we use alias this, that's a(nother)
> hole exposing non-unique access to the resource.

The holes must be identified and closed.

BTW, I'm amenable to adjusting the compiler to recognize Unique and help out as a last resort.

On 7/10/2014 8:13 AM, Sean Kelly wrote:
> On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
>> On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu wrote:
>>> We already have actor-style via std.concurrency. We also have fork-join
>>> parallelism via std.parallel. What we need is a library for CSP.
>>
>> The actor-style via std.concurrency is only between 'heavyweight' threads
>> though, no? Even if lightweight threads may be overhyped, part of the appeal
>> of Go and Erlang is that one can spawn tens of thousands of threads and it
>> 'just works'. It allows the server model of 'one green thread/actor per
>> client', which has a certain appeal in its simplicity. Akka similarly uses its
>> own lightweight threads, not heavyweight JVM threads.
>
> No.  I've had an outstanding pull request to fix this for quite a while now.  I
> think there's a decent chance it will be in the next release.  To be fair, that
> pull request mostly provides the infrastructure for changing how concurrency is
> handled.  A fiber-based scheduler backed by a thread pool doesn't exist yet,
> though it shouldn't be hard to write (the big missing piece is having a dynamic
> thread pool).  I was going to try and knock one out while on the airplane in a
> few days.

Sean, it is awesome that you are taking charge of this. I can't think of anyone more perfect for the job!

On 7/10/2014 6:51 AM, Andrei Alexandrescu wrote:
> On 7/9/14, 11:59 PM, deadalnix wrote:
>> On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
>>>>> 8. NotNull!T type
>>>>>
>>>>> For those that want a non-nullable reference type. This should be
>>>>> doable
>>>>> as a library type.
>>>> No.
>>>
>>> Rationale?
>>
>> Please, we've gone through this again and again and again and again.
>
> Yes, the arguments come and go by in forum discussions. To avoid this we need a
> well-written DIP that has a section illustrating the insufficiencies of library
> solutions, and then proposes the few needed additions to the language that make
> the thing work properly. Other language communities have done this with good
> results.

Yup. Otherwise this will come up again and again and again and again. :-)

On 7/9/2014 4:57 PM, H. S. Teoh via Digitalmars-d wrote:
> I'm sure there are plenty of holes in this proposal, so destroy away.
> ;-)

How about making a DIP out of this?

(And thanks for making a proposal!)

On 7/10/2014 3:34 AM, Dicebot wrote:
> On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
>> Is CDGC's Luca's earlier work on concurrent GC?
> Yes.

Great!


>>> I'd state it differently: "Marketing fuss about goroutines is the killer feature
>>> of Go" :) It does not have any fundamental advantage over existing actor model
>>> and I doubt it will matter _that_ much.
>>
>> Much of the froth about Go is dismissed by serious developers, but they nailed
>> the goroutine thing. It's Go's killer feature.
>
> Who are "they"?

I've heard it multiple times from people I trust. Sorry I can't be more specific.


> I don't know any serious developer who praises goroutines if he
> was not a CSP fan before. I forsee that it will make no impact for D because we
> simply don't have resources to advertise it as killing feature (on a same scale
> Go did).

Will it be a killer feature for D? No. But it is a valuable feature, and it looks to me like we can implement it without great effort, and without any language changes. If it can stop a major client from saying "we're going to use Go instead of D because of this" then it is worth it.


> You are totally missing the point if you consider this even comparable
> replacement. Reason why non-nullable types are awesome because you are 100% sure
> compiler will force you to handle null cases and if program compiles it is
> guaranteed to be safe in that regard. What you propose makes hardly any difference.

I'll risk annoying everyone by repeating at this point "what do you propose". Making non-null pointers the default is going to break every D program and so is not acceptable.

On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via Digitalmars-d wrote:
> On Thursday, 10 July 2014 at 16:55:34 UTC, H. S. Teoh via Digitalmars-d
[...]
> >I suspect this is one of the problems (perceived or otherwise) with the current PR process. A lot of work is just sitting there without even an acknowledgement from a bystander, so to speak, and the few that do get some attention, after comments have been addressed, continue to sit there with no indication of whether the change is unacceptable, or uninteresting, or interesting but people are too busy to look at it, or what. Sometimes I just stare at the PR page day after day asking, is something missing? Do people expect any other changes?  Are people too busy to even look at it? Even a casual remark as "I'll get around to this on the weekend (or next month, or, for that matter, next *year*)" would help bolster morale significantly. Letting things sit in limbo without so much as a comment, says, intentionally or not, that we just don't care, and that's very discouraging to potential contributors.
> 
> This is exactly the typical contributor experience.

Which we must change if we're going to increase D adoption. Unfortunately, I don't see any good solution to this, except just hoping for more contributors to pick up different pieces of Phobos as their "passion" and become the "lieutenant" for that part of it. But that requires first of all that contributors are motivated to contribute, yet the current situation isn't encouraging them to join in. It's a vicious cycle, and I don't know how to break it.


> >Now I'm not saying this with any bitterness, and, having a full-time job myself plus countless other responsibilities with family, etc., I totally understand that sometimes people are just too busy to respond.
> 
> It's difficult to believe that everybody is too busy to review PRs yet have ample time to invest in the most futile of forum discussions.

Well, that's just because futile forum discussions take almost no effort, while reviewing PRs requires the actual use of brain cells! ;-) As somebody once said, talk is cheap, and whining is actually free. Reviewing PRs, OTOH, requires one to actually sit down and look at real code and think over it. Not that it's a valid excuse, but this *is* a volunteer community, and people aren't going to do what they're asked to do, only what they're interested to do.


T

-- 
The richest man is not he who has the most, but he who needs the least.

On Thursday, 10 July 2014 at 18:25:56 UTC, H. S. Teoh via
Digitalmars-d wrote:
> On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via
>> 
>> This is exactly the typical contributor experience.
>
> Which we must change if we're going to increase D adoption.
> Unfortunately, I don't see any good solution to this, except just hoping
> for more contributors to pick up different pieces of Phobos as their
> "passion" and become the "lieutenant" for that part of it. But that
> requires first of all that contributors are motivated to contribute, yet
> the current situation isn't encouraging them to join in. It's a vicious
> cycle, and I don't know how to break it.

I think part of this will have to come from a policy change
regarding pull requests.  I propose that any pull request must
either be merged or rejected within one month of submission.  I'd
rather see a request rejected with an explanation than for it to
languish in revision hell for months or years while people slowly
iterate on changes.  It's better in my minds to submit a request,
have it rejected with comments, fix and resubmit multiple times
than to have pull requests just sitting in the queue forever with
no one knowing what their status is.

On 7/10/2014 8:50 AM, Andrei Alexandrescu wrote:
> On 7/10/14, 7:54 AM, Dicebot wrote:
>>> E.g.
>> https://github.com/D-Programming-Language/phobos/pull/1527 is some
>> apparently work that's just sitting there abandoned.
>>
>> Hm, slightly OT: is it considered widely acceptable to take over such
>> pull requests by reopening rebased one with identical content? I presume
>> Boost licensing implies so but not sure everyone else expects the same.
>
> That's totally on topic! I think it's fair game to take over pull requests of
> which authors did not respond to repeated pings. -- Andrei

Yup. Just include a link to the old one in your reboot of it, so the original author gets credit/blame for their work, even if they've disappeared.