www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows experience is atrocious

reply Rumbu <rumbu rumbu.ro> writes:
Long time D user here (from D1 era). I said to come back after 
two years to see how things evolved in the meantime.

Here is my Windows experience:

1. Downloaded DMD installer.
2. Cannot run, blocked by AppLocker, IOC blacklisted
3. Added to exception list
4. Cannot run, blocked by Windows SmartScreen
5. Bypass
6. You have DMD 2.090 installed, replace it? Yes
7. Failed, installer said run dmd-2.104.2.exe /f
8. Looking in cpanel to see if I an older version of D is 
installed. Nope.
9. Found an old folder with D. Deleted it.
10. Going to command prompt into downloads folder
11. Running dmd-2.104.2.exe /f
12. Error, an instance of DMD is already running.
13. Looking through my processes, there is no such thing
14. Running dmd-2.104.2.exe /f again. It works!
15. You don't have VS Tools 2019 installed. I have. 2015, 2017, 
2019 and 2022
16. Ignore and go on.
17. Launch VSCode
18. Install code-d, C++ already installed
19. Create a new project
20. Run tasks - Run -> dub cannot be initialized
21. Go to code.dlang.org
22. Click on Download -> redirect to github/releases
23. WTF, only source code.
24. building Dub from source
25. Added manually to PATH
26. Go back to VSCode
27. Edit dub.json, adding target ./bin/hello.exe
28. Build Task, dub-auto - Run hello, ok
29. Build Task, dub-auto - Build hello -> config -> edit 
tasks.json
30. Documentation says that I should have a dub template. Nope, I 
have a CMake template.
31. Too complicated. Close VSCode, posting on forum :)

----

OK, I know, there is VisualD, but install process is still 
complicated.
Jul 20 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:

 ...
 20. Run tasks - Run -> dub cannot be initialized
 21. Go to code.dlang.org


FWIW, dub.exe is part of the download. The rest sucks, agreed.
Jul 20 2023
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 [snip]


Windows user here, but I don't have that many issues. The biggest 
thing is remembering sometimes to check the path order sometimes.
Jul 20 2023
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:


You have the advantage of being a longtime Windows user. I've 
given up on Windows support for anything I share. It's just too 
difficult. The Linux experience is really, really easy, and it 
would be nice if the Windows experience was just as easy. This 
would be a good opportunity for the D Language Foundation to step 
in (and with a solid plan, raise some money).

Among other things, with a good Windows experience, I could write 
R packages in D and share them on Github. It's kind of useless to 
do that until setting up a Windows development environment is 
straightforward for someone that's not a professional software 
developer.
Jul 20 2023
parent harakim <harakim gmail.com> writes:
On Thursday, 20 July 2023 at 18:28:12 UTC, bachmeier wrote:

 On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:


 You have the advantage of being a longtime Windows user. I've 
 given up on Windows support for anything I share. It's just too 
 difficult. The Linux experience is really, really easy, and it 
 would be nice if the Windows experience was just as easy. This 
 would be a good opportunity for the D Language Foundation to 
 step in (and with a solid plan, raise some money).

 Among other things, with a good Windows experience, I could 
 write R packages in D and share them on Github. It's kind of 
 useless to do that until setting up a Windows development 
 environment is straightforward for someone that's not a 
 professional software developer.


It's interesting you both have problems. I have installed D on 
windows probably 10 times and never had an issue. If someone can 
repro, I would like to watch them repro so I can figure out 
what's going on. I would not mind coming up with a fix to make it 
simple.
Jul 20 2023
prev sibling next sibling parent reply harakim <harakim gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:

 1. Downloaded DMD installer.
 2. Cannot run, blocked by AppLocker, IOC blacklisted
 3. Added to exception list
 4. Cannot run, blocked by Windows SmartScreen
 5. Bypass
 6. You have DMD 2.090 installed, replace it? Yes
 7. Failed, installer said run dmd-2.104.2.exe /f
 8. Looking in cpanel to see if I an older version of D is 
 installed. Nope.
 9. Found an old folder with D. Deleted it.
 10. Going to command prompt into downloads folder
 11. Running dmd-2.104.2.exe /f
 12. Error, an instance of DMD is already running.
 13. Looking through my processes, there is no such thing
 14. Running dmd-2.104.2.exe /f again. It works!
 15. You don't have VS Tools 2019 installed. I have. 2015, 2017, 
 2019 and 2022
 16. Ignore and go on.
 17. Launch VSCode
 18. Install code-d, C++ already installed
 19. Create a new project
 20. Run tasks - Run -> dub cannot be initialized
 21. Go to code.dlang.org
 22. Click on Download -> redirect to github/releases
 23. WTF, only source code.
 24. building Dub from source
 25. Added manually to PATH
 26. Go back to VSCode
 27. Edit dub.json, adding target ./bin/hello.exe
 28. Build Task, dub-auto - Run hello, ok
 29. Build Task, dub-auto - Build hello -> config -> edit 
 tasks.json
 30. Documentation says that I should have a dub template. Nope, 
 I have a CMake template.
 31. Too complicated. Close VSCode, posting on forum :)

 ----

 OK, I know, there is VisualD, but install process is still 
 complicated.


I downloaded the latest version and Windows "protected" me from 
running the installer. So that much I was able to repro.

When I went to install, it asked me if I wanted to uninstall the 
old version, which I said I did, and then it uninstalled and 
installed perfectly. I tested that it compiled my project from 
one year ago and it worked like a charm. How do I know it didn't 
just fail to do anything, you might ask?

```
source\arsd\simpledisplay.d(6445,51): Deprecation: using `in ref` 
is deprecated, use `-preview=in` and `in` instead
...
source\arsd\http2.d(3567,17): Error: function `void 
arsd.http2.OpenSslSocket.close()` does not override any function, 
did you mean to override `nothrow  nogc scope  trusted void 
std.socket.Socket.close()`?
Error C:\Program Files\D\dmd2\windows\bin\dmd.exe failed with 
exit code 1.
```

Oh, D... *smile and sigh*
Jul 20 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 21 July 2023 at 02:54:16 UTC, harakim wrote:
I tested that it compiled my project

 from one year ago and it worked like a charm. How do I know it 
 didn't just fail to do anything, you might ask?


