On 12/29/14 4:25 PM, Walter Bright wrote:
> On 12/29/2014 8:51 AM, Dicebot wrote:
>> On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
>>> If anybody cared about good Windows debugging support or getting vibe.d
>>> working flawlessly on Windows, they'd have done it already.  Now,
>>> Manu might
>>> bring more attention to those issues through his post and someone may
>>> decide
>>> to work on them as a result- it has already spurred Walter to try and
>>> improve
>>> the phobos docs- which is why I have no problem with his criticism.
>>
>> Criticism about documentation is actually very well-placed - it is an
>> issue that
>> affects everyone, can be fixed in small chunks and does not require
>> huge effort
>> investment for each chunk. No one loses, everyone wins, yay!
>
> I am trying to lead by example, but so far I see only a couple pull
> requests from others improving the Phobos docs.
>
> C'mon, guys, most fixes are pretty trivial, it's just that there's a lot
> of them. If everyone does one for a function they're already familiar
> with, we can get a lot done.

I've also fixed a stray paren in std.algorithm (https://github.com/D-Programming-Language/phobos/pull/2824), which was diagnosed correctly every time the documentation was generated. During doc generation there are also a bunch of warnings about undocumented or mismatched params. It would be awesome if someone was on it.

I very much appreciate the folks who make it a point to contribute to the github repos in addition to helping out people on the forums. I've identified as a distinct task of mine for 2015 to improve my leadership skills, starting with convincing someone to literally remove one character :o).


Andrei

On 30 December 2014 at 04:08, Gary Willoughby via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
>>
>> I don't think it needs to be a zero-sum game.  Removing blockers to entry can make an orders-of-magnitude difference in the number of users for a particular platform, and when you gain users, you gain developers.  Paying now to remove basic usability issues could well free up a lot of core contributor time in future, by opening a door for Windows devs that makes it worth their while to invest effort into the language and its toolchain.
>
>
> Yes, this is how i see things.

I think this is the most important point I (tried) to make; users are
only likely to contribute once they already have _significant_
investment.
First-impressions matter, a lot, and it has been my experience that
many (most?) users I have introduced to D (mainly from my own
industry) have been scared off by first-impressions, relating to the
points I've discussed.

Business commitment is even more significant than user commitment,
since if a business becomes committed and there is a block in the way,
something that needs to be fixed and nobody else is available to do
it, there is a heightened probability they will assign someone paid
working time to address the issue. Support for existing commitments is
not usually negotiable.
As such, I think commercial users are quite important, and perhaps
even in the traditional open-source sense that it may actually lead to
things being done.
Of course, businesses are more conservative than users, and will never
make a company commitment if the experience appears shaky right out of
the gate. Those first(/early) impressions really matter!

On 30 December 2014 at 11:14, Manu <turkeyman@gmail.com> wrote:
> On 29 December 2014 at 15:44, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 12/20/2014 10:08 AM, Daniel Davidson wrote:
>>>
>>> Sure, sounds like a winning strategy. Probably not applicable, but were
>>> you to
>>> run into an issue with vibe or websockets would you proceed to write
>>> pretty
>>> printers for the supplied data structures, the returned data structures,
>>> etc,
>>
>>
>> probably yes, as I've done so when given someone else's program to debug. Writing a pretty-printer is often the first thing I do, as it also helps enormously in learning the data structures
>
> That if you don't have source to the library? (as is the overwhelming
> standard in my line of work)
> You can't instrument code that you don't have.

* what if...

Sorry, posting from a phone is really tedious! >_<

Anyway, I know you understand the debugging experience is very important.
You won't change our opinion on this matter with anecdote, it is immutable. ;)

On 12/29/2014 5:14 PM, Manu via Digitalmars-d wrote:
> That if you don't have source to the library? (as is the overwhelming
> standard in my line of work)
> You can't instrument code that you don't have.

It's always a big problem debugging inside code you don't have the source to. How is a debugger going to display the source code to it? How are any of the debugger features you say are critical going to work with no source code?

Debugging such requires low level assembler debugging.

On 12/29/2014 4:49 PM, H. S. Teoh via Digitalmars-d wrote:
> I was away on vacation for a week, so couldn't work on this.

What, not working on Christmas? How hard core are you? :-)

> I'll see if
> I can cook up a bunch of doc-related PR's this week. They *are* very
> low-hanging fruit that even newbies can easily contribute to.

Great! Looking forward to it.

On 12/29/14 2:12 AM, ponce wrote:
> On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote:
>> It would also be nice to anticipate that people looking to operate on
>> strings would look in std.string for things that are elsewhere. Once
>> upon a time, the std.string docs actually did have a table of links
>> for functions that had been moved to other pages. That was convenient
>> and shouldn't have been removed, IMO.
>>
>
> Finding a string in another comes to mind. Is it "countUntil"?

std.algorithm.find

> I'm still unsure if there is a min/max function I could use for builtin
> types in Phobos.

std.algorithm.min, std.algorithm.max

> I've found myself several times searching the following in Rosetta Code,
> and wished there was a site for common idioms.

Point taken.


Andrei

