www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - This is why I don't use D.

reply Everlast <Everlast For.Ever> writes:
I downloaded 3ddemo, extracted, built and I get these errors:

logger 2.66.0: building configuration "library"...
\dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16):
Error: cannot implicitly convert expression logger of type shared(Logger) to
std.historical.logger.core.Logger
\dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21): Error:
no property fracSec for type const(SysTime), did you mean
std.datetime.systime.SysTime.fracSecs?
\dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(86,27):
Error: template instance
`std.historical.logger.core.systimeToISOString!(LockingTextWriter)` error
instantiating
dmd.exe failed with exit code 1.

This is typical with most of my trials with D... something is 
always broken all the time and I'm expected to jump through a 
bunch of hoops to get it to work. File a issue, fix it myself, 
use a different library, etc. I'm expected to waste my time 
fixing a problem that really should not exist or should have a 
high degree of automation to help fix it. I really have better 
things to do with my time so I won't invest it in D.

This attitude of "It's your problem" is going to kill D.

There is really no incentive for me to use D except for it's 
language features... everything else it does, besides 
performance, is shit compared to what most other languages do. 
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).
Sep 04 2018
next sibling parent reply James Blachly <james.blachly gmail.com> writes:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:


...

 This is typical with most of my trials with D... something is 
 always broken all the time and I'm expected to jump through a 
 bunch of hoops to get it to work. File a issue, fix it myself, 
 use a different library, etc. I'm expected to waste my time 
 fixing a problem that really should not exist or should have a 
 high degree of automation to help fix it. I really have better 
 things to do with my time so I won't invest it in D.


Are you talking about this?

https://github.com/clinei/3ddemo

which hasn't been updated since February 2016?
Sep 04 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d 
wrote:

 On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:


 ...


 This is typical with most of my trials with D... something is
 always broken all the time and I'm expected to jump through a
 bunch of hoops to get it to work. File a issue, fix it myself,
 use a different library, etc. I'm expected to waste my time
 fixing a problem that really should not exist or should have a
 high degree of automation to help fix it. I really have better
 things to do with my time so I won't invest it in D.


 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. A package
updated last in February of 2016 may very well still work today with the
latest compiler, or it may fail to compile as happens here. It depends on
what the code is doing, what has changed in D since the last update, and how
up-to-date the code really was when it was last updated (e.g. if it was
ignoring deprecation warnings rather than fixing them, which I think was the
case here).

D is very usable as it is, and there are a number of great packages on dub,
but anything that isn't maintained will probably break eventually, even if
fixing it would likely be a quick fix. And if it isn't obvious whether a
package is maintained or not, it can be very frustrating when someone tries
to use it, thinking that it's usable when it isn't really.

I think that it's a bit much to ditch D over a particular package on dub not
working, but it is a real problem.

- Jonathan M Davis
Sep 04 2018
next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Wednesday, 5 September 2018 at 01:58:50 UTC, Jonathan M Davis 
wrote:

 On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via 
 Digitalmars-d wrote:

 [...]


 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. A package updated last in February of 2016 may very 
 well still work today with the latest compiler, or it may fail 
 to compile as happens here. It depends on what the code is 
 doing, what has changed in D since the last update, and how 
 up-to-date the code really was when it was last updated (e.g. 
 if it was ignoring deprecation warnings rather than fixing 
 them, which I think was the case here).

 [...]


Wouldn´t be interesting to specify the compiler version on 
dub.json?
(I think ruby uses this idea)
Sep 04 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Wednesday, 5 September 2018 at 04:32:18 UTC, SrMordred wrote:

 Wouldn´t be interesting to specify the compiler version on 
 dub.json?
 (I think ruby uses this idea)


Ruby 1.8 stuck around for four years before Ruby 1.9 came out. 
Then it was six years until Ruby 2.0 came out. These days, 
there's an annual release, but the magnitude of changes is also 
pretty small.

Compare with DMD over the past year. (Just one year!) opDot was 
deprecated, C-style array declarations were removed, opDispatch 
works differently with `with` statements, arithmetic with 
pointers of different types was deprecated, comma expressions no 
longer yield a value, `delete` was deprecated, hex string 
literals were deprecated, class allocators were deprecated, 
certain types of postblit operators were deprecated, some 
operations on `shared` variables were deprecated, declarations in 
switch-case statements can't be used in other case blocks 
anymore, `catch` statements have to declare something they catch 
now, you can't compare values from different enum types anymore...

That's not all the breaking language changes in the past year. 
And it's just one year. (I'm cheating a bit by counting both 
deprecations and lapsed deprecation periods, but still.)

D can't use semantic versioning because nearly every release has 
breaking changes. Most of them won't affect your code in 
particular, but once you start using a bunch of libraries, it's 
going to be painful.

So how does this work with your library and depending on a 
specific range of language versions? You test with whatever 
compiler you normally use, and if you're super conscientious, you 
might test out a few other versions. So in order to stay 
up-to-date with new compiler releases, you need to re-test your 
library, update the supported-versions flag, and tag a new 
release every time there's a compiler change.

Fortunately, this can be automated, as long as you have automated 
testing.
Sep 04 2018
parent reply RhyS <sale rhysoft.com> writes:
On Wednesday, 5 September 2018 at 05:53:46 UTC, Neia Neutuladh 
wrote:

 Compare with DMD over the past year. (Just one year!) opDot was 
 deprecated, C-style array declarations were removed, opDispatch 
 works differently with `with` statements, arithmetic with 
 pointers of different types was deprecated, comma expressions 
 no longer yield a value, `delete` was deprecated, hex string 
 literals were deprecated, class allocators were deprecated, 
 certain types of postblit operators were deprecated, some 
 operations on `shared` variables were deprecated, declarations 
 in switch-case statements can't be used in other case blocks 
 anymore, `catch` statements have to declare something they 
 catch now, you can't compare values from different enum types 
 anymore...

 That's not all the breaking language changes in the past year. 
 And it's just one year. (I'm cheating a bit by counting both 
 deprecations and lapsed deprecation periods, but still.)

 D can't use semantic versioning because nearly every release 
 has breaking changes. Most of them won't affect your code in 
 particular, but once you start using a bunch of libraries, it's 
 going to be painful.


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.

Now install D on my work PC. Guess what, some minor update came 
out for D, install ... and it broke some libraries again. Contact 
the author again ... wait for a official fix for a few weeks.

Imagine doing this for a year and half with each time you try D 
or want to show D to some colleagues, all you had was a broken 
mess.

And it did not stop at plugins for IDEs. Code that ran good on a 
version of D, refused to work on a later because of deprecated 
features. Or sometimes, it simply crashed without a single 
warning. I can NOT rely on any external package for my code, 
because any new compiler version can break these packages ( and 
my code ).

Do people want to see how many times Vibe.D broken? Or the Mysql 
plugin. You simply get fed up and give up.

Sure, i can fix my code but the external packages are a different 
matter ( not in the mood to learn all the external code and fix 
it every time something breaks ).

And sure, people can stick to only one compiler version for X 
years but then what? You already know how fragile everything is. 
What if you run into a bug in this older package, well, the 
author will fix this bug in the latest master ( what may require 
a new compiler version ). So you run into the whole chicken or 
egg situation!

Then your forced to manually start patching the old code. If you 
can! Sometimes code get changes so much over time that 
back-patching is hard as hell. Its just insane to work like this.

WebFreak001 resorted to actually pre-compiling all the code and 
shipping it like this on the Windows platform because it was the 
only was he was able to ensure that VSC Code-D plugin actually 
kept working! I have Go plugins for IDEs that also get 
git/compiled and they all work out of the box. Each time i 
install a IDE with Go at work, laptop, in a VM or anywhere!

At the same time i have PHP code that is 10 years old, that works 
with minor updates. No need to worry about mysql and other 
extensions because they are pre-compiled and stable. Go code that 
is several years old that instantly compiles with the latest 
compiler.

Its just amateurish at best. And this issue with the code 
deprecation's, bugs, changes is only one off many issues.

Its the same reason whenever i check back on D and see BetterC or 
other "improvements", that i simply yell. "FIX YOU SYSTEMS BEFORE 
INTRODUCING MORE CRAP". Sorry for the languages but i am sure 
that plenty of other people think the same.

I and my company is not motivated to support or help out D when i 
have already put in so much wasted time in the past.

And keep those excuses how its open source and the people need to 
fix everything themselves. I see several main developers, who are 
paid full time more playing around with introducing features only 
a handful of people want. Instead of actually making the language 
stable and ensuring the entire platform runs. D in my book is NOT 
a 2.xx version but feels like a pre-beta. Like 0.xx non-stable 
API language.

You can guess what we do NOT develop in D but simply use Go and 
PHP for our work. Go for the bits that needs extra speed, PHP for 
the easy and fast development. Both are API stable, you do not 
worry much about bugs or deprecation. New features can be 
experienced without massive code breaking.

I do not worry about Go its build-in HTTP server breaking. It 
simply runs on each compile, no matter what Go version we upgrade 
to. Vibe.D on the other hand is a mess. And NOT the fault of the 
Vibe.D authors but the dependencies they depend upon. I have now 
a simple rule. You want us as a company to use your languages for 
web development. You do not have a build in and maintained HTTP 
server? No thanks. And that attitude is a direct result from the 
fun we had with D.

So take my comments however you like, D is not ready for specific 
production jobs. If you build all your code yourself, then D is 
usable. But the moment you rely on 3th party code in the D 
platform, it is unstable at best.
Sep 05 2018
parent reply 0xEAB <desisma heidel.beer> writes:
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.
Sep 05 2018
parent JN <666total wp.pl> writes:
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".
Sep 06 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 05 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Sep 05 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/05/2018 05:49 PM, H. S. Teoh wrote:

 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.
 