Those deprecations and random breaking changes in the stdlib 
annoyed me but they were easy fixes, if you do the quick edits 
yourself or grab the new files from my arsd repo they all work 
again (tho if you get the new files, make sure you grab the new 
arsd\core.d file too since i added that upstream, but other than 
adding the file there's no public api changes in my lib)
Jul 20 2023
parent harakim <harakim gmail.com> writes:
On Friday, 21 July 2023 at 06:10:19 UTC, Adam D Ruppe wrote:

 On Friday, 21 July 2023 at 02:54:16 UTC, harakim wrote:
 I tested that it compiled my project

 from one year ago and it worked like a charm. How do I know it 
 didn't just fail to do anything, you might ask?


 Those deprecations and random breaking changes in the stdlib 
 annoyed me but they were easy fixes, if you do the quick edits 
 yourself or grab the new files from my arsd repo they all work 
 again (tho if you get the new files, make sure you grab the new 
 arsd\core.d file too since i added that upstream, but other 
 than adding the file there's no public api changes in my lib)


I appreciate the response. I know it's easy to fix. I just 
thought it was funny I was going out of my way to show how easy 
it was and then I was like, well how will I prove it actually 
updated and my answer was the same as always: because it doesn't 
compile. :D I know it's super easy to fix and I haven't had major 
issues with that since I started using your library as my base, 
so thanks for that!
Jul 21 2023
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 21 July 2023 at 02:54:16 UTC, harakim wrote:

 ```
 source\arsd\simpledisplay.d(6445,51): Deprecation: using `in 
 ref` is deprecated, use `-preview=in` and `in` instead
 ...
 source\arsd\http2.d(3567,17): Error: function `void 
 arsd.http2.OpenSslSocket.close()` does not override any 
 function, did you mean to override `nothrow  nogc scope 
  trusted void std.socket.Socket.close()`?
 Error C:\Program Files\D\dmd2\windows\bin\dmd.exe failed with 
 exit code 1.
 ```


Regression introduced in 
https://github.com/dlang/phobos/pull/8551 BTW. A long time ago I 
added a test to prevent exactly that kind of regression, but the 
PR "fixed" the test too. I don't know what the solution is here, 
though.
Jul 20 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2023 7:54 PM, harakim wrote:

 source\arsd\simpledisplay.d(6445,51): Deprecation: using `in ref` is
deprecated, 
 use `-preview=in` and `in` instead
 ...
 Oh, D... *smile and sigh*


Going to revisit this:

https://github.com/dlang/dmd/pull/15443
Jul 21 2023
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 22 July 2023 at 01:23:54 UTC, Walter Bright wrote:

 On 7/20/2023 7:54 PM, harakim wrote:

 source\arsd\simpledisplay.d(6445,51): Deprecation: using `in 
 ref` is deprecated, use `-preview=in` and `in` instead
 ...
 Oh, D... *smile and sigh*


 Going to revisit this:

 https://github.com/dlang/dmd/pull/15443


*sigh*
Jul 23 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/23/2023 2:12 AM, Paolo Invernizzi wrote:

 On Saturday, 22 July 2023 at 01:23:54 UTC, Walter Bright wrote:

 Going to revisit this:

 https://github.com/dlang/dmd/pull/15443


 
 *sigh*


??
Jul 23 2023
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 23 July 2023 at 17:14:39 UTC, Walter Bright wrote:

 On 7/23/2023 2:12 AM, Paolo Invernizzi wrote:

 On Saturday, 22 July 2023 at 01:23:54 UTC, Walter Bright wrote:

 Going to revisit this:

 https://github.com/dlang/dmd/pull/15443


 
 *sigh*


 ??


You know, I'm in the "deprecate and clean-up the language" camp 
since forever ...
Jul 24 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/24/2023 12:22 AM, Paolo Invernizzi wrote:

 You know, I'm in the "deprecate and clean-up the language" camp since forever
...


I am, too, but it clearly does not work for us.
Jul 24 2023
parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 24 July 2023 at 18:43:02 UTC, Walter Bright wrote:

 On 7/24/2023 12:22 AM, Paolo Invernizzi wrote:

 You know, I'm in the "deprecate and clean-up the language" 
 camp since forever ...


 I am, too, but it clearly does not work for us.


Don't mistake the destination with the method of getting there 
e.g. a few deprecations aren't actually stopping people from 
using D, it's just discouraging having a violent torrent of 
dip1000 deprecations which would (for us) require days or weeks 
of engineering-time to get around (if even possible) because the 
underlying model just isn't able to express the patterns that 
make D productive (as opposed to merely expressive).

For deprecations that are either syntactic or a direct 
substitution, the compiler should just fix it for you - clang and 
gcc (to a lesser extent) can both do this, e.g. the body=>do 
change - regardless of the justification the compiler should just 
parse it and fix it (or emit a diff, etc etc).
Jul 24 2023
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 24 July 2023 at 19:24:56 UTC, max haughton wrote:

 On Monday, 24 July 2023 at 18:43:02 UTC, Walter Bright wrote:

 On 7/24/2023 12:22 AM, Paolo Invernizzi wrote:

 You know, I'm in the "deprecate and clean-up the language" 
 camp since forever ...


 I am, too, but it clearly does not work for us.


 Don't mistake the destination with the method of getting there 
 e.g. a few deprecations aren't actually stopping people from 
 using D, it's just discouraging having a violent torrent of 
 dip1000 deprecations which would (for us) require days or weeks 
 of engineering-time to get around (if even possible) because 
 the underlying model just isn't able to express the patterns 
 that make D productive (as opposed to merely expressive).

 For deprecations that are either syntactic or a direct 
 substitution, the compiler should just fix it for you - clang 
 and gcc (to a lesser extent) can both do this, e.g. the 
 body=>do change - regardless of the justification the compiler 
 should just parse it and fix it (or emit a diff, etc etc).


I agree that a tool like python 2to3 could be useful, but the 
python experience seems to point out that it was pretty a failure 
overall.

That remind me of the Phobos v2/v3 work about the removing of 
auto decoding: the party proposing an "let's go with copy/past" 
loose the race, but the party proposing "let's go with a cleaver 
super-engineered way of sharing code" stalled ... sometime the 
best way to move forward is just the simplest one.

I sympathize with you about the torrent of dip1000 deprecations, 
our code was also hit by them. But if dip1000 is an added value 
to the codebase, that engineering-time is a good spent time I 
guess. The point is, aren't the actual compiler switches enough 
to let you choose when to do the transition of the codebase? 
What's the problem about that?

We have much more difficulties in reading some "modern" D code, 
full of scope/ref/in/const/auto ... plus  live ... plus care if 
scope is before or after, plus yes here scope is doing nothing, 
etc etc. Maybe because we use python a lot also (you know, 
machine learning ....) but simplicity, and "explicit is better 
than implicit" is a value.

I understand your point, but to me the need to explain a 
programmer, "yes dude, 'in ref' was an ancient way of doing 'in', 
just keep ALSO that in mind" is a strategic error. Stepping back 
from the current deprecation mechanics is a pity.

/Paolo
Jul 25 2023
next sibling parent reply harakim <harakim gmail.com> writes:
On Tuesday, 25 July 2023 at 10:21:30 UTC, Paolo Invernizzi wrote:

 I agree that a tool like python 2to3 could be useful, but the 
 python experience seems to point out that it was pretty a 
 failure overall.


I actually think python is an excellent example of a language 
that wanted to make major changes and pulled it off successfully. 
Being arguable the most popular language in the world is a pretty 
good proof! I don't mind if there is a D2 and D3 like Python, so 
long as it's something predictable and I can compile old 
projects. I think the versioning idea mentioned by H. S. Teoh 
would be a slightly better version of what they did because you 
wouldn't have to have virtualenvs for each project. To be fair, I 
don't know why you consider 2to3 a failure because I rarely do 
anything in Python, but maybe the 2to3 tool specifically is not 
part of the solution.


 sometimes the best way to move forward is just the simplest one.


I feel like this makes sense, but simplest for whom?

In the end, I would like an ecosystem of IDEs, libraries and 
tools that don't even exist in other languages. Until there is a 
way to take a 2-year-old abandoned project and pick it up and 
build it, it will be starting from scratch each time and a lot of 
the tools will not get built and stay built. It has to be 
something where work done is done and not lost. I would like a 
roadmap to that before I personally commit a lot of my time to it.


 The point is, aren't the actual compiler switches enough to let 
 you choose when to do the transition of the codebase? What's 
 the problem about that?


I would like to know more about this, can you give an example? 
Does the compiler already let you specify you want to keep using 
in ref (for example) or something like that?
Jul 25 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jul 25, 2023 at 03:06:22PM +0000, harakim via Digitalmars-d wrote:
[...]

 In the end, I would like an ecosystem of IDEs, libraries and tools
 that don't even exist in other languages. Until there is a way to take
 a 2-year-old abandoned project and pick it up and build it, it will be
 starting from scratch each time and a lot of the tools will not get
 built and stay built. It has to be something where work done is done
 and not lost.  I would like a roadmap to that before I personally
 commit a lot of my time to it.


[...]

This is why I came up with the versioning idea.  Basically, we need to
face the reality that a lot of code, once written, is going to stay that
way.  Once in a while you might refactor a bit of code here and there,
maybe even rewrite a module or two, but 90% of the code is going to stay
untouched for a long time, many years even. This is especially true if
we want D's library ecosystem to grow.  The bigger the ecosystem
becomes, the more code you'd have to rewrite to keep up-to-date with the
language if we continue updating it.  This is inescapable.  The result
is that more and more D code will accumulate in the ecosystem, and the
more it accumulates, the less likely someone will have the time / energy
/ motivation to rewrite it all when the language undergoes a fundamental
change.

The only solution, to avoid having to do a massive rewrite of 90% of D's
entire ecosystem every time there's a language change, is to have the
compiler understand old code and compile old code in the way it was
supposed to be compiled years ago.

Just think about it.  In human language, the same thing happens. Most
literary works in any language, including English, consists of a large
body of works written in an older dialect of the language -- think
Chaucer, Shakespeare, and more recent, but not contemporary authors --
in the 1900's, in the 1950's, etc.. When you read them, you get the
distinct sense that they used certain words differently from how we use
them today.  Yet our human brain automatically adapts itself, and parses
the older language *according to the older language*, so that we don't
have to rewrite Shakespeare in 2023's modern English just to be able to
read it.  Nobody's gonna rewrite the entire body of English literature
just to keep up with the modern language, that's totally impractical.
And nobody's gonna throw away older literature just because it's "not
compatible" with the modern language.  No, we keep the older stuff
around, and the contemporary language continues evolving like it always
has.

How do we reconcile the two?  It's not that hard, you just spontaneously
understand when you're reading a 1950's novel, for example, that it's
older literature, and they used certain expressions (language
constructs) we don't use today, but by looking at the context you can
more-or-less figure out what it means. And you just adapt your reading
accordingly to understand the text.

In compiler terms, this just means that the compiler has to (1)
understand that it's dealing with code meant for an older version of the
language, and (2) based on that knowledge adapt the way it processes the
code in a way that preserves its original meaning.

Tagging code with versions takes care of (1); that leaves the compiler
to implement (2), and it would work.

Something along these lines has to be done, otherwise we're never gonna
move forward.  The ecosystem is just gonna stagnate because the more the
language advances, the more old code and old libraries will stop
compiling.  But not changing the language doesn't work either -- English
in 2023 is different from English in 1823 for a reason.  It has to keep
up with the times.  Imagine if we still spoke Shakespearean English
today just because we feared that change would obsolete existing
literature.  That'd be ridiculous.  We need both progress and
compatibility with older literature (i.e., existing code).


T

-- 
Тише едешь, дальше будешь.
Jul 25 2023
next sibling parent reply harakim <harakim gmail.com> writes:
On Tuesday, 25 July 2023 at 16:51:04 UTC, H. S. Teoh wrote:

 In compiler terms, this just means that the compiler has to (1) 
 understand that it's dealing with code meant for an older 
 version of the language, and (2) based on that knowledge adapt 
 the way it processes the code in a way that preserves its 
 original meaning.


That's an interesting comparison to older languages. I agree if 
you can do 1 and 2 then the problem wouldn't exist. I have doubts 
about whether people would do (1), although it could be done 
retroactively as needed, maybe even in an automated fashion. So 
that could work. Then there is (2). Would there be 104 code paths 
(for ex, 1 for each version) in the compiler? That seems like it 
would be super complicated.


 Something along these lines has to be done, otherwise we're 
 never gonna move forward.  The ecosystem is just gonna stagnate 
 because the more the language advances, the more old code and 
 old libraries will stop compiling.


This is definitely true. I worked a job where we would sell a lot 
but our software was so bad, we would lose more customers than we 
gained. I hadn't really thought of it like that but I do feel 
like I find fewer tools and native libraries than I used to.

I think it would be reasonable for people to keep multiple 
compilers around. Maybe someone could be expected to keep each 
LTS version around. I don't know how much that would solve though 
since there would still be all the incremental versions. I'm not 
convinced the version thing is practical yet, but it would solve 
the problem. Do you think it would be practical to have a single 
compiler managing 100s of versions of the language?
Jul 25 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jul 26, 2023 at 04:27:24AM +0000, harakim via Digitalmars-d wrote:

 On Tuesday, 25 July 2023 at 16:51:04 UTC, H. S. Teoh wrote:

 In compiler terms, this just means that the compiler has to (1)
 understand that it's dealing with code meant for an older version of
 the language, and (2) based on that knowledge adapt the way it
 processes the code in a way that preserves its original meaning.


 That's an interesting comparison to older languages. I agree if you
 can do 1 and 2 then the problem wouldn't exist. I have doubts about
 whether people would do (1), although it could be done retroactively
 as needed, maybe even in an automated fashion. So that could work.


This one is easy: introduce a version declaration at the top of every
module, say a `version = "2.105.0";`, or something alongside the module
declaration, like `module my.module version("2.105.0");`.  All older
code that don't have this declaration will be assumed to be written for
some fixed baseline version, say the latest version before this scheme
is implemented in the compiler.  Then going forward, all unmarked code
will be pinned at that version, and to get newer features you'd
introduce the version declaration to your module, thereby ensuring that
it will be properly marked going forward.



 Then there is (2). Would there be 104 code paths (for ex, 1 for each
 version) in the compiler? That seems like it would be super
 complicated.


It's impractical to retroactively do this for previous releases. Just
set the current release (or whatever release this scheme will start in)
as the baseline, and have each new feature guarded by an appropriate
version condition, so that the old code path will continue to run if the
current module isn't versioned for a release that includes the new
feature.  We don't have to keep 104 copies of the compiler code around
for this, that'd be an unmaintainable mess.



 Something along these lines has to be done, otherwise we're never
 gonna move forward.  The ecosystem is just gonna stagnate because
 the more the language advances, the more old code and old libraries
 will stop compiling.


 
 This is definitely true. I worked a job where we would sell a lot but
 our software was so bad, we would lose more customers than we gained.
 I hadn't really thought of it like that but I do feel like I find
 fewer tools and native libraries than I used to.
 
 I think it would be reasonable for people to keep multiple compilers
 around.  Maybe someone could be expected to keep each LTS version
 around. I don't know how much that would solve though since there
 would still be all the incremental versions. I'm not convinced the
 version thing is practical yet, but it would solve the problem. Do you
 think it would be practical to have a single compiler managing 100s of
 versions of the language?


It will make the compiler more complex to maintain, certainly.  But
*something* has to be done... otherwise nothing is going to change and
the D ecosystem is going to remain small forever.


T

-- 
Once bitten, twice cry...
Jul 26 2023
parent reply harakim <harakim gmail.com> writes:
On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:

 It will make the compiler more complex to maintain, certainly.  
 But *something* has to be done... otherwise nothing is going to 
 change and the D ecosystem is going to remain small forever.


What specific advantages would you get in requiring every file to 
have a version as opposed to a compiler flag that can be passed 
in via the build tool like dub? I feel like a project is usually 
worked on as a version. I don't know a lot about linking but it 
seems like you could build each dependency with its own version 
and link them with rare exceptions. That would make it easier to 
use and also to retrofit old projects you come across than 
manually updating every file.

If you think per file is the way to go, then what if instead of 
defaulting to say 2.105 forever, it defaulted to the latest 
LTS/major version. And then if you wanted to compile older stuff 
that no longer compiles, it could just use the old compiler. I 
don't think it would be a high bar to have people download 
multiple versions of the compiler. It could be included in the 
default download perhaps. I always have several JDKs and usually 
even a few versions of Visual Studio.

Also, I agree that this wouldn't make sense retroactively. I was 
thinking if we have 100 versions now, then one day we will 
probably have 100 more.

I appreciate you taking the time to walk me through this because 
it's giving me a lot of peace of mind and I think you're 
definitely on to something.
Jul 26 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 27 July 2023 at 05:11:48 UTC, harakim wrote:

 On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:

 It will make the compiler more complex to maintain, certainly. 
  But *something* has to be done... otherwise nothing is going 
 to change and the D ecosystem is going to remain small forever.


 What specific advantages would you get in requiring every file 
 to have a version as opposed to a compiler flag that can be 
 passed in via the build tool like dub? I feel like a project is 
 usually worked on as a version. I don't know a lot about 
 linking but it seems like you could build each dependency with 
 its own version and link them with rare exceptions. That would 
 make it easier to use and also to retrofit old projects you 
 come across than manually updating every file.

 [snip]


One potential advantage would be that it is more fine-grained. 
You could incrementally change your project on a file-by-file 
basis without doing everything at once. I don't have a good sense 
of how this would work with dependencies.

Also, if you check out the links I included previously, the idea 
in Circle is if you don't include a version, then it is just 
normal C++. The versions are completely opt-in. I think HS Teoh 
makes reference to this in his later discussion that his own idea 
of it is basically opt-in. I think that was one of my hang-ups 
when I first tried to understand his idea.

The other part of Circle that is interesting is that you don't 
have to specify everything in each file, you can have a separate 
file that says what features you want to use and then have the 
version statement (or whatever it is called in Circle) refer to 
that. So instead of having to change every single file when you 
want to make an adjustment, you could only change it in one 
place. If D went this route, then I think something similar would 
be important.
Jul 27 2023
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jul 27, 2023 at 05:11:48AM +0000, harakim via Digitalmars-d wrote:

 On Wednesday, 26 July 2023 at 18:15:18 UTC, H. S. Teoh wrote:

 It will make the compiler more complex to maintain, certainly.  But
 *something* has to be done... otherwise nothing is going to change
 and the D ecosystem is going to remain small forever.


 
 What specific advantages would you get in requiring every file to have
 a version as opposed to a compiler flag that can be passed in via the
 build tool like dub?


3rd party libraries.  Say your project depends on libraries A, B, C.
Each of them could potentially be written for a different edition of the
language, and your own code could also be for a different edition, so
you'll have to compile with 4 different compilers.  Also, every time you
add a new dependency you potentially have to install yet another
compiler.  It's just not scalable, and needlessly confusing for newbies
("what, why do I need 10 different compilers just to compile my one test
project?!").

Better just to have a single compiler to handle it all.



 I feel like a project is usually worked on as a version. I don't know
 a lot about linking but it seems like you could build each dependency
 with its own version and link them with rare exceptions.


[...]

Not really. Most D releases are ABI-incompatible, so you're liable to
end up with lots of inscrutable linker errors and/or inscrutable runtime
odd behaviours caused by incompatible ABIs if you try to link together
objects compiled by different versions of the compiler.  Safer to use a
single compiler to compile and link everything.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it
often, use it unsparingly, to subdue your listeners into submission!
Jul 27 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2023 9:51 AM, H. S. Teoh wrote:

 The only solution, to avoid having to do a massive rewrite of 90% of D's
 entire ecosystem every time there's a language change, is to have the
 compiler understand old code and compile old code in the way it was
 supposed to be compiled years ago.


As much as we can, that's the way we're going to do it moving forward.

In addition, we're considering some sort of annotation in the source code
saying 
which "edition" of D the module conforms to.
Jul 26 2023
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jul 26, 2023 at 12:54:02PM -0700, Walter Bright via Digitalmars-d wrote:

 On 7/25/2023 9:51 AM, H. S. Teoh wrote:

 The only solution, to avoid having to do a massive rewrite of 90% of
 D's entire ecosystem every time there's a language change, is to
 have the compiler understand old code and compile old code in the
 way it was supposed to be compiled years ago.


 
 As much as we can, that's the way we're going to do it moving forward.


Good to hear!



 In addition, we're considering some sort of annotation in the source
 code saying which "edition" of D the module conforms to.


Yes, that's exactly what I have in mind.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney
Jul 26 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 26 July 2023 at 19:54:02 UTC, Walter Bright wrote:

 On 7/25/2023 9:51 AM, H. S. Teoh wrote:

 The only solution, to avoid having to do a massive rewrite of 
 90% of D's
 entire ecosystem every time there's a language change, is to 
 have the
 compiler understand old code and compile old code in the way 
 it was
 supposed to be compiled years ago.


 As much as we can, that's the way we're going to do it moving 
 forward.

 In addition, we're considering some sort of annotation in the 
 source code saying which "edition" of D the module conforms to.


Not sure if you're familiar with Circle, but it looks like that's 
what they are trying to do.

https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives

Started watching this
https://www.youtube.com/watch?v=x7fxeNqSK2k
Jul 26 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2023 1:28 PM, jmh530 wrote:

 Not sure if you're familiar with Circle, but it looks like that's what they
are 
 trying to do.
 
 https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives
 
 Started watching this
 https://www.youtube.com/watch?v=x7fxeNqSK2k


Yeah, something along those lines.
Jul 26 2023
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2023 3:21 AM, Paolo Invernizzi wrote:

 I understand your point, but to me the need to explain a programmer, "yes
dude, 
 'in ref' was an ancient way of doing 'in', just keep ALSO that in mind" is a 
 strategic error. Stepping back from the current deprecation mechanics is a
pity.


`in ref` is now accepted without comment. It doesn't hurt anything.
Jul 26 2023
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 25 July 2023 at 10:21:30 UTC, Paolo Invernizzi wrote:

 We have much more difficulties in reading some "modern" D code, 
 full of scope/ref/in/const/auto ... plus  live ... plus care if 
 scope is before or after, plus yes here scope is doing nothing, 
 etc etc. Maybe because we use python a lot also (you know, 
 machine learning ....) but simplicity, and "explicit is better 
 than implicit" is a value.

 I understand your point, but to me the need to explain a 
 programmer, "yes dude, 'in ref' was an ancient way of doing 
 'in', just keep ALSO that in mind" is a strategic error. 
 Stepping back from the current deprecation mechanics is a pity.


`in ref` is not an ancient way of doing `in`, it's a 
straightforward combination of `in` and `ref`. `-preview=in` 
improves `in`, your code that uses `in` is improved, that's all, 
there's no reason why it should affect `ref`.
Jul 27 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/27/23 4:01 AM, Kagamin wrote:

 On Tuesday, 25 July 2023 at 10:21:30 UTC, Paolo Invernizzi wrote:

 We have much more difficulties in reading some "modern" D code, full 
 of scope/ref/in/const/auto ... plus  live ... plus care if scope is 
 before or after, plus yes here scope is doing nothing, etc etc. Maybe 
 because we use python a lot also (you know, machine learning ....) but 
 simplicity, and "explicit is better than implicit" is a value.

 I understand your point, but to me the need to explain a programmer, 
 "yes dude, 'in ref' was an ancient way of doing 'in', just keep ALSO 
 that in mind" is a strategic error. Stepping back from the current 
 deprecation mechanics is a pity.


 
 `in ref` is not an ancient way of doing `in`, it's a straightforward 
 combination of `in` and `ref`. `-preview=in` improves `in`, your code 
 that uses `in` is improved, that's all, there's no reason why it should 
 affect `ref`.


With preview=in behavior, whether the parameter is passed by reference 
is decided by the compiler. `in ref` should just mean `in`.

-Steve
Jul 27 2023
next sibling parent Kagamin <spam here.lot> writes:
On Thursday, 27 July 2023 at 13:42:28 UTC, Steven Schveighoffer 
wrote:

 With preview=in behavior, whether the parameter is passed by 
 reference is decided by the compiler. `in ref` should just mean 
 `in`.


I see it as an optimization you get for free, not a dogma.
Jul 27 2023
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 27 July 2023 at 13:42:28 UTC, Steven Schveighoffer 
wrote:

 On 7/27/23 4:01 AM, Kagamin wrote:

 On Tuesday, 25 July 2023 at 10:21:30 UTC, Paolo Invernizzi 
 wrote:

 [...]


 
 `in ref` is not an ancient way of doing `in`, it's a 
 straightforward combination of `in` and `ref`. `-preview=in` 
 improves `in`, your code that uses `in` is improved, that's 
 all, there's no reason why it should affect `ref`.


 With preview=in behavior, whether the parameter is passed by 
 reference is decided by the compiler. `in ref` should just mean 
 `in`.

 -Steve


Exactly, Steve nailed it.

/P
Jul 27 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/24/2023 12:24 PM, max haughton wrote:

 For deprecations that are either syntactic or a direct substitution, the 
 compiler should just fix it for you - clang and gcc (to a lesser extent) can 
 both do this, e.g. the body=>do change - regardless of the justification the 
 compiler should just parse it and fix it (or emit a diff, etc etc).


The ones we can unambiguously fix are the ones we can accept anyway.
Jul 26 2023
parent reply max haughton <maxhaton gmail.com> writes:
On Wednesday, 26 July 2023 at 19:47:55 UTC, Walter Bright wrote:

 On 7/24/2023 12:24 PM, max haughton wrote:

 For deprecations that are either syntactic or a direct 
 substitution, the compiler should just fix it for you - clang 
 and gcc (to a lesser extent) can both do this, e.g. the 
 body=>do change - regardless of the justification the compiler 
 should just parse it and fix it (or emit a diff, etc etc).


 The ones we can unambiguously fix are the ones we can accept 
 anyway.


Shall we accept C-style casts anyway?

Practicality aside, D is also supposed to have some taste.
Jul 26 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2023 1:46 PM, max haughton wrote:

 Shall we accept C-style casts anyway?


I don't think we have without a warning since day 1.


 Practicality aside, D is also supposed to have some taste.


Of course.
Jul 26 2023
prev sibling parent reply harakim <harakim gmail.com> writes:
On Monday, 24 July 2023 at 07:22:57 UTC, Paolo Invernizzi wrote:

 On Sunday, 23 July 2023 at 17:14:39 UTC, Walter Bright wrote:

 On 7/23/2023 2:12 AM, Paolo Invernizzi wrote:

 On Saturday, 22 July 2023 at 01:23:54 UTC, Walter Bright 
 wrote:

 Going to revisit this:

 https://github.com/dlang/dmd/pull/15443


 
 *sigh*


 ??


 You know, I'm in the "deprecate and clean-up the language" camp 
 since forever ...


I am glad there is a deprecate and clean-up the language camp and 
it's gotten D to where it is today. I like to have improvements 
like that, but for about 7 years I have been in the stabilize the 
language camp and I'd like to explain why.

I have java code from 2006 that still compiles today. I have tens 
of thousands of lines of c/assembly from 1998 that compiles today 
with two errors and I would bet there's a flag to make it work if 
I didn't want to change it. In college (about 15 years ago) I 
helped someone with some code for their PHD dissertation. It was 
Fortran 57 code copied out of a textbook and it also compiled 
without issue. IMO, this is the norm for a project.

In contrast, I don't know that I have ever come back to an old D 
project and had it compile. Just the other day, I went to compile 
some code I wrote with dmd 2.100 with a 2.104 compiler and it 
would not compile. Sure, it's an easy fix, but that's not always 
the case and I am tired of tools that nickel-and-dime me. That is 
the whole point of picking a toolset, which includes the 
programming language: to have something that doesn't nickel and 
dime me - something that is fun and productive. When I'm in the 
flow, I can write code as fast as I can type forum posts. I can 


but really shines in some other cases. It's 90% of the way to a 
solid choice for just about anything.

It is very demotivating to spend 100 hours on a project and then 
have to put it away, then come back in 2 years and have 
innumerable compilation errors or have all your libraries become 
unusable. It is very hard to want to commit to that kind of 
language where the first step of picking up an old project is 
replacing libraries - if there are even replacements - and fixing 
compilation errors and THEN trying to remember what you were 
doing and where you were at and only then can you actually make 
progress. This isn't necessarily a dealbreaker for people who 
work on it full time and keep their code up to date nor for 
single people who have lots of free time anyway, but it's a 
dealbreaker for many who are investigating the language or even 
for a part-time hobbyist.

So that is why I am a proponent of stabilizing the language. So I 
can work on solving my problem of interest and not working on 
rewriting libraries or compilation errors. So I can spend the 
time to get really good and write my own tools so it's even more 
out of the way of solving my problem.

Obviously, I would prefer the team to keep cleaning up the 
language, given it doesn't break all my existing code. Someone 
mentioned that gcc autocorrects code. That would facilitate clean 
up. Having a tool that would go through and make the minor 
automatic changes to upgrade to the latest standard would be a 
solution, if that is practical. Having a simple and unambiguous 
guide to changes you need to make between language versions could 
work if people knew to look for it and could find it easily. I 
also think distributing libraries as binaries could solve most of 
the big issues, tbh, although that idea doesn't seem to get a lot 
of mileage for reasons I can't understand.

I believe there is a plan that can work for everyone. I'm not an 
expert on compilers or build chains and I'm not super clear on 
where the language is going, so I'm not a great person to explain 
what that plan is. I am very happy to see that stability is being 
addressed, and I also understand I may not reflect the target 
audience of the language. I'm trying to find a way to get into 
the compiler to get some experience in my free time, but mostly 
I'm hoping to understand the different perspectives of people on 
this issue so I can draft a meaningful problem statement. I would 
like to be in a position to provide some good advice or even come 
up with a great idea to solve the stability issues without 
sacrificing moving the language forward. If you are open to it, I 
would appreciate hearing more about your perspective on this via 
a phone call or chat. If you're interested you can hit me up here 
or at my gmail address that is the same as my username.
Jul 25 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jul 25, 2023 at 07:28:46AM +0000, harakim via Digitalmars-d wrote:

 On Monday, 24 July 2023 at 07:22:57 UTC, Paolo Invernizzi wrote:


[...]

 You know, I'm in the "deprecate and clean-up the language" camp
 since forever ...


 
 I am glad there is a deprecate and clean-up the language camp and it's
 gotten D to where it is today. I like to have improvements like that,
 but for about 7 years I have been in the stabilize the language camp
 and I'd like to explain why.
 
 I have java code from 2006 that still compiles today. I have tens of
 thousands of lines of c/assembly from 1998 that compiles today with
 two errors and I would bet there's a flag to make it work if I didn't
 want to change it. In college (about 15 years ago) I helped someone
 with some code for their PHD dissertation. It was Fortran 57 code
 copied out of a textbook and it also compiled without issue. IMO, this
 is the norm for a project.
 
 In contrast, I don't know that I have ever come back to an old D
 project and had it compile. Just the other day, I went to compile some
 code I wrote with dmd 2.100 with a 2.104 compiler and it would not
 compile. Sure, it's an easy fix, but that's not always the case and I
 am tired of tools that nickel-and-dime me.


I'm actually in both camps, if that even makes sense. :-D

One of the main reasons I liked D so much is that it got rid of a lot of
baggage in C/C++ that it inherits from, resulting in a much cleaner
language with fewer dark corners and gotchas. Over time, however, it has
started accumulating its own cruft and share of dark corners. Sometimes
I wish those corners could be straightened out, but each time my hopes
are dashed by the spectre of "we don't want to break user code".

Ironically, at the same time user code continues to break, including my
own projects, and that's also frustrating.  I remember several D
projects where, coming back to it after a couple of years hoping to make
a quick 5-minute fix for a small issue, I end up spending hours or even
days to update it because something got deprecated, or plain broke, due
to some language changes. There was one project that I couldn't even
compile for *months* before my loud complaining pushed some kind soul to
fix it. So in that sense I'm also in the "please don't break my existing
code" camp.

These two camps seem fundamentally incompatible with each other, but
I've been thinking there must be a way to have the best of both worlds.
I've suggested this before, but versioning source code seems to be a
potential approach. Each source file should have a version declaration
to declare which version of the language/compiler it's based on, and
when the compiler sees this, it enables "compatibility mode",
effectively compile the file as much as possible with the old semantics
of the language. Breaking changes are suppressed so that it behaves as
if it was an older version of the language. Optionally when an old
feature is used a warning is issued, but compilation should not abort
because of that -- it should still compile and work as before. Give the
user the option of using the old semantics until he's ready to upgrade
it.

Of course, some changes are fundamentally incompatible with older
versions of the language; in those cases we'd have to issue an error.
In the ideal world, this shouldn't happen.  New code added to an old
project can declare a newer version and use new features, but the old
code will continue to use the older version until the programmer
manually changes the version declaration. This shouldn't matter, because
if new code X uses a new feature that causes a compile error due to bad
interaction with old module M, it wouldn't have been checked in, in the
first place. If it ever compiled, that means X must be compatible with
M in spite of the version difference, so the compiler should just
continue to compile it as before.  If X becomes incompatible with M and
the author updates M to be compatible, then so much the better. But if
not, things should still work as before.

Libraries should also have access to the declared version of the caller,
so that when the library API changes, the old API can be kept present to
keep existing callers compilable; user code can optionally declare a
version to use the latest and greatest API instead, and update his code
to be compatible. As long as the old version is in effect, there should
be no API breakages.

Essentially, what I'm proposing is in effect the equivalent of having a
virtual dub package whose versions reflect the language version, and
different modules will depend on different versions. If there's a way to
resolve the dependencies, then the code should compile. If not, it won't
compile, and wouldn't have compiled in the first place, so users should
have already noticed this and did something about it.  But a project
that used to compile should continue to do so no matter what.


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:
Jul 25 2023
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 25 July 2023 at 09:55:31 UTC, H. S. Teoh wrote:

 [snip]

 I'm actually in both camps, if that even makes sense. :-D
 [snip]


What you describe with respect to compatibility mode is opt-in on 
a per file basis, which might place an annoying burden on users. 
As opposed to something that works more globally, like dub 
toolchain requirements (though I'm not sure how that resolves the 
issue with respect to libraries you mention).

However, I'm sympathetic to the idea. For it to work however, it 
might end up making the compiler a little more complicated since 
it would need to be able to compiler previous versions of the D 
language (or force you to have multiple D compilers installed and 
just call them).

What if instead you paired that with something like the LTS ideas 
floating around. So the D equivalent of something like 
`-std=c++20`. One of the operational difficulties with the LTS 
idea is that you can just call some version of DMD the LTS, but 
that doesn't get you bug fixes from newer versions that you might 
want. You need people to actually implement them. However, if the 
LTS version is kept within the main compiler as a switch, then it 
is a little bit easier to keep it up to date with bug fixes.

It still would end up making the compiler (and work on the 
compiler) more complicated. If someone adds a new feature or some 
kind of breaking change, then they would need to maintain the old 
behavior in a version statement. Normal bug fixes could be 
applied without this, so it would impact both versions.

It would also be different from C/C++ where you have to opt-in to 
the newer version. In D, you would be opting in to the older 
version (unless something were changed with how we think about 
releases).
Jul 25 2023
parent harakim <harakim gmail.com> writes:
On Tuesday, 25 July 2023 at 12:59:48 UTC, jmh530 wrote:

 What if instead you paired that with something like the LTS 
 ideas floating around. So the D equivalent of something like 
 `-std=c++20`. One of the operational difficulties with the LTS 
 idea is that you can just call some version of DMD the LTS, but 
 that doesn't get you bug fixes from newer versions that you 
 might want. You need people to actually implement them. 
 However, if the LTS version is kept within the main compiler as 
 a switch, then it is a little bit easier to keep it up to date 
 with bug fixes.


That's interesting. So basically the main compiler would be able 
to compile two versions: the current version and the LTS. That 
seems like it simplifies a lot of the issues. Then it would just 
be a matter of how to detect which of the two versions the code 
would build with, which I think is achievable, even as simple as 
specifying in the dub json/sdl file.

So then the only problem left is how you go from one LTS to 
another. A guide would work, and the compiler could even spit out 
a link since it knows what version you are on and what version 
you are targeting. However, if the LTS versions are frequent, I 
think a tool would be better. Or maybe you just keep multiple 
versions around and compile using the old LTS version of the 
compiler.
Jul 25 2023
prev sibling parent harakim <harakim gmail.com> writes:
On Tuesday, 25 July 2023 at 09:55:31 UTC, H. S. Teoh wrote:

 But a project that used to compile should continue to do so no 
 matter what.


I agree with this, and I guess technically if you had every 
version of dmd lying around it could do it today. You wouldn't be 
able to necessarily do it with one version of the compiler... you 
would have to look at each library separately. That's where your 
version comes in or using binaries.


 Essentially, what I'm proposing is in effect the equivalent of 
 having a virtual dub package whose versions reflect the 
 language version, and different modules will depend on 
 different versions. If there's a way to resolve the 
 dependencies, then the code should compile. If not, it won't 
 compile, and wouldn't have compiled in the first place, so 
 users should have already noticed this and did something about 
 it.


I have had similar thoughts about versioning but I think it could 
be difficult and also it could make the compiler extremely 
complex. That's why I was thinking about the one time upgrade 
tool. However, if you had multiple versions of the compiler 
installed and the latest version would just defer to an older 
version, if available, then this would actually be a simpler 
solution and require very little re-work.
Jul 25 2023
prev sibling next sibling parent CM <celestialmachinist proton.me> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 [...]


For what it's worth, "installing" and using LDC (and its provided 
dub) is painless on Windows.
Jul 20 2023
prev sibling next sibling parent reply Curious Observer <c.o mail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 31. Too complicated. Close VSCode, posting on forum :)


Not a D user but though I'd give it try:

1. Download Windows 7z file from here: 
https://dlang.org/download.html

2. Unzipped file into this folder:

          D:\Utilities\dmd\dmd2

3. Found the binaries and add that folder to the PATH:

          D:\Utilities\dmd\dmd2\windows\bin

4. In a d:\Tutorial folder I ran this command and hit enter to 
all the questions asked:

         dub init my_test

5. Ran these commands to build the new project:

        cd my_test
        dub

The build creates an executable and it runs just fine.

         d:\Tutorial\my_test>my_test
         Edit source/app.d to start your project.
Jul 20 2023
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 21 July 2023 at 04:55:00 UTC, Curious Observer wrote:

 On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 31. Too complicated. Close VSCode, posting on forum :)


 Not a D user but though I'd give it try:

 1. Download Windows 7z file from here: 
 https://dlang.org/download.html

 2. Unzipped file into this folder:

          D:\Utilities\dmd\dmd2

 3. Found the binaries and add that folder to the PATH:

          D:\Utilities\dmd\dmd2\windows\bin

 4. In a d:\Tutorial folder I ran this command and hit enter to 
 all the questions asked:

         dub init my_test

 5. Ran these commands to build the new project:

        cd my_test
        dub

 The build creates an executable and it runs just fine.

         d:\Tutorial\my_test>my_test
         Edit source/app.d to start your project.


