On Thursday, 6 September 2018 at 01:13:37 UTC, 0xEAB wrote:
> On Wednesday, 5 September 2018 at 14:39:39 UTC, RhyS wrote:
>> This is the same reason why D with Code-D on Windows was a total disaster. You install VSC+CodeD. It breaks because some dependency library somewhere was not updated for DMD xx.0, because D broke/changed something again. Contact the author, ... wait for a official fix for weeks.
>
> Not to long ago one had to wait for months for a fix.
> In the meantime, VisualD and DMD broke because of a VS update.
> Good old times 2017 :P
>
> But it got better. I can't remember that I ever had a problem compiling one of the libdparse tools since then.

I think the problem is rebuilding the dependency libraries in the first place. This is the Linux/macOS way. On Windows, it's customary to provide binaries that "just work".

On Wednesday, 5 September 2018 at 07:07:50 UTC, JN wrote:
> On Wednesday, 5 September 2018 at 06:16:57 UTC, Neia Neutuladh wrote:
>> On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
>>> To me, this strongly suggests the following idea:
>>> - add *all* dlang.org packages to our current autotester / CI
>>>   infrastructure.
>>> - if a particular (version of a) package builds successfully, log the
>>>   compiler version / git hash / package version to a database and add
>>>   a note to dlang.org that this package built successfully with this
>>>   compiler version.
>
> Might be hard to definen what does it mean to "build successfully". Many D packages love their metaprogramming, so just building the package might be enough. Unit tests might even pass, but when trying to use it in an application it might fail in compilation.
>

+1 talk here assume that we can know what we build compile or not,
but with template it doesn't make sense unless the unittest instantiate.

And since we can't add unittest magically where there is none, it's not a maintenance problem but a visibility problem.

Packages that are unmaintained (registry could detect that) should be harder to find.

On Thursday, 6 September 2018 at 10:35:44 UTC, Guillaume Piolat wrote:
> +1 talk here assume that we can know what we build compile or not,
> but with template it doesn't make sense unless the unittest instantiate.
>
> And since we can't add unittest magically where there is none, it's not a maintenance problem but a visibility problem.

Then would it be possible to use code coverage to hint users about packages possibly not building anymore even if they are shown to be buildable ?

On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany wrote:
> On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
>> On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus wrote:
>>> On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
>>>> [...]
>>>
>>> If you don't want to use D, then don't use D. No one is holding a gun to your head.
>>>
>>> It seems to me like what D needs, right now, is people who are willing to roll up their sleeves and get to work when they see something that needs fixing. If that's something you're either unable or unwilling to do, for whatever reason, then D probably isn't a good choice for you right now. And that's ok. We all have our own goals and priorities, and no single programming language is going to be a perfect fit for everybody.
>>
>>
>> I'm not going to sit here and spend have my time fixing shit that should have never broke in the first place.
>>
>> Thanks, you've made a great decision for me, I'm not longer using D for anything. The only reason I used it was for it's binary support and meta programming... no longer. Screw performance, non one else really cares and one doesn't necessarily need meta programming.
>>
>> Thanks, see you in another life!
>
> You showed as a painful issue in our eco system which we can work on, thank you.
>
> You do not need to work on this but do you have a proposal for a solution? What would you help (ranking according to last update, ...)
>
> Kind regards
> Andre


The problem is that all projects should be maintained. The issue, besides the tooling which can only reduce the problem to manageable levels, is that projects go stale over time.

This is obvious! You say though "But we can't maintain every package, it is too much work"... and that is the problem, not that it is too much work but there are too many packages. This is the result of allowing everyone to build their own kitchen sink instead of having some type of common base types.

It's sort of like most things now... say cell phone batteries... everyone makes a different one to their liking and so it is a big mess to find replacements after a few years.


See, suppose if there were only one package... and everyone maintained it. Then as people leave other people will come in in a continual basis and the package will always be maintained as long as people are using it.

This is why D needs organization, which it has none. It needs structure so things work and last and it isn't a continual fight.

It's like if someone doesn't take care of their car. Eventually it starts to break down and when they do shitty fixes it only buys them a little time before it breaks down again and again.

The issue isn't the fixes nor the car but how they use the car and not maintain it properly. That is, it is their mindsets. Since D seems to be full of people with very little understanding how how to build a proper foundation for organization, D has little chance of surviving. As the car breaks down more and more it is just a matter of time before it ends up in the junk heap. It was a great car while it lasted though...

On Thursday, 6 September 2018 at 10:55:04 UTC, Laurent Tréguier wrote:
> Then would it be possible to use code coverage to hint users about packages possibly not building anymore even if they are shown to be buildable ?

I see yet another problem here. Having to maintain a high coverage just to get your package flagged as maintained might lead to a package not getting maintained in the first place.

Of course, coverage can be considered a measurement for code quality. But can one really derive the state of maintenance from it?

On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
>
> The problem is that all projects should be maintained. The issue, besides the tooling which can only reduce the problem to manageable levels, is that projects go stale over time.
>
> This is obvious! You say though "But we can't maintain every package, it is too much work"... and that is the problem, not that it is too much work but there are too many packages. This is the result of allowing everyone to build their own kitchen sink instead of having some type of common base types.

I doubt having too many packages will be D's downfall. Javascript is a thriving language even if tons of NPM packages are unmaintained (and even if they still run, they potentially have security vulnerabilities due to old dependencies).

