Re: D's Continous Changing
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.
Re: D's Continous Changing
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.
Re: D's Continous Changing
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
Re: D's Continous Changing
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
Re: D's Continous Changing
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/
Re: D's Continous Changing
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
Re: D's Continous Changing
```
"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.
Re: D's Continous Changing
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.
Re: D's Continous Changing
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
Re: D's Continous Changing
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 ;) ?
Re: D's Continous Changing
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.
Re: D's Continous Changing
On Thu, Mar 04, 2021 at 06:43:57AM +, 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."
Re: D's Continous Changing
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.
Re: D's Continous Changing
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. But let me tell something, where I work we have software in C#, 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.
Re: D's Continous Changing
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.
D's Continous Changing
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
#3 is not in the purview of a language developer, but #1 and #2
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
for things like web development with C# around. I'd love for it
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.
