On Thursday, 8 August 2013 at 22:19:28 UTC, Johannes Pfau wrote:
> I'd like to explain the special issue we have with std.json -
> as far as I understand it:
> *snip*

This actually brings up the main beefs I have with the phobos dev process:

1) your requirements list should be prominently documented, so people considering writing something for phobos know what is needed up front

2) what's considered for phobos and what is just outside its scope?

3) these processes should be more authoritative than "as far as I understand it" - then new people could get involved with reviewing too, since they have an objective list of stuff to be on the lookout for and don't have to wait for someone else to come along and say something

4) phobos lets the perfect be the enemy of the good. std.json really isn't that bad, and ~50 lines of prettier add-on API could make it nicer, but instead of doing that we wait years for something that doesn't seem to be happening at all.


> * the orignal author is no longer around. AFAICS there's nobody feeling responsible for this module.

This is a problem too: a module shouldn't be in the hands of one person. If any random contributor follows the documented rules, they should get their code pulled in. Since phobos is a community project, I think we should all be equally responsible for every part of it. One person might take the lead and do most the work.... but it shouldn't be *exclusive*, so if that one person can't or won't do something, someone else can just do it.

Am 09.08.2013 00:19, schrieb Johannes Pfau:
> Am Thu, 08 Aug 2013 22:15:28 +0200
> schrieb "Tofu Ninja" <emmons0@purdue.edu>:
> 
>> On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote:
>>> Am 08.08.2013 20:24, schrieb Adam D. Ruppe:
>>>> On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote:
>>>>> I made a pull request improving the API a few weeks ago,
>>>>> no one seems to really care.
>>>>
>>>> Phobos needs a new dictator.
>>>
>>> Either that, or I will soon start my own standard lib and stop
>>> caring
>>> about phobos. I think, I even know a few who would help me...
>>
>> It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it.
> 
> I'm sorry that you've had such bad experiences when contributing to phobos. I think this is less of a phobos than a std.json problem. I'd like to explain the special issue we have with std.json - as far as I understand it:
> 

I think the problem is, people are afraid that changes will hurt D. The mentallity to improve D and make it awsome is lost (at least if feels like it), now all what is left "WE NEED TO MAKE D PRODUCTION READY!!!1111111 COMPANIES USE D!!!!1111" which makes sense, but one shouldn't forget why D was "invented", to improve the programming situation and craft a language which is superior to all others and which allows to write simple clean but yet powerful code!

Am Fri, 09 Aug 2013 00:39:50 +0200
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> On Thursday, 8 August 2013 at 22:19:28 UTC, Johannes Pfau wrote:
> > I'd like to explain the special issue we have with std.json -
> > as far as I understand it:
> > *snip*
> 
> This actually brings up the main beefs I have with the phobos dev process:
> 
> 1) your requirements list should be prominently documented, so people considering writing something for phobos know what is needed up front

I posted this to the wiki:
http://wiki.dlang.org/Wish_list/std.json
and linked it from http://wiki.dlang.org/Wish_list
If you know some better place for that page, feel free to move it.

> 
> 2) what's considered for phobos and what is just outside its scope?

Sometimes I wonder about that as well. We usually follow the 'batteries included' approach and all kind of modules are accepted into phobos. However Andrei often dislikes 'trivial to implement' functions and simple helper functions or helper aliases.

> 
> 3) these processes should be more authoritative than "as far as I understand it" - then new people could get involved with reviewing too, since they have an objective list of stuff to be on the lookout for and don't have to wait for someone else to come along and say something

There was a discussion about std.json some time ago and the list I posted is what I remember from that discussion. But we should really document such 'requirements'. Though std.json is an exception here, we usually don't have a list of 'requirements' before the module is written.

> 
> 4) phobos lets the perfect be the enemy of the good. std.json really isn't that bad, and ~50 lines of prettier add-on API could make it nicer, but instead of doing that we wait years for something that doesn't seem to be happening at all.
> 
I totally agree. I think it's a problem with exaggerating API stability when phobos is not ready for that yet. Although if it's really add-on only this shouldn't be a problem.

> 
> > * the orignal author is no longer around. AFAICS there's nobody feeling responsible for this module.
> 
> This is a problem too: a module shouldn't be in the hands of one person. If any random contributor follows the documented rules, they should get their code pulled in. Since phobos is a community project, I think we should all be equally responsible for every part of it. One person might take the lead and do most the work.... but it shouldn't be *exclusive*, so if that one person can't or won't do something, someone else can just do it.

This is working for some modules(std.algorithm, std.range). I don't know why it's not working for modules like std.json or std.xml.

On Thu, Aug 08, 2013 at 03:49:15PM +0200, bearophile wrote:
> David:
> 
> >If we follow an existing implementation, we should follow JavaScript
> 
> In my opinion we should follow the formal JSON grammar.
[...]

+1.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.

