On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote:
>
> You don't need to have subsystem for Linux to use bash.  Just the standard git client for Windows is enough.
>

Happy to find out about this. It's not like using git bash everyday on Windows to know this by default.

sh setup.sh
[...]
make -> Command error: undefined switch '-C'

On Monday, 12 March 2018 at 04:48:43 UTC, psychoticRabbit wrote:

>
> but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really.
>
> It's like comparing my local corner shop to some worldwide supermarket chain.
>

I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country.

I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself.

On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote:
>
> I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country.
>
> I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself.

yeah, but if you know in advance, that you need a fork lift to reach it, and that you'll also need two additional excavators running on a special kind of fuel, which is not available in your country...then..and only then.. are your expectations in line with reality ;-)

but people come to D, thinking they can just walk over to the shelf and take it.
(because that's often what they are used to).

Some of us are actually used to the very opposite - i.e you always have make that extra effort, even to do the most simple things. But that effort just seems normal to us.

I agree, there needs to be more middle ground, which both types will benefit from in the end.

On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:
> Now, I actually understand ranges and am very glad that they're there, but as a D newbie, they were annoying, because they were unfamiliar.

Ranges are D's monads. The only thing missing is the burrito tutorials.

On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:
> On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:
>> Now, I actually understand ranges and am very glad that they're there, but as a D newbie, they were annoying, because they were unfamiliar.
>
> Ranges are D's monads. The only thing missing is the burrito tutorials.

I always thought the best spice in D is UFCS. If only there would be one for local symbols (but that needs either foundation's decision or I need to write my first DIP and do something instead of just crying silently into my sleeve). I really found few usages for that, like using methods of class on data types that stored inside ranges inside that class. Image data being glued to each other in different lists like data in SQL among tables. Not like an show stopper, but after I rewrote part of my application into D - a lot of stuff become so much more elegant and easy to read and maintain. UFCS would help with readability in cases like I had tons.

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:
> What could be done from your perspective to make the setup easier?

(This is from the perspective of a novice programmer, who hasn't really interacted with open source projects much)

When I first tried to compile dmd+druntime+phobos quite a while ago, I found the information on the wiki about building on windows[1] pretty unhelpful (in fact I never managed get all 3 to compile properly), though that seems to have gotten a lot better now (especially that it tells you how to structure your directories, which from what I remember you just had to piece together and guess from what the wiki commands were doing originally). Luckily the two contributions I made back then didn't require me to actually have any of that working...

As a spoiled Windows user, I like convenience, and I like things being easy to do. For me, trying to simply build everything was a frustrating task that took up a few days of time (reminder, this *was* quite a bit ago before the Windows part of the wiki was updated, and I was/still am pretty new to working on projects that aren't my own).

One of the more frustrating yet annoyingly simple issues I was having was that the version of Make in my PATH (GNU Make at a guess) wasn't able to use win32.mak, which led to me getting confused and frustrated for a day or two before I figured out(can't remember how exactly) that I had to use Digital Mars' make... I don't think there's any clear text on the wiki that says "For Windows, you *need* to use Digital Mars' make to use win32.mak".

After I changed to using Digital Mars' Make, I ran into another annoying but very simple issue. The wiki says to use "make -fwin32.mak release", ok fine:
```
PS D:\Coding\D\Tools\dlang\dmd2\src\dmd\src> make -fwin32.mak release
Error: can't read makefile 'win32'
```

Turns out all I had to do was put a space between '-f' and 'win32.mak'. Thankfully I only wasted about 30mins at most figuring that out. Didn't make it any less frustrating though.

Around the time I was adding std.traits.isCopyable to Phobos, I thought to myself "Maybe I can at least get the testing stuff to work!"... So I go to the wiki and see something along the lines of "make -fposix.mak std/traits.test" and thought that win32.mak would have the same functionality - however it doesn't, and only has a target to unittest the entirety of Phobos, giving me the impression Windows seems to just be a footnote compared to Posix platforms. ('make -f win32.mak dscanner' is another example). For isCopyable, it was easier for me to just develop it in it's own file, move it into std.traits, and hope the auto-tester could build it.

I think I did manage to get "make -f win32.mak unittest" (for phobos) to work at one point, but a test that included sockets failed (I think it was a test between paired sockets, and one of them timed out). This of course made it feel pointless to use, since it'd just always fail.

One last example of a very tiny issue, is that for DMD, the makefiles you use to build it are in, for example 'dmd2/src/dmd/src/win32.mak', instead of 'dmd2/src/dmd/win32.mak' making it a bit inconsistent with druntime('dmd2/src/druntime/win32.mak') and phobos('dmd2/src/phobos/win32.mak').

There were certainly a bunch more tiny issues and bumps I had when trying to build things my first time around that I can't remember, whether it be due to my own incompetency or due to issues with the wiki/win32.mak, and after the two changes I made to Phobos I just had no will to continue, and gave up for a while.

I genuinely feel it'd have been easier for me to just load up Ubuntu on a VM and go from there, instead of developing on Windows.

One thing I'd would have liked, as a Windows/lazy user, and as a beginner, is a single file/tool that would've helped me setup and build everything (like that setup.sh you linked, except it's a Bash script...)

And in a perfect world, we wouldn't need 3 different makefiles (win32.mak, win64.mak, and posix.mak), but instead there'd either be a single makefile, or some other tool is used to provide a cross-platform way to access the current features of posix.mak. I understand that this isn't an easy issue to solve though, hence the "in a perfect world" (you could also say, in a perfect world, everyone develops on a Posix platform! ;)).

Then I recently gathered up the will to want to contribute again, and decided to make a Powershell script that does exactly that for me which actually turned out to work pretty well, I can build all 3 projects without too much hassle, and without having to remember all those annoying pitfalls e.g. "-f win32.mak instead of -fwin32.mak", something I would've liked to have in the first place. Or so I thought.

I wanted to try and add some colouring[2] to dmd's error messages (sounds easy enough right?), so I have a quick look and see all I need to do is add some backticks around certain parts of the error message[3, as an example]. So I add my backticks into one error I can easily trigger, build it using my powershell script, and then all I see is that an exception (I think it was actually a RangeError) was thrown, and the stack trace was just a bunch of addresses without any text. (I don't have that build of dmd.exe anymore, and most of dmd has been colourised by now, so I can't get an accurate copy-paste of what happened or try to reproduce it.)

I decided "that's not supposed to happen", and tried to colourise a few other error messages... but I got the exact same result. I try to take an already coloursised error message, copy and paste it to another file, and try again to no avail.

At that point I decided that it's probably yet another issue with my build environment that I'll have to try an work out, but if I can't even get something 'trivial' such as colouring in messages working without frustration, then I can't be bothered to put in any more effort with trying to do anything else (I'd rather not be stuck only being able to do documentation changes), since, at least in my experience, I'm probably just too inexperienced, and I just keep hitting road blocks and endless frustrations.

I have a lot of free time, and I have a lot of love for this language, but when I struggle to get _anything_ to work (and also struggle to find something I'm actually capable of trying to do, I find Bugzilla a bit hard to use) then it makes me demotivated. Maybe I'm missing something, maybe I'm just an idiot, maybe the wiki is incorrect, etc. There's clearly _something_ wrong with what I'm doing, but I can't bring myself to try and figure out what anymore (I say that, but I know full well I'll shortly want to try again, and again, and again, until I can finally help out with dlang ;( ). I'd like to note that the process of submitting the PRs didn't make me run into any issue (though, the changes were really simple, so I doubt there was much room for something to stop them)

This post may not be all that helpful, but I feel the need to voice the frustrations with my experience. Sorry for the pointless/off-topic rant.

[1] https://wiki.dlang.org/Building_under_Windows
[2] https://github.com/dlang/dmd/projects/2
[3] https://github.com/dlang/dmd/pull/7781/files

On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
> This post may not be all that helpful, but I feel the need to voice the frustrations with my experience. Sorry for the pointless/off-topic rant.

Thank you for this post, I found this actually really insightful. I'm also (relatively) inexperienced, a Windows user, and I have time/motivation for contributing. Your post is very relatable to me. But while you actually tried to compile dmd, I kind of pushed it aside after seeing how much there is involved in setting it up, predicting a big hassle like you describe. I really wish it could be as simple as cloning the repository and running a command on Windows.

On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
> I wanted to try and add some colouring[2] to dmd's error messages (sounds easy enough right?), so I have a quick look and see all I need to do is add some backticks around certain parts of the error message[3, as an example]. So I add my backticks into one error I can easily trigger, build it using my powershell script, and then all I see is that an exception (I think it was actually a RangeError) was thrown, and the stack trace was just a bunch of addresses without any text. (I don't have that build of dmd.exe anymore, and most of dmd has been colourised by now, so I can't get an accurate copy-paste of what happened or try to reproduce it.)
>
> I decided "that's not supposed to happen", and tried to colourise a few other error messages... but I got the exact same result. I try to take an already coloursised error message, copy and paste it to another file, and try again to no avail.
>
> At that point I decided that it's probably yet another issue with my build environment that I'll have to try an work out, but if I can't even get something 'trivial' such as colouring in messages working without frustration, then I can't be bothered to put in any more effort with trying to do anything else (I'd rather not be stuck only being able to do documentation changes), since, at least in my experience, I'm probably just too inexperienced, and I just keep hitting road blocks and endless frustrations.

If all you did was adding backticks to error messages, you might have been hitting issue 18403 [1]. That bug caused Windows DMD to crash whenever it tried printing a colored error message. It's very possible that you did nothing wrong, and you just had bad luck.

When you can't make sense of something like that, posting here in the forum is often worthwhile (Learn or General, though; not Announce). It's still pretty common that newcomers find bugs. More experienced members of the community can help determine if you're hitting one. If it's not a bug, they can help fixing things on your end.


[1] https://issues.dlang.org/show_bug.cgi?id=18403

On Monday, 12 March 2018 at 19:09:42 UTC, Dennis wrote:
> On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
>> This post may not be all that helpful, but I feel the need to voice the frustrations with my experience. Sorry for the pointless/off-topic rant.
>
> Thank you for this post, I found this actually really insightful. I'm also (relatively) inexperienced, a Windows user, and I have time/motivation for contributing. Your post is very relatable to me. But while you actually tried to compile dmd, I kind of pushed it aside after seeing how much there is involved in setting it up, predicting a big hassle like you describe. I really wish it could be as simple as cloning the repository and running a command on Windows.

hey... I have 25+ years experience as a systems administator.

i.e I'm very, very used to doing very complex things. complex, is my day at the office.

But even I couldn't get my head around how to compile D from source on Windows ;-)

I do have it compling just fine on my freebsd system, and multiple different linux's I use. But Windows? Forget it. Someone will need to explain in detail how that is actually done - I no longer have the patience for working that one out.

On Tuesday, 13 March 2018 at 01:23:39 UTC, psychoticRabbit wrote:
> hey... I have 25+ years experience as a systems administator.
>
> i.e I'm very, very used to doing very complex things. complex, is my day at the office.
>
> But even I couldn't get my head around how to compile D from source on Windows ;-)
>
> I do have it compling just fine on my freebsd system, and multiple different linux's I use. But Windows? Forget it. Someone will need to explain in detail how that is actually done - I no longer have the patience for working that one out.

As a counterpoint, I _did_ manage to compile DMD, Phobos and Druntime on Windows as a lowly university student using only the instructions from the wiki, and I'm no genius. It _is_ possible and not very difficult as long as you follow the instructions to the letter.

Of course this was also before you needed to have HOST_DC defined in your path, and the repo layout was a bit different, but it's not an insurmountable problem. And if you run into problems, you can come here or go on IRC to ask for help.