Funny how things become a lot easier once you dispense with all 
the "convenience features" meant to increase "ease of use".
Jul 20 2023
prev sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Friday, 21 July 2023 at 04:55:00 UTC, Curious Observer wrote:

 On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 31. Too complicated. Close VSCode, posting on forum :)


 Not a D user but though I'd give it try:

 1. Download Windows 7z file from here: 
 https://dlang.org/download.html


Yes, there are a lot of ways to install it, you can even git 
clone dmd and compile it, write your code in notepad++ or copy 
con hello.d, but here I am talking about user experience. Today, 
a programming language without a language aware editor and 
without debug features, it's unusable. Compare with rust:

1. Download installer
2. Run it, no user interaction except pressing Enter
3. Launch VSCode
4. Extensions/rust-analyzer
5. cargo new hello
6. rust-analyzer/run -> ok
7. rust-analyzer/debug/run -> ok
Jul 20 2023
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Friday, 21 July 2023 at 05:29:16 UTC, Rumbu wrote:

 On Friday, 21 July 2023 at 04:55:00 UTC, Curious Observer wrote:
Compare with rust:

 1. Download installer
 2. Run it, no user interaction except pressing Enter
 3. Launch VSCode
 4. Extensions/rust-analyzer
 5. cargo new hello
 6. rust-analyzer/run -> ok
 7. rust-analyzer/debug/run -> ok


