www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D's Continous Changing

reply harakim <harakim gmail.com> writes:
Every time I come back to a D program I wrote over a year ago, it 
seems like there are numerous breaking changes and it takes me a 
while to get it to compile again. And the documentation is 
difficult to figure out. I wish I could remember every time I've 
had to change this line of code, but I know most times I have 
come back to this project over the last 14 years, I have had to 
change it.

This is more or less what I had the last time:
auto sekunden = to!("seconds", long)(dauer);
		
return cast(long)floor(sekunden * 18);

The compiler complained about double. I found a post in dlang 
from 2019 saying the library doesn't allow double conversion. It 
sure doesn't! However, it used to.


I downloaded bindbc and got an error building with dmd version 
2.087. The error was 'atomicFence is not a template declaration'. 
Mike suggested I upgrade to 2.095 and lo and behold, that 
compilation issue went away.

Now, I hate Java as much as the next guy (maybe more than most 
next guys), but the things that led to me being a Java Developer 
today are:
1. The Java Trails tutorials and JDK documentation
2. Backwards compatibility and easy-to-understand versioning
3. Lack of self-respect and willingness to stand up for what's 
right


are. I always feel like I want to be an evangelist for D, but 
then I come back and things have changed and by the time I figure 
out what's going on and do something cool, I need to take a 
break. That is because I run into compilation errors with a few 
minor version updates, I spend a lot of time retooling and fixing 
my project to work on a new version of the compiler (or, I 
assume, standard library) and libraries. I don't have that 
problem in other languages.

If I write code in Java (barring a few major changes like the 
generics update), it will continue to work just fine in newer 
versions of Java. I can dig out the Java version of the program 
which I wrote - just before the D program I am referring to - in 
2006/2007 and it still compiles and runs horribly just like the 
day I wrote it.

When Java 6 came out, I bought a book called Java 6 SE 
Development. I read it and since I knew Java 5 now I knew what 
was in Java 6.

As to the Java Trails and JDK documentation, I could figure out 
how to do anything in the standard library that I needed to. I 
didn't have to look anywhere else. As a new developer I wrote an 
entire multi-threaded application that connected to a server 
written in C and made thousands of draws per frame at 8-10 frames 
per second, and I didn't have to use any resources outside of one 
book and the standard Java library documentation. That's pretty 
good.

Contrast to me trying to figure out how to format a number in 
binary. format!"%b"(number) does not work but is very similar to 
what is suggested in the documentation. I was able to figure out 
it's format("%b", number) but it took a few minutes.

I also have to figure out how to determine how many 18ths of a 
second have elapsed since the application started up. Don't ask 
me why 18ths, that is just the number that the server uses. Does 
total give me the total number of nanoseconds or the number of 
nanoseconds after the large time units are factored out? The 
documentation appears to say one thing but the tests appear to 
show the opposite. I just have to write a test program to figure 
it out.

I've been using D for close to half my life and I have no 
intention to stop using it, but it will never be my go-to tool 

to be the language and tooling that I reach for all the time. It 
has the potential to be that, but just the thought of having to 
upgrade to the new compiler, new standard library, new build 
tools and new library makes me hesitate every time. Even now, on 
this project, I am going to spend ~10 hours to work through these 
issues just to get back to where I was.

I think the first thing to do is lock down D to major version 
changes. Any DMD 2 program should continue to compile with any 
future 2.x version of DMD. If it is not longer backwards 
compatible, make that version 3. Then for each version upgrade, 
write some kind of upgrade guide. Crowd source it even as people 
experience issues.

Maybe it's just me, but if I had confidence that the versions 
would be around a little while and an example I write today would 
work for others in a year or two, I would be more willing to 
contribute examples, documentation and so forth. As it is, I will 
probably do that in some fashion, but very limited and possibly 
not in as community-wide of a venture.

PS I have a copy of The D Programming Language I refer to when I 
start programming but it's in a storage unit. That is at least as 
good as the Java Trails, although I'm not sure the examples would 
even compile today.
Mar 03 2021
next sibling parent reply harakim <harakim gmail.com> writes:
For the record, I was able to resolve all of my issues in about 7 
hours. That included upgrading from DerelictSDL to bindbc and 
converting to use dub instead of make.

I hope my above post does not lead people to believe that I don't 
like D, because I otherwise wouldn't have lost track of time 
until midnight working on this project!

