On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via Digitalmars-d wrote:
>
> I think you've missed my entire point.
> The summary is this:
> Tried D, tried a very popular and often hyped D library/framework,
> encountered bugs. There was friction along the way which undermines
> confidence, but the critical point, the thing that caused the call to
> be made, was that the debugger didn't work, and we were unable to
> diagnose the bug with relative ease.
> It's possible that wouldn't have inspired the call to be made if it
> weren't for the prior friction... ie, if it were the first point of
> friction, we might have persevered through that one, but the aggregate
> prior to that point painted a clear picture, and that was the
> proverbial straw.
>
> Immaturity in the language seemed to allow for greater tolerance than
> immaturity in the tooling.
> This is the experience I was trying to convey... which was to be taken
> as a case study, that is all.
>

What I'm wondering is how is it you didn't encounter this issue yourself before ? If you've been using D for 6 or 7 years, and it was a small project that was done in 20 to 30 lines of node.js ? So you clearly entered unknown territory and expected everything to be fine, despite your experience with D.

Can you link us to the issue(s) you created on Vibe.d's Github ?

We know some stuff sux. Just look at std.datetime's documentation. On my 15" laptop, the links take all the screen. And this part is totally useless, as no one is going to use it (beside ctrl + f, but you have to know what you are looking for). Not mentioning the size of enum (just look at how much space trivial enums such as "DayOfWeek" or "Month" takes).

However, many of us lack the time and interest to fix this, as we know our way around. The same goes for all the tooling/libraries, they were developped, and are maintained out of one's necessity, not because "we" need it.

On Thursday, 18 December 2014 at 13:51:08 UTC, Vadim Lopatin wrote:
> git clone git@github.com:buggins/dlangide.git
> cd dlang ide
> dub run

Sorry, it should be

git clone https://github.com/buggins/dlangide.git
cd dlangide
dub run

On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics wrote:
> please stop with this dub ....
>
> It do not respect OS specification
> Is a monolith application,inside they are at least 3 kinds of software:
> - a builder
> - a package manager
> - a package indexer
>
> In any case the :
>  - no respect of OS specification and standard path
>  - any discussion with OS packager or development with their needs
>
> it is to me no dub!!!

How do you intend to provide build tools and package distribution that work across all OS?

POSIX compatible OS each with its own format, Windows, mainframes and embedded OS?

Are you going to distribute packages for all of them?

On Thursday, 18 December 2014 at 13:52:58 UTC, Vadim Lopatin wrote:
> On Thursday, 18 December 2014 at 13:51:08 UTC, Vadim Lopatin wrote:
>> git clone git@github.com:buggins/dlangide.git
>> cd dlang ide
>> dub run
>
> Sorry, it should be
>
> git clone https://github.com/buggins/dlangide.git
> cd dlangide
> dub run

Cool. A D IDE in D that integrates all the existing tools would be great (dscanner, dvm etc.)

Maybe it's time to pick people's brains for ideas and suggestions.

>
> How do you intend to provide build tools and package distribution that work across all OS?
>


split dub in smaller project as this packager could integrate tools inside Os themself.

python with his setup.py is to me a nice win
with it packager can configure it to fit right on Os
end user can use pip install
and pypi index package

That is soooo hard ...

On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics wrote:
> please stop with this dub ....
>
> It do not respect OS specification
> Is a monolith application,inside they are at least 3 kinds of software:
> - a builder
> - a package manager
> - a package indexer
>
> In any case the :
>  - no respect of OS specification and standard path
>  - any discussion with OS packager or development with their needs
>
> it is to me no dub!!!

There is nothing in dub which conflicts with doing solid packaging. Unless you miss `make install` of course. I don't.