Basically exactly the same for D, you are doing something wrong.

1. Download the installer
2. Run it and tell smartscreen that you are absolutely aware of 
what you are doing
3. Launch VSCode
4. install code-d
5. dub init
6. dub run --build=release
7. dub run

The only thing is that smartscreen requires you to click that 
"details" button and manually allow it to run the installer 
because it is "reputation" based filter and there is few people 
using D compared to rust.
Jul 20 2023
parent reply Rumbu <rumbu rumbu.ro> writes:
On Friday, 21 July 2023 at 06:14:16 UTC, evilrat wrote:

 On Friday, 21 July 2023 at 05:29:16 UTC, Rumbu wrote:

 On Friday, 21 July 2023 at 04:55:00 UTC, Curious Observer 
 wrote:
Compare with rust:





 6. rust-analyzer/run -> ok
 7. rust-analyzer/debug/run -> ok


 Basically exactly the same for D, you are doing something wrong.



 6. dub run --build=release
 7. dub run

 The only thing is that smartscreen requires you to click that 
 "details" button and manually allow it to run the installer 
 because it is "reputation" based filter and there is few people 
 using D compared to rust.


Nope, I am asked if I want to replace my 2.041 version with 2.041 
version :)
And if I go on, it still pretends that I don't have VS 2019 
installed.

