On Saturday, 8 September 2018 at 18:10:50 UTC, Jonathan M Davis wrote:
> A related issue is projects that have dependencies outside of D itself
> - for instance, a project that wraps GTK or Qt or something C or C++ library
> that is on many systems but which isn't guaranteed to be present. It would
> be trivial to end up with packages being marked as unmaintained or not even
> working at all when in reality, they work just fine. It's just that they
> require more than just dub and the D compiler to work.

Something that compiled with dmd 2.069.0 but doesn't compile with 2.080.0 is compatible with the former and not the latter. If something seems to fail to compile with every compiler version, we can make a soft recommendation for the version that was newest when that version of that package was released.

This doesn't let us tell you whether a package works or not, but it does let us recommend a compiler version pretty well.

It would certainly require careful messaging.

On 09/08/2018 08:43 AM, Guillaume Piolat wrote:
> 
> We have something similar with dpldocs which builds docs lazily, and is now linked from code.dlang.org
> 
> It's a matter of extending it with downloading toolchain and building.
> 
> I can't speak for anyone else but it looks to me as a realistic way to have it.
> You can also donate to Adam for http://dpldocs.info/, it has interesting things like cross-package search (search ALL of code.dlang.org at once)

Interesting. Got links to the relevant parts of the those projects?

On Saturday, 8 September 2018 at 23:33:42 UTC, Nick Sabalausky (Abscissa) wrote:
>> I can't speak for anyone else but it looks to me as a realistic way to have it.
>> You can also donate to Adam for http://dpldocs.info/, it has interesting things like cross-package search (search ALL of code.dlang.org at once)
>
> Interesting. Got links to the relevant parts of the those projects?

Patreon blog here: https://www.patreon.com/adam_d_ruppe

I don't manage to find x-module search again, perhaps disabled.

If your project is public you can use dpldocs.
For example with your project: http://sdlang-d.dpldocs.info/index.html

Github: https://github.com/adamdruppe/dpldocs

On Saturday, 8 September 2018 at 18:10:50 UTC, Jonathan M Davis wrote:
> A related issue is projects that have dependencies outside of D itself
> - for instance, a project that wraps GTK or Qt or something C or C++ library
>
> [...]
>
> These problems aren't necessarily insurmountable, but they do complicate the things. And while we do want to provide better information about what is and isn't working and maintained, we also don't want to be marking projects as not working when they actually work just fine
>
> - Jonathan M Davis

Thanks for mentioning that. This is indeed a problem I'm facing during writing my tester.
My idea: I'm currently playing around with trying to let DUB not link.

On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> Really, D wins on very few metrics but the D fanboys will only focus on those.
>
> If D wants to survive it better get people willing to help it, making their lives more difficult when there are far better options out there will only starve D of what it needs(investing). All those that think D is just fine, you are cutting your own throats... Eventually D will become defunct and you'll have to move on. Might be 10 years, 20 years, 30 years... but when Walter and Andrew are done with D in a few years there will be no one who will keep it alive(maybe a fork will occur but doubtful it would get anywhere).

And of course every single one of these threads descends right into the same rampant myopic pedantry.

"I'm a new user and I like some things about this, but half the time it was broken and all people tell me to do is fix it myself. If D wants to grow large and replace other languages, it needs normal users who do not have tons of experience or who don't have the time to contribute to it, and their experience needs to be a smooth one."

"Go away and stop using D. Now, if only we had more experienced users with lots of time to contribute to the compiler..."

*10 pages of nitpicking over specific features, forgetting entirely to address or empathize with the OP's position*

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.

Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/.

The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds.

Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change.

On Mon, Sep 10, 2018 at 01:27:20AM +0000, Neia Neutuladh via Digitalmars-d 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.
> 
> Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/.
> 
> The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds.
> 
> Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change.

Awesome!  Thanks so much for actually doing something about it, instead of merely talking about it like I did.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

On Monday, 10 September 2018 at 01:27:20 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.
>
> Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/.
>
> The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds.
>
> Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change.

Nice work. I wonder about some of your results, as it says that dub itself doesn't build with all of the dmd versions, but somehow the tests pass sometimes (shouldn't be possible if you can't build dub itself). I just tested with `dub fetch dub; dub build dub` with the dub 1.10 that comes alongside dmd 2.081.1 on linux/x64 and it built the latest dub 1.11 without a problem.

Regardless, you should talk to Sonke about getting this integrated with code.dlang.org and to Mike about putting up a funding target to pay for both permanent server resources and your time coding this up. I've already said I'd donate towards such a target:

https://forum.dlang.org/post/acxedxzzesxkyomrsmjo@forum.dlang.org

On Sunday, 9 September 2018 at 14:28:11 UTC, Guillaume Piolat wrote:
> I don't manage to find x-module search again, perhaps disabled.

Yeah, there's a memory leak in it so leaving it up would kill the box to build actual docs. And the last couple months have been crazy IRL, but I scheduled some time this week to work on the code again (last week, pushed up a new parser with the uda on params support, etc btw).

I think my solution is going to be to dump the search index in a rdbms and let it manage the memory lol (though it is an immutable binary tree, why it leaks is kinda beyond me, probably just sloppy code somewhere like "foo" ~ desc).

On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote:
> Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/.
>
> The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds.
>
> Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change.

My respect, neat.

May I ask why some packages are missing (e.g. `midi-gamepad`)?
A question, how this it currently handle link libraries?