On 06/09/2018 4:19 AM, H. S. Teoh wrote:
> On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
>> wrote:
> [...]
>>> And that is why I think we should implement my idea of putting *all*
>>> dub packages on code.dlang.org into our CI infrastructure, and log
>>> all successes / failures to a database that can then be used to
>>> display the range of version(s) of compilers that successfully built
>>> each package on code.dlang.org. Then people can quickly see, at a
>>> glance, whether the package still works with the version of the
>>> compiler that they're using (usually the most recent release, but
>>> not always, so this information can be super useful in making
>>> decisions).
>>
>> Oh, I think that that's a good idea, and it should help with folks
>> picking libraries to use, but it doesn't fix the fundamental problem
>> that whoever wrote the library needs to continue to maintain it or
>> pass it on to someone else to maintain it when they don't want to
>> maintain it anymore, or anyone using it is going to be screwed. So,
>> while your suggestion will definitely help with a piece of the
>> problem, it doesn't solve the part that I was talking about.
> [...]
> 
> Once packages are annotated with the last working compiler version, it
> will be an easy next step to identify all broken packages that need
> maintenance.  If there's an easy fix, someone could open a PR and push
> it upstream, or if upstream has abandoned the project, we could fork it
> and apply the fix.  Either way, CI automation would help us with the
> initial chore of identifying such packages in the first place.
> 
> Also, if the last working compiler version is prominently displayed e.g.
> in the search results, it will inform people about the maintenance state
> of that package, which could factor in their decision to use that
> package or find an alternative.  It will also inform people about
> potential breakages before they upgrade their compiler.
> 
> It doesn't solve all the problems, but it does seem like a good initial
> low-hanging fruit that shouldn't be too hard to implement.
> 
> 
> T

Alternatively we can let dub call home for usage with CI systems and register it having been tested for a given compiler on a specific tag.

On Wednesday, 5 September 2018 at 15:28:38 UTC, H. S. Teoh wrote:
> And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).

This would be very useful. I think you should even have a database for it.

The Package X passes on DMD Y but not with DMD Z.

I mean something like: https://caniuse.com/

S.

On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis wrote:
> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d wrote:
>> On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
>>
>> > 3rd party libraries are usually the real problem if there is one. They need to be maintained, and if something happens that breaks them from one release to another, that can prevent you from upgrading until it's fixed - which may or may not be quick even if they're maintained. And if they're not maintained, well, then that's a serious problem. Now, that would be a big problem in pretty much any language, but the greater rate of change in D does make it worse than it would be in languages that change at a much more glacial pace.
>>
>> [...]
>>
>> And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).
>
> Oh, I think that that's a good idea, and it should help with folks picking libraries to use, but it doesn't fix the fundamental problem that whoever wrote the library needs to continue to maintain it or pass it on to someone else to maintain it when they don't want to maintain it anymore, or anyone using it is going to be screwed. So, while your suggestion will definitely help with a piece of the problem, it doesn't solve the part that I was talking about.
>

I have more radical proposition. Why not check regularly the maintainers of a library querying for feedback. If no response or negative response simply remove the package from the main list. Put it in a section for unmaintained projects.
It would not change fundamentaly the state of the packages, but would at least rein in on too high expectations.
OP would probably not reacted as badly as he did if he had known that the package he tried was unmaintained.
This might reduce the number of packages available, but it is often much better to have fewer choices than chosing the the wrong one (or two or three).

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:
>> [...]
>
>
> 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!

yes i think i lurked around long enough, bye D.

On 9/5/18 11:46 AM, Dennis wrote:
> On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven Schveighoffer wrote:
>> 3ddemo has one commit. In February 2016. I think it would be an amazing feat indeed if a project with one version builds for more than 2 years in any language.
> 
> This problem is not about 3ddemo. I can totally relate to the OP, when I started learning D (we're talking April 2017 here) I tried many OpenGL demos and GUI libraries. I like learning by example, so I tried a lot of them on both Ubuntu and Windows. My success rate of building them was below 20%, and even if it did succeed, it often still had deprecation warnings, or linking errors when loading the required shared libraries, or glitches like messed up text rendering. I would try to fix it myself, but the error messages were not clear at all for a beginner and Googling them yielded few results.

I should say, I have little experience with or understanding of building opengl stuff. My experience with trying stuff is that it's very finnicky about which libraries are installed or how the environment has to be properly set up.

Even after I got 3ddemo to compile, it didn't run, wouldn't open certain libraries.

So I think it would be nice if these experiences were better, but I don't know what the core D projects need to do here. My guess is that there is not a lot of manpower making proper easy-to-use 3d libraries.

> We're not even only talking about small unmaintained projects here: at the time I tried it, Gtk-D was broken.[1] Out of frustration I carried on in C# for a while, and guess what: the first best OpenTK demo I found basically worked first try. Now I didn't give up on D, but I can totally understand that others (like OP) don't have the patience to put up with this.

I think Gtk-D has gotten a lot better (not my experience, but Tilix seems to be doing good with it) since then.

> While we can't force volunteers to keep their D projects up to date, we could try to give some incentive by notifying them via code.dlang.org, or give users information on what compiler / environment is required for dub packages to build. It might prevent some new users from leaving D out of frustration.

I think a "known good" configuration entry, even if it's manual, would be a good thing to add.

-Steve

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.

On Wednesday, 5 September 2018 at 15:28:38 UTC, H. S. Teoh wrote:
> On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
>> [...]
> [...]
>
> And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).
>

Good idea. Something like this would be nice https://i.imgur.com/tfBIvNy.png

On Wed, Sep 05, 2018 at 04:40:19PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
[...]
> 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.

Yeah, to truly capture dependencies properly, you need to specify the dub version and the compiler version(s).  And dub needs to treat this just like any other dependency.

The problem with compiler versions, though, is that while you can specify a minimum compiler version (e.g., if you use a feature that's not implemented in earlier versions), you can't reasonably specify a maximum compiler version, because you can't predict when your code will stop compiling due to future changes in the language / compiler and/or future regressions.  For the latter, you still need a CI infrastructure to periodically test your code against the latest compiler toolchain to determine whether or not it still compiles.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

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.

On Wednesday, 5 September 2018 at 16:26:14 UTC, rikki cattermole wrote:
> On 06/09/2018 4:19 AM, H. S. Teoh wrote:
>> On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>>> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
>>> wrote:
> [...]
>> Also, if the last working compiler version is prominently displayed e.g.
>> in the search results, it will inform people about the maintenance state
>> of that package, which could factor in their decision to use that
>> package or find an alternative.  It will also inform people about
>> potential breakages before they upgrade their compiler.
>> 
>> It doesn't solve all the problems, but it does seem like a good initial
>> low-hanging fruit that shouldn't be too hard to implement.
>
> Alternatively we can let dub call home for usage with CI systems and register it having been tested for a given compiler on a specific tag.

A possibility might be to let package owners specify one of the build status badges commonly added to README files when registering the DUB package. Then display the badge in the code.dlang.org pages (home page, search result page). It would of course be better to display the latest compiler version tested, but repurposing existing badges might be simpler and provide some value until a more sophisticated scheme can be implemented.

--Jon