And nope also for VSCode experience. I don't touch the terminal. 
All is done from VSCode command palette/user interface. And step 
7 is about debugging (e.g. set a breakpoint, inspect locals, call 
stack and so on).
Jul 21 2023
parent evilrat <evilrat666 gmail.com> writes:
On Friday, 21 July 2023 at 07:12:28 UTC, Rumbu wrote:

 On Friday, 21 July 2023 at 06:14:16 UTC, evilrat wrote:

 On Friday, 21 July 2023 at 05:29:16 UTC, Rumbu wrote:

 On Friday, 21 July 2023 at 04:55:00 UTC, Curious Observer 
 wrote:
Compare with rust:





 6. rust-analyzer/run -> ok
 7. rust-analyzer/debug/run -> ok


 Basically exactly the same for D, you are doing something 
 wrong.



 6. dub run --build=release
 7. dub run

 The only thing is that smartscreen requires you to click that 
 "details" button and manually allow it to run the installer 
 because it is "reputation" based filter and there is few 
 people using D compared to rust.


 Nope, I am asked if I want to replace my 2.041 version with 
 2.041 version :)
 And if I go on, it still pretends that I don't have VS 2019 
 installed.

 And nope also for VSCode experience. I don't touch the 
 terminal. All is done from VSCode command palette/user 
 interface. And step 7 is about debugging (e.g. set a 
 breakpoint, inspect locals, call stack and so on).