I also should mention that this project was probably last touched 
in 2017. I thought I pulled it out a year ago, but that was a 
different project.
Mar 03 2021
next sibling parent matheus <matheus mail.com> writes:
On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:

 ...


Yes it's a problem indeed. I had the same problem and that's 
worse when you don't upgrade very often.


do you think that upgrading was smoothly with all the tools that 
Microsoft provides?

No it wasn't, and it gets worse with third party components.

So this guy was hired just for that, port a very old code to the 
new framework, and after a month he did, yes it compiled 
alright... but the software didn't work as expected is some 
cases, some controls wasn't acting right and was very unreliable.

Guess what? They are still developing with old framework until 
everything works correctly on the new framework.

Matheus.
Mar 03 2021
prev sibling parent reply user1234 <user1234 12.de> writes:
On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:

 For the record, I was able to resolve all of my issues in about 
 7 hours. That included upgrading from DerelictSDL to bindbc and 
 converting to use dub instead of make.

 I hope my above post does not lead people to believe that I 
 don't like D, because I otherwise wouldn't have lost track of 
 time until midnight working on this project!

 I also should mention that this project was probably last 
 touched in 2017. I thought I pulled it out a year ago, but that 
 was a different project.


otherwise another solution is to check every two monthes the 
sanity of your projects. E.g a montly cronjob on a CI service and 
that uses latest DMD Docker image. If it fails you got an 
email... It certainly cooler to take 5 mins every two monthes 
than 7 hours 4 years.
Mar 03 2021
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 04, 2021 at 06:43:57AM +0000, user1234 via Digitalmars-d-learn
wrote:

 On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:

 For the record, I was able to resolve all of my issues in about 7
 hours.  That included upgrading from DerelictSDL to bindbc and
 converting to use dub instead of make.




[...]

 I also should mention that this project was probably last touched in
 2017. I thought I pulled it out a year ago, but that was a different
 project.


 
 otherwise another solution is to check every two monthes the sanity of
 your projects. E.g a montly cronjob on a CI service and that uses
 latest DMD Docker image. If it fails you got an email... It certainly
 cooler to take 5 mins every two monthes than 7 hours 4 years.


Y'know what'd be cool: if people could add their D projects to some kind
of master CI (don't know if the existing dmd/druntime/phobos CI config
allows this) so that whenever a change in the language causes breakage,
the relevant PR will get flagged for review.  I wouldn't say block the
PR altogether -- we don't want some obscure no-longer-maintained project
to hold back everyone else -- but at least flag it as a breaking change
so that the owner can be contacted to see if something could be worked
out.

I know we already do this for some key projects, but a large-scale
CI test would be nice, if we had the resources for it.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he
said, "A double negative forms a positive. In some languages, though, such as
Russian, a double negative is still a negative. However, there is no language
wherein a double positive can form a negative." A voice from the back of the
room piped up, "Yeah, yeah."
Mar 03 2021
prev sibling parent reply Siemargl <inqnone gmail.com> writes:
On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote:

 otherwise another solution is to check every two monthes the 
 sanity of your projects. E.g a montly cronjob on a CI service 
 and that uses latest DMD Docker image. If it fails you got an 
 email... It certainly cooler to take 5 mins every two monthes 
 than 7 hours 4 years.


Nice idea. Try do it with all hundreds of used in your projects 
libraries.
Mar 04 2021
parent user1234 <user1234 12.de> writes:
On Thursday, 4 March 2021 at 09:21:12 UTC, Siemargl wrote:

 On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote:

 otherwise another solution is to check every two monthes the 
 sanity of your projects. E.g a montly cronjob on a CI service 
 and that uses latest DMD Docker image. If it fails you got an 
 email... It certainly cooler to take 5 mins every two monthes 
 than 7 hours 4 years.


 Nice idea. Try do it with all hundreds of used in your projects 
 libraries.


isObject, isArray, etc ;) ?
Mar 04 2021
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:

 Every time I come back to a D program I wrote over a year ago, 
 it seems like there are numerous breaking changes and it takes 
 me a while to get it to compile again.


I am porting a large code base from Extended Pascal to D and I 
know that there will be changes in the language in the future 
that will take an effort to adapt to. Yet, I am still in the camp 
of wanting these changes to happen because we don't want to port 
from a dead language to another dead language, we need the 
language to be alive.