That's something else I've been thinking for awhile would be really good 
to integrate into a package manager: CI results. I'm not aware of any 
package manager that does it. (Though my worldview can be a bit small, 
so who knows?)

In the olden days of D, for my libs and projects and such, I used to 
maintain a note in my source, readme, etc about "This project has been 
tested to compile with DMD vBlah, blah, blah". And changes would be 
noted in the changelog.

Of course that was horrible, so now that there's CI, all my projects 
define "supported compiler versions" as "Whatever is listed in 
.travis.yml/appveyor.yml". And I try to be explicit about that in the 
readme, and provide a link to the file.

Personally, I think that's a really good way to go. However, for awhile 
now, I've been starting to think: "Wouldn't it be awesome to have a 
packager manager that AUTOMATICALLY picks up compatibility information 
directly from each project's CI results for each tagged release?"

I think that would be freaking sweet.

It would also be nice to have a simple, built-in way to test against 
multiple dependency versions. Right now, I have some projects that kinda 
hack around that by using a custom buildscript that checks an envvar I 
can set in .travis.yml for an alternate dub.selections.json to be used 
in-place of dub.selections.json (by copying overtop the default one). I 
mainly use that for compiler versions that require alternate versions of 
my project's dependencies (usually vibe.d). But it can also be used to 
test on a range of dependencies. So far, I like to test on both "oldest 
supported dep versions" and "latest available". Ideally, I'd like to 
expand that though, although it is a tradeoff between basic rigor vs not 
soaking up too much of the CI's free resources.

It's nice, but problem is, all that could be handled much better, given 
proper support from a package manager. But the biggest thing that would 
help here is still just proper orthogonal handling of dependencies (ie, 
not treating compiler and package manager as the dependencies they 
really are).

(Weird...I just realized, I think my spellchecker is set to a UK dict 
instead of a US one. Not sure if it's Thunderbird or my whole system 
(Manjaro), or what to do about it...Ugh, more futzing ahead...)
Sep 07 2018
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky 
(Abscissa) wrote:

 Personally, I think that's a really good way to go. However, 
 for awhile now, I've been starting to think: "Wouldn't it be 
 awesome to have a packager manager that AUTOMATICALLY picks up 
 compatibility information directly from each project's CI result


How many projects do use CI, though? Especially how many of those 
that actually suffer from not being actively maintained?
How many project maintainers are interested in playing around 
with different compiler versions on their CI?  Even if they are, 
in the end they will just remove old compilers as soon as 
building with them fails in order to get positive CI results...

my 2 ¢
Sep 07 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/07/2018 10:29 AM, 0xEAB wrote:

 On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky (Abscissa) 
 wrote:

 Personally, I think that's a really good way to go. However, for 
 awhile now, I've been starting to think: "Wouldn't it be awesome to 
 have a packager manager that AUTOMATICALLY picks up compatibility 
 information directly from each project's CI result


 
 How many projects do use CI, though? Especially how many of those that 
 actually suffer from not being actively maintained?
 How many project maintainers are interested in playing around with 
 different compiler versions on their CI?  Even if they are, in the end 
 they will just remove old compilers as soon as building with them fails 
 in order to get positive CI results...
 


Those are all valid problems, but they're all equally problematic 
regardless of whether or not a package manager makes use of the CI data 
available.

But at least with a CI-aware pack manager, the package manager can at 
least avoid selecting a dependency combination that CI testing has 
already shown doesn't work.

Plus, if not enough projects use CI, than any additional incentive to 
nudge them into using it is only a good thing.
Sep 07 2018
prev sibling parent reply Guillaume Piolat <spam smam.org> writes:
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky 
(Abscissa) wrote:

 Personally, I think that's a really good way to go. However, 
 for awhile now, I've been starting to think: "Wouldn't it be 
 awesome to have a packager manager that AUTOMATICALLY picks up 
 compatibility information directly from each project's CI 
 results for each tagged release?"

 I think that would be freaking sweet.


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)
Sep 08 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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?
Sep 08 2018
parent reply Guillaume Piolat <spam smam.org> writes:
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
Sep 09 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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).
Sep 10 2018
parent Guillaume Piolat <spam smam.org> writes:
On Monday, 10 September 2018 at 12:16:03 UTC, Adam D. Ruppe wrote:

 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).


Perhaps -profile=gc can tell
Webfreak made a "symbol search" program which looks similar?
Sep 20 2018
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Sep 06 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/06/2018 09:12 AM, Steven Schveighoffer wrote:


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


Even with perfect backwards compatibility in the compiler, minimum 
compiler version will still tend to matter. Also, cherry-picking 
specific 2.x.0 versions that are known to not work due to regressions.


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


True enough.


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


Fair point on manpower.
Sep 07 2018
parent 0xEAB <desisma heidel.beer> writes:
On Friday, 7 September 2018 at 08:17:45 UTC, Nick Sabalausky 
(Abscissa) wrote:

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


 Fair point on manpower.


Does using semver really solve anything here?
I've got the feeling that we'll end up with v128.0.1, v129.0.0, 
v130.0.0 and so on, plus nobody caring about maintaining an LTS 
branches.

Also, anybody is free to downgrade their compiler to any outdated 
version anyway, giving those old versions a different version 
number won't make using them more attractive, imho.
Sep 07 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 05, 2018 at 01:18:17AM +0000, James Blachly via Digitalmars-d wrote:

 On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:
 


 ...


[...]

 Are you talking about this?
 
 https://github.com/clinei/3ddemo
 
 which hasn't been updated since February 2016?


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.
- if a particular (version of a) package fails to build for whatever
  reason, log the failure and have a bot add a note to dlang.org that
  this package does NOT build with that compiler version.
   - possibly add the package to a blacklist for this compiler version
     so that we don't consume too many resources on outdated packages
     that no longer build.
- periodically update dlang.org (by bot) to indicate the last known
  compiler version that successfully built this package.
- in the search results, give preference to packages that built
  successfully with the latest official release.

This should help clear up these incidents with outdated packages.


T


T

-- 
When solving a problem, take care that you do not become part of the problem.
Sep 04 2018
next sibling parent Eugene Wissner <belka caraus.de> writes:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:

 On Wed, Sep 05, 2018 at 01:18:17AM +0000, James Blachly via 
 Digitalmars-d wrote:

 On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:
 


 ...


 [...]

 Are you talking about this?
 
 https://github.com/clinei/3ddemo
 
 which hasn't been updated since February 2016?


 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.
 - if a particular (version of a) package fails to build for 
 whatever
   reason, log the failure and have a bot add a note to 
 dlang.org that
   this package does NOT build with that compiler version.
    - possibly add the package to a blacklist for this compiler 
 version
      so that we don't consume too many resources on outdated 
 packages
      that no longer build.
 - periodically update dlang.org (by bot) to indicate the last 
 known
   compiler version that successfully built this package.
 - in the search results, give preference to packages that built
   successfully with the latest official release.

 This should help clear up these incidents with outdated 
 packages.


 T


 T


Many CI failures I had where because of code.dlang.org wasn't 
accessible (and none of its mirrors). It doesn't make sense to 
test a bunch of packages without a reliable infrastructure.
Furthermore I don't think it is the problem. The problem is that 
I can take PHP7 from this year and run pretty big 5 years old 
applications with it. It isn't possible with D. And it is 
something Walter mentioned many times: there are people who want 
changes and people who want stability - and you can't make 
everyone happy.

For example I like the fact that the language changes 
permanently. Things like broken interface contracts - regression 
that isn't fixed for two years now - make me really sad, but 
conscious breakages with deprecation period are fine. PHP doesn't 
have the freedom to update the language more than it does because 
of economic reasons: a lot of smaller customers just don't have 
money to update their code every month or they don't understand 
why they should spend money on it if it already works (I think it 
is similar for C++), so I also use D that can step forward faster.
Sep 04 2018
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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.


This kind of automation would also be useful for semantic 
versioning. By detecting whether a PR would cause any existing 
projects to not compile, we could automatically determine whether 
to apply it to the next minor release.

Unfortunately, that wouldn't distinguish between patch and minor 
releases, but probably a decent heuristic would be if any new 
compilable / runnable testcases were added.
Sep 04 2018
parent reply JN <666total wp.pl> writes:
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.

I agree however that dub needs some mechanism of marking outdated 
packages. I think it'd be healthy for D ecosystem in the long run 
in general. There were a few times when I wanted to implement 
some functionality, I was like "oh, there's obviously a dub 
package for that". And there were, seven of them. Turns out two 
were just an experiment, four didn't compile anymore (not 
maintained since 2016), the last one worked, but I had to use a 
git dev branch, because the one in the repository wasn't working 
properly.

I commonly see an argument for putting things like logging, 
serialization, archive support out of standard library and into 
dub packages. I think it has some merit, but one of the main 
advantages of having stuff in the standard library is that it's 
commonly used and tested. I can expect std.experimental.logging, 
std.zip to always work, because they are properly tested as part 
of D release process.
Sep 05 2018
parent reply Guillaume Piolat <spam smam.org> writes:
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.
Sep 06 2018
parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
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 ?
Sep 06 2018
parent reply 0xEAB <desisma heidel.beer> writes:
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?
Sep 06 2018
parent Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
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.
Sep 06 2018
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:

 On Wed, Sep 05, 2018 at 01:18:17AM +0000, James Blachly via 
 Digitalmars-d 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.
 - if a particular (version of a) package fails to build for 
 whatever
   reason, log the failure and have a bot add a note to 
 dlang.org that
   this package does NOT build with that compiler version.
    - possibly add the package to a blacklist for this compiler 
 version
      so that we don't consume too many resources on outdated 
 packages
      that no longer build.
 - periodically update dlang.org (by bot) to indicate the last 
 known
   compiler version that successfully built this package.
 - in the search results, give preference to packages that built
   successfully with the latest official release.

 [...]