Well ok, I'm not using rust but seems like that rust extension 
provide a no-brainer way of launching debugger, yep, ok D sucks - 
you have to install C++ extension (and lldb on linux too), create 
a new launch config using that "cppvsdbg"/lldb engine and point 
to your executable, then set a breakpoint and hit F5.

Also btw I started my journey in D in 2009 but first version I 
remember to actually use was 2.052 which was somewhere in 2011, 
having such issues with outdated installers is probably expected.
Jul 21 2023
prev sibling parent Kagamin <spam here.lot> writes:
I always had bad experience with install wizards, so I evade them 
like a plague.
Jul 26 2023
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:


1. download dmd.vXXX.7z
2. unpack at some folder X/dmd.vXXX
3. make symlink as "dmd" to it. u can easy change symlink to next 
ver in future instead edit %PATH%
4. add X/dmd/windows/bin to %PATH%. u can use dmd & dub now
5. copy X/dmd/src/druntime/src/core/sync/package.d to 
X/dmd/src/druntime/import/core/sync/ cuz some build issue

END
do same for LDC
END 2
Jul 21 2023
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 [...]


The last time I installed all of this (3 weeks ago perhaps) was 
inside a managed infosec-heavy windows setup and I had no issues 
at all other than needing to insist on installing in the first 
step. So milage does vary...
Jul 21 2023
parent Kagamin <spam here.lot> writes:
On Friday, 21 July 2023 at 17:30:37 UTC, max haughton wrote:

 The last time I installed all of this (3 weeks ago perhaps) was 
 inside a managed infosec-heavy windows setup and I had no 
 issues at all other than needing to insist on installing in the 
 first step. So milage does vary...