> It's sort of like most things now... say cell phone batteries... everyone makes a different one to their liking and so it is a big mess to find replacements after a few years.
>
>
> See, suppose if there were only one package... and everyone maintained it. Then as people leave other people will come in in a continual basis and the package will always be maintained as long as people are using it.

If we could have something as simple as "having the one and only package that fits every use case", we wouldn't have multiple OS's, multiple programming languages, etc.
I do agree that having "the one" would make everything easier in theory, but reality isn't theory.

On 9/5/18 4:40 PM, Nick Sabalausky (Abscissa) wrote:
> On 09/04/2018 09:58 PM, Jonathan M Davis wrote:
>> On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d
>> wrote:
>>>
>>> Are you talking about this?
>>>
>>> https://github.com/clinei/3ddemo
>>>
>>> which hasn't been updated since February 2016?
>>
>> This is part of why it's sometimes been discussed that we need a way to
>> indicate which dub packages are currently maintained and work.
> 
> What we need is for DUB to quit pretending the compiler (and DUB itself, for that matter) isn't a dependency just like any other. I pointed this out years ago over at DUB's GitHub project, but pretty much just got silence.


The compiler doesn't change all that often, and when it does, it's usually a long deprecation cycle.

The problem really is that phobos/druntime change all the time. And they are tied to the compiler.

I think some sort of semver scheme really should be implemented for the compiler and phobos. But we need more manpower to handle that.

-Steve

On Thursday, 6 September 2018 at 13:03:09 UTC, 0xEAB wrote:
> On Thursday, 6 September 2018 at 10:55:04 UTC, Laurent Tréguier wrote:
>> Then would it be possible to use code coverage to hint users about packages possibly not building anymore even if they are shown to be buildable ?
>
> I see yet another problem here. Having to maintain a high coverage just to get your package flagged as maintained might lead to a package not getting maintained in the first place.
>
> Of course, coverage can be considered a measurement for code quality. But can one really derive the state of maintenance from it?

Maybe not. I simply thought that it could help know if a package would still build in real-world situations, especially with a lot of meta-programming.

On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
> On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany wrote:
>> On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
>>> [...]
>>
>> You showed as a painful issue in our eco system which we can work on, thank you.
>>
>> You do not need to work on this but do you have a proposal for a solution? What would you help (ranking according to last update, ...)
>>
>> Kind regards
>> Andre
>
>
> The problem is that all projects should be maintained. The issue, besides the tooling which can only reduce the problem to manageable levels, is that projects go stale over time.
>
> This is obvious! You say though "But we can't maintain every package, it is too much work"... and that is the problem, not that it is too much work but there are too many packages. This is the result of allowing everyone to build their own kitchen sink instead of having some type of common base types.
>
> It's sort of like most things now... say cell phone batteries... everyone makes a different one to their liking and so it is a big mess to find replacements after a few years.
>
>
> See, suppose if there were only one package... and everyone maintained it. Then as people leave other people will come in in a continual basis and the package will always be maintained as long as people are using it.
>
> This is why D needs organization, which it has none. It needs structure so things work and last and it isn't a continual fight.
>
> It's like if someone doesn't take care of their car. Eventually it starts to break down and when they do shitty fixes it only buys them a little time before it breaks down again and again.
>
> The issue isn't the fixes nor the car but how they use the car and not maintain it properly. That is, it is their mindsets. Since D seems to be full of people with very little understanding how how to build a proper foundation for organization, D has little chance of surviving. As the car breaks down more and more it is just a matter of time before it ends up in the junk heap. It was a great car while it lasted though...

That's what I have said elsewhere in the thread. Checking the maintainer of a package, if there's no feedback, put the package out of the main list and put it in a purgatory where it can get stale for itself. If a new maintainer appears for a specific package, it can be reinstated in the approved list when it works again.
What annoys people is not that there are broken packages in the list, but that there is no way to know beforehand if one is choosing a reliable package or a hobby experiment gone wrong. This uncertainty is grating imo.

On Thursday, 6 September 2018 at 13:08:00 UTC, Laurent Tréguier wrote:
> On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
>>
>> The problem is that all projects should be maintained. The issue, besides the tooling which can only reduce the problem to manageable levels, is that projects go stale over time.
>>
>> This is obvious! You say though "But we can't maintain every package, it is too much work"... and that is the problem, not that it is too much work but there are too many packages. This is the result of allowing everyone to build their own kitchen sink instead of having some type of common base types.
>
> I doubt having too many packages will be D's downfall. Javascript is a thriving language even if tons of NPM packages are unmaintained (and even if they still run, they potentially have security vulnerabilities due to old dependencies).
>
>> It's sort of like most things now... say cell phone batteries... everyone makes a different one to their liking and so it is a big mess to find replacements after a few years.
>>
>>
>> See, suppose if there were only one package... and everyone maintained it. Then as people leave other people will come in in a continual basis and the package will always be maintained as long as people are using it.
>
> If we could have something as simple as "having the one and only package that fits every use case", we wouldn't have multiple OS's, multiple programming languages, etc.
> I do agree that having "the one" would make everything easier in theory, but reality isn't theory.

You totally missed the point.

The point with 1 package only was to demonstrate how easy it is to maintain and that it theoretically would have the long longevity. When one has an infinite number of packages then every package(or almost everyone) would rot very quickly.

I didn't say there should actually only be one package, as that is absurd. What I said was that because D has no organizational structure to focus work on a fewer number of better maintained and designed packages there is a ton of shit out there for D that doesn't work but there is no way of knowing and not always an easy fix because it takes time to understand the code or it is simply defunct.

This is not rocket science...