I think this idea was suggested before and I hope this will be 
done.
And when the compilation yield some warnings, about deprecation, 
the owner of the package should be notified and asked for update, 
too.

Regards MT.
Sep 05 2018
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
 - if a particular (version of a) package fails to build for 
 whatever
   reason, log the failure and have a bot add a note to 
 dlang.org that
   this package does NOT build with that compiler version.
    - possibly add the package to a blacklist for this compiler 
 version
      so that we don't consume too many resources on outdated 
 packages
      that no longer build.
 - periodically update dlang.org (by bot) to indicate the last 
 known
   compiler version that successfully built this package.
 - in the search results, give preference to packages that built
   successfully with the latest official release.


Yes please!
Sep 06 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 6 September 2018 at 18:20:05 UTC, Bastiaan Veelo 
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.
 - if a particular (version of a) package fails to build for 
 whatever
   reason, log the failure and have a bot add a note to 
 dlang.org that
   this package does NOT build with that compiler version.
    - possibly add the package to a blacklist for this compiler 
 version
      so that we don't consume too many resources on outdated 
 packages
      that no longer build.
 - periodically update dlang.org (by bot) to indicate the last 
 known
   compiler version that successfully built this package.
 - in the search results, give preference to packages that built
   successfully with the latest official release.


 Yes please!


Ah, but would you actually pay for such a service to be set up?

https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo forum.dlang.org

It's all well and good to hope for such services, but they're 
unlikely to happen unless paid for.
Sep 06 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via Digitalmars-d 
wrote:

 Ah, but would you actually pay for such a service to be set up?

 https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo forum.dlang.org

 It's all well and good to hope for such services, but they're
 unlikely to happen unless paid for.


That's actually something that I could see happening without anyone being
paid to do it, but it's much more likely to get done in a timely manner if
someone is paid to do it, and it's arguably critical enough for the dub
ecosystem that it's something that the Foundation should pay someone to do.

- Jonathan M Davis
Sep 06 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis 
wrote:

 On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via 
 Digitalmars-d wrote:

 Ah, but would you actually pay for such a service to be set up?

 https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo forum.dlang.org

 It's all well and good to hope for such services, but they're 
 unlikely to happen unless paid for.


 That's actually something that I could see happening without 
 anyone being paid to do it, but it's much more likely to get 
 done in a timely manner if someone is paid to do it, and it's 
 arguably critical enough for the dub ecosystem that it's 
 something that the Foundation should pay someone to do.

 - Jonathan M Davis


The software itself is pretty simple (besides it has to deal with 
some DUB bugs). It would just need someone to run it. If running 
it every DMD release is sufficient and if it doesn't need to be 
automated, it won't be such a big deal anymore.

By the way, I'm currently playing around testing DUB packages 
with my prototype.
Sep 07 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, September 7, 2018 8:36:11 AM MDT 0xEAB via Digitalmars-d wrote:

 On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis

 wrote:

 On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via

 Digitalmars-d wrote:

 Ah, but would you actually pay for such a service to be set up?

 https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo forum.dlang.org

 It's all well and good to hope for such services, but they're
 unlikely to happen unless paid for.


 That's actually something that I could see happening without
 anyone being paid to do it, but it's much more likely to get
 done in a timely manner if someone is paid to do it, and it's
 arguably critical enough for the dub ecosystem that it's
 something that the Foundation should pay someone to do.

 - Jonathan M Davis


 The software itself is pretty simple (besides it has to deal with
 some DUB bugs). It would just need someone to run it. If running
 it every DMD release is sufficient and if it doesn't need to be
 automated, it won't be such a big deal anymore.

 By the way, I'm currently playing around testing DUB packages
 with my prototype.


I don't see how such a system could work very well if it's not automated.
Simply doing it with every release of dmd means that newer packages won't be
tested, and it would force someone to take the time to run stuff every dmd
release, which they may or may not have time to do. IMHO, it really only
makes sense to set up something automated.

I would expect that any time code.dlang.org detected that a package had a
new version (or a package was added), the new versions would be tested.

What's somewhat more of an open question is how new compiler releases should
be handled. Aside from the issue that _every_ package then potentially needs
to be tested (which could take a while), there's the issue of which versions
to test. Testing every release of a package would be overkill, but simply
testing the latest isn't necessarily enough.

Also, there's the question of what it even means to test each package to
verify that it's working. Does that mean running the unit tests? Not all
projects run them the same way, and it could be pretty expensive to run the
tests for all packages on code.dlang.org. And of course, that assumes that
the package even has any unit tests to begin with. So, should testing the
package just mean that dub build works? That will catch the really basic
problems, but it won't usually catch problems in templates and could easily
miss other types of problems - though maybe it's enough. Regardless, it's
going to need to be made clear what it means that code.dlang.org claims that
a package works with a particular version of the compiler.

All in all, while this seems like a great idea, the more I think about it,
the more it seems like it could get pretty thorny when sorting out all of
the details.

- Jonathan M Davis
Sep 07 2018
parent 0xEAB <desisma heidel.beer> writes:
On Friday, 7 September 2018 at 15:24:13 UTC, Jonathan M Davis 
wrote:

 I don't see how such a system could work very well if it's not 
 automated. Simply doing it with every release of dmd means that 
 newer packages won't be tested, and it would force someone to 
 take the time to run stuff every dmd release, which they may or 
 may not have time to do. IMHO, it really only makes sense to 
 set up something automated.


How big is the chance that a newly added package isn't compatible 
with the recent version of DMD?
But yeah, I get your point of the problematic of having this not 
automated.
Sep 07 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Sep 07, 2018 at 09:24:13AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
[...]

 I don't see how such a system could work very well if it's not
 automated.  Simply doing it with every release of dmd means that newer
 packages won't be tested, and it would force someone to take the time
 to run stuff every dmd release, which they may or may not have time to
 do. IMHO, it really only makes sense to set up something automated.


Yes, it needs to be automated and run in the background by a machine.
Humans are just too unreliable for this.



 I would expect that any time code.dlang.org detected that a package
 had a new version (or a package was added), the new versions would be
 tested.


That would make the most sense.



 What's somewhat more of an open question is how new compiler releases
 should be handled. Aside from the issue that _every_ package then
 potentially needs to be tested (which could take a while), there's the
 issue of which versions to test. Testing every release of a package
 would be overkill, but simply testing the latest isn't necessarily
 enough.


The initial setup will take a long time because we have so many packages
that have never been tested in this way before.  But once the database
is up-to-date, I expect that it will take much less work to keep things
up-to-date.

For the initial setup, I don't think it's necessary to test *every*
historial release of the compiler -- the most important thing is the
current official releases of all compilers (gdc, ldc, dmd).[*]  If a
package doesn't compile with the latest release, then optionally do a
unidirectional search backwards to find the last compiler version that
compiles it successfully, and log that.

([*] I was going to suggest including dmd-nightly as well, but that
poses the problem of load: running it every night will cause a lot of CI
churn, which also generates a lot of mostly-useless information -- no
one will care about which of 50 dmd git revisions failed / succeeded to
compile a package, just whether the *latest* dmd-nightly works.  So
perhaps an update once a week or once a month in between releases will
be enough.  But dmd-nightly is an optional extra that can be skipped for
now.  The important baseline is the current official releases of gdc /
ldc / dmd.)



 Also, there's the question of what it even means to test each package
 to verify that it's working. Does that mean running the unit tests?
 Not all projects run them the same way, and it could be pretty
 expensive to run the tests for all packages on code.dlang.org. And of
 course, that assumes that the package even has any unit tests to begin
 with. So, should testing the package just mean that dub build works?
 That will catch the really basic problems, but it won't usually catch
 problems in templates and could easily miss other types of problems -
 though maybe it's enough. Regardless, it's going to need to be made
 clear what it means that code.dlang.org claims that a package works
 with a particular version of the compiler.


[...]

Let's not overcomplicate things and doom the flight before it takes off.
Let's start with the absolute minimum baseline, and then additional
perks can be added on top of that once the baseline is working.

I say the baseline is that dub build works.

If we feel like going an extra mile, dub test.

If we feel like doing even more, then add other stuff like compiling
provided example programs, testing template instantiations and what-not.
(Though one would expect that dub test ought to do that already,
otherwise I question the quality of the code / unittests.)

As long as we publish exactly what is being run to verify whether the
package "works", I think that should be good enough for starters.  Even
if dub build, say, doesn't catch all problems, it's still better than
the status quo of no information at all.  Let's not let the perfect
become the enemy of the good, as is the common malady around here.


T

-- 
The problem with the world is that everybody else is stupid.
Sep 07 2018
parent reply rjframe <dlang ryanjframe.com> writes:
On Fri, 07 Sep 2018 09:35:29 -0700, H. S. Teoh wrote:


 ([*] I was going to suggest including dmd-nightly as well, but that
 poses the problem of load: running it every night will cause a lot of CI
 churn, which also generates a lot of mostly-useless information -- no
 one will care about which of 50 dmd git revisions failed / succeeded to
 compile a package, just whether the *latest* dmd-nightly works.  So
 perhaps an update once a week or once a month in between releases will
 be enough.  But dmd-nightly is an optional extra that can be skipped for
 now.  The important baseline is the current official releases of gdc /
 ldc / dmd.)


The beta might be better than dmd-nightly, as they would avoid the churn 
and still provide maintainers with time to react to problems with the 
upcoming release before the release is out.
Sep 08 2018
parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 8 September 2018 at 11:24:50 UTC, rjframe wrote:

 The beta might be better than dmd-nightly, as they would avoid 
 the churn and still provide maintainers with time to react to 
 problems with the upcoming release before the release is out.


