On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu wrote:
> In the meantime, everybody's busy arguing the minutia of logo redesign. The length (not existence) of that thread is a piece of evidence of what's wrong with our community.

Actually, that thread is a good sign and a good source for community building. You know, people establishing boundaries and goals together rather than trying to figure out if it is worth contributing the vision of somebody else or adding to an existing patchwork which has a unclear direction. It was a small managable piece (the logo) so people felt like participating. It also was a ground where people can share their views on what-we-really-are-about on an abstract level.

> Of course that doesn't undo the fact that Walter and I are on hook for a number of things. What I'm saying is I disagree with the allegation that "no amount of volunteer effort will help". From the looks of things, we're in dire need of volunteer effort.

Motivation is a difficult sport, but it would help a lot if you just specced out the D2 language fully and plotted in the missing parts, without implementation, but with proofs of correctness. All this putting stuff in, then ripping it out is demotivating. (Why contribute if it will be ripped out at the next turn of events?)

People with formal training (CS background) will favour elegance and correctness, which implies solid advance speccing… Without it, they are unlikely to contribute unless they have D in production or miss features which could make it possible for them to use D in production…

There is too much pushing for breadth in the D community. What you need is depth, the depth of quality and polish. Possibly reducing the scopes and feature set, not extending it even more.

Maybe you have to cut back on system programming and go for fast brute force lock-the-world GC without destructors, or maybe you have to favour system programming. But surely, the worst option is to not set a clear direction.

To match up with the best-in-class in the web space you need a tight performant HTTP and SPDY implementation with support for all relevant content negotiation headers, solid caching handling, automatic compression, well working timeouts/load balancing, all the right hooks for rapid development, builtin Memcache support, a solid NOSQL abstraction, a transactional task queue and be tight on memory so you can run the service on cheap hosting. That would bring you to the basics of Go/App Engine… Then you have to be better…

Kudos for vibe.d, but it won't really matter until it is better than the alternatives. Building WordPress on top of it won't matter, because creating WordPress is not difficult. The difficult part is building the WordPress community.

On 7/10/14, 7:53 AM, Sean Kelly wrote:
> On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu wrote:
>> On 7/9/14, 1:51 PM, Walter Bright wrote:
>>> On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
>>>> Hmmm... how about using u after that?
>>>
>>> Using u after that would either cause an exception to be thrown, or
>>> they'd get T.init as a value. I tend to favor the latter, but of course
>>> those decisions would have to be made as part of the design of Unique.
>>
>> That semantics would reenact the auto_ptr disaster so probably
>> wouldn't be a good choice. -- Andrei
>
> The problem with auto_ptr is that people rarely used it for what it was
> designed for.  Probably because it was the only smart pointer in the
> STL.  As I'm sure you're aware, the purpose of auto_ptr is to explicitly
> define ownership transfer of heap data.  For that it's pretty much
> perfect, and I use it extensively.  It looks like unique_ptr is pretty
> much the same, but with a facelift.  Underneath it still performs
> destructive copies, unless I've misread the docs.

Nononono - unique_ptr never moves from lvalues. Also, the educational argument for auto_ptr doesn't stand; it was bad design, pure and simple. -- Andrei

On Thursday, 10 July 2014 at 15:35:03 UTC, John Colvin wrote:
> On Thursday, 10 July 2014 at 14:54:51 UTC, 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.
>
> I don't see why this would invalidate the licence:
>
> fork the branch that contains the request, rebase to fix any conflicts, make any extra commits needed, open a new pull request. It's really no different from merging the pull and then fixing it afterwards.

So long as the author's name remains in place in the license blurb I think you're pretty much free to do whatever you want with the code.  That's the beauty of the Boost license.  It's as close to Public Domain as it seems possible to get given the vagaries of international law.

I would *love* to have a good networking package in Phobos.  It's been my #1 item for basically the entire 10 years I've been using D.  It just happens to conflict a bit too much with my professional work for me to comfortably make any contribution without internal approval, and I don't see that happening unless we start using D and want to contribute back to the language.

vibe.d exists now though, and maybe someone could tease it apart to get some portion of it in Phobos and leave the rest as a third-party extension?  That's being actively developed, and is really quite nice, though perhaps not so general-purpose as std.net was intended to be.