On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via Digitalmars-d wrote:
>>
>>
>> I think you've missed my entire point.
>> The summary is this:
>> Tried D, tried a very popular and often hyped D library/framework,
>> encountered bugs. There was friction along the way which undermines
>> confidence, but the critical point, the thing that caused the call to
>> be made, was that the debugger didn't work, and we were unable to
>> diagnose the bug with relative ease.
>> It's possible that wouldn't have inspired the call to be made if it
>> weren't for the prior friction... ie, if it were the first point of
>> friction, we might have persevered through that one, but the aggregate
>> prior to that point painted a clear picture, and that was the
>> proverbial straw.
>>
>> Immaturity in the language seemed to allow for greater tolerance than
>> immaturity in the tooling.
>> This is the experience I was trying to convey... which was to be taken
>> as a case study, that is all.
>>
>
> What I'm wondering is how is it you didn't encounter this issue yourself before ? If you've been using D for 6 or 7 years, and it was a small project that was done in 20 to 30 lines of node.js ? So you clearly entered unknown territory and expected everything to be fine, despite your experience with D.

Simple, I never tried to use websockets in vibe.d
I had some past experience with vibe.d to do some web page stuff, and
my experience was practically flawless, which is why I had confidence
in it in the first place.

Other common language issues that I did anticipate, I expected to be
able to work through. I did know the debugger was an issue; it was
actually my biggest fear going in. It did turn out to be the thing
that bit me in the arse!
I just hoped/expected we wouldn't need the debugger in such a small
and simple program.
The debugger does work okay for certain tasks, particularly if you
control your coding style and make sure it's compatible with the
debugger. I didn't have that luxury though as I usually do, since we
were working on a foreign framework.


> Can you link us to the issue(s) you created on Vibe.d's Github ?

https://github.com/rejectedsoftware/vibe.d/issues/931

I can't really articulate the problem well. Google's Native Client is a part of the puzzle, and that's a complex environment to get working. We tested the NaCl client against some other websocket servers though, and the problem didn't occur.

I want to try and isolate a test case if I ever get some free time at work :/


The other problem I can't isolate, it's just that the first file
that's requested from time to time locks up the browser... if I kill
the browser, reload and refresh, the problem goes away.
I'll also see if I can post some code that demonstrates that case, but
I have my suspicions that's client specific too.


> We know some stuff sux. Just look at std.datetime's documentation. On my 15" laptop, the links take all the screen. And this part is totally useless, as no one is going to use it (beside ctrl + f, but you have to know what you are looking for). Not mentioning the size of enum (just look at how much space trivial enums such as "DayOfWeek" or "Month" takes).
>
> However, many of us lack the time and interest to fix this, as we know our way around. The same goes for all the tooling/libraries, they were developped, and are maintained out of one's necessity, not because "we" need it.

I know. I only said that there were a lot of complaints relating to
the documentation, because there were.
Although that said, as far as I can tell, it wasn't a particularly
heavily weighting factor in the decision. Just worth noting; it wasn't
endearing to anyone.

On Thursday, 18 December 2014 at 14:32:03 UTC, Dicebot wrote:
> On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics wrote:
>> please stop with this dub ....
>>
>> It do not respect OS specification
>> Is a monolith application,inside they are at least 3 kinds of software:
>> - a builder
>> - a package manager
>> - a package indexer
>>
>> In any case the :
>> - no respect of OS specification and standard path
>> - any discussion with OS packager or development with their needs
>>
>> it is to me no dub!!!
>
> There is nothing in dub which conflicts with doing solid packaging. Unless you miss `make install` of course. I don't.

I agree, after all , all is possible.
but maybe I missed a feature make generation with dub is not supported : https://github.com/D-Programming-Language/dub/issues/52

and some var like LIB_DIR, PREFIX, DFLAGS, INCLUDE_DIR will be required by packager to set correctly the package

On Thursday, 18 December 2014 at 14:31:10 UTC, bioinfornatics wrote:
>>
>> How do you intend to provide build tools and package distribution that work across all OS?
>>
>
>
> split dub in smaller project as this packager could integrate tools inside Os themself.
>
> python with his setup.py is to me a nice win
> with it packager can configure it to fit right on Os
> end user can use pip install
> and pypi index package
>
> That is soooo hard ...

So now you are making Python a dependency.

Besides porting D to a new platform, Python must also be ported.

Yes, there are computer systems without Python support.

> So now you are making Python a dependency.
>
> Besides porting D to a new platform, Python must also be ported.
>
> Yes, there are computer systems without Python support.

What ?
I took an example what is done in a close field .
I haven't said to put python as dependencies ...