Betas are often outdated and contain problems that are already 
fixed in the released version. For example right now if you test 
something with dmd beta you test 2.082-beta.2 but 2.082.0 is 
already released. That sounds  crazy when you thing more about 
that.
Sep 08 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
Sep 09 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Sep 09 2018
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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
Sep 10 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Monday, 10 September 2018 at 10:50:16 UTC, Joakim wrote:

 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.


Thank you, fixed.

For some reason, libcurl was being linked in only with dub build, 
and despite the fact that the test harness itself uses libcurl, 
dub build couldn't find it.

I cleared out all failed builds just to be certain -- about six 
hours lost total, and I'll trade six hours for bad data any day.


 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:


Thank you.
Sep 10 2018
prev sibling next sibling parent reply 0xEAB <desisma heidel.beer> writes:
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?
Sep 10 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Monday, 10 September 2018 at 13:58:37 UTC, 0xEAB wrote:

 May I ask why some packages are missing (e.g. `midi-gamepad`)?


midi-gamepad has no releases. It has 0.1.1-alpha, which is a 
prelease version, and ~master, which is a branch, and I can't 
rely on ~master being consistent in successive builds.


 A question, how this it currently handle link libraries?


It blindly takes the results of dub build and dub test.
Sep 10 2018
next sibling parent 0xEAB <desisma heidel.beer> writes:
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh 
wrote:

 midi-gamepad has no releases. It has 0.1.1-alpha


So it doesn't test pre-release versions.
Thanks for clarification.
Sep 10 2018
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh 
wrote:

 It blindly takes the results of dub build and dub test.


Another question:
How does it deal with targetType set to "sourceLibrary"?

Moreover, a future feature could be build logs, so one could 
check why something failed to build.
Sep 10 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote:

 On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh 
 wrote:

 It blindly takes the results of dub build and dub test.


 Another question:
 How does it deal with targetType set to "sourceLibrary"?


As of five minutes ago, for source libraries, the test result is 
copied to the build result.


 Moreover, a future feature could be build logs, so one could 
 check why something failed to build.


I'm hesitant to do much in this regard because I don't want 
people to treat this as a CI system. It would certainly be useful 
for finding bugs in the tester, though.
Sep 10 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Monday, 10 September 2018 at 20:36:44 UTC, Neia Neutuladh 
wrote:

 On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote:

 Moreover, a future feature could be build logs, so one could 
 check why something failed to build.


 I'm hesitant to do much in this regard because I don't want 
 people to treat this as a CI system. It would certainly be 
 useful for finding bugs in the tester, though.


A possible solution to this problem could be not testing updated 
packages for a compiler version they have already been tested 
with. This comes with some downsides, though - but it prevents 
abusing your service as CI.


By the way, thanks for all your explanations :)
Sep 11 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 11 September 2018 at 13:48:36 UTC, 0xEAB wrote:

 By the way, thanks for all your explanations :)


No problem! If it's inscrutable, it's not very useful.
Sep 11 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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/.


A quick status update:

Per-package reports and build badges are now a thing. 
http://ikeran.org/report/package/accessors.html Dunno if anybody 
would want a build badge, but it's there. And a bit big. Oh well.

Backfill has gotten all .0 releases from 2.069.0 forward. I'm 
cutting off the backfill for point releases at 2.080.1, about two 
days from now. 19 compilers rather than 43 makes this project a 
bit more sustainable. (It was previously taking six hours to 
build a single compiler release, but with some changes, it 
started taking 16.)

After the backfill finishes, I'll start grabbing new dub 
packages, which will be trivial. The next tasks are 
auto-detecting new DMD versions (pretty straightforward) and 
making machine-readable output.

As an aside, the current output is about 50MB of HTML and SVG, 
served as static files. I thought of using arsd's cgi.d, but 
there really isn't a point for now.
Sep 19 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh 
wrote:

 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/.


 A quick status update:


And source code is available at 
https://git.ikeran.org/dhasenan/dubautotester

Please don't judge me.
Sep 19 2018
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 20 September 2018 at 04:16:41 UTC, Neia Neutuladh 
wrote:

 And source code is available at 
 https://git.ikeran.org/dhasenan/dubautotester

 Please don't judge me.


Nice work.
Sep 19 2018
prev sibling parent reply drug <drug2004 bk.ru> writes:
20.09.2018 07:16, Neia Neutuladh пишет:

 On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh wrote:

 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/.


 A quick status update:


 
 And source code is available at 
 https://git.ikeran.org/dhasenan/dubautotester
 
 Please don't judge me.


Autotester should show build logs because for example `nanogui` package 
reported as failed although it builds on my machines successfully.
Sep 19 2018
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 20 September 2018 at 06:41:54 UTC, drug wrote:

 Autotester should show build logs because for example `nanogui` 
 package reported as failed although it builds on my machines 
 successfully.


This is because the D project tester (i assume this is what you 
call autotester) uses optionally a custom script, i believe. Same 
problem for "iz". It's ok in the autotester but not in the 
dubautotester. Fortunately this one can be fixed, it's just a 
problem with "warningAsError".

I agree for the logs. This could help authors.
Sep 20 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thursday, 20 September 2018 at 06:41:54 UTC, drug wrote:

 Autotester should show build logs because for example `nanogui` 
 package reported as failed although it builds on my machines 
 successfully.


The tester is now submodule-aware and I removed builds for 
packages with a `.gitmodules` file.

I'm adding logs only for failed builds. This is an annoying 
amount of UI work that I might well have messed up horribly.
Sep 20 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh 
wrote:

 The tester is now submodule-aware and I removed builds for 
 packages with a `.gitmodules` file.


I'm not sure whether this is actually a good idea. There are some 
projects that support both, DUB and submodules+makefile. Those 
would (unnecessarily) get excluded.
Sep 21 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Friday, 21 September 2018 at 20:49:54 UTC, 0xEAB wrote:

 On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh 
 wrote:

 The tester is now submodule-aware and I removed builds for 
 packages with a `.gitmodules` file.


 I'm not sure whether this is actually a good idea. There are 
 some projects that support both, DUB and submodules+makefile. 
 Those would (unnecessarily) get excluded.


I meant that I removed the past builds for things with git 
submodules so that they could be rebuilt.

Stderr is captured now, but I believe I messed up the UI for it. 
C'est la vie.
Sep 21 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 21 September 2018 at 22:26:11 UTC, Neia Neutuladh 
wrote:

 On Friday, 21 September 2018 at 20:49:54 UTC, 0xEAB wrote:

 On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh 
 wrote:

 The tester is now submodule-aware and I removed builds for 
 packages with a `.gitmodules` file.


 I'm not sure whether this is actually a good idea. There are 
 some projects that support both, DUB and submodules+makefile. 
 Those would (unnecessarily) get excluded.


 I meant that I removed the past builds for things with git 
 submodules so that they could be rebuilt.

 Stderr is captured now, but I believe I messed up the UI for 
 it. C'est la vie.


The "tests" check doesn't seem to work properly for DMD <= 
v2.072.0.

If one looks at the reports[0] for those compilers, one will that 
pretty everything failed.
For example, `discord-rpc`[1] doesn't even have any unittests.


[0] http://ikeran.org/report/compiler/dmd2.072.0.html
[1] http://ikeran.org/report/package/discord-rpc.html
Oct 06 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On 10/06/2018 01:38 AM, 0xEAB wrote:

 The "tests" check doesn't seem to work properly for DMD <= v2.072.0.
 
 If one looks at the reports[0] for those compilers, one will that pretty 
 everything failed.
 For example, `discord-rpc`[1] doesn't even have any unittests.


I'm clearing out those build results so we'll rerun them. This should 
get proper error reports as well (they're working at last!).

I've also moved the project to proper hosting, which should slow it down 
even more but provide better security.
Oct 06 2018
prev sibling parent Manu <turkeyman gmail.com> writes:
On Tue., 4 Sep. 2018, 10:45 pm H. S. Teoh via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:


 On Wed, Sep 05, 2018 at 01:18:17AM +0000, James Blachly via Digitalmars-d
 wrote:

 On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:


 ...


 [...]

 Are you talking about this?

 https://github.com/clinei/3ddemo

 which hasn't been updated since February 2016?


 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.
 - if a particular (version of a) package fails to build for whatever
   reason, log the failure and have a bot add a note to dlang.org that
   this package does NOT build with that compiler version.
    - possibly add the package to a blacklist for this compiler version
      so that we don't consume too many resources on outdated packages
      that no longer build.
 - periodically update dlang.org (by bot) to indicate the last known
   compiler version that successfully built this package.
 - in the search results, give preference to packages that built
   successfully with the latest official release.

 This should help clear up these incidents with outdated packages.


Bravo. Can't wait!






 Sep 05 2018



prev sibling next sibling parent reply Paul Backus <snarwin gmail.com>  writes:


On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 There is really no incentive for me to use D except for it's 
 language features... everything else it does, besides 
 performance, is shit compared to what most other languages do. 
 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).


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.



 Sep 04 2018



  parent reply Everlast <Everlast For.Ever>  writes:


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:

 There is really no incentive for me to use D except for it's 
 language features... everything else it does, besides 
 performance, is shit compared to what most other languages do. 
 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).


 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!



 Sep 04 2018



 next sibling parent reply Andre Pany <andre s-e-a-p.de>  writes:


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



 Sep 05 2018



  parent reply Everlast <Everlast For.Ever>  writes:


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...



 Sep 06 2018



 next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com>  writes:


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.



 Sep 06 2018



  parent reply Everlast <Everlast For.Ever>  writes:


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...



 Sep 06 2018



  parent  Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com>  writes:


On Thursday, 6 September 2018 at 16:27:38 UTC, Everlast wrote:

 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...