It seems that most of my active use of D these days is writing scripts to talk to our servers for various tasks.  For the most part I just use libcurl for that and it's pretty okay, but for the things that don't talk HTTP... ugh.

On 7/10/14, 8:29 AM, Sean Kelly wrote:
> Robert's struggle with getting std.logger accepted is the stuff told to
> children around the campfire so they don't venture out into the dark.

Actually we use his logger at Facebook quite extensively (and happily). -- Andrei

On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
> On 7/10/14, 8:29 AM, Sean Kelly wrote:
>> Robert's struggle with getting std.logger accepted is the stuff told to
>> children around the campfire so they don't venture out into the dark.
>
> Actually we use his logger at Facebook quite extensively (and happily). -- Andrei

And I still waiting for him to call for next formal review / voting round ;)

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;

>    int* p = new int;
>    Unique!(int*) u = p;         // must fail

The existing design actually allows that, but nulls p:

    int* p = new int;
    Unique!int u = p;         // ok
    assert(p is null);
    assert(!u.isEmpty);

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

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.

BTW, should isEmpty be documented? It seems to be public ATM.

On Thursday, 10 July 2014 at 15:51:25 UTC, Andrei Alexandrescu wrote:
>
> Nononono - unique_ptr never moves from lvalues. Also, the educational argument for auto_ptr doesn't stand; it was bad design, pure and simple. -- Andrei

The documentation at:

http://en.cppreference.com/w/cpp/memory/unique_ptr

must be incomplete.  In their example they use std::move when moving the value between pointers, but there's no mention of that in the description of the type.  I guess I should just check the standard.  I haven't looked at it very closely because I'm stuck using a pre-C++0x compiler at work.

On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
> On 7/10/14, 8:29 AM, Sean Kelly wrote:
>> Robert's struggle with getting std.logger accepted is the stuff told to
>> children around the campfire so they don't venture out into the dark.
>
> Actually we use his logger at Facebook quite extensively (and happily). -- Andrei

Yep, it's good!  But still not in Phobos despite his efforts.  At this point I honestly don't know what the blocker is either.  Maybe just inertia.

On Thu, Jul 10, 2014 at 07:30:42AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> Looking at the second oldest pull request (https://github.com/D-Programming-Language/phobos/pull/1138) that's just a documentation pull, on which I myself last asked about status on March 15.

Sorry, I got busy and didn't have time to look at it. I just updated it per the latest comments; please review.


> Furthermore there are just a good amount of pull requests that have nothing to do with any leadership. E.g. https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned.

Perhaps somebody should take over this pull (fork it or copy-n-paste, whatever). I haven't used std.net.curl since that last time, and likely won't be using it anytime soon because I find the API hard to use -- for my needs, using std.process to call wget/curl is good enough. So I'm probably not the best person to work on the API right now.

And just for the record, I have no problem whatsoever with people taking over my PRs and submitting their own PRs with identical content. What's important is that the code gets in there somehow.


[...]
> Of course that doesn't undo the fact that Walter and I are on hook for a number of things. What I'm saying is I disagree with the allegation that "no amount of volunteer effort will help". From the looks of things, we're in dire need of volunteer effort.
[...]

Since we're on this topic, I wish somebody would review this PR:

	https://github.com/D-Programming-Language/phobos/pull/2276

There have been multiple usability bugs filed against cartesianProduct, and this PR addresses the most common use case (which is also the simplest to fix) in those complaints. 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.

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. Or sometimes a PR is just beyond your depth and you don't really want to get involved for fear of saying things or making decisions that you aren't qualified to make.  But judging at the frequency of non-response to PRs, I'm starting to wonder if we, as a community, have bitten off a far bigger chunk than we can chew, in the sense that Phobos covers a huge scope of very different things, yet there aren't enough people interested / qualified in each specific area to be able to review / pull PRs directed at that area in a timely manner. Perhaps we're becoming the jack of all trades and master of one, so to speak?


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

Am Thu, 10 Jul 2014 08:50:12 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> 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

I agree, but it's probably a good idea to keep the author name in the git history.

In git author/committer can be different, see http://stackoverflow.com/questions/18750808/difference-between-author-and-committer-in-git