On 12/29/14 8:54 PM, Andrei Alexandrescu wrote:
> On 12/29/14 4:25 PM, Walter Bright wrote:
>> On 12/29/2014 8:51 AM, Dicebot wrote:
>>> On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
>>>> If anybody cared about good Windows debugging support or getting vibe.d
>>>> working flawlessly on Windows, they'd have done it already.  Now,
>>>> Manu might
>>>> bring more attention to those issues through his post and someone may
>>>> decide
>>>> to work on them as a result- it has already spurred Walter to try and
>>>> improve
>>>> the phobos docs- which is why I have no problem with his criticism.
>>>
>>> Criticism about documentation is actually very well-placed - it is an
>>> issue that
>>> affects everyone, can be fixed in small chunks and does not require
>>> huge effort
>>> investment for each chunk. No one loses, everyone wins, yay!
>>
>> I am trying to lead by example, but so far I see only a couple pull
>> requests from others improving the Phobos docs.
>>
>> C'mon, guys, most fixes are pretty trivial, it's just that there's a lot
>> of them. If everyone does one for a function they're already familiar
>> with, we can get a lot done.
>
> I've also fixed a stray paren in std.algorithm
> (https://github.com/D-Programming-Language/phobos/pull/2824), which was
> diagnosed correctly every time the documentation was generated. During
> doc generation there are also a bunch of warnings about undocumented or
> mismatched params. It would be awesome if someone was on it.
>
> I very much appreciate the folks who make it a point to contribute to
> the github repos in addition to helping out people on the forums. I've
> identified as a distinct task of mine for 2015 to improve my leadership
> skills, starting with convincing someone to literally remove one
> character :o).

Please, let's make the build of the documentation be an error on auto tester. I can say personally, there is so much more involved with building the docs than I care to deal with. You need all the repositories, and the dlang.org repository, which I rarely use. IIRC, you also need everything laid out in the right way to get that to work.

If the auto tester simply errored when the doc has issues, then at least someone would be aware of it.

-Steve

On 12/30/14 4:30 AM, Steven Schveighoffer wrote:
> Please, let's make the build of the documentation be an error on auto
> tester. I can say personally, there is so much more involved with
> building the docs than I care to deal with. You need all the
> repositories, and the dlang.org repository, which I rarely use. IIRC,
> you also need everything laid out in the right way to get that to work.

mkdir /dir/for/d/
cd /dir/for/d/
git clone https://github.com/D-Programming-Language/tools
tools/update.sh

... and you're there. This should be on a wiki page. Takers?

> If the auto tester simply errored when the doc has issues, then at least
> someone would be aware of it.

Agreed.


Andrei

On Tuesday, 30 December 2014 at 00:25:28 UTC, Walter Bright wrote:
>> Criticism about documentation is actually very well-placed - it is an issue that
>> affects everyone, can be fixed in small chunks and does not require huge effort
>> investment for each chunk. No one loses, everyone wins, yay!
>
> I am trying to lead by example, but so far I see only a couple pull requests from others improving the Phobos docs.
>
> C'mon, guys, most fixes are pretty trivial, it's just that there's a lot of them. If everyone does one for a function they're already familiar with, we can get a lot done.

I am personally scared of DDOC and unlikely to do any contributions to documentation that require more than just adding "Params:" while it is the only option. It is really that bad.

It is also much better when newcomers try proposing documentation changes as they have fresh understanding of what is wrong.

So, getting back to this. What do I see wrong in this thread? It creates a clear message : you don't really want to be a D contributor.

Once you start doing it, all privileges of doubt that belong to "user" are lost and bunch of obligations suddenly appears. And of all obligation worst offender written by Gary is requirement to strongly identify oneself with a D project.

Let's get it straight : I don't want to ever be associated with D upstream. I have never wanted to be part of Phobos development team. Only reason I have write access is that last time I complained about issues in pull request management Andrei has suddenly given me write access and asked to fix it myself. Probably my biggest mistake was agreeing to do it instead of answering "fuck you" like Manu did.

And I find this comment by Manu absolutely outrageous:

> Surely you can understand that my desire to *use* D as a tool is not
> at odds with my desire to continue to work in the fields that I prefer
> to work in?

You can hardly even imagine how angry I was when reading it and amount of spoken swearwords that have never reached the NG. Here I am just being told in most straightforward way "I don't want to work on things I need because I have better things to do so you must do those things instead as you can't do anything better anyway".

Yes, there was an argument about long-term profit caring about users from other fields bring. Sorry, but D community is simply not big enough to afford such long-term investments. To make work on Windows toolchain of any interest to me following future assumption would need to hold true:

- it will actually help to attract new users
- at least some portion of this added user base will decide to contribute back, directly or indirectly
- some of resulting contributions will benefit Linux ecosystem too
- that final added value will be higher than original investment

It will take quite a while. I appreciate feedback about what is wrong but not _demands_ about what to work on. If kind acceptance of any demands is considered inherent duty of anyone it least a bit associated with D dev team I kindly ask to remove any access from me to avoid any further confusion. There is no way I will oblige to image written down by Gary in this thread.