I know that you wanted to talk about easier maintenance. But what 
exactly is that D organization going to do ? Prevent people from 
making more packages and force them to work on theirs instead ?
No matter if there is an organization, there will always be 
unofficial packages going stale. You sound like it's going to be 
a magical solution.



 Sep 06 2018



prev sibling  parent reply Patrick Schluter <Patrick.Schluter bbox.fr>  writes:


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.



 Sep 06 2018



  parent reply Everlast <Everlast For.Ever>  writes:


On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter 
wrote:

 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.


The problem is that google isn't going to help. Most people find 
packages by searching google in some way and then follow that 
rabbit hole. It would be impossible to know then until it's too 
late.

But things such as your suggestions can mitigate the problem. 
Dub, for example, could have a list of reliable packages built 
in(or could have a master list) that can automatically inform the 
user about these issues... rather than the user having to look up 
on a web page.

The more the compilers and tools do for us the easier our life 
becomes. The more complex things get the more time it takes. 
Since most things tend towards complexity it means things should 
be designed well from the get go before they become mainstream so 
messes like this do not happen.



 Sep 06 2018



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Thu, Sep 06, 2018 at 04:32:09PM +0000, Everlast via Digitalmars-d wrote:

 On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter wrote:


[...]

 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.


 
 The problem is that google isn't going to help. Most people find
 packages by searching google in some way and then follow that rabbit
 hole. It would be impossible to know then until it's too late.
 
 But things such as your suggestions can mitigate the problem. Dub, for
 example, could have a list of reliable packages built in(or could have
 a master list) that can automatically inform the user about these
 issues...  rather than the user having to look up on a web page.


[...]

Again, this strongly suggests the idea I've mentioned a few times now:
*all* packages on code.dlang.org needs to be run through a CI tester,
and success/failure to compile should be reported back to dlang.org
somehow.  Then in the search results and in the package's home page,
there should be a prominently-displayed notice of which compiler
versions work / don't work with the package.

This gives users the information they need to make the right decision
(e.g., the last known compiler that compiles this package is 2.060, so
don't bother, move on.).

And this *must* be automated, because nobody has the time or energy to
manually test every package against every known compiler release and
manually update code.dlang.org.  And doing it manually tends to quickly
get out of date, not to mention the chance of human error.


T

-- 
Ignorance is bliss... until you suffer the consequences!



 Sep 06 2018



  parent reply Nicholas Wilson <iamthewilsonator hotmail.com>  writes:


On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:

 Again, this strongly suggests the idea I've mentioned a few 
 times now: *all* packages on code.dlang.org needs to be run 
 through a CI tester, and success/failure to compile should be 
 reported back to dlang.org somehow.  Then in the search results 
 and in the package's home page, there should be a 
 prominently-displayed notice of which compiler versions work / 
 don't work with the package.

 This gives users the information they need to make the right 
 decision (e.g., the last known compiler that compiles this 
 package is 2.060, so don't bother, move on.).

 And this *must* be automated, because nobody has the time or 
 energy to manually test every package against every known 
 compiler release and manually update code.dlang.org.  And doing 
 it manually tends to quickly get out of date, not to mention 
 the chance of human error.


 T


How would this work for packages that cannot be built by DMD? Or 
that have no CI infrastructure but are maintained? *cough* 
DCompute *cough*



 Sep 08 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Saturday, September 8, 2018 7:28:53 AM MDT Nicholas Wilson via 
Digitalmars-d wrote:

 On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:

 Again, this strongly suggests the idea I've mentioned a few
 times now: *all* packages on code.dlang.org needs to be run
 through a CI tester, and success/failure to compile should be
 reported back to dlang.org somehow.  Then in the search results
 and in the package's home page, there should be a
 prominently-displayed notice of which compiler versions work /
 don't work with the package.

 This gives users the information they need to make the right
 decision (e.g., the last known compiler that compiles this
 package is 2.060, so don't bother, move on.).

 And this *must* be automated, because nobody has the time or
 energy to manually test every package against every known
 compiler release and manually update code.dlang.org.  And doing
 it manually tends to quickly get out of date, not to mention
 the chance of human error.


 T


 How would this work for packages that cannot be built by DMD? Or
 that have no CI infrastructure but are maintained? *cough*
 DCompute *cough*


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.

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



 Sep 08 2018



 next sibling parent  Neia Neutuladh <neia ikeran.org>  writes:


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.



 Sep 08 2018



prev sibling  parent  0xEAB <desisma heidel.beer>  writes:


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.



 Sep 09 2018



prev sibling  parent  lurker <lurker aol.com>  writes:


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.



 Sep 05 2018



prev sibling next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com>  writes:


On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:

 logger 2.66.0: building configuration "library"...
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16):
Error: cannot implicitly convert expression logger of type shared(Logger) to
std.historical.logger.core.Logger
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21):
Error: no property fracSec for type const(SysTime), did you mean
std.datetime.systime.SysTime.fracSecs?
 \dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(86,27):
Error: template instance
`std.historical.logger.core.systimeToISOString!(LockingTextWriter)` error
instantiating
 dmd.exe failed with exit code 1.

 [...]


Isn't that the historical branch? Well then of course it mightn't 
work due to advancements in the std lib. Why aren't you using 
std.experimental.logger?

If D is so "shit", why not use another language? Most things work 
fine if you aren't grappling to old libraries and using that 
clutch at straws that D is "dying".



 Sep 04 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Tuesday, September 4, 2018 7:54:49 PM MDT Dylan Graham via Digitalmars-d 
wrote:

 On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:

 logger 2.66.0: building configuration "library"...
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16)
 : Error: cannot implicitly convert expression logger of type
 shared(Logger) to std.historical.logger.core.Logger
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21)
 : Error: no property fracSec for type const(SysTime), did you mean
 std.datetime.systime.SysTime.fracSecs?
 \dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(8
 6,27): Error: template instance
 `std.historical.logger.core.systimeToISOString!(LockingTextWriter)`
 error instantiating dmd.exe failed with exit code 1.

 [...]


 Isn't that the historical branch? Well then of course it mightn't
 work due to advancements in the std lib. Why aren't you using
 std.experimental.logger?

 If D is so "shit", why not use another language? Most things work
 fine if you aren't grappling to old libraries and using that
 clutch at straws that D is "dying".


If I understand correctly, those errors are from trying to simply use a
package from code.dlang.org. The code errors are not his. They're a result
of the package he's trying to use not being maintained, which very much does
suck, though it's going to be a problem with most any language to one degree
or another. I think that he's overreacting, but he is pointing out a real
problem that has been discussed before. We need to find a way to improve
code.dlang.org so that it's clearer whether a package is maintained and
working or whether it's been abandoned. For all I know, the folks working on
code.dlang.org already have plans for a way to improve that, but they're
busy people, and progress isn't always fast - especially when it's a quality
of life thing and not a technical issue that has to be fixed for things to
work.

- Jonathan M Davis



 Sep 04 2018



  parent reply Dylan Graham <dylan.graham2000 gmail.com>  writes:


On Wednesday, 5 September 2018 at 02:10:27 UTC, Jonathan M Davis 
wrote:

 [...]


Sure, yeah, but if you're using a package that hasn't been 
maintained in 2-3 years you need to take whether it will work 
with a grain of salt anyway.



 Sep 04 2018



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Tuesday, September 4, 2018 8:37:16 PM MDT Dylan Graham via Digitalmars-d 
wrote:

 On Wednesday, 5 September 2018 at 02:10:27 UTC, Jonathan M Davis

 wrote:

 [...]


 Sure, yeah, but if you're using a package that hasn't been
 maintained in 2-3 years you need to take whether it will work
 with a grain of salt anyway.


Definitely, but plenty of folks seem to eroneously assume that everything on
code.dlang.org works, and unless you're actively thinking about the
possibility that something there is unmaintained, you're probably not going
to notice that it hasn't been updated in years. And sadly, even if a package
was updated a few months ago, it could still be broken. So, the date that it
was last updated isn't always a good measure of whether it works, though the
older the date is, the more likely it is that the package is broken.

I don't actually think that this is a huge issue, but I do think that past
discussions on the topic have made it fairly clear that we need to improve
code.dlang.org with regards to making it clearer which packages are actively
maintained and generally considered to be solid vs those which are
unmaintained and/or in an alpha state. Stuff like the package's rating and
how old the most recent version is definitely help, but more could (and
arguably should) be done. However, as with many things around here, even if
we agree that something should be done, that doesn't mean that it's actually
going to get done soon - especially if it's something that's more likely to
cause pain to newcomers than longtime users.

- Jonathan M Davis



 Sep 04 2018



prev sibling next sibling parent  Kagamin <spam here.lot>  writes:


On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:

 This attitude of "It's your problem" is going to kill D.


Well, if you hate problems, programming will hurt you a lot in 
any language.



 Sep 05 2018



prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On 9/4/18 8:49 PM, Everlast wrote:

 I downloaded 3ddemo, extracted, built and I get these errors:
 
 logger 2.66.0: building configuration "library"...
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16):
Error: 
 cannot implicitly convert expression logger of type shared(Logger) to 
 std.historical.logger.core.Logger
 \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21): 
 Error: no property fracSec for type const(SysTime), did you mean 
 std.datetime.systime.SysTime.fracSecs?
 \dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(86,27): 
 Error: template instance 
 `std.historical.logger.core.systimeToISOString!(LockingTextWriter)` 
 error instantiating
 dmd.exe failed with exit code 1.
 
 This is typical with most of my trials with D... something is always 
 broken all the time and I'm expected to jump through a bunch of hoops to 
 get it to work. File a issue, fix it myself, use a different library, 
 etc. I'm expected to waste my time fixing a problem that really should 
 not exist or should have a high degree of automation to help fix it. I 
 really have better things to do with my time so I won't invest it in D.


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.