On Thu, Aug 08, 2013 at 11:45:19AM -0400, Nick Sabalausky wrote:
> On Thu, 08 Aug 2013 17:17:38 +0200
> "Tofu Ninja" <emmons0@purdue.edu> wrote:
> 
> > On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
> > > On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
> > >> In my opinion we should follow the formal JSON grammar.
> > >
> > > This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.
> > 
> > A formal grammar can be found here starting on page 202 but I
> > don't know enough about grammars to be able to interpret it.
> > http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
> > 
> > Im starting to become less sure if its a bug or not...
[...]

I find that the spec is not very clear as to what is/isn't allowed. RFC-4627 is more unambiguous: it explicitly states that insignificant whitespace is allowed before or after any of the six structural characters, which are defined (in section 2) to be:

	[ { ] } : ,

Section 2.4 in RFC-4627 defines the number format very clearly. There is no mention of insignificant whitespace. This, plus the statement above in section 2 about structural characters, makes it clear that whitespace is NOT allowed inside a number literal.

So please file a bug against std.json.


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener

On Thursday, August 08, 2013 14:38:34 SteveGuo wrote:
> I think bug reports should be here http://forum.dlang.org/group/digitalmars.D.bugs

Please, never, never post to that list. It shouldn't even accept posts to it (and it may not anymore, since I haven't seen anyone post to it for a while). The whole purpose of that list is to sign up for notifications from bugzilla, and bugzilla will post to the list whenever a bug report is created or changed. All bug reports should go to

http://d.puremagic.com/issues

- Jonathan M Davis

On Thu, Aug 08, 2013 at 08:24:19PM +0200, Adam D. Ruppe wrote:
> On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote:
> >I made a pull request improving the API a few weeks ago,
> >no one seems to really care.
> 
> Phobos needs a new dictator.

Or rather, Phobos needs more reviewers/committers. In the past 2 weeks or so, pull requests have been piling up, and lots of them have a green on the autotester, yet very few requests are actually being pulled. Sounds like the usually-active Phobos devs are busy with other things.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

On Thu, Aug 08, 2013 at 10:15:28PM +0200, Tofu Ninja wrote:
> On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote:
> >Am 08.08.2013 20:24, schrieb Adam D. Ruppe:
> >>On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote:
> >>>I made a pull request improving the API a few weeks ago,
> >>>no one seems to really care.
> >>
> >>Phobos needs a new dictator.
> >
> >Either that, or I will soon start my own standard lib and stop
> >caring
> >about phobos. I think, I even know a few who would help me...
> 
> It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it.

Yeah, another Phobos/Tango (or whatever it may be) split is probably going to be the thing that finally kills off D before it ever reaches widespread adoption. Please, let's not go there.

Here's another approach. If you feel something is wrong with Phobos and your pulls aren't getting accepted for whatever reason, why not package it up nicely in a form that's easily installable by users, and publish it? Say you have a replacement for std.json that you feel is far superior, well, then make it installable as a standalone library (say alt.json), and promote it here and get many people to start to use it. Once it's widely-used, I suspect it will be far easier to convince people to put it into Phobos. :-)


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Thu, Aug 08, 2013 at 11:40:45PM +0200, David wrote:
> Am 08.08.2013 22:15, schrieb Tofu Ninja:
[...]
> > It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it.
> 
> phobos is actually useable, still I don't like many of its design choices. I feel the same with D. D itself is better than most languages, I still think there is a long way to go, but "official" D people seem like it's enough and block progress

Well, I don't speak for them, whoever they are, but in my understanding one of the main reasons there's such a high bar to changes is because we're trying to stabilize the language so that adopters can rely on it not having drastic changes every other release, that will require massive code rewrites. No language will ever be perfect, and if we keep on breaking people's existing code in the endless quest to improve the language, D will have no users left.


> (e.g. @property/-property the whole situation is a mess, but instead of properly reimplementing it, they try to fix an already broken system and break code with it, why not break code once, but replace it with a proper system)

The problem is that nobody can agree on what the "proper" system should be. We've had that @property discussion before. Nobody is happy with the current state of affairs, but nobody can agree with what the solution should be, either. We just have long neverending debates about it but no conclusion is ever reached.

Perhaps what's needed, is somebody who's headstrong enough, and persistent enough, to just pick one of the solutions -- any one of them -- take the time to implement it in DMD, and show it to the rest of us to prove how superior it is. Then continue to pester Walter ceaselessly until he agrees to merge it. In the current state of stalemate, an actual, working implementation of a solution (even if it's not quite the one that one may have in mind) should be pretty convincing.

Complaining about it yet being unwilling to do anything about it, OTOH, is very likely to just fall on deaf ears, judging from what I've seen around these parts. That's just the way things work, unfortunately. *shrug*


T

-- 
Some days you win; most days you lose.

On Saturday, 10 August 2013 at 18:28:32 UTC, H. S. Teoh wrote:
> ...
> T

Perhaps there's a forum bug here. I was not in this broken piece of therad.

Bye,
bearophile