The way I deal with this is to lock down version numbers with the 
revision number of our code base. By having dub.selections.json 
under revision control we make sure that the same version of 
dependencies are used every time until we upgrade, and by having 
this in dub.json:

```
	"toolchainRequirements": {
		"frontend": "==2.096"
	},
```

we ensure that the code simply refuses to compile with any other 
language version.

So, if two years from now we were to check out a revision that 
was two years old, yes we would have to downgrade the compiler 
but it would still work. Upgrading to a newer language version or 
dependency version can be done outside of the main development 
branch, where it can be properly tested before merging.

Ideally I want the build system to automatically install and/or 
activate the compiler specified in the code base so that a 
toolchain upgrade becomes just like a regular feature commit, 
possibly using one of the existing compiler version managers [1, 
2] or by extending dub itself. Then, fellow developers will 
hardly notice compiler upgrades, the build farm doesn't need 
attention, and bisecting revisions to pin down the occurrence of 
a regression can be done without complications.

I think it is important that warts in the language and standard 
library are removed, and luckily we have a proper deprecation 
mechanism. My advice is, if you pick up a two-year old project 
and don't want to deal with breakages, you just continue with the 
versions from that time; Until you choose to use newer features, 
but you can plan for the work that this requires.

-- Bastiaan.

[1] https://dlang.org/install.html
[2] https://code.dlang.org/packages/dvm
Mar 04 2021
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:

 Contrast to me trying to figure out how to format a number in 
 binary. format!"%b"(number) does not work but is very similar 
 to what is suggested in the documentation. I was able to figure 
 out it's format("%b", number) but it took a few minutes.


This works for me:
  rdmd --eval="writeln(format!`%b`(5));"
  101
  rdmd --eval="writeln(__VERSION__);"
  2096

-- Bastiaan.
Mar 04 2021
parent reply harakim <harakim gmail.com> writes:
 ```
 	"toolchainRequirements": {
 		"frontend": "==2.096"
 	},
 ```


Thanks! I didn't know you could specify a toolchain version. I 
agree it would be cool if it automatically downloaded the correct 
version of compiler, but this will be helpful. Is it possible to 
download old versions of the compiler somewhere?

On Thursday, 4 March 2021 at 10:22:51 UTC, Bastiaan Veelo wrote:

 On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:

 Contrast to me trying to figure out how to format a number in 
 binary. format!"%b"(number) does not work but is very similar 
 to what is suggested in the documentation. I was able to 
 figure out it's format("%b", number) but it took a few minutes.


 This works for me:
  rdmd --eval="writeln(format!`%b`(5));"
  101
  rdmd --eval="writeln(__VERSION__);"
  2096

 -- Bastiaan.


I want this almost every week at work. When I run into some 
trivial statement that I need to know for sure how it works, it's 
rarely worth it to create a whole new file and make a main method 
and all that. I just edit and run the entire program again, which 
is a waste of time.
So about ten seconds later:
PS> rdmd --eval="writeln(format!`%b`(5));"
~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error:
template argument expected following `!`
Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", 
"-d", "-v", "-o-", 
"~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d",
"-I~\\AppData\\Local\\Temp\\.rdmd"]

PS> rdmd --eval="writeln(__VERSION__);"
2095

That was pretty sweet. However, it kind of goes to the point of 
my post. A one-revision difference means the documentation is not 
accurate for my compiler.

I'm not saying the language shouldn't evolve, I'm just saying it 
might make sense to keep compatibility changes to every 6 months 
or a year. Then you could keep the old documentation around for 
the old version, and create new documentation for the new version 
and no matter which version someone is using they would have 
documentation (within limits.)

Depending on how long I can keep at this project, I would be down 
to host my source wherever it needs to be hosted (provided it's 
git) to get the new-version-check feature. I might even pay a bit 
for it. I doubt that makes it worth it, but I thought I'd throw 
that out there in case more people agree.

I like D. I like that D is changing. To go along with that, I 
would like a little more predictability with major version 
releases. I see there is a lot more documentation than the last 
time I checked so I'll take a deeper look at that.
Mar 04 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 correct version of compiler, but this will be helpful. Is it 
 possible to download old versions of the compiler somewhere?


 From this page you can follow a trail all the way back to 0.00 if 
you're so inclined:

https://dlang.org/changelog/index.html
Mar 04 2021
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 5 March 2021 at 03:35:31 UTC, Mike Parker wrote:

 On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 correct version of compiler, but this will be helpful. Is it 
 possible to download old versions of the compiler somewhere?


 From this page you can follow a trail all the way back to 0.00 
 if you're so inclined:

 https://dlang.org/changelog/index.html