I built it successfully with DMD 2.076 (I just picked a random old 
version). So it's still usable, you just have to know what version of 
the compiler to use. I'd say it would be nice to record which version it 
builds with in some way on code.dlang.org.


 
 This attitude of "It's your problem" is going to kill D.


I wouldn't say the attitude is "It's your problem", but more that you 
can't expect a completely unmaintained, scantily tested piece of 
software to magically work because it's written in D.

In this phase of D's life, things just aren't going to stay buildable. 
We are making too many changes to the language and the standard library 
to say that D is going to build things today that were buildable 2+ 
years ago.

In time, this will settle down, and D will be much more stable. I'd 
recommend coming back and checking again later. But I would definitely 
suggest not looking for older projects to test with.


 There is really no incentive for me to use D except for it's language 
 features... everything else it does, besides performance, is shit 
 compared to what most other languages do. Really, D wins on very few 
 metrics but the D fanboys will only focus on those.


Sounds like you have other problems than buildability, so maybe D just 
isn't right for you. Thanks for stopping by!

-Steve



 Sep 05 2018



 next sibling parent reply SashaGreat <s great.com>  writes:


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.

 I built it successfully with DMD 2.076 (I just picked a random 
 old version). So it's still usable, you just have to know what 
 version of the compiler to use. I'd say it would be nice to 
 record which version it builds with in some way on 
 code.dlang.org.


I think the first post is an overreaction, but now I'd like to 
know what is the correct line of thinking in the community:

It's normal that it's not working newer versions?

I'm not being sarcastic, because if breakage is for a good reason 
or in pursuit of a better language I wouldn't mind so much.