I suppose it was windows enterprise edition? Defender on windows 
home edition behaves differently and is eager to give heuristic 
false positive detections.
Jul 26 2023
prev sibling next sibling parent reply MrJay <mrjcraft2021 gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:

 1. Downloaded DMD installer.
 2. Cannot run, blocked by AppLocker, IOC blacklisted
 3. Added to exception list
 4. Cannot run, blocked by Windows SmartScreen
 5. Bypass
 6. You have DMD 2.090 installed, replace it? Yes
 7. Failed, installer said run dmd-2.104.2.exe /f
 8. Looking in cpanel to see if I an older version of D is 
 installed. Nope.
 9. Found an old folder with D. Deleted it.
 10. Going to command prompt into downloads folder
 11. Running dmd-2.104.2.exe /f
 12. Error, an instance of DMD is already running.
 13. Looking through my processes, there is no such thing
 14. Running dmd-2.104.2.exe /f again. It works!
 15. You don't have VS Tools 2019 installed. I have. 2015, 2017, 
 2019 and 2022
 16. Ignore and go on.
 17. Launch VSCode
 18. Install code-d, C++ already installed
 19. Create a new project
 20. Run tasks - Run -> dub cannot be initialized
 21. Go to code.dlang.org
 22. Click on Download -> redirect to github/releases
 23. WTF, only source code.
 24. building Dub from source
 25. Added manually to PATH
 26. Go back to VSCode
 27. Edit dub.json, adding target ./bin/hello.exe
 28. Build Task, dub-auto - Run hello, ok
 29. Build Task, dub-auto - Build hello -> config -> edit 
 tasks.json
 30. Documentation says that I should have a dub template. Nope, 
 I have a CMake template.
 31. Too complicated. Close VSCode, posting on forum :)

 ----

 OK, I know, there is VisualD, but install process is still 
 complicated.