Okay, maybe not. A number of the oldest versions aren't 
available. Anyway, there's also:

http://ftp.digitalmars.com/
Mar 04 2021
prev sibling next sibling parent reply Siemargl <inqnone gmail.com> writes:
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 I want this almost every week at work. When I run into some 
 trivial statement that I need to know for sure how it works, 
 it's rarely worth it to create a whole new file and make a main 
 method and all that. I just edit and run the entire program 
 again, which is a waste of time.
 So about ten seconds later:
 PS> rdmd --eval="writeln(format!`%b`(5));"
 ~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error:
template argument expected following `!`
 Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", 
 "-d", "-v", "-o-", 
 "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d",
"-I~\\AppData\\Local\\Temp\\.rdmd"]

 PS> rdmd --eval="writeln(__VERSION__);"
 2095

 That was pretty sweet. However, it kind of goes to the point of 
 my post. A one-revision difference means the documentation is 
 not accurate for my compiler.


This is problem with Powershell. (May by need to create bugreport 
?)

This example runs fine from CMD (but i recommend FAR for 
conveniety) and fails from PS.

Tested Win10.1909, dmd 2.095
Mar 04 2021
parent harakim <harakim Gmail.com> writes:
On Friday, 5 March 2021 at 07:51:24 UTC, Siemargl wrote:

 On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 I want this almost every week at work. When I run into some 
 trivial statement that I need to know for sure how it works, 
 it's rarely worth it to create a whole new file and make a 
 main method and all that. I just edit and run the entire 
 program again, which is a waste of time.
 So about ten seconds later:
 PS> rdmd --eval="writeln(format!`%b`(5));"
 ~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error:
template argument expected following `!`
 Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", 
 "-d", "-v", "-o-", 
 "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d",
"-I~\\AppData\\Local\\Temp\\.rdmd"]

 PS> rdmd --eval="writeln(__VERSION__);"
 2095

 That was pretty sweet. However, it kind of goes to the point 
 of my post. A one-revision difference means the documentation 
 is not accurate for my compiler.


 This is problem with Powershell. (May by need to create 
 bugreport ?)

 This example runs fine from CMD (but i recommend FAR for 
 conveniety) and fails from PS.

 Tested Win10.1909, dmd 2.095


The file never includes the quote marks for some reason, I've 
tried a few different ways although I haven't been able to figure 
out why yet. The documentation for powershell says it should 
work. This undocumented feature works though:

PS> rdmd --eval='writeln(format!`"%b`"(78));'
1001110

On Friday, 5 March 2021 at 03:35:31 UTC, Mike Parker wrote:

 On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 correct version of compiler, but this will be helpful. Is it 
 possible to download old versions of the compiler somewhere?


 From this page you can follow a trail all the way back to 0.00 
 if you're so inclined:

 https://dlang.org/changelog/index.html


Thanks, I bookmarked this.
Mar 05 2021
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote:

 That was pretty sweet. However, it kind of goes to the point of 
 my post. A one-revision difference means the documentation is 
 not accurate for my compiler.

 I'm not saying the language shouldn't evolve, I'm just saying 
 it might make sense to keep compatibility changes to every 6 
 months or a year. Then you could keep the old documentation 
 around for the old version, and create new documentation for 
 the new version and no matter which version someone is using 
 they would have documentation (within limits.)


The website is *supposed* to keep documentation for old versions 
around, and allow you to select them using the drop-down menu at 
the top-right:

https://i.imgur.com/ICu9Z7a.png

However, it looks like this feature is currently broken, since 
the archived documentation stops at version 2.081. I've filed an 
issue in the appropriate repository [1], so hopefully that will 
be fixed soon.

[1] https://github.com/dlang/docarchives.dlang.io/issues/1
Mar 05 2021
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 5 March 2021 at 15:54:37 UTC, Paul Backus wrote:

 The website is *supposed* to keep documentation for old 
 versions around, and allow you to select them using the 
 drop-down menu at the top-right:


note that in some cases my website lets you pull old versions too:

http://phobos.dpldocs.info/v2.068.0/

for example. But since I rarely use old versions it probably 
won't be in cache and thus you have to wait for the slow process 
of it downloading and generating the files.
Mar 05 2021