But I'd to know if breakage is considerate "normal" or 
"shouldn't" happen in any way, like for example in Linux user 
space (Even it's not 100%) or C++ world.

I'm telling this because I'm stuck with an older DMD version: 
2.062, because the newer versions doesn't compiles my project.

S.



 Sep 05 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via Digitalmars-d 
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.

 I built it successfully with DMD 2.076 (I just picked a random
 old version). So it's still usable, you just have to know what
 version of the compiler to use. I'd say it would be nice to
 record which version it builds with in some way on
 code.dlang.org.


 I think the first post is an overreaction, but now I'd like to
 know what is the correct line of thinking in the community:

 It's normal that it's not working newer versions?

 I'm not being sarcastic, because if breakage is for a good reason
 or in pursuit of a better language I wouldn't mind so much.

 But I'd to know if breakage is considerate "normal" or
 "shouldn't" happen in any way, like for example in Linux user
 space (Even it's not 100%) or C++ world.

 I'm telling this because I'm stuck with an older DMD version:
 2.062, because the newer versions doesn't compiles my project.

 S.


Really, the expectation is that you're going to use a version of dmd/ldc/gdc
that is at least close to current. It may make sense to stick to a
particular compiler version for a while, but the longer you go without
updating, the more likely it is that your code will break. 2.062 is
positively ancient at this point, and depending on what your code does, it
could be rather interesting to update it. I'd suggest that you try to move
up through the compiler versions a few at a time rather than jumping
straight to the latest, since that way, if you're using any symbols or
features that were removed, you'll benefit from deprecation messages along
the way, and in general, the changes required to keep code working when
jumping only a few compiler releases are minimal (though it obviously
depends on the code).

We do generally want to keep code compiling long term if possible, but if a
change is required to improve the language or standard library, then we'll
often make it. Such changes are done via the deprecation process so that
they don't immediately break code, but the deprecation process for Phobos is
generally about two years (it's less consistent with dmd, though if
anything, it's generally longer rather than shorter). So, if you go that
long without making sure that you're code compiles with the current
compiler, then you could easily have code breakage. You may very well not
end up being affected by any deprecations for years, depending on what
you're doing, but the longer you go without moving to a newer compiler, the
more likely you are to have problems. And while we try not to break code
without going through the deprecation process, regressions do sometimes get
in, and sometimes, fixing a bug means breaking existing code (especially if
code depends on the buggy behavior for one reason or another). The kind of
changes that we generally avoid are those where we can't provide a gradual
transition (e.g. we'd love to get rid of auto-decoding, but no one has yet
come up with a way to do it that wouldn't immediately break tons of code, so
we haven't gotten rid of it).

If you're expecting to be able to write D code, not touch it for years, and
then have it continue to work with the newest compiler, then you're going to
be very disappointed. However, if you at least make sure that your code
works with the current compiler every few releases, then it usually
shouldn't take much effort to keep it working. Over time, we've gotten
pickier about what we're willing to break (e.g. we won't usually change
symbols names just because the current name isn't as good as we'd like,
whereas 5+ years ago, we were a lot more willing to change names in order to
improve Phobos), and most stuff does stay the same, but don't expect that
everything is set in stone. Changes should usually be gradual enough to
avoid immediately breaking code, but they do happen. So, if you want your D
code to continue to work over time, I would encourage you to make sure that
it works with the current compiler at least yearly.

- Jonathan M Davis



 Sep 05 2018



  parent reply SashaGreat <s great.com>  writes:


On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis 
wrote:

 On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via 
 Digitalmars-d wrote:
 ...


Thanks for replying and I think I'm ok with this line of thought.

And another thing it's not just my own code, but the 
third-parties libraries where some were unmaintained which I 
think it was because the breakage with new compilers.

I think I'll try a gradual update and see how it goes.

S.



 Sep 05 2018



 next sibling parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Wednesday, September 5, 2018 9:05:29 AM MDT SashaGreat via Digitalmars-d 
wrote:

 On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis

 wrote:

 On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via
 Digitalmars-d wrote:
 ...


 Thanks for replying and I think I'm ok with this line of thought.

 And another thing it's not just my own code, but the
 third-parties libraries where some were unmaintained which I
 think it was because the breakage with new compilers.

 I think I'll try a gradual update and see how it goes.


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.

- Jonathan M Davis



 Sep 05 2018



prev sibling  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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).


T

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



 Sep 05 2018



 next sibling parent  SashaGreat <s great.com>  writes:


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.



 Sep 05 2018



prev sibling  parent  Arun Chandrasekaran <aruncxy gmail.com>  writes:


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



 Sep 05 2018



prev sibling  parent reply Dennis <dkorpel gmail.com>  writes:


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.

We're not even only talking about small unmaintained projects 
here: at the time I tried it, Gtk-D was broken.[1] Out of 

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.

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.

[1] https://forum.gtkd.org/groups/GtkD/thread/589/



 Sep 05 2018



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


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 

 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



 Sep 05 2018



prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


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.

- Jonathan M Davis



 Sep 05 2018



 next sibling parent  Dennis <dkorpel gmail.com>  writes:


On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis 
wrote:

 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.


It's okay for a library to become outdated, as long as new 
libraries emerge. When a user finds 5 dub packages that provide a 
solution, and they try the first 3 and they all fail, he might 
get the impression it's all broken. If it was shown that only the 
last two build on the newest compiler, they could immediately 
pick that.

If it is a niche package and there's only one option which 
doesn't build, then it's still a problem yeah. But it would still 
be an improvement if maintained libraries wouldn't have to 
compete with broken abandoned ones in the search results.



 Sep 05 2018



prev sibling  parent  Patrick Schluter <Patrick.Schluter bbox.fr>  writes:


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).



 Sep 05 2018



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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

-- 
It said to install Windows 2000 or better, so I installed Linux instead.



 Sep 05 2018



  parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


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.



 Sep 05 2018



  parent  Jon Degenhardt <jond noreply.com>  writes:


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



 Sep 05 2018



prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Friday, September 7, 2018 10:35:29 AM MDT H. S. Teoh via Digitalmars-d 
wrote:

 On Fri, Sep 07, 2018 at 09:24:13AM -0600, Jonathan M Davis via
 Digitalmars-d wrote: [...]

 What's somewhat more of an open question is how new compiler releases
 should be handled. Aside from the issue that _every_ package then
 potentially needs to be tested (which could take a while), there's the
 issue of which versions to test. Testing every release of a package
 would be overkill, but simply testing the latest isn't necessarily
 enough.


 The initial setup will take a long time because we have so many packages
 that have never been tested in this way before.  But once the database
 is up-to-date, I expect that it will take much less work to keep things
 up-to-date.

 For the initial setup, I don't think it's necessary to test *every*
 historial release of the compiler -- the most important thing is the
 current official releases of all compilers (gdc, ldc, dmd).[*]  If a
 package doesn't compile with the latest release, then optionally do a
 unidirectional search backwards to find the last compiler version that
 compiles it successfully, and log that.


I pretty much assumed that we'd just start with the most recent compiler
release, and then we'd only have to run anything for a given package when it
did a new release or when a new version of the compiler was released. My
point about versions was about which versions of a package to test. We don't
necessarily want to just test the latest package version, but we also don't
want to be testing every version of a package when a new compiler version
comes out. I think that at some point here, some thought will have to go
into what makes the most sense in that regard.


 ([*] I was going to suggest including dmd-nightly as well, but that
 poses the problem of load: running it every night will cause a lot of CI
 churn, which also generates a lot of mostly-useless information -- no
 one will care about which of 50 dmd git revisions failed / succeeded to
 compile a package, just whether the *latest* dmd-nightly works.  So
 perhaps an update once a week or once a month in between releases will
 be enough.  But dmd-nightly is an optional extra that can be skipped for
 now.  The important baseline is the current official releases of gdc /
 ldc / dmd.)


My gut reaction is that we shouldn't include anything but actual dmd
releases. As a developer of Phobos, I do often use the development version,
but in general, I don't think that that's something that we should be
encouraging the average user to do.


 Also, there's the question of what it even means to test each package
 to verify that it's working. Does that mean running the unit tests?
 Not all projects run them the same way, and it could be pretty
 expensive to run the tests for all packages on code.dlang.org. And of
 course, that assumes that the package even has any unit tests to begin
 with. So, should testing the package just mean that dub build works?
 That will catch the really basic problems, but it won't usually catch
 problems in templates and could easily miss other types of problems -
 though maybe it's enough. Regardless, it's going to need to be made
 clear what it means that code.dlang.org claims that a package works
 with a particular version of the compiler.


 [...]

 Let's not overcomplicate things and doom the flight before it takes off.
 Let's start with the absolute minimum baseline, and then additional
 perks can be added on top of that once the baseline is working.

 I say the baseline is that dub build works.

 If we feel like going an extra mile, dub test.

 If we feel like doing even more, then add other stuff like compiling
 provided example programs, testing template instantiations and what-not.
 (Though one would expect that dub test ought to do that already,
 otherwise I question the quality of the code / unittests.)

 As long as we publish exactly what is being run to verify whether the
 package "works", I think that should be good enough for starters.  Even
 if dub build, say, doesn't catch all problems, it's still better than
 the status quo of no information at all.  Let's not let the perfect
 become the enemy of the good, as is the common malady around here.


Honestly, I wouldn't rely on anything beyond dub build working in a
consistent manner across projects. As far as I can tell, you can't actually
do anything properly custom with dub test, and I'm inclined to think that
how it approaches things is outright wrong. With dxml, I was forced to
abandon dub test completely, because it broke anything that depended on
dxml. As far as I can tell, what happens is that dub pulls in the
dependencies and builds them all with dub build (so without stuff like
-unittest), but then when you use dub test on your project, it stupidly uses
all of the configuration options that the dub test configuration uses in the
dependencies, meaning that anything that didn't get built with dub build
wasn't there, and you got linker errors. I initially tried to fix it by
versioning all unittest blocks and all unit test helpers with a version
identifier specific to dxml's dub test build, but dub stupidly declared that
version identifier when any project depending on dxml ran dub test, so you
_still_ got linker errors. My conclusion was that the only sane thing to do
was to completely abandon dub test and define a separate build type for
running dxml's unit tests so that the version identifier could actually only
be declared when building dxml's unit test build. The result is that dub
test always passes but does absolutely nothing, which is really annoying,
but I don't trust how dub test behaves farther than I can throw it, and it's
currently my intention to never use it on any library I release ever. The
whole thing really pisses me off.

So, anyway, I think that it's pretty clear that you can't rely on anything
other than dub build working for a project, because that has to work for it
function as a dub package, whereas none of the rest does.

Regardless, aside from pointing out that dub test is not a command that you
can rely on working for dub packages in general, my point was really that we
need to be sure of what we're trying to test here, and when we present it on
code.dlang.org, it needs to be clear what it's indicating. If we were to
decide that we wanted it to indicate some level of actual functionality,
then we'd pretty much have to figure out how to run unit tests or to
indicate the lack of unit testing, which creates a whole host of problems.
On the other hand, if we just want to do dub build, we need to be clear that
when code.dlang.org indicates that a project "passes," all that means is
that dub build succeeds and that it doesn't actually say anything about how
well the package works. Ideally, we want to present useful information that
isn't misleading.

- Jonathan M Davis



 Sep 07 2018



 next sibling parent reply 0xEAB <desisma heidel.beer>  writes:


On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis 
wrote:

 Honestly, I wouldn't rely on anything beyond dub build working 
 in a consistent manner across projects. As far as I can tell, 
 you can't actually do anything properly custom with dub test, 
 and I'm inclined to think that how it approaches things is 
 outright wrong.



Talking about `dub build`, is there a way to make it build 
dependencies but not link?


   "targetType": "staticLibrary"    <-- doesn't build any 
dependencies


   "dflags": ["-c"],
   "targetType": "executable"       <-- -c will get stripped off 
by DUB


On the other hand:
How big is the chance that building with the `syntaxOnly` option 
succeeds on a package that wouldn't actually build?


What's the reason for this questions?
Well, there's the evil `sourceLibrary` build type, that makes it 
impossible to build a package itself, no matter what.


Kind regards,
Elias



 Sep 07 2018



  parent  0xEAB <desisma heidel.beer>  writes:


On Friday, 7 September 2018 at 20:06:47 UTC, 0xEAB wrote:

 What's the reason for this questions?
 Well, there's the evil `sourceLibrary` build type, that makes 
 it impossible to build a package itself, no matter what.


 Kind regards,
 Elias



Okay, sorry, I think my last message will cause some confusion.

(1) Problem no.1 is that one cannot build a package with 
targetType `sourceLibrary`.
(2) No.2 in order to circumvent that, one could just use this 
package as dependency in some dummy pacakge.
(3) Only targetType `executable` will make DUB build the 
dependencies of a package
(4) At the same time, DUB will always try to link the objects 
then, not passing through `-c` when specified as d-flag. Means, 
the "build" (the build itself works fine, of course) of all 
packages depending on non-available libs will fail (because DUB 
will exit with some linker error).


Kind regards,
Elias



 Sep 07 2018



prev sibling  parent reply Nicholas Wilson <iamthewilsonator hotmail.com>  writes:


On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis 
wrote:

 Honestly, I wouldn't rely on anything beyond dub build working 
 in a consistent manner across projects. As far as I can tell, 
 you can't actually do anything properly custom with dub test, 
 and I'm inclined to think that how it approaches things is 
 outright wrong.


For Dcompute I define a unittest configuration that has a main 
that runs tests, and the (default) library configuration excludes 
source files in the test directory. It seems to work fine. 
Admittedly it is a little different to you usual package, and 
there are no test specific symbols and no unit tests, and I 
haven't tested anything that has dcompute as a dependancy.

Are you suggesting this will break users of Dcompute that run dub 
test in their code? If so that truly does suck, because regular 
unittests will not cut the mustard.



 Sep 08 2018



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Saturday, September 8, 2018 7:44:09 AM MDT Nicholas Wilson via 
Digitalmars-d wrote:

 On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis

 wrote:

 Honestly, I wouldn't rely on anything beyond dub build working
 in a consistent manner across projects. As far as I can tell,
 you can't actually do anything properly custom with dub test,
 and I'm inclined to think that how it approaches things is
 outright wrong.


 For Dcompute I define a unittest configuration that has a main
 that runs tests, and the (default) library configuration excludes
 source files in the test directory. It seems to work fine.
 Admittedly it is a little different to you usual package, and
 there are no test specific symbols and no unit tests, and I
 haven't tested anything that has dcompute as a dependancy.

 Are you suggesting this will break users of Dcompute that run dub
 test in their code? If so that truly does suck, because regular
 unittests will not cut the mustard.


Okay. It's been several months since I dug into this, so hopefully I have
the details straight.

Unless no one using dcompute uses dub test on their own projects, you
probably don't have the worst part of this problem, because if you did,
they'd be complaining about linker errors.

Honestly, unittest blocks in general are somewhat broken, but what really
doesn't work correctly is code that's versioned for unit tests. e.g. if
you've declared some types or functions to use specifically in your unit
tests and which have no business being in the actual library (e.g. dxml has
dxml/internal.d which includes stuff specifically to help the unit tests and
is not part of the public API). The core problem is caused by the language,
but the way dub handles things negates the workarounds for the problem.

When you import a module that includes unittest blocks, and you're compiling
your module with -unittest, the version identifier unittest is defined when
importing the module, meaning that all unittest blocks are processed, and
everything inside a version(unittest) block is considered to be part of the
module. With regards to the unittest blocks themselves, this is nothing but
negative. It means that they have to compile regardless of whether
everything they use is available to the module importing them, and it's a
pointless waste of compiler resources. This is even worse when a unittest
block is inside a template, because than anyone using that template then
also gets the unittest blocks compiled into their code (once for each
instantation of the template), meaning that the unittest blocks in the
libraries you use can actually be compiled into your program and get run
when you run your own unit tests. IMHO, when importing a module, unittest
blocks should be treated as version(none) rather than version(unittest), but
that's not currently the case.

The less straightforward problem is the helpers that are compiled with
version(unittest). We can't treat everything that's version(unittest) as
version(none) when importing, because that would make it impossible to share
unit test helpers between modules. The cleanest way to deal with those is
therefore to put them in a separate module that gets imported locally by the
unittest blocks. That way, you don't accidentally mark anything in the
module with the unittest blocks as version(unittest), and it allows you to
hide the symbols from any modules that import your module. However, because
the unittest blocks themselves are still processed when importing, it
doesn't actually work to hide the symbols being imported like it should. The
compiler still processes them when it imports the module. This causes
problems when the modules being imported weren't actually compiled into the
library that you're linking against (since normally, libraries aren't
compiled with -unittest) - hence the linker errors. If you use unit test
helpers that are version(unittest) in a library, you risk linker errors in
any project that imports that library. Not marking them with
version(unittest) can fix that problem, but it then pollutes projects using
the library.

While it's certainly ugly, the easiest way to solve the problem at present
is to version all of your unittest blocks with a version identifier specific
to your project. That way, any projects depending on your library won't
actually end up compiling the unittest blocks, because while the unittest
version identifier will have been declared, the version identifier specific
to your project will not have been. There was actually a PR for Phobos a few
months back that tried to do this to all of Phobos to fix this problem with
Phobos, but it was rejected on the grounds that it was hideous and that we
should solve it in the language - which I agree with, but in the interim, we
still have to deal with the problem - hence why dxml has the dxmlTests
version identifier. Without it, any projects using dxml would get linker
errors when running their own tests.