I am very surprised you had this many issues, I helped a coworker 
of mine who is not a programmer go through the installation and 
didnt have any problems, just normal installation stuff, like 
clicking on what you want installed etc.. I am going to install 
the latest version right now and see what the steps are again,
but to reiterate I did switch to a scripting language for my work 
because I didnt want to help like 10 people install D but I got 
my scripts down to zero installation which is always better than 
any installation. so until D is zero installation it can still 
get better.
Jul 21 2023
parent MrJay <mrjcraft2021 gmail.com> writes:
On Friday, 21 July 2023 at 18:33:07 UTC, MrJay wrote:

 I am very surprised you had this many issues, I helped a 
 coworker of mine who is not a programmer go through the 
 installation and didnt have any problems, just normal 
 installation stuff, like clicking on what you want installed 
 etc.. I am going to install the latest version right now and 
 see what the steps are again,
 but to reiterate I did switch to a scripting language for my 
 work because I didnt want to help like 10 people install D but 
 I got my scripts down to zero installation which is always 
 better than any installation. so until D is zero installation 
 it can still get better.


I just re installed D
this is all the necessary steps I took.
starting from the website home page, and downloads folder is 
already open.

on website click download windows installer
double click dmd-2.104.2.exe
windows warning do you want this to make changes
replace D version
next
uninstall
next
next
next
finish
Jul 21 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/20/23 12:22 PM, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after two years 
 to see how things evolved in the meantime.
 
 Here is my Windows experience:


I think you suffer from having already-installed D stuff, or some unique 
environment that the installer is tripping on. Probably some bug that 
can be filed there. Installing from scratch is usually easier.

However, I do agree that the Windows experience (especially including an 
IDE) could be more curated.

Here was my instructions for installing DMD/VSCode on Windows that I 
used for my homeschool class: https://codingcat.club/d_installation.html

I wish it was just "run this exe". to be fair, the DMD installer now 
asks you to install some version of Visual Studio, and I think even can 
work without it (wasn't true back when I wrote the instructions).


 OK, I know, there is VisualD, but install process is still complicated.


VisualD means you are willing to switch to that build system and not use 
dub. I've never used it because of that.

VSCode with code-d is a pretty good experience (except for debugging on 
Windows).

-Steve
Jul 22 2023
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Saturday, 22 July 2023 at 15:29:45 UTC, Steven Schveighoffer 
wrote:

 VisualD means you are willing to switch to that build system 
 and not use dub. I've never used it because of that.


Not a big deal, just run generate the projects with `dub generate 
visuald`, though I only rarely use it for most complex debugging 
cases because IIRC you have to modify project a bit after that, 
and also have to generate needed subpackages too.
Jul 23 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 22 July 2023 at 15:29:45 UTC, Steven Schveighoffer 
wrote:


 I think even can work without it (wasn't true back when I wrote 
 the instructions).


If true, that would be a good step forward. My memories of 
installing on Windows involved a petabyte of Visual Studio 
downloads followed by configuration issues that I didn't know or 
care to know how to fix.
Jul 23 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 24 July 2023 at 01:01:58 UTC, bachmeier wrote:

 On Saturday, 22 July 2023 at 15:29:45 UTC, Steven Schveighoffer 
 wrote:


 I think even can work without it (wasn't true back when I 
 wrote the instructions).


 If true, that would be a good step forward. My memories of 
 installing on Windows involved a petabyte of Visual Studio 
 downloads followed by configuration issues that I didn't know 
 or care to know how to fix.


dmd on Windows has never required Visual Studio, though the 
installer would really push you toward it since it was better for 
a while - more compatible 32 bit with other libraries and 64 bit 
linking support - but you didn't technically NEED those, and both 
of these are now supported by the bundle standing alone.

If you just take the dmd zip and use it in place, things just 
work.
Jul 23 2023
prev sibling next sibling parent user1234 <user12324 12.de> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 Long time D user here (from D1 era). I said to come back after 
 two years to see how things evolved in the meantime.

 Here is my Windows experience:

 1. Downloaded DMD installer.
 2. Cannot run, blocked by AppLocker, IOC blacklisted
 [...]
 30. Documentation says that I should have a dub template. Nope, 
 I have a CMake template.
 31. Too complicated. Close VSCode, posting on forum :)

 OK, I know, there is VisualD, but install process is still 
 complicated.


that's funny today I wanted to setup git on an account that's not 
admin:

![](https://i.imgur.com/EtS5tFB.png)

comon comon, the default path is C:\git on windows... that just 
cannot work for a secundary account.
Jul 24 2023
prev sibling parent IchorDev <zxinsworld gmail.com> writes:
On Thursday, 20 July 2023 at 16:22:47 UTC, Rumbu wrote:

 2. Cannot run, blocked by AppLocker, IOC blacklisted
 3. Added to exception list
 4. Cannot run, blocked by Windows SmartScreen


Gotta love Windows. /sarcasm


 5. Bypass
 6. You have DMD 2.090 installed, replace it? Yes
 7. Failed, installer said run dmd-2.104.2.exe /f


If you have BASH, you could use the installer script: 
https://dlang.org/install.html
I find it makes updating & installing multiple compilers pretty 
convenient, especially if you modify your BASH profile.


 27. Edit dub.json, adding target ./bin/hello.exe
 30. Documentation says that I should have a dub template. Nope, 
 I have a CMake template.


Maybe I'm misunderstanding but... you can use dub recipes 
(dub.json) *or* CMake. Not sure what dub's CMake support is like, 
  if indeed it has it.


 OK, I know, there is VisualD, but install process is still 
 complicated.


I don't like VisualD that much.
Jul 24 2023