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.

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.

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.

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!

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.

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!

>

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.

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.

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

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