Where dub makes this whole situation worse is that for some reason, the
build configuration for your library that's used when you run dub test is
also used by anything that pulls in your library via dub. I had made it so
that dub test declared dxmlTests so that dub test would work properly for
dxml but with the idea that then any projects depending on dxml would not
declare dxmlTests. However, because dub pulls in the dependencies' unit test
configurations instead of just using the non-unit test one like it should,
that results in any projects that depend on dxml having dxmlTests declared,
so the problem isn't fixed, and all of those annoying version(dxmlTests)
blocks were a waste of time.

To workaround this stupidity of dub, I was forced to create a separate set
of buildTypes for running the unit tests in debug, release, or with code
coverage. Those buildTypes must be used, or there are no unit tests, meaning
that dub test goes really fast and does nothing useful whatsoever. And
because of this whole issue, I avoid dub test like the plague.

So, dub needs to fix what it's doing (I can't remember what I reported at
the time - I really should make sure that I have all of the facts straight
and clearly explained in a bug report for dub), and once it is fixed, then
dub test can be used again by projects that need to do custom stuff with
their unit test configurations. But that still leaves the compiler problem,
and a DIP needs to written to fix that. IIRC, Jonathan Marler was trying to
fix it several months ago, but I think that he was mucking around with
version(unittest) in general, and he ran into all kinds of weird problems.
So, I don't know what it would really take to fix the problem in the
compiler, but I think that it's pretty clear that unittest blocks should be
utterly ignored when the module they're in is imported, and right now,
they're not.

- Jonathan M Davis



 Sep 08 2018



prev sibling next sibling parent reply Everlast <Everlast For.Ever>  writes:


Seems there are a few good suggestions.

Here is another:

Have dub have the ability to submit patches when a previously 
broken package compiles.

For example, I fixed a few bugs in the demo pretty quick... dub 
should automatically push those changes to the right place so 
they can be used by everyone else(with rollback of course).

Dub simply determines if a package is broken by trying to compile 
it. When the package then compiles from being fixed by the user, 
dub can recognize that and push the changes automatically(by 
keeping track of the broken parts of the code and the changes).

This then allows fixes to accumulate by single users rather than 
everyone having to fix things themselves and requiring them to 
put in the effort to push the changes themselves.

99% of all these problems can be eliminated with a PROPERLY 
designed system. I would think that it would be the first thing 
on the table to do since without a properly designed system 
things just head towards chaos like they have. The sooner the 
PROPERLY designed system is created the sooner we all can benefit 
from such a PROPERLY designed system.

Look how much wasted time and energy this single thread has 
created just because of the improperly designed system. The 
problem is people need to get out of the dark ages and stop 
thinking like programmers from the 70's.  There are better away 
to do things, it just takes people wanting to do them and willing 
to spend the time to figure out the proper way. By making a 
design that reduces the burden on the user, the user will be more 
willing to contribute and will be able to contribute more and 
everyone will benefit.



 Sep 07 2018



  parent reply Neia Neutuladh <neia ikeran.org>  writes:


On Saturday, 8 September 2018 at 00:04:08 UTC, Everlast wrote:

 Seems there are a few good suggestions.

 Here is another:

 Have dub have the ability to submit patches when a previously 
 broken package compiles.


So I identify a package that doesn't compile anymore and submit a 
patch that adds a bitcoin miner and sets fire to your cat?

If dub packages were scoped to a user, then you could fork a dub 
package more easily. Then the dub registry page for that package 
could contain both the information "this package doesn't compile 
with DMD > 2.65.0" and "this package has a more up-to-date fork 
that compiles with DMD > 2.068.0".

That means I can't hijack your project, which is good, but 
updating broken dependencies takes manual intervention, which is 
bad.



 Sep 07 2018



  parent reply Everlast <Everlast For.Ever>  writes:


On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh 
wrote:

 On Saturday, 8 September 2018 at 00:04:08 UTC, Everlast wrote:

 Seems there are a few good suggestions.

 Here is another:

 Have dub have the ability to submit patches when a previously 
 broken package compiles.


 So I identify a package that doesn't compile anymore and submit 
 a patch that adds a bitcoin miner and sets fire to your cat?


There are ways around this:

1. If the code is just a few lines and does not escape then it is 
marked safe and is safe.

This probably gets at least 50% of all patches because it is from 
a bug that is a few lines of code.

2. Require users to log in to be able to submit changes. Users 
must wait a week after registering to sub changes and can only 
submit so many changes per day.
They can submit more but they are flagged.

3. Commits to the end user side can be reviewed.

4. A forum thread is generated for each project with sub threads 
for each commit. These can be "rated" for how well they fix the 
problem by others and people can discuss them, sort of like 
bugzilla but better(more forum like).


5. large changes are automatically committed but are not 
automatically used. They must be marked as valid by the 
maintainer of the project or the community.


Basically your argument is that we should throw the baby out with 
the bath water because MAYBE the baby will grow up to be Hitler. 
Your logic is the same as cops who say "I should kill this guy 
now because MAYBE he has a gun" or any other insane thing that is 
a "MAYBE" but actually very unlikely.


Instead of assuming the most unlikely case, which is insane, it 
is better to assume the most likely case and then add in the 
necessary checks to deal with the unlikely cases.


Because, you know, I could download a dub package right now that 
does exactly what you just said, so it is really irrelevant. The 
only thing having dub automatically handle it all for you would 
do is give someone a little more incentive to try and make it 
happen that way. But seriously, do you think this would be a 
common attack vector for psychopaths?

When you make it 99.9999% likely they will be ineffective then 
who cares what they do. If it does happen, the chances are it 
will fail for various reasons. It it is probably 1 in a billion 
shot that they will create a patch that will be effective for 
what they want(to get your bank account, or whatever).

It's much more likely that other routes would be more effective 
and since psychopaths are only worried about being successful 
they are not going to waste their time with an attack vector that 
is almost surely not going to succeed.

Basically those that are in such a secure environment are also 
not going to make it easy(e.g., they will use a VM alternate OS, 
sandbox, etc).

Those that don't really care don't have much to lose so it 
wouldn't matter if the attacker was successful.

6. Users can define levels for automatically including code - 0 
for automatic, all cases
1 - When patches do not escape
2 - When patches do not escape and are less than x KB or y lines.
3 - When forum rating > 10 people and 90%
...
X - Review all changes
Y - Ignore all
etc...

This way paranoid users can opt out. If, say, psychopaths do 
start using D to spread their insanity, then people can just 
switch to a more secure level and it will squash the problem 
quickly making it less an incentive for the attackers.


So, you see, there are plenty of solutions that can solve your 
hypothetical reason for squashing something that would be very 
practical.

There is absolutely no reason to throw the baby out... none! 
Don't allow it to turn in to a Hitler, it's not the babies fault, 
it's yours for what you teach it.

Meaning, there is no reason to not have dub automate everything 
as much as possible for hypothetical security concerns... Teach 
dub how to deal with them to a high enough degree that anyone 
attempting such things will be shut down quickly. It's not 100% 
but nothing is. After all, we are not even talking about 
something that hackers have ever used as an attack vector 
before... it's not even in the realm of what they are after(it's 
not just system control because most systems are useless).



 If dub packages were scoped to a user, then you could fork a 
 dub package more easily. Then the dub registry page for that 
 package could contain both the information "this package 
 doesn't compile with DMD > 2.65.0" and "this package has a more 
 up-to-date fork that compiles with DMD > 2.068.0".

 That means I can't hijack your project, which is good, but 
 updating broken dependencies takes manual intervention, which 
 is bad.


Yes, but if one just makes it a bit more intelligent one can 
solve the problem PROPERLY!

I'm not saying my solutions are what should be done because I'm 
just throwing out rough ideas. What I'm saying is that THERE IS A 
PROPER SOLUTION!

It would take people communicating in an organized and structured 
way to come up with that proper solution.

This means a group of people deciding that it should be done and 
that they will work together to solve the problem by coming up 
with the correct solution then coding that solution. It would 
take months, not days and it would involve a lot of people 
working together which requires organization to be effective. It 
can't be done on a forum like this.



 Sep 07 2018



 next sibling parent  Neia Neutuladh <neia ikeran.org>  writes:


On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:

 There are ways around this:


Take a step back and consider what you're asking for.

You are asking for dub to become github. A very cruddy version of 
github. One in which everyone can submit changes to every 
repository. With a forum and a voting mechanism where anyone can 
vote. Where each person applies a complex set of rules to 
determine whether a given change should be applied to their local 
copy.

You expect this to improve reliability, when you're making it 
less likely that anyone else has seen the codebase that any 
particular person is using.

The security fixes you've suggested are defeated just by 
registering a few extra accounts, and the "does not escape" thing 
uses a term that I'm moderately sure you came up with.

You don't seem to understand the difference between trusting a 
specific person in charge of a repository, and trusting everyone 
in the world (or at least everyone who can make a dozen fake 
accounts and upvote their own patches).

You also haven't considered social options for dealing with the 
problem. See https://github.com/dlang-community/discussions for 
the organization we have that deals with this problem already.



 Sep 07 2018



prev sibling  parent  Joakim <dlang joakim.fea.st>  writes:


On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:

 On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh 
 wrote:

 [...]


 There are ways around this:

 [...]


Is there any other language that does any of this? I don't think 
any language does all of it, so do you plan to wait a couple 
decades for any language to do it before you start programming?

Some of these are worthwile suggestions, but nobody's doing them 
yet. I suggest you start implementing them somewhere- maybe here, 
dub is an OSS project: https://github.com/dlang/dub - rather than 
lecturing others about how it's all so obvious. That way, you can 
actually get some work done before the cows come home. ;)



 Sep 08 2018



prev sibling  parent  Nerve <nervecenter7 gmail.com>  writes:


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*



 Sep 09 2018