www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D for Game Development

reply "karabuta" <karabutaworld gmail.com> writes:
D is really cool and makes a good candidate for developing a 
game. Are there any guys out there using D for indie games?

For some time I have been seeing some cool game engine being 
developed in the DUB repo. What more is happening? I don't see 
derelictSDl and derelictSFML activities much. Whatup?
Jul 30 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


GC's up.
Jul 30 2015
next sibling parent reply "Minas Mina" <minas_0 hotmail.co.uk> writes:
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


I was thinking of using D for my game server (which is in C++ at 
the moment)... is the gc going to be such an issue? I know of 
 nogc but I also do know that some stuff needs gc, e.g strings 
and exceptions.

 From the things I read on this forum, it seems work is being done 
to make exceptions not use the gc. How is that moving along;
Jul 30 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 July 2015 at 14:12:32 UTC, Minas Mina wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 I was thinking of using D for my game server (which is in C++ 
 at the moment)... is the gc going to be such an issue? I know 
 of  nogc but I also do know that some stuff needs gc, e.g 
 strings and exceptions.

 From the things I read on this forum, it seems work is being 
 done to make exceptions not use the gc. How is that moving 
 along;


The good thing with D is that you can avoid the GC for the most 
part. So If you think that make sense for your project, go for 
it. It can work and I even think this is a good choice.

But the GC in its current form is not very good, so avoid it.
Jul 30 2015
prev sibling next sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


Minecraft, written in java which has a GC does perfectly fine.

A GC is not a reason a game cannot be developed.

Look at how many browser-based games there are, which use a GC 
somewhere from the interpreted Flash or JS.
Jul 30 2015
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


Minecraft is a dog though ... I always have to kill my kids 
ongoing game
if I ever want to do any real work on the same machine.
Jul 30 2015
next sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 14:44:30 UTC, CraigDillabaugh wrote:

 On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland 
 wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


 Minecraft is a dog though ... I always have to kill my kids 
 ongoing game
 if I ever want to do any real work on the same machine.


It's a dog because Java is a dog. But that's not because of the 
GC.

It's not really that bad either, I can open up Minecraft at any 
time and have it sit in the background quietly using ~800Mb ram 
and virtually no cpu time.

Either your kid has tons of mods in their Minecraft or your 
computer is a bit dated.
Jul 30 2015
next sibling parent "Alex Parrill" <initrd.gz gmail.com> writes:
On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland wrote:

 It's a dog because Java is a dog. But that's not because of the 
 GC.

 It's not really that bad either, I can open up Minecraft at any 
 time and have it sit in the background quietly using ~800Mb ram 
 and virtually no cpu time.


It's mostly because, in Java, every one of those tiny immutable 
`(x,y,z)` tuples and vectors have to be allocated on the heap.

D is nice because you can allocate such small things on the 
stack, but it also doesn't have a massively optimized collector 
either.


 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


Tons of mods is the only way I can (or more accurately, can't) 
play MC anymore.
Jul 30 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland wrote:

 It's a dog because Java is a dog. But that's not because of the 
 GC.

 It's not really that bad either, I can open up Minecraft at any 
 time and have it sit in the background quietly using ~800Mb ram 
 and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


Now compare that kind of resources consumption with any game 
based on Quake III engine. While you are at it, compare the 
graphisms. Still not convinced ? Measure latencies, which are 
critical for most games.
Jul 30 2015
next sibling parent reply =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


Heh, what about the original Quake or Unreal? Both ran quite well 
on a Pentium 100 with 16MB of RAM. Not sure if memory is serving 
me right, but I suspect the amount of visible triangles per scene 
in Quake 1 can be comparable to that of Minecraft's, except it 
was released almost 20 years ago... I think I was able to run it 
on my 486 with 8MB of RAM, though it was more of a slideshow than 
a game, even with minimum viewport size, but still!
Jul 30 2015
parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 22:39:38 UTC, Márcio Martins wrote:

 On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


 Heh, what about the original Quake or Unreal? Both ran quite 
 well on a Pentium 100 with 16MB of RAM. Not sure if memory is 
 serving me right, but I suspect the amount of visible triangles 
 per scene in Quake 1 can be comparable to that of Minecraft's, 
 except it was released almost 20 years ago... I think I was 
 able to run it on my 486 with 8MB of RAM, though it was more of 
 a slideshow than a game, even with minimum viewport size, but 
 still!


Are you kidding me? Visible triangles in Quake 1 was sub 2,000.

Visible triangles in a "far" render mode on Minecraft tops over 
200,000.

Please don't make such a statement without looking. Each 
minecraft block is 16 triangles. Multiply that by however many 
blocks you have, and you'll see that number sky-rockets.
Jul 30 2015
prev sibling next sibling parent "lobo" <swamplobo gmail.com> writes:
On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


The OP is talking about indie games not AAA blockbusters.

In general D is great for writing indie games, you just need to 
be aware that the GC is not the best and use  nogc where 
possible. It's not difficult and probably less overhead than 
writing the same code in C++.

As for the Java GC, well Minefcraft does very well and has 
millions of happy blockheads playing it.

bye,
lobo
Jul 30 2015
prev sibling next sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


Again,

People see minecraft as "terrible graphics, pixellated" but each 
block represents 16 triangles, and there could be thousands of 
blocks on screen. You're easily looking at 200,000 triangles on 
"far" render mode.

Then you have folks who use 512x512 mapped images per block, so 
now you have a HUGE textel density.

People need to get their facts straight. I don't like Minecraft, 
but by no means in Minecraft some amateur game from 1990s running 
terribly on a computer.

That game is every bit as CPU intensive as a modern game, though 
it looks like trash at first.

Granted, it's by far not written well, but even for poorly 
written code, it performs better than I could have ever expected.
Jul 30 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Friday, 31 July 2015 at 03:29:59 UTC, Brandon Ragland wrote:

 People see minecraft as "terrible graphics, pixellated" but 
 each block represents 16 triangles


I really hope they don't render a block with 16 triangles.


 and there could be thousands of blocks on screen. You're easily 
 looking at 200,000 triangles on "far" render mode.


Look up triangles/sec on modern video cards, you'll be surprised.


 Then you have folks who use 512x512 mapped images per block, so 
 now you have a HUGE textel density.

 People need to get their facts straight. I don't like 
 Minecraft, but by no means in Minecraft some amateur game from 
 1990s running terribly on a computer.


Compared to real games, it is.
Aug 02 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2015 1:51 a.m., Sebastiaan Koppe wrote:

 On Friday, 31 July 2015 at 03:29:59 UTC, Brandon Ragland wrote:


snip


 People need to get their facts straight. I don't like Minecraft, but
 by no means in Minecraft some amateur game from 1990s running terribly
 on a computer.


 Compared to real games, it is.


Some of things that goes on in the modding world is truely amazing.
I can't find the tweets about it from  pahimar. But:
For every item/block with a recipe and vanilla items/blocks hardcoded. 
It'll calculate at the start of runtime an EMC value in EE3. It does it 
ridiculously fast.

He did an amazing job of optimizing it. I generally believe that we 
probably couldn't even match it in D.

Unfortunately Vanilla Minecraft is quite a dog still, but getting better 
slowly. Even with the mass breakages of mods in the mean time.
Aug 02 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:

 Some of things that goes on in the modding world is truely 
 amazing.

 For every item/block with a recipe and vanilla items/blocks 
 hardcoded. It'll calculate at the start of runtime an EMC value 
 in EE3. It does it ridiculously fast.


I understand absolutely nothing about it.
Aug 02 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:

 On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:

 Some of things that goes on in the modding world is truely amazing.

 For every item/block with a recipe and vanilla items/blocks hardcoded.
 It'll calculate at the start of runtime an EMC value in EE3. It does
 it ridiculously fast.


 I understand absolutely nothing about it.


I'll try my best to explain it.

- An item/block may or may not have a crafting recipe, it may have many 
or uses a non crafting mechanism to create
- There could be 200k-400k+ blocks and items per modded instance
- Each item/block may have an "EMC" value which is 1 .. int.max
- The EMC value is calculated based upon the crafting recipes and all 
items/blocks that makes it up EMC values
- Vanilla blocks/items have hard coded EMC values
- Optionally other mods items/blocks may be required to have their 
values hard coded so the calculation can work
- Back in EE2 it was all hard coded
- In EE3 very few are hard coded

The usage of the EMC value doesn't really matter. What does matter is 
that these calculations occur at the start of runtime. If this was 
poorly written this would have massive performance problems.
Aug 02 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Monday, 3 August 2015 at 03:28:26 UTC, Rikki Cattermole wrote:

 On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:

 On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole 
 wrote:

 Some of things that goes on in the modding world is truely 
 amazing.

 For every item/block with a recipe and vanilla items/blocks 
 hardcoded.
 It'll calculate at the start of runtime an EMC value in EE3. 
 It does
 it ridiculously fast.


 I understand absolutely nothing about it.


 I'll try my best to explain it.

 - There could be 200k-400k+ blocks and items per modded instance


I don't understand why there are so many. Once you calculated the 
EMC for each block -or item-type, you have them all, no?
Aug 02 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2015 6:53 p.m., Sebastiaan Koppe wrote:

 On Monday, 3 August 2015 at 03:28:26 UTC, Rikki Cattermole wrote:

 On 3/08/2015 1:35 p.m., Sebastiaan Koppe wrote:

 On Sunday, 2 August 2015 at 14:03:50 UTC, Rikki Cattermole wrote:

 Some of things that goes on in the modding world is truely amazing.

 For every item/block with a recipe and vanilla items/blocks hardcoded.
 It'll calculate at the start of runtime an EMC value in EE3. It does
 it ridiculously fast.


 I understand absolutely nothing about it.


 I'll try my best to explain it.

 - There could be 200k-400k+ blocks and items per modded instance


 I don't understand why there are so many. Once you calculated the EMC
 for each block -or item-type, you have them all, no?


200k-400k does sound a lot, but it really isn't.
There is a 'standard' mod called forge multi part. Basically for every 
block it adds a rather large amount more. It's at the very least *10 the 
real number of blocks.
There are other mods that do similar but different things like this.

Here is an old video from Direworld20 that should help you understand[0].

Also keep in mind dependencies between blocks and items for crafting 
recipes.

For the Agrarian Skies2 mod pack, it has roughly 4*13*499 items/blocks. 
Based upon what was visible from NEI.

I did have block+item dump here, but ugh too big for NNTP server.

The lists only total 6145 but based upon NEI it would be closer to 
25948. So obviously there are many many things not included in the item 
+ block dumps. Things like multiparts are not listed by the looks.
FYI Agrarian Skies is a themed mod pack that was not designed for 
fanciness so e.g. no extra "cool" blocks. Other packs like Direwolf20 
would have much more massive numbers. After all there is a reason why 
Mojang shifted from a number to identify blocks and items to strings. 
Mods were using them up a little too much[1].

[0] https://www.youtube.com/watch?v=u9yUr4jmU6s
[1] http://forum.feed-the-beast.com/threads/4096-and-beyond.20774/
Aug 03 2015
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


People always compare things to Minecraft when discussing if 
garbage collection is feasible in a game. Which is annoying, 
because I'm sure Minecraft's allocations would make most people 
sad. It's not a fair comparison.

Some quotes:
"Minecraft 1.8 has so many performance problems that I just don't 
know where to start with. Maybe the biggest and the ugliest 
problem is the memory allocation. Currently the game allocates 
(and throws away immediately) 50 MB/sec when standing still and 
up to 200 MB/sec when moving. That is just crazy."

But that was just a one off thing for 1.8 I believe, the normal 
is much better:
"How did that work in previous releases? The previous Minecraft 
releases were much less memory hungry. The original Notch code 
(pre 1.3) was allocating about 10-20 MB/sec which was much more 
easy to control and optimize."

10-20 MB of garbage every second. That's just ridiculous to think 
of in a language like D. And that was long ago, it's probably 
worse now. Luckily D has things like ranges and other ways of 
improving this.

Source: 
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272953-1-8-7-optifine-hd-d6-fps-boost-hd-textures-aa-af?page=2111#c43757
Jul 31 2015
next sibling parent reply "Brandon Ragland" <brandon callmemaybe.com> writes:
On Friday, 31 July 2015 at 21:40:51 UTC, Kapps wrote:

 On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland 
 wrote:

 It's a dog because Java is a dog. But that's not because of 
 the GC.

 It's not really that bad either, I can open up Minecraft at 
 any time and have it sit in the background quietly using 
 ~800Mb ram and virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your 
 computer is a bit dated.


 Now compare that kind of resources consumption with any game 
 based on Quake III engine. While you are at it, compare the 
 graphisms. Still not convinced ? Measure latencies, which are 
 critical for most games.


 People always compare things to Minecraft when discussing if 
 garbage collection is feasible in a game. Which is annoying, 
 because I'm sure Minecraft's allocations would make most people 
 sad. It's not a fair comparison.

 Some quotes:
 "Minecraft 1.8 has so many performance problems that I just 
 don't know where to start with. Maybe the biggest and the 
 ugliest problem is the memory allocation. Currently the game 
 allocates (and throws away immediately) 50 MB/sec when standing 
 still and up to 200 MB/sec when moving. That is just crazy."

 But that was just a one off thing for 1.8 I believe, the normal 
 is much better:
 "How did that work in previous releases? The previous Minecraft 
 releases were much less memory hungry. The original Notch code 
 (pre 1.3) was allocating about 10-20 MB/sec which was much more 
 easy to control and optimize."

 10-20 MB of garbage every second. That's just ridiculous to 
 think of in a language like D. And that was long ago, it's 
 probably worse now. Luckily D has things like ranges and other 
 ways of improving this.

 Source: 
 http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272953-1-8-7-optifine-hd-d6-fps-boost-hd-textures-aa-af?page=2111#c43757


The point is that because Minecraft does such a shoddy job at any 
kind of memory allocation, optimization, or conservation, the GC 
has a lot more to handle, and is abused quite regularly due to 
Mojang's lack of any real world coding experience it seems.

The point of the comparison is this:

If Minecraft, which is terrible, can do it with a GC, then why 
can't a *well* made D game work even better.

I'm not defending Minecraft in any way shape or form, I'm 
actually defending the JVM GC.

Minecraft is terribly designed and mad,e and uses excessive 
amounts of resources partially just based on it's design. A whole 
bunch of "blocks" yes "blocks" represent 12 outer triangles and 
on diagonal triangle through the center. The stairs, etc. that 
the game has represents even more tris.

So if you have:

* A game which regularly renderings in excess of 200,000 trs per 
frame
* A game with terrible optimizations (if any....)
* A game based on Java with a GC

And it can still pull 30FPS on my cruddy 8 year old Gateway, than 
a GC is NOT the reason to NOT use the D language.

If anything, you should take the lessons from Minecraft and do it 
*better* in D and you'll have much much better resource 
allocation, usage, and far less GC abuse.

-Peace
Aug 01 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 2/08/2015 11:15 a.m., Brandon Ragland wrote:

 On Friday, 31 July 2015 at 21:40:51 UTC, Kapps wrote:

 On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland wrote:

 It's a dog because Java is a dog. But that's not because of the GC.

 It's not really that bad either, I can open up Minecraft at any time
 and have it sit in the background quietly using ~800Mb ram and
 virtually no cpu time.

 Either your kid has tons of mods in their Minecraft or your computer
 is a bit dated.


 Now compare that kind of resources consumption with any game based on
 Quake III engine. While you are at it, compare the graphisms. Still
 not convinced ? Measure latencies, which are critical for most games.


 People always compare things to Minecraft when discussing if garbage
 collection is feasible in a game. Which is annoying, because I'm sure
 Minecraft's allocations would make most people sad. It's not a fair
 comparison.

 Some quotes:
 "Minecraft 1.8 has so many performance problems that I just don't know
 where to start with. Maybe the biggest and the ugliest problem is the
 memory allocation. Currently the game allocates (and throws away
 immediately) 50 MB/sec when standing still and up to 200 MB/sec when
 moving. That is just crazy."

 But that was just a one off thing for 1.8 I believe, the normal is
 much better:
 "How did that work in previous releases? The previous Minecraft
 releases were much less memory hungry. The original Notch code (pre
 1.3) was allocating about 10-20 MB/sec which was much more easy to
 control and optimize."

 10-20 MB of garbage every second. That's just ridiculous to think of
 in a language like D. And that was long ago, it's probably worse now.
 Luckily D has things like ranges and other ways of improving this.

 Source:
 http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1272953-1-8-7-optifine-hd-d6-fps-boost-hd-textures-aa-af?page=2111#c43757


 The point is that because Minecraft does such a shoddy job at any kind
 of memory allocation, optimization, or conservation, the GC has a lot
 more to handle, and is abused quite regularly due to Mojang's lack of
 any real world coding experience it seems.

 The point of the comparison is this:

 If Minecraft, which is terrible, can do it with a GC, then why can't a
 *well* made D game work even better.

 I'm not defending Minecraft in any way shape or form, I'm actually
 defending the JVM GC.

 Minecraft is terribly designed and mad,e and uses excessive amounts of
 resources partially just based on it's design. A whole bunch of "blocks"
 yes "blocks" represent 12 outer triangles and on diagonal triangle
 through the center. The stairs, etc. that the game has represents even
 more tris.


Notch has said previously, if he had known Minecraft was going to become 
a hit like it was, he would have made it in C++. It was never made to be 
performant unfortunately.


 So if you have:

 * A game which regularly renderings in excess of 200,000 trs per frame
 * A game with terrible optimizations (if any....)


In the last few releases Mojang has been rewriting large portions of 
Minecraft for the purpose of performance optimization. E.g. thread friendly.
It's broken mods ridiculously every single release.


 * A game based on Java with a GC

 And it can still pull 30FPS on my cruddy 8 year old Gateway, than a GC
 is NOT the reason to NOT use the D language.

 If anything, you should take the lessons from Minecraft and do it
 *better* in D and you'll have much much better resource allocation,
 usage, and far less GC abuse.

 -Peace
Aug 01 2015
prev sibling parent "rsw0x" <anonymous anonymous.com> writes:
On Friday, 31 July 2015 at 21:40:51 UTC, Kapps wrote:

 On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote:

 [...]


 People always compare things to Minecraft when discussing if 
 garbage collection is feasible in a game. Which is annoying, 
 because I'm sure Minecraft's allocations would make most people 
 sad. It's not a fair comparison.

 [...]


This is because of java's lack of stack allocation AFAIK. Lots of 
small objects that are created and quickly thrown away(like you'd 
see in a game) creates intense GC pressure.
Aug 01 2015
prev sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 30 July 2015 at 14:44:30 UTC, CraigDillabaugh wrote:

 On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland 
 wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


 Minecraft is a dog though ... I always have to kill my kids 
 ongoing game
 if I ever want to do any real work on the same machine.


This is because of java

most allocations in D are on the stack, not the heap. Java has no 
concept of stack allocations outside of basic types.

Furthermore, more often than not allocations in D on the heap 
contain no pointers/references at all(>60% of all allocated 
memory in nearly every D program I tested that wasn't optimized 
to not use the GC contained no pointers/references.) and AFAIK 
the current GC makes no use of this fact.
Aug 01 2015
parent reply "thedeemon" <dlang thedeemon.com> writes:
On Sunday, 2 August 2015 at 05:03:34 UTC, rsw0x wrote:

 Furthermore, more often than not allocations in D on the heap 
 contain no pointers/references at all (>60% of all allocated 
 memory in nearly every D program I tested that wasn't optimized 
 to not use the GC contained no pointers/references.) and AFAIK 
 the current GC makes no use of this fact.


Of course it does: memory allocated for data without pointers is 
not scanned (see core.memory.BlkAttr.NO_SCAN). It has been this 
way for ages.
Aug 01 2015
parent "rsw0x" <anonymous anonymous.com> writes:
On Sunday, 2 August 2015 at 06:25:34 UTC, thedeemon wrote:

 On Sunday, 2 August 2015 at 05:03:34 UTC, rsw0x wrote:

 Furthermore, more often than not allocations in D on the heap 
 contain no pointers/references at all (>60% of all allocated 
 memory in nearly every D program I tested that wasn't 
 optimized to not use the GC contained no pointers/references.) 
 and AFAIK the current GC makes no use of this fact.


 Of course it does: memory allocated for data without pointers 
 is not scanned (see core.memory.BlkAttr.NO_SCAN). It has been 
 this way for ages.


Partially correct.

If you compare the amount of memory allocated by the GC that is 
marked NO_SCAN compared to passing precise type information with 
the allocation many, many allocations that are without 
pointers/references are not marked NO_SCAN.
Aug 02 2015
prev sibling next sibling parent "karabuta" <karabutaworld gmail.com> writes:
On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


I totally agree with you. Most people think of games as a life 
support system. Even MMO RPG games are able to scale with all the 
latency problems. And GC in D is not even much of an issues when 
compared to others like ..you know. But they are used for game 
development.
Jul 30 2015
prev sibling parent reply "Minas Mina" <minas_0 hotmail.co.uk> writes:
On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


Not really.
http://www.minecraftforum.net/forums/support/server-support/server-administration/1916245-garbage-collection-issues-help-with-java

Look it up in google.
Jul 30 2015
next sibling parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Thursday, 30 July 2015 at 15:23:18 UTC, Minas Mina wrote:

 On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland 
 wrote:

 On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't 
 see derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


 Minecraft, written in java which has a GC does perfectly fine.

 A GC is not a reason a game cannot be developed.

 Look at how many browser-based games there are, which use a GC 
 somewhere from the interpreted Flash or JS.


 Not really.
 http://www.minecraftforum.net/forums/support/server-support/server-administration/1916245-garbage-collection-issues-help-with-java

 Look it up in google.


First: That doesn't reflect the majority of users, and is an 
isolated case.

Second: That doesn't prove anything about GC in general. Perhaps 
they were using an out-dated Java version, or one of their 
plugins was hogging things up.

Garbage collection is a non-issue even in most video games. 
Minecraft is an *extreme* case because minecraft has tons and 
tons of user variables to take into account, such as the 
thousands of blocks users place, and all the entities that 
wouldn't be an issue in say, an FPS or MMO RPG game.

If anything, Minecraft is an example of how well GC can work, 
even when the program itself is seriously abusing the heap and 
dynamic memory allocation.
Jul 30 2015
prev sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
Everyone always references Minecraft, but that's not the only 
Java game out there. There are quite a few on Steam. You'll never 
even know they're Java if you don't follow their development, as 
they ship with a bundled JRE. The Java games that perform poorly 
or hog resources are always held up as an example of why Java is 
a dog or why GC for games is a problem, but then the ones that 
perform well don't even become part of the conversation.

Experienced Java game developers know how to code to the GC and 
tune their apps to maximize performance. There's quite a lot of 
knowledge tucked away in the posts at java-gaming.org, where 
they've shared their experience and their games. The GC itself is 
not a deal breaker, nor is the Java language. People prove it 
every day.

The same can be true of D. When enough D experience has been 
accumulated and shared, people will be writing games that take 
the GC into account. There's no reason to avoid it completely. It 
can be made to work for you. Even today, games in C and C++ focus 
on minimizing allocations, using the stack as much as possible 
and setting aside as much heap memory up front as they can. Given 
that collections in D only run during allocations, there's no 
reason why that same strategy won't work in D. It's all about 
strategy and profiling, finding what hurts performance and 
learning how to avoid it.
Jul 30 2015
parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
Using C code from D is actually a fairly straightforward to do, all
you need to do is write a D version of the function signature you want
to call and tell D to mangle it as a C function eg extern(C) { int
SDL_Init(uint flags); } now you just need to tell the linker to link
in libsdl and you are ready to go.

I have personally found Derelict adds too much complexity and breaks
too often for my liking.

If you want to play with a cross platform game engine with D bindings
you could look at https://github.com/TurkeyMan/fuji


On Fri, Jul 31, 2015 at 11:53 AM, Mike Parker via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Everyone always references Minecraft, but that's not the only Java game out
 there. There are quite a few on Steam. You'll never even know they're Java
 if you don't follow their development, as they ship with a bundled JRE. The
 Java games that perform poorly or hog resources are always held up as an
 example of why Java is a dog or why GC for games is a problem, but then the
 ones that perform well don't even become part of the conversation.

 Experienced Java game developers know how to code to the GC and tune their
 apps to maximize performance. There's quite a lot of knowledge tucked away
 in the posts at java-gaming.org, where they've shared their experience and
 their games. The GC itself is not a deal breaker, nor is the Java language.
 People prove it every day.

 The same can be true of D. When enough D experience has been accumulated and
 shared, people will be writing games that take the GC into account. There's
 no reason to avoid it completely. It can be made to work for you. Even
 today, games in C and C++ focus on minimizing allocations, using the stack
 as much as possible and setting aside as much heap memory up front as they
 can. Given that collections in D only run during allocations, there's no
 reason why that same strategy won't work in D. It's all about strategy and
 profiling, finding what hurts performance and learning how to avoid it.
Jul 30 2015
prev sibling parent reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


 GC's up.


Regarding D's GC and Games written in D you can also take a look 
at a old project of mine and the results that came out of it.

http://3d.benjamin-thaut.de/?p=20

Kind Regards
Benjamin Thaut
Aug 05 2015
parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote:

 Regarding D's GC and Games written in D you can also take a 
 look at a old project of mine and the results that came out of 
 it.

 http://3d.benjamin-thaut.de/?p=20


Towards the end you list some performance and memory leaking 
issues in D. Have you seen improvement in these areas?
Aug 05 2015
parent reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:

 On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut 
 wrote:

 Regarding D's GC and Games written in D you can also take a 
 look at a old project of mine and the results that came out of 
 it.

 http://3d.benjamin-thaut.de/?p=20


 Towards the end you list some performance and memory leaking 
 issues in D. Have you seen improvement in these areas?



- Comparision of TypeInfo objects in druntime is done by building 
two strings and then comparing those two strings. This will 
always leak memory and do a lot of unneccesary allocations which 
are a performance bottleneck. I reworte the comparison so it does 
not allocate a single byte.

I did a pull request to improve this once, but it was rejected. 
So this issue still remains. Comparing two type info objects 
still produces garbage.

- Calls to the druntime invariant handler are emitted in release 
build also and there is no way to turn them off. Even if the 
class does not have any invariants the invariant handler will 
always be called, walk the class hirarchy and generate multiple 
cache misses without actually doing anything.

Afaik this has been fixed.

- The new statement will not free any memory if the constructor 
throws a exception. So you are forced to replace both the new and 
the delete statement. But you can not replace the new statement 
with similar nice syntax especially for inner classes and arrays.

This issue still remains, although might improve soon with 
std.allocator. The language is not designed to make it possible 
for new/delete to be replaced in a nice way so most likely

new int[3] will become allocator.makeArray!int(3)

- Inlining of DMD. Inlining of DMD seems to be very minimal. Most 
of my overloaded operators are not inlined by dmd at all.

This somewhat improved, especially with pragma(inline) but dmd is 
still really bad at inlining and I still can't compile all my 
projects with the -inline switch because dmd produces invalid 
function calls if I do so. And don't tell me to use a different 
compiler, on windows the only viable option still is dmd. Gdc for 
windows is no longer maintained and ldc is not there yet (but 
might be soon).

- Array literals. They always allocate, even if they don’t have 
to. For example when asiging to a fixed size array, or when 
passing to a function with a scope parameter.

This greatly improved. Thanks to Kenji you can now have non 
allocating array literals.

- D-Style variadic functions. Same as array literals, because 
internaly they are rewrote to one. Especially for these kind of 
functions I don’t see any reason why they should allocate on the 
heap.

I'm not sure about this one, I would have to investigate.

Kind Regards
Benjamin Thaut
Aug 06 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 August 2015 at 11:18, Benjamin Thaut via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:

 On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote:

 Regarding D's GC and Games written in D you can also take a look at a old
 project of mine and the results that came out of it.

 http://3d.benjamin-thaut.de/?p=20



 Towards the end you list some performance and memory leaking issues in D.
 Have you seen improvement in these areas?




 - Comparision of TypeInfo objects in druntime is done by building two
 strings and then comparing those two strings. This will always leak memory
 and do a lot of unneccesary allocations which are a performance bottleneck.
 I reworte the comparison so it does not allocate a single byte.

 I did a pull request to improve this once, but it was rejected. So this
 issue still remains. Comparing two type info objects still produces garbage.

 - Calls to the druntime invariant handler are emitted in release build also
 and there is no way to turn them off. Even if the class does not have any
 invariants the invariant handler will always be called, walk the class
 hirarchy and generate multiple cache misses without actually doing anything.

 Afaik this has been fixed.

 - The new statement will not free any memory if the constructor throws a
 exception. So you are forced to replace both the new and the delete
 statement. But you can not replace the new statement with similar nice
 syntax especially for inner classes and arrays.

 This issue still remains, although might improve soon with std.allocator.
 The language is not designed to make it possible for new/delete to be
 replaced in a nice way so most likely

 new int[3] will become allocator.makeArray!int(3)

 - Inlining of DMD. Inlining of DMD seems to be very minimal. Most of my
 overloaded operators are not inlined by dmd at all.

 This somewhat improved, especially with pragma(inline) but dmd is still
 really bad at inlining and I still can't compile all my projects with the
 -inline switch because dmd produces invalid function calls if I do so. And
 don't tell me to use a different compiler, on windows the only viable option
 still is dmd. Gdc for windows is no longer maintained and ldc is not there
 yet (but might be soon).


There are binaries that are released every so often (and announced in
the GDC channel), but not one seems to give feedback on them.

http://gdcproject.org/downloads
Aug 06 2015
prev sibling parent "jmh530" <john.michael.hall gmail.com> writes:
On Thursday, 6 August 2015 at 09:18:44 UTC, Benjamin Thaut wrote:

 [snip]
 
 Kind Regards
 Benjamin Thaut


Thanks.
Aug 06 2015
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


The Derelict packages are fairly stable. You aren't going to see 
any activity there except for bug fixes or updates to match new 
versions of the C libraries. They're still very much alive, 
though.
Jul 30 2015
prev sibling next sibling parent "Laeeth Isharc" <nospamlaeeth nospamlaeeth.com> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?



In case you haven't seen, have a look at prior dconf talks by the 
German chap and by Manu.
Jul 30 2015
prev sibling next sibling parent "ZombineDev" <valid_email he.re> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


There's a small incomplete list of game dev libraries here:
https://github.com/zhaopuming/awesome-d#awesome-d
Jul 30 2015
prev sibling next sibling parent "rcorre" <ryan rcorre.net> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?


I hack away at little games in D whenever I can find some free 
time.
My previous project was a strategy game:
https://github.com/rcorre/terra-arcana

I've abandoned it for now to move on to a less complex project 
that I can hopefully finish, but it did get to a playable state.

As far as the GC stuff, I haven't run into issues like I used to 

allocations (my last two projects were turn-based-strategy).

For now, D just seems to make me more productive than any other 
language I've tried. I'm hoping that if I do run into memory 
issues, std.allocator may be able to help.
Aug 02 2015
prev sibling next sibling parent "ref2401" <refactor24 gmail.com> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


You should have a look at this engine 
http://dash.circularstudios.com/
Aug 04 2015
prev sibling next sibling parent reply "develop32" <develop32 gmail.com> writes:
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?


Not an indie game, but Remedy is making Quantum Break using D.
Aug 04 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 4 August 2015 at 18:59:34 UTC, develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?


 Not an indie game, but Remedy is making Quantum Break using D.


And they are not using the GC.
Aug 04 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?


 Not an indie game, but Remedy is making Quantum Break using D.


Got a source for that? As I can't find it.
Aug 04 2015
next sibling parent reply "ref2401" <refactor24 gmail.com> writes:
On Tuesday, 4 August 2015 at 19:13:44 UTC, Rikki Cattermole wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are
 there any guys out there using D for indie games?


 Not an indie game, but Remedy is making Quantum Break using D.


 Got a source for that? As I can't find it.


http://remedygames.com/job_offer/senior-tools-programmer/
Aug 04 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 August 2015 at 06:12, ref2401 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 4 August 2015 at 19:13:44 UTC, Rikki Cattermole wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?



 Not an indie game, but Remedy is making Quantum Break using D.



 Got a source for that? As I can't find it.



 http://remedygames.com/job_offer/senior-tools-programmer/


Haha, it doesn't mention getting drunk, naked and doing laps of the
block in -30 degree winter with 20 of your (male) colleagues as a
necessary skill ;)
Aug 06 2015
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?



 Not an indie game, but Remedy is making Quantum Break using D.



 Got a source for that? As I can't find it.


Hi. I dunnit, and I did a talk about it at dconf2013.
Aug 06 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:

 On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?



 Not an indie game, but Remedy is making Quantum Break using D.



 Got a source for that? As I can't find it.


 Hi. I dunnit, and I did a talk about it at dconf2013.


I knew you were involved with them back then. I was more interested in 
anything that happened after that.
Aug 06 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:

 On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?




 Not an indie game, but Remedy is making Quantum Break using D.




 Got a source for that? As I can't find it.



 Hi. I dunnit, and I did a talk about it at dconf2013.



 I knew you were involved with them back then. I was more interested in
 anything that happened after that.


It took a lot longer for us to get the compiler to a sufficiently
stable state that we were able to build reliably than we'd liked. In
the mean time, code pegged for D was forced to be written in C, so a
lot of D code ended out being C code on account of 'couldn't wait'.
When I left, there were a couple of critical systems running in D, and
a few toolchain issues left to work out (Windows DLL's + GC). It was
left with Ethan who occasionally appears here.
I'm not sure where it went after that. There was much enthusiasm among
the team, but the toolchain progressed slower than we could afford,
and we just had to get on with it in some cases. Hopefully there's
still some D code in there, and (if the problems were fixed!) there's
no good reason why it wouldn't have scaled out from where I left it.
Aug 06 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:

 On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:

 On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?




 Not an indie game, but Remedy is making Quantum Break using D.




 Got a source for that? As I can't find it.



 Hi. I dunnit, and I did a talk about it at dconf2013.



 I knew you were involved with them back then. I was more interested in
 anything that happened after that.


 It took a lot longer for us to get the compiler to a sufficiently
 stable state that we were able to build reliably than we'd liked. In
 the mean time, code pegged for D was forced to be written in C, so a
 lot of D code ended out being C code on account of 'couldn't wait'.
 When I left, there were a couple of critical systems running in D, and
 a few toolchain issues left to work out (Windows DLL's + GC). It was
 left with Ethan who occasionally appears here.
 I'm not sure where it went after that. There was much enthusiasm among
 the team, but the toolchain progressed slower than we could afford,
 and we just had to get on with it in some cases. Hopefully there's
 still some D code in there, and (if the problems were fixed!) there's
 no good reason why it wouldn't have scaled out from where I left it.


Yeah I hope it had. Although would be nice to hear from Remedy what they 
currently use / think of D.
I kinda hoped that they had released e.g. a blog post about it, which 
they haven't.
Aug 06 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:

 On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:

 On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game.
 Are
 there any guys out there using D for indie games?





 Not an indie game, but Remedy is making Quantum Break using D.





 Got a source for that? As I can't find it.




 Hi. I dunnit, and I did a talk about it at dconf2013.




 I knew you were involved with them back then. I was more interested in
 anything that happened after that.



 It took a lot longer for us to get the compiler to a sufficiently
 stable state that we were able to build reliably than we'd liked. In
 the mean time, code pegged for D was forced to be written in C, so a
 lot of D code ended out being C code on account of 'couldn't wait'.
 When I left, there were a couple of critical systems running in D, and
 a few toolchain issues left to work out (Windows DLL's + GC). It was
 left with Ethan who occasionally appears here.
 I'm not sure where it went after that. There was much enthusiasm among
 the team, but the toolchain progressed slower than we could afford,
 and we just had to get on with it in some cases. Hopefully there's
 still some D code in there, and (if the problems were fixed!) there's
 no good reason why it wouldn't have scaled out from where I left it.



 Yeah I hope it had. Although would be nice to hear from Remedy what they
 currently use / think of D.
 I kinda hoped that they had released e.g. a blog post about it, which they
 haven't.


Our experience wasn't really positive. Can't/don't-want-to write a
blog post about that.
Trust me, we were very enthusiastic to stand at GDC and give a lecture
about our experience, but it didn't really go according to plan,
mostly blocked by trivial shit that's been known problems for at least
as long as I've been around here.
It's not so much language problems, it's tooling problems. It's the
most important and perhaps most neglected aspect of the D ecosystem.

1. DMD has unsatisfactory codegen for anything other than debug builds.
2. DMD generates x87 code, and uses real everywhere. We can't be
generating new x87+real instructions in 2015. It's deprecated
hardware!
2. LDC has a lot more bugs than DMD (which still has quite a few
bugs), and the Windows build is new and even more immature still.
3. LDC has no debuginfo. **biggest practical issue by far!**
4. LDC/GDC are always a few versions behind DMD. This creates an
awkward/almost-impossible situation when you rely on DMD to build
debug code, and LDC to build releasable code. Depending on 2 flaky
compilers is even less fun than one.
5. DLL's were really flakey at the time, I'm not sure how they are
now, but I'm concerned they may not be much better.
6. Shared druntime; we were loading D code from DLL's, lots of them.
It's not really reasonable for each DLL to have it's own druntime
instance, they need to share one provided by the host app.
7. D binaries are *gigantic*, I don't know why. D seems to link the
world, and I'm certain that most of the crap that's linked is never
referenced or executed... it just makes gigantic binaries for some
reason, even with line-for-line translations of C/C++ code. That's not
real good on games consoles where icache is king.


I tried to use D in my current workplace on 3 occasions now, and ran
into a different set of problems.
In the first attempt I tried to write a simple vibe.d webserver app,
but it kept crashing randomly when I was using the API's exactly as
intended (apparently a client was posting `/n` instead of `/r/n`, or
maybe the inverse of that, and it didn't like it). The IDE/debugging
situation is basically impossible; vibe.d throws exceptions all over
the place, with no really good tools for debugging this sort of thing.
My colleagues freaked out and thought I was crazy, and my credibility
was diminished.

In my second attempt, progress was interrupted by some ICE's, linking
with some C++ code caused various problems.

I investigated making another attempt to use D where we have some web
front-end code that's built using Emscripten. D would have been
perfect for this job, but LDC can't target Emscripten and/or NaCl. I
don't see that coming along any time soon. I briefly looked at trying
to make an Emscripten build of LDC, but it requires probably weeks
worth of research and expert knowledge to approach it.

A final recent attempt was basically a non-starter on account of no Qt
bindings that work &&/|| are up to date.

I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but
it's *possible* to get my work done... and that's more important than
literally anything else.

I'm getting pretty close to calling it a day. Is 6 years enough time
to repeatedly prove to myself that I'm chasing a fantasy?
People keep talking about Rust, I'm thinking of giving it a shot.

I think D needs a budget, and paid programmers employed to do boring
shit that makes the whole thing more stable and robust. Mozilla seems
to have this(?)
D seems to consistently offer 95% solutions to problems. 95% is not a
solution, it's just another problem.

Oops, I ranted. Sorry! :)
Aug 08 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:

 On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:

 On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:

 On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 5/08/2015 6:59 a.m., develop32 wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game.
 Are
 there any guys out there using D for indie games?





 Not an indie game, but Remedy is making Quantum Break using D.





 Got a source for that? As I can't find it.




 Hi. I dunnit, and I did a talk about it at dconf2013.




 I knew you were involved with them back then. I was more interested in
 anything that happened after that.



 It took a lot longer for us to get the compiler to a sufficiently
 stable state that we were able to build reliably than we'd liked. In
 the mean time, code pegged for D was forced to be written in C, so a
 lot of D code ended out being C code on account of 'couldn't wait'.
 When I left, there were a couple of critical systems running in D, and
 a few toolchain issues left to work out (Windows DLL's + GC). It was
 left with Ethan who occasionally appears here.
 I'm not sure where it went after that. There was much enthusiasm among
 the team, but the toolchain progressed slower than we could afford,
 and we just had to get on with it in some cases. Hopefully there's
 still some D code in there, and (if the problems were fixed!) there's
 no good reason why it wouldn't have scaled out from where I left it.



 Yeah I hope it had. Although would be nice to hear from Remedy what they
 currently use / think of D.
 I kinda hoped that they had released e.g. a blog post about it, which they
 haven't.


 Our experience wasn't really positive. Can't/don't-want-to write a
 blog post about that.
 Trust me, we were very enthusiastic to stand at GDC and give a lecture
 about our experience, but it didn't really go according to plan,
 mostly blocked by trivial shit that's been known problems for at least
 as long as I've been around here.
 It's not so much language problems, it's tooling problems. It's the
 most important and perhaps most neglected aspect of the D ecosystem.

 1. DMD has unsatisfactory codegen for anything other than debug builds.
 2. DMD generates x87 code, and uses real everywhere. We can't be
 generating new x87+real instructions in 2015. It's deprecated
 hardware!
 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to build
 debug code, and LDC to build releasable code. Depending on 2 flaky
 compilers is even less fun than one.
 5. DLL's were really flakey at the time, I'm not sure how they are
 now, but I'm concerned they may not be much better.
 6. Shared druntime; we were loading D code from DLL's, lots of them.
 It's not really reasonable for each DLL to have it's own druntime
 instance, they need to share one provided by the host app.
 7. D binaries are *gigantic*, I don't know why. D seems to link the
 world, and I'm certain that most of the crap that's linked is never
 referenced or executed... it just makes gigantic binaries for some
 reason, even with line-for-line translations of C/C++ code. That's not
 real good on games consoles where icache is king.


 I tried to use D in my current workplace on 3 occasions now, and ran
 into a different set of problems.
 In the first attempt I tried to write a simple vibe.d webserver app,
 but it kept crashing randomly when I was using the API's exactly as
 intended (apparently a client was posting `/n` instead of `/r/n`, or
 maybe the inverse of that, and it didn't like it). The IDE/debugging
 situation is basically impossible; vibe.d throws exceptions all over
 the place, with no really good tools for debugging this sort of thing.
 My colleagues freaked out and thought I was crazy, and my credibility
 was diminished.

 In my second attempt, progress was interrupted by some ICE's, linking
 with some C++ code caused various problems.

 I investigated making another attempt to use D where we have some web
 front-end code that's built using Emscripten. D would have been
 perfect for this job, but LDC can't target Emscripten and/or NaCl. I
 don't see that coming along any time soon. I briefly looked at trying
 to make an Emscripten build of LDC, but it requires probably weeks
 worth of research and expert knowledge to approach it.

 A final recent attempt was basically a non-starter on account of no Qt
 bindings that work &&/|| are up to date.

 I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but
 it's *possible* to get my work done... and that's more important than
 literally anything else.

 I'm getting pretty close to calling it a day. Is 6 years enough time
 to repeatedly prove to myself that I'm chasing a fantasy?
 People keep talking about Rust, I'm thinking of giving it a shot.

 I think D needs a budget, and paid programmers employed to do boring
 shit that makes the whole thing more stable and robust. Mozilla seems
 to have this(?)
 D seems to consistently offer 95% solutions to problems. 95% is not a
 solution, it's just another problem.

 Oops, I ranted. Sorry! :)


Don't worry about it!
But I see your point. All we can do is truck on.

You will enjoy my latest blog post I think[0].
I reiterate one thing, if it's hard, it's probably wrong. So, lets make 
things easy. Build a wide range a libraries to make certain programs 
easy to write.

Something I'd like to say is that I do really appreciate you and your 
work. If I could I would love to learn from you directly. I cannot give 
a higher respect or appreciation then that.
Even though it is hard for you to still be here, I hope you do continue 
to help D grow. This is a good community, we just need time before real 
adoption. E.g. we are only just now starting to unify projects.

[0] 
http://cattermole.co.nz/blog/uncategorized/where-goes-game-development-in-d/
Aug 08 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:

 [...]



 Don't worry about it!
 But I see your point. All we can do is truck on.

 You will enjoy my latest blog post I think[0].
 I reiterate one thing, if it's hard, it's probably wrong. So, lets make
 things easy. Build a wide range a libraries to make certain programs easy to
 write.

 Something I'd like to say is that I do really appreciate you and your work.
 If I could I would love to learn from you directly. I cannot give a higher
 respect or appreciation then that.
 Even though it is hard for you to still be here, I hope you do continue to
 help D grow. This is a good community, we just need time before real
 adoption. E.g. we are only just now starting to unify projects.


Cheers, but don't get me wrong; I've barely contributed anything of
value other than advocacy and little bits and pieces here and there. I
don't deserve any credit, I just complain about things that make it
impossible for me to get on with my work.
You'll know D is on good shape when you don't hear a peep from me anymore ;)
Aug 09 2015
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:






[snip]

 Even though it is hard for you to still be here, I hope you do continue to
 help D grow. This is a good community, we just need time before real
 adoption. E.g. we are only just now starting to unify projects.


 Cheers, but don't get me wrong; I've barely contributed anything of
 value other than advocacy and little bits and pieces here and there. I
 don't deserve any credit, I just complain about things that make it
 impossible for me to get on with my work.


std.simd though would be awesome to have ;)


 You'll know D is on good shape when you don't hear a peep from me anymore ;)




-- 
Dmitry Olshansky



 Aug 09 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:






 [snip]

 Even though it is hard for you to still be here, I hope you do continue
 to
 help D grow. This is a good community, we just need time before real
 adoption. E.g. we are only just now starting to unify projects.



 Cheers, but don't get me wrong; I've barely contributed anything of
 value other than advocacy and little bits and pieces here and there. I
 don't deserve any credit, I just complain about things that make it
 impossible for me to get on with my work.



 std.simd though would be awesome to have ;)


Yeah, I keep coming back to it, and getting myself stuck with various
troubles making it work good. I'm perpetually unhappy with my code,
and I just need a really good block of time to get through it.
If people want to review std.color and help get that off my
short-list, I promise I'll make std.simd my top priority :P

I also haven't had need for it in my recent work, so it's not being
motivated by necessity since I haven't been game-dev-ing much.



 Aug 09 2015



 next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:






 [snip]

 Even though it is hard for you to still be here, I hope you do continue
 to
 help D grow. This is a good community, we just need time before real
 adoption. E.g. we are only just now starting to unify projects.



 Cheers, but don't get me wrong; I've barely contributed anything of
 value other than advocacy and little bits and pieces here and there. I
 don't deserve any credit, I just complain about things that make it
 impossible for me to get on with my work.



 std.simd though would be awesome to have ;)


 Yeah, I keep coming back to it, and getting myself stuck with various
 troubles making it work good. I'm perpetually unhappy with my code,
 and I just need a really good block of time to get through it.
 If people want to review std.color and help get that off my
 short-list, I promise I'll make std.simd my top priority :P


Well, let us march towards std.experimental.color then :)
I'll see what I need about it or maybe it's plenty good enough for me 
already.

One thing I've hit with color in the past is painfully slow bulk array 
at once color conversions. In 2013 my CV app for an embbeded linux 
device had spent ~50% of time gray-scaling input image(!) that is until 
I coded a bit of NEON to fix that to ~11%. And note I'm no SIMD guru so 
I had spent an evening worth of time to test a few versions but the 
result was well worth it.


 I also haven't had need for it in my recent work, so it's not being
 motivated by necessity since I haven't been game-dev-ing much.



-- 
Dmitry Olshansky



 Aug 09 2015



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 23:52, Dmitry Olshansky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:






 [snip]

 Even though it is hard for you to still be here, I hope you do continue
 to
 help D grow. This is a good community, we just need time before real
 adoption. E.g. we are only just now starting to unify projects.




 Cheers, but don't get me wrong; I've barely contributed anything of
 value other than advocacy and little bits and pieces here and there. I
 don't deserve any credit, I just complain about things that make it
 impossible for me to get on with my work.




 std.simd though would be awesome to have ;)



 Yeah, I keep coming back to it, and getting myself stuck with various
 troubles making it work good. I'm perpetually unhappy with my code,
 and I just need a really good block of time to get through it.
 If people want to review std.color and help get that off my
 short-list, I promise I'll make std.simd my top priority :P



 Well, let us march towards std.experimental.color then :)
 I'll see what I need about it or maybe it's plenty good enough for me
 already.

 One thing I've hit with color in the past is painfully slow bulk array at
 once color conversions. In 2013 my CV app for an embbeded linux device had
 spent ~50% of time gray-scaling input image(!) that is until I coded a bit
 of NEON to fix that to ~11%. And note I'm no SIMD guru so I had spent an
 evening worth of time to test a few versions but the result was well worth
 it.


I'm happy to do optimisation passes, and have plenty of experience to
do so, but the API and general feature set needs to be agreed before I
do that sort of thing.
Optimisation can come via future PR's.

Incidentally, std.color would be a great customer for std.simd ;)



 Aug 09 2015



prev sibling  parent  "jmh530" <john.michael.hall gmail.com>  writes:


On Sunday, 9 August 2015 at 12:27:26 UTC, Manu wrote:

 Yeah, I keep coming back to it, and getting myself stuck with 
 various
 troubles making it work good. I'm perpetually unhappy with my 
 code,
 and I just need a really good block of time to get through it.
 If people want to review std.color and help get that off my
 short-list, I promise I'll make std.simd my top priority :P

 I also haven't had need for it in my recent work, so it's not 
 being motivated by necessity since I haven't been game-dev-ing 
 much.


Cool.



 Aug 09 2015



prev sibling next sibling parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 ...


This pretty much hit the nail on the head on why dmd needs 
deprecated.

I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I 
don't care if it works on windows, it produces code slower than 
interpreted lua. Exactly what use is that? It may as well not 
work on windows at all as far as release builds are concerned.

dmd not being deprecated continues the cycle of gdc/ldc lagging 
versions behind and being understaffed in manpower.



 Aug 08 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:

 On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 ...


 This pretty much hit the nail on the head on why dmd needs 
 deprecated.

 I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I 
 don't care if it works on windows, it produces code slower than 
 interpreted lua. Exactly what use is that? It may as well not 
 work on windows at all as far as release builds are concerned.

 dmd not being deprecated continues the cycle of gdc/ldc lagging 
 versions behind and being understaffed in manpower.


I think another point to look at is how far gdc and ldc have come 
while still having so few people working on them. Clearly they 
are able to get more done faster because they can leverage the 
work of the llvm and gcc devs. Seems silly that the majority of 
our talent is focused on dmd when it is the slowest of the bunch. 
D's "not made here" syndrome strikes again!

Also I really wish we had 1 main editor that was "THE" D editor. 
Something that was officially maintained and packaged with the 
rest of D. VisualD is cool, but not cross platform. monoD is 
nice, but no windows debugging support. DDT is also nice, it says 
it can do debugging in windows, but I was never been able to get 
it to work. They all have problems. If I had to vote, I would 
vote for monoD or DDT as they are both the closest to being 
complete solutions. But one really needs to be the focus and 
packaged with D, make it complete and let the others die.

D debugging is in a laughable state. It really sucks and it seems 
to not be a concern at all by the core D people. That alone is a 
huge problem. If only we could get a cross platform D debugger 
that just worked and was officially maintained.

Again tooling is D's biggest problem.

Just my 2c



 Aug 08 2015



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:


 On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:


 ...


 This pretty much hit the nail on the head on why dmd needs deprecated.

 I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care
 if it works on windows, it produces code slower than interpreted lua.
 Exactly what use is that? It may as well not work on windows at all as far
 as release builds are concerned.

 dmd not being deprecated continues the cycle of gdc/ldc lagging versions
 behind and being understaffed in manpower.


 I think another point to look at is how far gdc and ldc have come while
 still having so few people working on them. Clearly they are able to get
 more done faster because they can leverage the work of the llvm and gcc
 devs. Seems silly that the majority of our talent is focused on dmd when it
 is the slowest of the bunch. D's "not made here" syndrome strikes again!

 Also I really wish we had 1 main editor that was "THE" D editor. Something
 that was officially maintained and packaged with the rest of D. VisualD is
 cool, but not cross platform. monoD is nice, but no windows debugging
 support. DDT is also nice, it says it can do debugging in windows, but I
 was never been able to get it to work. They all have problems. If I had to
 vote, I would vote for monoD or DDT as they are both the closest to being
 complete solutions. But one really needs to be the focus and packaged with
 D, make it complete and let the others die.


(Neo)Vim?  :o)




 D debugging is in a laughable state. It really sucks and it seems to not
 be a concern at all by the core D people. That alone is a huge problem. If
 only we could get a cross platform D debugger that just worked and was
 officially maintained.


Not sure which environment you refer to, but most times I've been pinged
into discussion, the problem was less the debugger (GDB) and more the
compiler (DMD) which does not produce enough (or wrong) information to even
allow some basics to work properly.

So your idea of a debugger tool to fix all problems is a non-starter
project because from DMD there is not much information present to begin
with.  You can't magically build a debug environment that represents a
program state in its entirety from nothing!

Iain.



 Aug 08 2015



  parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:

 On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


[...]


 (Neo)Vim?  :o)




[...]


 Not sure which environment you refer to, but most times I've 
 been pinged
 into discussion, the problem was less the debugger (GDB) and 
 more the
 compiler (DMD) which does not produce enough (or wrong) 
 information to even
 allow some basics to work properly.

 So your idea of a debugger tool to fix all problems is a 
 non-starter project because from DMD there is not much 
 information present to begin with.  You can't magically build a 
 debug environment that represents a program state in its 
 entirety from nothing!

 Iain.


+1, gdb works just fine with both gdc and ldc(gdc moreso.) 
Another area that dmd falls flat on its face in.

The only real problem I have with GDC is that it's slow.



 Aug 09 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 09:03, rsw0x via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:


 On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 [...]


 (Neo)Vim?  :o)



 [...]


 Not sure which environment you refer to, but most times I've been pinged
 into discussion, the problem was less the debugger (GDB) and more the
 compiler (DMD) which does not produce enough (or wrong) information to
 even
 allow some basics to work properly.

 So your idea of a debugger tool to fix all problems is a non-starter
 project because from DMD there is not much information present to begin
 with.  You can't magically build a debug environment that represents a
 program state in its entirety from nothing!

 Iain.


 +1, gdb works just fine with both gdc and ldc(gdc moreso.) Another area
 that dmd falls flat on its face in.

 The only real problem I have with GDC is that it's slow.


Well I have no control over the sheer number of optimization passes in GCC
backend, nor the sheer number of functions the D frontend wants to send to
compile.  :o)

If the libraries were shared, this would reduce linking time, which in
various benchmarks I've done is where most small projects spend the
majority of their time doing.  But no one has as of yet come up with a
feasibly implementable idea to do that.

Iain.



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:

 If the libraries were shared, this would reduce linking time, which in various
 benchmarks I've done is where most small projects spend the majority of their
 time doing.  But no one has as of yet come up with a feasibly implementable
idea
 to do that.


We ship Phobos as a shared library on Linux, OSX and FreeBSD.



 Aug 09 2015



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:


 If the libraries were shared, this would reduce linking time, which in
 various
 benchmarks I've done is where most small projects spend the majority of
 their
 time doing.  But no one has as of yet come up with a feasibly
 implementable idea
 to do that.


 We ship Phobos as a shared library on Linux, OSX and FreeBSD.


... By inventing your own storage section?  This doesn't work where TLS is
not natively supported.  (Though, no one has really told me how it works
after years repeatedly asking, but this is what I assume is being done).



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 12:51 AM, Iain Buclaw via Digitalmars-d wrote:

 On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:

     On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:

         If the libraries were shared, this would reduce linking time, which in
         various
         benchmarks I've done is where most small projects spend the majority of
         their
         time doing.  But no one has as of yet come up with a feasibly
         implementable idea
         to do that.


     We ship Phobos as a shared library on Linux, OSX and FreeBSD.

 ... By inventing your own storage section?  This doesn't work where TLS is not
 natively supported.  (Though, no one has really told me how it works after
years
 repeatedly asking, but this is what I assume is being done).


I don't understand your question. On Linux, TLS data is inserted into the same 
section that gcc puts it. On OSX, where gcc didn't support TLS, dmd did create 
it into a data segment. Every time a new thread was created, druntime would 
malloc a chunk of data, and copy that data segment into it to initialize it. 
Then it would save a pointer to the malloced data in the thread data structure.

Accessing the OSX TLS involved finding the thread data structure for the
current 
thread, and getting the pointer to the TLS malloced data, and adding the offset 
of the symbol to it.

The only reason a new data section was required was so that all the TLS data 
from all the object modules would be adjacent. It's the only way to do it.



 Aug 09 2015



  parent reply Johannes Pfau <nospam example.com>  writes:


Am Sun, 9 Aug 2015 01:05:35 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:


 I don't understand your question. On Linux, TLS data is inserted into
 the same section that gcc puts it. On OSX, where gcc didn't support
 TLS, dmd did create it into a data segment. Every time a new thread
 was created, druntime would malloc a chunk of data, and copy that
 data segment into it to initialize it. Then it would save a pointer
 to the malloced data in the thread data structure.
 
 Accessing the OSX TLS involved finding the thread data structure for
 the current thread, and getting the pointer to the TLS malloced data,
 and adding the offset of the symbol to it.
 


Do you support shared libraries on OSX with that emulated TLS system
for all use cases? What if library A want to access a exported TLS
variable in library B? How do you:

1) Find the library the imported symbol is exported from (libraryB)
2) Find the TLS block for that library
3) Find the offset in that TLS block 


 The only reason a new data section was required was so that all the
 TLS data from all the object modules would be adjacent. It's the only
 way to do it.
 


That statement is too broad to be true ;-) GCC's emulated TLS doesn't
have adjacent memory for TLS variables and it works fine with D
(and the GC). It is a little bit slower than if we had adjacent memory.
OTOH this approach works with all kinds of shared libraries and
requires very little system specific code (only need some pthread tls
mechanism). And it is compatible with GCCs emulated TLS, so you can
even have extern TLS variables shared between C and D with emutls.



 Aug 09 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 2:04 AM, Johannes Pfau wrote:

 That statement is too broad to be true ;-) GCC's emulated TLS doesn't
 have adjacent memory for TLS variables and it works fine with D
 (and the GC). It is a little bit slower than if we had adjacent memory.
 OTOH this approach works with all kinds of shared libraries and
 requires very little system specific code (only need some pthread tls
 mechanism). And it is compatible with GCCs emulated TLS, so you can
 even have extern TLS variables shared between C and D with emutls.


The reason I did the special support for TLS on OSX is because gcc at the time 
did not support TLS in any way shape or form. Now that it does, dmd should 
change to do it the same way.



 Aug 09 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 8/9/15 5:15 AM, Walter Bright wrote:

 On 8/9/2015 2:04 AM, Johannes Pfau wrote:

 That statement is too broad to be true ;-) GCC's emulated TLS doesn't
 have adjacent memory for TLS variables and it works fine with D
 (and the GC). It is a little bit slower than if we had adjacent memory.
 OTOH this approach works with all kinds of shared libraries and
 requires very little system specific code (only need some pthread tls
 mechanism). And it is compatible with GCCs emulated TLS, so you can
 even have extern TLS variables shared between C and D with emutls.


 The reason I did the special support for TLS on OSX is because gcc at
 the time did not support TLS in any way shape or form. Now that it does,
 dmd should change to do it the same way.


"Where is the bugzilla issue" etc :o). -- Andrei



 Aug 09 2015



  parent reply Jacob Carlborg <doob me.com>  writes:


On 09/08/15 15:53, Andrei Alexandrescu wrote:


 "Where is the bugzilla issue" etc :o). -- Andrei


It's been there for a while [1] ;)

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

-- 
/Jacob Carlborg



 Aug 09 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 11:50 AM, Jacob Carlborg wrote:

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


Thanks for helping out with this.



 Aug 09 2015



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 09/08/15 11:04, Johannes Pfau wrote:


 Do you support shared libraries on OSX with that emulated TLS system
 for all use cases?


Shared libraries are not supported at all on OS X.

-- 
/Jacob Carlborg



 Aug 09 2015



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 09/08/15 09:33, Walter Bright wrote:


 We ship Phobos as a shared library on Linux, OSX and FreeBSD.


No on OS X.

-- 
/Jacob Carlborg



 Aug 09 2015



prev sibling  parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sun, Aug 9, 2015 at 12:33 AM, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:


 If the libraries were shared, this would reduce linking time, which in
 various
 benchmarks I've done is where most small projects spend the majority of
 their
 time doing.  But no one has as of yet come up with a feasibly
 implementable idea
 to do that.


 We ship Phobos as a shared library on Linux, OSX and FreeBSD.


on OSX I only see libphobos2.a (including dmd 2.068)



 Aug 11 2015



  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-08-11 09:08, Timothee Cour via Digitalmars-d wrote:


 on OSX I only see libphobos2.a (including dmd 2.068)


It's not supported on OS X.

-- 
/Jacob Carlborg



 Aug 12 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/8/2015 11:36 PM, Tofu Ninja wrote:

 On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:

 dmd not being deprecated continues the cycle of gdc/ldc lagging versions
 behind and being understaffed in manpower.


 I think another point to look at is how far gdc and ldc have come while still
 having so few people working on them. Clearly they are able to get more done
 faster because they can leverage the work of the llvm and gcc devs. Seems silly
 that the majority of our talent is focused on dmd when it is the slowest of the
 bunch. D's "not made here" syndrome strikes again!


There's pretty much no talent focused on the dmd back end. I do most of the 
(very) occasional bug fixes, and sometimes Martin or Daniel correct something, 
and that's about it.

The idea that it is sucking up resources is incorrect.



 Aug 09 2015



  parent reply Johannes Pfau <nospam example.com>  writes:


Am Sun, 9 Aug 2015 00:32:00 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 8/8/2015 11:36 PM, Tofu Ninja wrote:

 On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:

 dmd not being deprecated continues the cycle of gdc/ldc lagging
 versions behind and being understaffed in manpower.


 I think another point to look at is how far gdc and ldc have come
 while still having so few people working on them. Clearly they are
 able to get more done faster because they can leverage the work of
 the llvm and gcc devs. Seems silly that the majority of our talent
 is focused on dmd when it is the slowest of the bunch. D's "not
 made here" syndrome strikes again!


 
 There's pretty much no talent focused on the dmd back end. I do most
 of the (very) occasional bug fixes, and sometimes Martin or Daniel
 correct something, and that's about it.
 
 The idea that it is sucking up resources is incorrect.
 


The DMD devs aren't working on the backend, but the GDC and LDC are
neither ;-) He's talking about the glue layer.

DMD has the advantage that whenever a frontend pull request requires
glue layer changes you get at and once by the contributor. But for
LDC and GDC the glue layer changes have to be implemented by GDC/LDC
devs.



 Aug 09 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 2:07 AM, Johannes Pfau wrote:

 DMD has the advantage that whenever a frontend pull request requires
 glue layer changes you get at and once by the contributor. But for
 LDC and GDC the glue layer changes have to be implemented by GDC/LDC
 devs.


If LDC were the default, then the GDC devs would still have to do the same work.



 Aug 09 2015



  parent reply Johannes Pfau <nospam example.com>  writes:


Am Sun, 9 Aug 2015 02:17:11 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 8/9/2015 2:07 AM, Johannes Pfau wrote:

 DMD has the advantage that whenever a frontend pull request requires
 glue layer changes you get at and once by the contributor. But for
 LDC and GDC the glue layer changes have to be implemented by GDC/LDC
 devs.


 
 If LDC were the default, then the GDC devs would still have to do the
 same work.
 


Sure. I'm not arguing that LDC or GDC should be the default, just
wanted to explain why we could really need some more contributors for GDC/LDC
;-)



 Aug 09 2015



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 2:33 AM, Johannes Pfau wrote:

 Sure. I'm not arguing that LDC or GDC should be the default, just
 wanted to explain why we could really need some more contributors for GDC/LDC
;-)



We could use more contributors in general!



 Aug 09 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 Aug 2015 11:35 am, "Johannes Pfau via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 Am Sun, 9 Aug 2015 02:17:11 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:


 On 8/9/2015 2:07 AM, Johannes Pfau wrote:

 DMD has the advantage that whenever a frontend pull request requires
 glue layer changes you get at and once by the contributor. But for
 LDC and GDC the glue layer changes have to be implemented by GDC/LDC
 devs.


 If LDC were the default, then the GDC devs would still have to do the
 same work.


 Sure. I'm not arguing that LDC or GDC should be the default, just
 wanted to explain why we could really need some more contributors for


GDC/LDC ;-)

I'd just like to add (before I disappear for the day).  That I spent the
first 4 years developing gdc on a netbook which had a single core Atom chip
clocked at 1.6ghz, with 4GB memory (upgraded from 2GB after building
libphobos unittester started consuming far too much memory).

Just incase anyone pulls out the 'takes too long to build' rabbit from
their hat.

Iain.



 Aug 09 2015



prev sibling  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 11:07, Johannes Pfau via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 Am Sun, 9 Aug 2015 00:32:00 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:


 On 8/8/2015 11:36 PM, Tofu Ninja wrote:

 On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:

 dmd not being deprecated continues the cycle of gdc/ldc lagging
 versions behind and being understaffed in manpower.


 I think another point to look at is how far gdc and ldc have come
 while still having so few people working on them. Clearly they are
 able to get more done faster because they can leverage the work of
 the llvm and gcc devs. Seems silly that the majority of our talent
 is focused on dmd when it is the slowest of the bunch. D's "not
 made here" syndrome strikes again!


 There's pretty much no talent focused on the dmd back end. I do most
 of the (very) occasional bug fixes, and sometimes Martin or Daniel
 correct something, and that's about it.

 The idea that it is sucking up resources is incorrect.


 The DMD devs aren't working on the backend, but the GDC and LDC are
 neither ;-) He's talking about the glue layer.

 DMD has the advantage that whenever a frontend pull request requires
 glue layer changes you get at and once by the contributor. But for
 LDC and GDC the glue layer changes have to be implemented by GDC/LDC
 devs.


I think that is more of a problem with length of development + number of
contributors/changes.

For instance, when it was just Walter committing changes, the number of
"fixed" bugs was of a reasonable number such that I could have gone through
them all and tested them within a day (this is back when the D2 testsuite
was private and I had no way other way to track whether or not codegen
changes were required).

Now we have the testsuite, which seems to be a good enough gauge for
finding problems.  However if there's been a change (eg: refactor) between
what codegen is lowered in the frontend vs. glue, then it becomes a commit
hunt trawling through thousands of changes to work out which one is
relevant to the new wrong-code-on-previously-working test.  One day turns
into a week, turns into a month, turns into half a year.

Iain.



 Aug 09 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 2:25 AM, Iain Buclaw via Digitalmars-d wrote:

 Now we have the testsuite, which seems to be a good enough gauge for finding
 problems.  However if there's been a change (eg: refactor) between what codegen
 is lowered in the frontend vs. glue, then it becomes a commit hunt trawling
 through thousands of changes to work out which one is relevant to the new
 wrong-code-on-previously-working test.  One day turns into a week, turns into a
 month, turns into half a year.


Would git bisect help with that?



 Aug 09 2015



prev sibling  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:

 On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 ...


 This pretty much hit the nail on the head on why dmd needs 
 deprecated.

 I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I 
 don't care if it works on windows, it produces code slower than 
 interpreted lua. Exactly what use is that? It may as well not 
 work on windows at all as far as release builds are concerned.


Well, for Win64 the codegen is simply wrong. I don't even care if 
the codegen is fast or not, but correct should be a given. 
Biggest problem for me so far.

Aggravated by the time it takes to isolate such bugs.



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 12:59 PM, ponce wrote:

 Well, for Win64 the codegen is simply wrong. I don't even care if the codegen
is
 fast or not, but correct should be a given. Biggest problem for me so far.


There's nothing I nor anyone else can do with comments like this.

It passes the executable part of the test suite on Win64. If there are bugs in 
the Win64 code generation, I don't see any on Bugzilla.

Please post incorrect codegen bugs to bugzilla. If they are already on
bugzilla, 
please post the bug numbers.



 Aug 09 2015



  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Sunday, 9 August 2015 at 20:24:47 UTC, Walter Bright wrote:

 On 8/9/2015 12:59 PM, ponce wrote:

 Well, for Win64 the codegen is simply wrong. I don't even care 
 if the codegen is
 fast or not, but correct should be a given. Biggest problem 
 for me so far.


 There's nothing I nor anyone else can do with comments like 
 this.

 It passes the executable part of the test suite on Win64. If 
 there are bugs in the Win64 code generation, I don't see any on 
 Bugzilla.

 Please post incorrect codegen bugs to bugzilla. If they are 
 already on bugzilla, please post the bug numbers.


Once I get back to Windows I will post the report.
The problem is that from a selfish point of view I can better 
optimize for my time and just disable optimizations in the faulty 
code, moving on to the next task. A Tragedy of the commons 
situation.



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 2:03 PM, ponce wrote:

 Once I get back to Windows I will post the report.


Thank you.


 The problem is that from a selfish point of view I can better optimize for my
 time and just disable optimizations in the faulty code, moving on to the next
 task. A Tragedy of the commons situation.


I think that's very short term thinking. You will benefit from the fixes since 
you won't have to debug or work around them any more.



 Aug 09 2015



  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote:

 On 8/9/2015 2:03 PM, ponce wrote:

 Once I get back to Windows I will post the report.


 Thank you.


https://issues.dlang.org/show_bug.cgi?id=14896



 Aug 10 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/10/2015 3:32 AM, ponce wrote:

 On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote:

 On 8/9/2015 2:03 PM, ponce wrote:

 Once I get back to Windows I will post the report.


 Thank you.


 https://issues.dlang.org/show_bug.cgi?id=14896


Good!



 Aug 10 2015



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:

 1. DMD has unsatisfactory codegen for anything other than debug builds.


Do you mean the codegen is slower? But consider that the bottleneck in most 
programs is a small section of code. Taking a good look at the generated code 
for that and comparing with another compiler can often hint at an easy 
improvement to dmd that can address that bottleneck.

But waiting for someone else to discover the same thing on some other piece of 
code means you'll be waiting a long time.



 2. DMD generates x87 code, and uses real everywhere.


Less so now than it used to. For float and double, it uses SIMD.


 We can't be
 generating new x87+real instructions in 2015. It's deprecated
 hardware!


x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or
not. 
Why was it a problem for you?



 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to build
 debug code, and LDC to build releasable code. Depending on 2 flaky
 compilers is even less fun than one.
 5. DLL's were really flakey at the time, I'm not sure how they are
 now, but I'm concerned they may not be much better.
 6. Shared druntime; we were loading D code from DLL's, lots of them.
 It's not really reasonable for each DLL to have it's own druntime
 instance, they need to share one provided by the host app.


I agree, and now we ship a Phobos DLL, resolving that issue.


 7. D binaries are *gigantic*, I don't know why. D seems to link the
 world, and I'm certain that most of the crap that's linked is never
 referenced or executed... it just makes gigantic binaries for some
 reason, even with line-for-line translations of C/C++ code. That's not
 real good on games consoles where icache is king.


Yes, that's an ongoing problem. I need to spend some time on that one.



 I tried to use D in my current workplace on 3 occasions now, and ran
 into a different set of problems.
 In the first attempt I tried to write a simple vibe.d webserver app,
 but it kept crashing randomly when I was using the API's exactly as
 intended (apparently a client was posting `/n` instead of `/r/n`, or
 maybe the inverse of that, and it didn't like it).


Were these bugs reported?



 In my second attempt, progress was interrupted by some ICE's, linking
 with some C++ code caused various problems.


ICE's in what? What problems?



 A final recent attempt was basically a non-starter on account of no Qt
 bindings that work &&/|| are up to date.


Bindings aren't too hard to update.



 I'm getting pretty close to calling it a day. Is 6 years enough time
 to repeatedly prove to myself that I'm chasing a fantasy?
 People keep talking about Rust, I'm thinking of giving it a shot.

 I think D needs a budget, and paid programmers employed to do boring
 shit that makes the whole thing more stable and robust. Mozilla seems
 to have this(?)
 D seems to consistently offer 95% solutions to problems. 95% is not a
 solution, it's just another problem.

 Oops, I ranted. Sorry! :)


I think what stalled Remedy's use of D is you left Remedy. Note that while you 
were there I went to Finland largely at my own expense to help make it work for 
Remedy. After you left, there wasn't much interest from Remedy.

I note that I rarely know just what is blocking you. For example, you say above 
you got some ICEs. What ICEs? We cannot fix bugs we don't know about. I would 
also very much appreciate if you would pitch in to help with things that are 
blocking you, like updated Qt bindings. Generally, people around here tend to 
contribute fixes for things that personally interest or block them. Priorities 
for you aren't priorities for others.

D doesn't have a community so large that you can sit back and assume many
others 
will run into the same issues you have and will fix them. You have to be more 
proactive.

Looking at open bugzilla issues you've commented on:

https://issues.dlang.org/show_bug.cgi?id=5227
https://issues.dlang.org/show_bug.cgi?id=6343
https://issues.dlang.org/show_bug.cgi?id=8845
https://issues.dlang.org/show_bug.cgi?id=9065
https://issues.dlang.org/show_bug.cgi?id=9137
https://issues.dlang.org/show_bug.cgi?id=10203
https://issues.dlang.org/show_bug.cgi?id=10959
https://issues.dlang.org/show_bug.cgi?id=11541
https://issues.dlang.org/show_bug.cgi?id=12440
https://issues.dlang.org/show_bug.cgi?id=13265
https://issues.dlang.org/show_bug.cgi?id=14260

That's it. None of them seem to be ones you brought up in your post. To get 
attention for issues that are blocking you you absolutely have to file bugzilla 
reports. That doesn't guarantee they will be fixed, but if you do not file
them, 
it DOES guarantee that they will NOT be addressed, and you'll get frustrated.



 Aug 08 2015



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 07:31, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:


 1. DMD has unsatisfactory codegen for anything other than debug builds.


 Do you mean the codegen is slower? But consider that the bottleneck in
 most programs is a small section of code. Taking a good look at the
 generated code for that and comparing with another compiler can often hint
 at an easy improvement to dmd that can address that bottleneck.

 But waiting for someone else to discover the same thing on some other
 piece of code means you'll be waiting a long time.


Sometimes just using the wrong CPU can have adverse effects:

https://issues.dlang.org/show_bug.cgi?id=5100




 2. DMD generates x87 code, and uses real everywhere.


 Less so now than it used to. For float and double, it uses SIMD.

 We can't be

 generating new x87+real instructions in 2015. It's deprecated
 hardware!


 x87 works on every x86 CPU, and I doubt it will ever go away, deprecated
 or not. Why was it a problem for you?


I know that at least for the benefit of std.math, we should allow any
precision without expensive casting to and from real, which has been found
to be a performance problem on various benchmarks (GDC, LDC, DMD, doesn't
matter).

Iain.



 Aug 08 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:

 I know that at least for the benefit of std.math, we should allow any precision
 without expensive casting to and from real, which has been found to be a
 performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).


I thought that had largely been done.



 Aug 09 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 09:28, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:


 I know that at least for the benefit of std.math, we should allow any
 precision
 without expensive casting to and from real, which has been found to be a
 performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).


 I thought that had largely been done.


What about intrinsics?

https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:

 What about intrinsics?

 https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630


There isn't a simd cosine instruction, so making cos(double) builtin 
accomplishes nothing. However, the casting in those functions go away when code 
is generated.

For example:

   import std.math;
   double foo(double d) {
     return cos(d);
   }

generates:

   _D3foo3fooFdZd:
                 fld     qword ptr 4[ESP]
                 fcos
                 ret     8



 Aug 09 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 09:53, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:


 What about intrinsics?


 https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630


 There isn't a simd cosine instruction, so making cos(double) builtin
 accomplishes nothing. However, the casting in those functions go away when
 code is generated.

 For example:

   import std.math;
   double foo(double d) {
     return cos(d);
   }

 generates:

   _D3foo3fooFdZd:
                 fld     qword ptr 4[ESP]
                 fcos
                 ret     8


This is on Windows?  I'm not seeing this on Linux.  http://goo.gl/58yhwU



 Aug 09 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 1:05 AM, Iain Buclaw via Digitalmars-d wrote:

 This is on Windows?  I'm not seeing this on Linux. http://goo.gl/58yhwU


You're seeing that on Linux because doubles are passed/returned in XMM0 on 
Linux, and the only way to load XMM0 into the x87 is to pass it through a
memory 
location. There's still no casting to/from real, even in that asm code.



 Aug 09 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 1:11 AM, Walter Bright wrote:

 You're seeing that on Linux because doubles are passed/returned in XMM0 on
 Linux, and the only way to load XMM0 into the x87 is to pass it through a
memory
 location. There's still no casting to/from real, even in that asm code.


BTW, if you want to suggest faster emitted code for cos(float) and cos(double), 
I'm game! Fire away!



 Aug 09 2015



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:

 1. DMD has unsatisfactory codegen for anything other than debug builds.



 Do you mean the codegen is slower? But consider that the bottleneck in most
 programs is a small section of code. Taking a good look at the generated
 code for that and comparing with another compiler can often hint at an easy
 improvement to dmd that can address that bottleneck.

 But waiting for someone else to discover the same thing on some other piece
 of code means you'll be waiting a long time.


I understand, but that's not sustainable.
We can't be in a situation where I'm at work with a deadline, and I
need to invoke the community to address a codegen issue that's
blocking a release. Unexpected surprises like that with unknown/long
turn-around times aren't a practical commitment.
Last time I was concerned with this, x87 was destroying DMD
performance. Floats were x87, moved to XMM (according to x64 ABI) when
passed to functions, then moved back into x87 on the other side when
they're operated on.
Float code was overwhelmed with shuffling values between registers.
Basically all hot code is float code in my line of work.

I think Ethan was in discussions with you about this some time back?
It was a problem at the time I left Remedy.

Also, I think one of the big issues is the optimiser in general. The
inliner's just not fantastic, and D depends on it perhaps even more
than C++, especially when using the modern lazy code style.
I'm sure I can hand-assist DMD to produce the assembly I expect for
some hot function with some work, but traditional hand-assisted code
generation all falls apart when you start stacking lazy-ranges and
generally using the modern D style.
DMD's backend has almost no development, it's advancing at near-zero
velocity compared to LLVM. We need to get out of the situation where
LDC and GDC are perpetually 1-2 versions behind.

Incidentally, In my recent (dead-end) experience with LDC, I get
endless ICE's whenever I try to do anything mildly complex. When you
have your Debug and Release build straddling language versions and
compilers with different ICE characteristics, it's just not a
practical workflow. Only green-fields projects or the simplest of
simple apps can hope not to trigger bugs constantly in that
environment.



 2. DMD generates x87 code, and uses real everywhere.



 Less so now than it used to. For float and double, it uses SIMD.


Okay, is this fairly recent? My last set of comprehensive tests are
probably out of date.



 We can't be
 generating new x87+real instructions in 2015. It's deprecated
 hardware!



 x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or
 not. Why was it a problem for you?


Massive register swapping was the issue. I'd like to think register
swapping should never be implicitly generated unless I *explicitly*
type the real keyword, I don't want to see x87 opcodes.



 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to build
 debug code, and LDC to build releasable code. Depending on 2 flaky
 compilers is even less fun than one.
 5. DLL's were really flakey at the time, I'm not sure how they are
 now, but I'm concerned they may not be much better.
 6. Shared druntime; we were loading D code from DLL's, lots of them.
 It's not really reasonable for each DLL to have it's own druntime
 instance, they need to share one provided by the host app.



 I agree, and now we ship a Phobos DLL, resolving that issue.


Really? Where is it? (I can't see it in the distribution).



 7. D binaries are *gigantic*, I don't know why. D seems to link the
 world, and I'm certain that most of the crap that's linked is never
 referenced or executed... it just makes gigantic binaries for some
 reason, even with line-for-line translations of C/C++ code. That's not
 real good on games consoles where icache is king.



 Yes, that's an ongoing problem. I need to spend some time on that one.


That'll be nice. Bear in mind, I'm just giving an account here of why
we were unable to produce blog posts and hype from our experience
using D at Remedy, at least up until the time I left, I'm not sure
where they are with it now. I hope it didn't fizzle, but there were
more problems than we initially hoped for, and I think that damaged
confidence a lot.

In the short term? I struggle to imagine the ddmd transition taking
less than 3-6 months.



it would be Emscripten support, and LDC as default D compiler ;)



 I tried to use D in my current workplace on 3 occasions now, and ran
 into a different set of problems.
 In the first attempt I tried to write a simple vibe.d webserver app,
 but it kept crashing randomly when I was using the API's exactly as
 intended (apparently a client was posting `/n` instead of `/r/n`, or
 maybe the inverse of that, and it didn't like it).



 Were these bugs reported?


Yup, and some of them fixed. Other's remain because I couldn't create
a reduced test environment; async communications using websockets in
this case.
At the time I was actually heckled by people here telling me I was
stupid to try and use vibe.d commercially.
I was fairly surprised, it seems like one of the D community's biggest
success stories, and people were (almost violently) telling me I'm
stupid to attempt to use it in production.



 In my second attempt, progress was interrupted by some ICE's, linking
 with some C++ code caused various problems.



 ICE's in what? What problems?


LDC. I think it's the most high-priority tool in the ecosystem, and it
doesn't have anywhere near enough manpower. I am 100% in favour of the
many calls for LDC as front-line compiler.

Might I suggest - and I'm sure you won't like this, but I think it
would do worlds of good; your experience implementing MS debuginfo in
DMD is invaluable and fairly unique. If you could contribute that
debuginfo support to LLVM, it would make a world of difference.



 A final recent attempt was basically a non-starter on account of no Qt
 bindings that work &&/|| are up to date.



 Bindings aren't too hard to update.


Qt is not a small library. Binding Qt appears to be a much, much
bigger task than my task. I'd need to take it as an ongoing hobby
project, but I'm overrun with those already >_<



 I'm getting pretty close to calling it a day. Is 6 years enough time
 to repeatedly prove to myself that I'm chasing a fantasy?
 People keep talking about Rust, I'm thinking of giving it a shot.

 I think D needs a budget, and paid programmers employed to do boring
 shit that makes the whole thing more stable and robust. Mozilla seems
 to have this(?)
 D seems to consistently offer 95% solutions to problems. 95% is not a
 solution, it's just another problem.

 Oops, I ranted. Sorry! :)



 I think what stalled Remedy's use of D is you left Remedy. Note that while
 you were there I went to Finland largely at my own expense to help make it
 work for Remedy. After you left, there wasn't much interest from Remedy.


You're probably right to an extent, I was really pushing for it and I
had the latitude to do so at the time, but interest was actually very
high. Most commercial dev's I've worked with tend not to engage in the
open-source space though, so maybe it just wasn't part of their habit
to involve in communities like this one. I really do appreciate the
effort you made. I hope it was valuable development regardless, I
think a lot of important things came form it.

The reality is that it did take a lot longer to get to a workable
state than we had initially budgeted though. Off the back of that, I
think there was a lot of confidence lost, and we also entering a phase
of crunch.
The gravity of crunch in the video games industry can't be
understated; once the crunch coding begins, there is very little time
in anyone's life to get some new experimental tech across the line. We
reached the point where we were able to implement systems in D and it
was looking great, but by that time, none of the systems we planned to
implement in D were written in D because their deadlines had already
passed, so they fell back to C instead, and momentum was lost.



 I note that I rarely know just what is blocking you. For example, you say
 above you got some ICEs. What ICEs? We cannot fix bugs we don't know about.


LDC bugs, I reported them all. I couldn't sufficiently reduce test
cases in most cases though. The latest release has some promising
looking bugs fixed and I'm keen to try it out again on that code, but
the time for that code has passed so it's just another opportunity
missed at this point. I'll try it out enthusiastically, but what are
the odds I'm blocked again a couple of hours later by some other minor
and frustrating thing?


 I would also very much appreciate if you would pitch in to help with things
 that are blocking you, like updated Qt bindings. Generally, people around
 here tend to contribute fixes for things that personally interest or block
 them. Priorities for you aren't priorities for others.


I understand, and I've come to terms with this. But the practical
effect of that is sadly just to distance me from D. And I'm honestly
not trying to be negative, just realistic.
I looked into writing Qt bindings, but it's a pretty big job, probably
much bigger than the job they are to be used for. The question I have
to ask though is, would that enable me to do my work, or would I just
run into the next problem? That was the blocker, but there may have
been endless problems after that.
I can't reasonably gamble with my deadlines in that way. It's a bit of
a chicken-and-egg problem.

Sadly, I'm working more overtime than ever this year, so I just don't
have after-hours at the moment. You might have noticed my relative
silence.
I'm still trying to polish up std.color (which was a blocker for one
of my after-hours projects) in the free time I have. It's kinda
sitting in limbo waiting on ctfe float ^^ operator, and also
reviews...



 D doesn't have a community so large that you can sit back and assume many
 others will run into the same issues you have and will fix them. You have to
 be more proactive.


I understand, but I don't have time to allocate.
The only practical suggestion that comes to mind is that D needs a
budget, and employees. People paid to take the really boring stuff
seriously, and ideally prioritise paying corporate users, such that
they can have confidence that their issues won't be show-stoppers.
That probably wouldn't work well in practise though. While the number
of bugs and issues in DMD are steadily declining, I'm finding the
show-stoppers are just moving elsewhere.
LDC has ICE's in the quantity that DMD used to have, Android and iOS
support (ie, most computers in the world) are moving along rather
slowly; they are single-man teams and don't have core support.
Emscripten, NaCl, etc aren't supported.
Almost all my recent work can't ignore these platforms. Bugs relating
to external blockers like these don't belong in the DMD database.

In fact, we've been discussing for a few months that we'd have have
another very promising opportunity to use D at work in a really
appropriate context if I could rely on Android and iOS appearing
within 6-12 months or so. It would take a plug-in form like at Remedy,
which I think is a really practical transition path for a company with
engineers that need opportunities to get their feet wet, but can't
afford to bet the farm.



 Looking at open bugzilla issues you've commented on:

 https://issues.dlang.org/show_bug.cgi?id=5227
 https://issues.dlang.org/show_bug.cgi?id=6343
 https://issues.dlang.org/show_bug.cgi?id=8845
 https://issues.dlang.org/show_bug.cgi?id=9065
 https://issues.dlang.org/show_bug.cgi?id=9137
 https://issues.dlang.org/show_bug.cgi?id=10203
 https://issues.dlang.org/show_bug.cgi?id=10959
 https://issues.dlang.org/show_bug.cgi?id=11541
 https://issues.dlang.org/show_bug.cgi?id=12440
 https://issues.dlang.org/show_bug.cgi?id=13265
 https://issues.dlang.org/show_bug.cgi?id=14260

 That's it. None of them seem to be ones you brought up in your post.


This small number actually represents how far DMD has come recently. I
recognise and appreciate how far the compiler has come; I don't have
codegen or language issues very often at all these days. And likewise,
they haven't been the focus of my complaints. LDC not supporting
debuginfo for instance doesn't appear on the DMD bugzilla.

Note, x^^y is still in that list. That's blocking std.color ;)


 To get attention for issues that are blocking you you absolutely have to file
 bugzilla reports. That doesn't guarantee they will be fixed, but if you do
 not file them, it DOES guarantee that they will NOT be addressed, and you'll
 get frustrated.


I think you misunderstood the point of my rant. What I was trying to
share is past experience, not the state of the ecosystem today. It's
important to note the recurring experience where there always seems to
be some random thing that blocks me. I've approached many different
kinds of projects now, from a lot of different angles. I'm still
unable to make one stick. I'm obviously doing something wrong
repeatedly, but you can't say I haven't given it a jolly good effort!

I'm pretty consistent at logging bugs, except those that I can't
justify burning a few hundred dollars of work time to produce a
reduction that I could log are often lost (and often quite important).
I'm often inhibited by the fact that I attempt to use D at work, and
offices are stupid proprietary places so I can't share code >_<

My job and workloads have changed a lot recently, so I'm facing new problems.
But yeah, LDC and missing libraries+platforms are the source of almost
all my issues in 2015. It would be great for DMD devs to be building
LDC routinely, and this situation where GDC and LDC are a couple of
versions behind DMD has to end asap.



 Aug 09 2015



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 09/08/15 13:38, Manu via Digitalmars-d wrote:


 In fact, we've been discussing for a few months that we'd have have
 another very promising opportunity to use D at work in a really
 appropriate context if I could rely on Android and iOS appearing
 within 6-12 months or so.


There's been quite a lot of activities lately in improving the Andriod 
and iOS support by Joakim and Dan.

-- 
/Jacob Carlborg



 Aug 09 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10 August 2015 at 05:00, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 09/08/15 13:38, Manu via Digitalmars-d wrote:


 In fact, we've been discussing for a few months that we'd have have
 another very promising opportunity to use D at work in a really
 appropriate context if I could rely on Android and iOS appearing
 within 6-12 months or so.



 There's been quite a lot of activities lately in improving the Andriod and
 iOS support by Joakim and Dan.


Indeed, I've been watching with great interest.

I wonder how .so files to work on those platforms? I expect iOS would
leverage OSX support almost verbatim?
On Android, all binaries are .so files; but I fear there will be a
problem when a program is comprised of many .so files working
together... will that mean as many instances of phobos and druntime?



 Aug 10 2015



  parent reply Jacob Carlborg <doob me.com>  writes:


On 10/08/15 14:25, Manu via Digitalmars-d wrote:


 I wonder how .so files to work on those platforms? I expect iOS would
 leverage OSX support almost verbatim?


Shared libraries are not supported on OS X, at least not with DMD, not 
sure about LDC.


 On Android, all binaries are .so files; but I fear there will be a
 problem when a program is comprised of many .so files working
 together... will that mean as many instances of phobos and druntime?


On Posix, when using shared libraries, there's only one shared Phobos 
and druntime. I assume it would be implemented the same way on Andriod.

-- 
/Jacob Carlborg



 Aug 10 2015



  parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Monday, 10 August 2015 at 14:44:42 UTC, Jacob Carlborg wrote:

 Shared libraries are not supported on OS X, at least not with 
 DMD, not sure about LDC.


Shared libraries works well here on OS X with LDC 0.15.2-beta2 
(and only with LDC).



 Aug 10 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d

 But waiting for someone else to discover the same thing on some other piece
 of code means you'll be waiting a long time.


 I understand, but that's not sustainable.
 We can't be in a situation where I'm at work with a deadline, and I
 need to invoke the community to address a codegen issue that's
 blocking a release. Unexpected surprises like that with unknown/long
 turn-around times aren't a practical commitment.


It will NEVER get fixed if you don't file bug reports, and you'll continue to
be 
frustrated (and me too, because there's NOTHING I can do to improve things
based 
on what you post here).



 Last time I was concerned with this, x87 was destroying DMD
 performance. Floats were x87, moved to XMM (according to x64 ABI) when
 passed to functions, then moved back into x87 on the other side when
 they're operated on.
 Float code was overwhelmed with shuffling values between registers.
 Basically all hot code is float code in my line of work.


All I really need is a bugzilla issue with just ONE example of needlessly using 
the x87 where a SIMD instruction would be better.



 I think Ethan was in discussions with you about this some time back?
 It was a problem at the time I left Remedy.


As I recall, I heard from Ethan just once since you left. In contrast, I hear 
regularly from Sociomantic when they've got an issue, and I'm able to 
consequently help them be successful with D.



 Also, I think one of the big issues is the optimiser in general. The
 inliner's just not fantastic, and D depends on it perhaps even more
 than C++, especially when using the modern lazy code style.
 I'm sure I can hand-assist DMD to produce the assembly I expect for
 some hot function with some work, but traditional hand-assisted code
 generation all falls apart when you start stacking lazy-ranges and
 generally using the modern D style.
 DMD's backend has almost no development, it's advancing at near-zero
 velocity compared to LLVM. We need to get out of the situation where
 LDC and GDC are perpetually 1-2 versions behind.

 Incidentally, In my recent (dead-end) experience with LDC, I get
 endless ICE's whenever I try to do anything mildly complex. When you
 have your Debug and Release build straddling language versions and
 compilers with different ICE characteristics, it's just not a
 practical workflow. Only green-fields projects or the simplest of
 simple apps can hope not to trigger bugs constantly in that
 environment.


I can't help you with LDC ICE's, but are you filing bug reports for them?
Again, 
if you don't file bug reports, NOTHING WILL GET FIXED. You will be frustrated 
and everyone else will be, too.



 2. DMD generates x87 code, and uses real everywhere.


 Less so now than it used to. For float and double, it uses SIMD.


 Okay, is this fairly recent? My last set of comprehensive tests are
 probably out of date.


No, it's been that way for a while.



 Massive register swapping was the issue. I'd like to think register
 swapping should never be implicitly generated unless I *explicitly*
 type the real keyword, I don't want to see x87 opcodes.


It'll still use the x87 for things like FCOS and FSIN. But if it's doing an
x87, 
say, multiply when it should be using SIMD, you need to file a bug report.
Vague 
statements are not actionable.



 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to build
 debug code, and LDC to build releasable code. Depending on 2 flaky
 compilers is even less fun than one.
 5. DLL's were really flakey at the time, I'm not sure how they are
 now, but I'm concerned they may not be much better.
 6. Shared druntime; we were loading D code from DLL's, lots of them.
 It's not really reasonable for each DLL to have it's own druntime
 instance, they need to share one provided by the host app.



 I agree, and now we ship a Phobos DLL, resolving that issue.


 Really? Where is it? (I can't see it in the distribution).


Should be in the bin directory.



 At the time I was actually heckled by people here telling me I was
 stupid to try and use vibe.d commercially.
 I was fairly surprised, it seems like one of the D community's biggest
 success stories, and people were (almost violently) telling me I'm
 stupid to attempt to use it in production.


I didn't see such comments, but there'll always be naysayers.



 Might I suggest - and I'm sure you won't like this, but I think it
 would do worlds of good; your experience implementing MS debuginfo in
 DMD is invaluable and fairly unique. If you could contribute that
 debuginfo support to LLVM, it would make a world of difference.


All I know is actually in the DMD source code.



 Bindings aren't too hard to update.


 Qt is not a small library. Binding Qt appears to be a much, much
 bigger task than my task. I'd need to take it as an ongoing hobby
 project, but I'm overrun with those already >_<


You wouldn't need to do the whole thing, just an update to the existing one,
and 
just enough to get your project moving. Does your project use every Qt 
declaration? :-)



 You're probably right to an extent, I was really pushing for it and I
 had the latitude to do so at the time, but interest was actually very
 high. Most commercial dev's I've worked with tend not to engage in the
 open-source space though, so maybe it just wasn't part of their habit
 to involve in communities like this one. I really do appreciate the
 effort you made. I hope it was valuable development regardless, I
 think a lot of important things came form it.


The Win64 port came out of it, at least!



 LDC bugs, I reported them all.


That's great. Do they remain open?



 The question I have
 to ask though is, would that enable me to do my work, or would I just
 run into the next problem?


I have no idea.



 Note, x^^y is still in that list. That's blocking std.color ;)


It has trivial workarounds.



 I'm obviously doing something wrong
 repeatedly, but you can't say I haven't given it a jolly good effort!


I do appreciate that, and your efforts.



 I'm pretty consistent at logging bugs, except those that I can't
 justify burning a few hundred dollars of work time to produce a
 reduction that I could log are often lost (and often quite important).
 I'm often inhibited by the fact that I attempt to use D at work, and
 offices are stupid proprietary places so I can't share code >_<


If your bug reports require an NDA, I'd be happy to sign one and we can handle 
the bug report privately. In any case, by the time a bug report is reduced to 
one suitable for filing, I've never seen one that had any information in it
that 
was of proprietary value.

At least for targets that DMD supports, I recommend sticking with DMD if you
are 
blocked by LDC. At least get the project working and stable before worrying
with 
LDC specific problems.



 Aug 09 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:

 On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d

 I agree, and now we ship a Phobos DLL, resolving that issue.


 Really? Where is it? (I can't see it in the distribution).


 Should be in the bin directory.


There is no Phobos dll, only Phobos lib.



 Aug 09 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 8/9/2015 9:26 PM, Tofu Ninja wrote:

 On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:

 On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d

 I agree, and now we ship a Phobos DLL, resolving that issue.


 Really? Where is it? (I can't see it in the distribution).


 Should be in the bin directory.


 There is no Phobos dll, only Phobos lib.


There's linux/lib32/libphobos2.so, for example.



 Aug 09 2015



  parent reply "Benjamin Thaut" <code benjamin-thaut.de>  writes:


On Monday, 10 August 2015 at 05:23:20 UTC, Walter Bright wrote:

 On 8/9/2015 9:26 PM, Tofu Ninja wrote:

 On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:

 On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d

 I agree, and now we ship a Phobos DLL, resolving that issue.


 Really? Where is it? (I can't see it in the distribution).


 Should be in the bin directory.


 There is no Phobos dll, only Phobos lib.


 There's linux/lib32/libphobos2.so, for example.


But that is linux. You can't say "phobos dll" because everyone 
then expects dlls to work on windows, which still isn't the case. 
Its correct that we have a shared library version of phobos on 
linux, but a shared library version of phobos on windows is still 
in the future. I'm currently working on it, but there are so many 
issues with the language design, the export keyword, the module 
level visibility system the unittests etc etc that its going to 
take some more time. Also the front end transition from C++ to D 
hits me hard also.



 Aug 11 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 8/11/2015 12:57 AM, Benjamin Thaut wrote:

 Also the front end transition from C++ to D hits me hard also.


It's going to hit everyone hard who works on the front end.



 Aug 11 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10 August 2015 at 06:26, Tofu Ninja via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:


 On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:


 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d


 I agree, and now we ship a Phobos DLL, resolving that issue.


 Really? Where is it? (I can't see it in the distribution).


 Should be in the bin directory.


 There is no Phobos dll, only Phobos lib.



No shared library support on Windows.

This is part of the reason why shared library support has not made its way
to GDC yet (at least for D2).  I almost exorbitantly follow a
one-size-fits-all stance on all codegen-related aspects.  If it's not
cross-platform, it's not going in.

Iain.



 Aug 09 2015



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10 August 2015 at 06:51, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:

 On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d

 But waiting for someone else to discover the same thing on some other
 piece
 of code means you'll be waiting a long time.


 I understand, but that's not sustainable.
 We can't be in a situation where I'm at work with a deadline, and I
 need to invoke the community to address a codegen issue that's
 blocking a release. Unexpected surprises like that with unknown/long
 turn-around times aren't a practical commitment.



 It will NEVER get fixed if you don't file bug reports, and you'll continue
 to be frustrated (and me too, because there's NOTHING I can do to improve
 things based on what you post here).


I think you misunderstood my point again. I'm trying to say that it's
precarious to make a commitment to something you know (or suspect) has
unknown issues. The practical outcome is that there's a strong
pressure against making such a commitment (ie, not use D), and then
certainly no bugs will be found or reported.

The thing is, whatever bugs may or may not be discovered are almost
certainly already 'fixed' in LLVM/GCC. There's no work to do there,
those backends have legions of developers working on them every day.
There is literally nothing DMD can ever to do catch up. It may be sad
to admit, but it's just how it is. Maintaining and fixing the DMD
codegen just takes time away from other things (I understand you argue
that it's very little time in practical terms, but that's not really a
great argument; it just admits that DMD is not progressing), and it
has lead to a fragmented experience, which is the biggest practical
issue I've been finding with D in recent times.
DMD as a frontend to LLVM seems like the most practical and reliable
option as the default offering.

You did a lot of work to make debugging in DMD work well, and the work
really paid off! DMD is the only windows compiler that produces a
workable debugging experience.
The consequence of that though, is to have created a situation where
people necessarily rely on a tooling situation where they use 2
different compilers for debug and release, and because the other
compilers are always a few versions out of date, you're behind on all
the latest developments.
If that effort to reverse engineer Microsoft's debuginfo were
contributed to LLVM, almost every native developer, D or any language
otherwise, would all be better off.

So the point is, many of my modern D issues aren't issues that I can
bug. I can't log on bugzilla: "using DMD for debug and LDC for release
builds sucks; fix debuginfo in LLVM". That's obviously outside the
scope of DMD, but I suggest that maybe it shouldn't be?
DMD has become fairly reliable for me, I don't fight it much anymore
(or maybe I'm just much better at knowing what works well?), but the
larger ecosystem seems to be the biggest cause of friction now. These
aren't problems that are easily directed to a particular bug tracker,
they represent a conjunction of tooling, and maybe strategies need to
be considered where core developers are aware of these issues.

Leveraging the world of LLVM tooling is the most practical and
bang-for-buck solution I can imagine. The other advantage of core dev
using an LLVM backend, would be that port/architecture related bugs
would become the business of core development. CI would necessarily
have to build for many architectures, and PR's blocked until they work
on ARM/iOS/etc.



 Last time I was concerned with this, x87 was destroying DMD
 performance. Floats were x87, moved to XMM (according to x64 ABI) when
 passed to functions, then moved back into x87 on the other side when
 they're operated on.
 Float code was overwhelmed with shuffling values between registers.
 Basically all hot code is float code in my line of work.



 All I really need is a bugzilla issue with just ONE example of needlessly
 using the x87 where a SIMD instruction would be better.


Like I said, it's not a problem I have today. I was answering a
question and discussing historical problems.



 I think Ethan was in discussions with you about this some time back?
 It was a problem at the time I left Remedy.



 As I recall, I heard from Ethan just once since you left.


That's a bummer. Sorry to hear that. I should catch up with those guys
and see where they're at.



 In contrast, I hear regularly from Sociomantic when they've got an issue, and
I'm able to
 consequently help them be successful with D.


Thing is, most of my 2015 blockers are outside the scope of DMD unless
DMD decides to adopt LLVM as it's backend.
DMD is in pretty good shape these days, it's just a shame it can't be
used to compile software that runs on modern computers (arm, iOS,
Android, web).

We all need Android, iOS, Emscripten. We need equal confidence the
ports work well as that DMD is released to a high quality. I think
they should be built by the DMD core CI, all platforms tested for each
release, cross-compilers released simultaneously, and PR's rejected
when they fail on other arch/OS's.
Unless you feel these are DMD core issues, then like I say above, I
have nothing to bug except for minor issues like x^^y, which are
logged, and that large static struct issue, which you fixed quickly.

I'm really hoping that the DDMD transition will give an opportunity
for all compilers to truly share the frontend code, so they can all
track the same frontend revision at the same time, and PR's can fail
CI out of the gate if they break other platforms/architectures.
I've posted on so many occasions about how important the mobile ports
are; immeasurably more so than their developer representation (1 guy
each).
If you feel I haven't communicated this with you effectively, I'm
sorry. I personally feel I sound like a broken record on this, but I
also haven't felt like you're the right guy to hassle personally about
these things. I do however think it would be extremely valuable for
you to take a strong interest in LDC and it's health. Realise, when
LDC doesn't work, it's letting DMD and the whole D experience down
too.

(*note: as in prior posts, I don't intend to down-play GDC; it's also
very important. It's just that LDC has better platform coverage)



 Also, I think one of the big issues is the optimiser in general. The
 inliner's just not fantastic, and D depends on it perhaps even more
 than C++, especially when using the modern lazy code style.
 I'm sure I can hand-assist DMD to produce the assembly I expect for
 some hot function with some work, but traditional hand-assisted code
 generation all falls apart when you start stacking lazy-ranges and
 generally using the modern D style.
 DMD's backend has almost no development, it's advancing at near-zero
 velocity compared to LLVM. We need to get out of the situation where
 LDC and GDC are perpetually 1-2 versions behind.

 Incidentally, In my recent (dead-end) experience with LDC, I get
 endless ICE's whenever I try to do anything mildly complex. When you
 have your Debug and Release build straddling language versions and
 compilers with different ICE characteristics, it's just not a
 practical workflow. Only green-fields projects or the simplest of
 simple apps can hope not to trigger bugs constantly in that
 environment.



 I can't help you with LDC ICE's, but are you filing bug reports for them?
 Again, if you don't file bug reports, NOTHING WILL GET FIXED. You will be
 frustrated and everyone else will be, too.


I'm not sure what I've said to give you such a strong impression I
don't file bugs. I almost always do unless they would take me many
hours of paid work time to reduce, that's the only situation in which
they slip.

I feel like you've taken my post way out of context, or really
personally somehow. I don't mean that. I was just giving an account of
historic happenings in response to a question.



 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to build
 debug code, and LDC to build releasable code. Depending on 2 flaky
 compilers is even less fun than one.
 5. DLL's were really flakey at the time, I'm not sure how they are
 now, but I'm concerned they may not be much better.
 6. Shared druntime; we were loading D code from DLL's, lots of them.
 It's not really reasonable for each DLL to have it's own druntime
 instance, they need to share one provided by the host app.




 I agree, and now we ship a Phobos DLL, resolving that issue.



 Really? Where is it? (I can't see it in the distribution).



 Should be in the bin directory.


Manu MANU-PC /c/dev/D/dmd2/windows/bin
$ ls *.dll
dm.dll  eecxxx86.dll  emx86.dll  libcurl.dll  mspdb41.dll  shcv.dll  tlloc.dll


Anyway, it's great to hear it's come good. I don't need it right now,
but it'll be useful again in the future I'm certain.



 At the time I was actually heckled by people here telling me I was
 stupid to try and use vibe.d commercially.
 I was fairly surprised, it seems like one of the D community's biggest
 success stories, and people were (almost violently) telling me I'm
 stupid to attempt to use it in production.



 I didn't see such comments, but there'll always be naysayers.



 Might I suggest - and I'm sure you won't like this, but I think it
 would do worlds of good; your experience implementing MS debuginfo in
 DMD is invaluable and fairly unique. If you could contribute that
 debuginfo support to LLVM, it would make a world of difference.



 All I know is actually in the DMD source code.


Sure, but that's probably not the best place for it. You did the hard
yards, but without putting it in LLVM it's utility is significantly
reduced.
I've actually had quite a few conversations with LLVM dev's about
this, and one of the key excuses for not supporting MS debuginfo was
the classic "it's not documented". I promptly pointed them at your
work every single time it came up, but they ignored or dismissed it
every time. Dev's are funny like that.



 Bindings aren't too hard to update.


 Qt is not a small library. Binding Qt appears to be a much, much
 bigger task than my task. I'd need to take it as an ongoing hobby
 project, but I'm overrun with those already >_<



 You wouldn't need to do the whole thing, just an update to the existing one,
 and just enough to get your project moving. Does your project use every Qt
 declaration? :-)


Qt5 is a significant development away from Qt4, and I didn't find any
existing Qt binding that touches Qt5.

The hard part is reproducing moc, and uic. If you haven't had contact
with Qt, you'll need to read up on what they are for.
I'm confident a quality D binding for Qt would do away with their
suite of annoying auxiliary tools; we could do their job with compile
time magic and mixins, but reproducing those tools in CTFE represents
a lot of work. You can't do anything with Qt until they work.

Auxiliary build tools (like moc/uic) are an annoying facet of any
build system, and on doing away with those I think D would be a
fantastic language for using Qt, but it's a lot of work.



 Note, x^^y is still in that list. That's blocking std.color ;)



 It has trivial workarounds.


Kinda.

void f(T)()
{
  static immutable float someData[256] = ctfeGenTable!T(); // <- uses x^^y

  ...use `someData`...
}

Assume there are many possible T's.
Lazy initialisation of tables like this feels pretty rough. Runtime-if
to populate someData doesn't feel great, particularly because in my
particular case of interest, these are very high frequency functions.
I don't want to commit such a hack to phobos.



 I'm obviously doing something wrong
 repeatedly, but you can't say I haven't given it a jolly good effort!



 I do appreciate that, and your efforts.



 I'm pretty consistent at logging bugs, except those that I can't
 justify burning a few hundred dollars of work time to produce a
 reduction that I could log are often lost (and often quite important).
 I'm often inhibited by the fact that I attempt to use D at work, and
 offices are stupid proprietary places so I can't share code >_<



 If your bug reports require an NDA, I'd be happy to sign one and we can
 handle the bug report privately. In any case, by the time a bug report is
 reduced to one suitable for filing, I've never seen one that had any
 information in it that was of proprietary value.


It's about the time available to spend on complicated reductions while
I'm on the clock. This is the only reason in my case that bugs don't
lead to bug reports.
Considering your comparison to Sociomantic before; I suspect they have
more than one guy in the building that would actually do this stuff.



 At least for targets that DMD supports, I recommend sticking with DMD if you
 are blocked by LDC. At least get the project working and stable before
 worrying with LDC specific problems.


But a project is a non-starter if there's no evidence that LDC will
work according to our release schedule. You wouldn't start a project
and get it working with the expectation that you have to rewrite it in
C because the compiler doesn't support your target platforms (and
never claimed that it would). It's a super-hard-no-room-for-argument
blocker.
I can say with confidence, that if I have any reason to believe LDC
would work well on Android, iOS, Emscripten, I would have definitely
taken the time to write Qt support... I'm suffering C++ harder than
I've ever suffered before at the moment! >_< .. My colleagues are
actually really keen to have me try out D at work, if I could just
demonstrate that it met our starting criteria.

So, back to the beginning, I encourage you seriously consider LDC as
frontline compiler. I can't think of anything that would make more of
a positive impact to the D ecosystem than if the core dev's are
building LDC, core CI tests and PR's must pass on all
platforms/arch's, cross-compilers get simultaneous release with DMD,
and wider platform/arch support became the business of core dev's (and
the DMD bug tracker).
DMD has an accepted responsibility to x86, x64, and win, linux, bsd,
osx... why not widen that to arm, android, ios at least? These are the
most common computers in the world after all.

I really hope this is a top-priority goal for the switch to DDMD.



 Aug 10 2015



  parent reply "jmh530" <john.michael.hall gmail.com>  writes:


On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote:

 I really hope this is a top-priority goal for the switch to 
 DDMD.


My understanding is that 2.069 is supposed to bring DDMD support. 
I think there has been a lot of heated discussion about something 
that really isn't that far away. Nevertheless, I think you've 
made your case well about sort of merging LDC and DMD.

One big positive for DMD is that it is very easy to install on 
Windows. Just about anyone can get up and running quite easily. 
It doesn't require the installation of MSVC (which I can't stand) 
or Min-GW at all. If DMD and LDC are sort of merged in the way 
that you say, I just hope care is taken to ensure that it is easy 
for people to get started with it.



 Aug 10 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 11 August 2015 at 01:15, jmh530 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote:

 I really hope this is a top-priority goal for the switch to DDMD.



 My understanding is that 2.069 is supposed to bring DDMD support. I think
 there has been a lot of heated discussion about something that really isn't
 that far away. Nevertheless, I think you've made your case well about sort
 of merging LDC and DMD.

 One big positive for DMD is that it is very easy to install on Windows. Just
 about anyone can get up and running quite easily. It doesn't require the
 installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC
 are sort of merged in the way that you say, I just hope care is taken to
 ensure that it is easy for people to get started with it.


I think some care would be taken to bundle the distribution so it's
both minimal and convenient for users to install and get started with.



 Aug 10 2015



  parent reply "kink" <noone nowhere.com>  writes:


On Tuesday, 11 August 2015 at 00:56:57 UTC, Manu wrote:

 On 11 August 2015 at 01:15, jmh530 via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 One big positive for DMD is that it is very easy to install on 
 Windows. Just about anyone can get up and running quite 
 easily. It doesn't require the installation of MSVC (which I 
 can't stand) or Min-GW at all. If DMD and LDC are sort of 
 merged in the way that you say, I just hope care is taken to 
 ensure that it is easy for people to get started with it.


 I think some care would be taken to bundle the distribution so 
 it's both minimal and convenient for users to install and get 
 started with.


Afaik DMD for Win64 requires the MS linker, so good luck without 
Visual Studio then. Same goes for LDC on Win64, although an LLVM 
COFF linker is under development. Serious system programming on 
Windows without MSVC and its C runtime? Not really an option; 
MinGW appears to be a dead end and never really fitted the 
Windows eco-system.



 Aug 12 2015



 next sibling parent reply "jmh530" <john.michael.hall gmail.com>  writes:


On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote:

 Afaik DMD for Win64 requires the MS linker, so good luck 
 without Visual Studio then. Same goes for LDC on Win64, 
 although an LLVM COFF linker is under development. Serious 
 system programming on Windows without MSVC and its C runtime? 
 Not really an option; MinGW appears to be a dead end and never 
 really fitted the Windows eco-system.



Well I'm not sure what percent "serious system programming" is 
done by other people, but I don't do any. I'll take your word 
that the MS linker is required.

Regardless, my point is more about the importance of a seamless 
installation on Windows than necessarily about what is required 
or not.

It is easy to get started with DMD on Windows, roughly equivalent 
to python or R (what I more commonly program in). This makes it 
easy for people to get started learning D and playing around with 
RDMD. That's a good thing. By contrast, it seems quite 
complicated to get LDC or GDC working on Windows. I see 
explanations of how to build from source. There also appears to 
be a binary on the github page, but I haven't gotten it working 
(I didn't exactly try that hard though). I just hope that if DMD 
is replaced or moved to using LLVM, then care is taken to ensure 
that installation remains as simple as it currently is.

This isn't unique to D. I just tried to install the Clang Windows 
binary and I got a message about MSVC integration failing. I have 
Visual Express 2008, so I figure maybe a newer version is 
required, but it doesn't say anywhere on the download page what 
version is required (the building page says VS 2013 is, but 
shouldn't the download page clearly explain that?). Moreover, it 
doesn't bring up any kind of option for me to download and 
install what is missing.

I would consider the installation of Lyx to be a good example of 
a seamless installation. Lyx requires MiKTeX, so if it detects 
it's missing during installation, then it will download it. It 
might also update your version of MiKTeX also.



 Aug 12 2015



 next sibling parent  "kink" <noone nowhere.com>  writes:


On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote:

 Well I'm not sure what percent "serious system programming" is 
 done by other people, but I don't do any.


I understand your points. I meant to say that D is a system 
programming language (too), so it's tightly coupled to some 
internals of the OS. And Windows being a proprietary OS, Visual 
Studio or more precisely at least its runtime is likely to be 
required in the future as well.

Almost ;) proper support for Win64 in LDC is about to be 
completed with the next release. It will most likely require 
Visual Studio 2015. But that's about it, you'll just need to 
extract an LDC archive. When invoking ldc2.exe, you'll need to 
make sure some environment variables are properly set up (e.g., 
by using a Visual Studio command prompt), for it to find the 
linker, libs etc.

Last time I built clang (from source, using Visual Studio) I was 
amazed by how painless that was. LLVM requires VS 2013 atm (at 
least for building), but Windows/MSVC support is still being 
finalized (native MSVCRT exception handling etc.). VS 2008 is 
really quite old by now, so I'd really recommend upgrading (VS 
2015 Community is free btw).



 Aug 12 2015



prev sibling  parent  "Mike Parker" <aldacron gmail.com>  writes:


On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote:

 Regardless, my point is more about the importance of a seamless 
 installation on Windows than necessarily about what is required 
 or not.




 This isn't unique to D. I just tried to install the Clang 
 Windows binary and I got a message about MSVC integration 
 failing. I have Visual Express 2008,


The express versions of Visual Studio do not include everything 
needed to do Windows development. You also need download a 
version of the Windows SDK. My recommendation is that you just 
uninstall the Express version and install Visual Studio Community 
2013. Then go ahead and remove every trace of DMD from your 
system. Make sure it's not in your system PATH. After that, 
download the latest installer and run it. It will find your VS 
installation automatically and will configure sc.ini 
appropriately. It has worked for me every time I've tried it.

I don't think DMD is able to work with 2015 just yet, because of 
the C Runtime changes. I had trouble with it when VS 2015 was 
first released, so I deleted it and reverted to 2013.



 Aug 12 2015



prev sibling  parent  "Kagamin" <spam here.lot>  writes:


On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote:

 Afaik DMD for Win64 requires the MS linker, so good luck 
 without Visual Studio then. Same goes for LDC on Win64, 
 although an LLVM COFF linker is under development. Serious 
 system programming on Windows without MSVC and its C runtime? 
 Not really an option; MinGW appears to be a dead end and never 
 really fitted the Windows eco-system.


MSVC toolchain is required to link 3rd-party C++ code compiled 
with MSVC, mingw links c runtime just fine.



 Aug 13 2015



prev sibling  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Sunday, 9 August 2015 at 05:31:41 UTC, Walter Bright wrote:

 I agree, and now we ship a Phobos DLL, resolving that issue.


I think most people these days associate "DLL" exclusively with 
windows. I certainly do.



 Aug 10 2015



  parent reply Jacob Carlborg <doob me.com>  writes:


On 10/08/15 10:43, John Colvin wrote:


 I think most people these days associate "DLL" exclusively with windows.
 I certainly do.


Exactly. "DLL" on Windows and "shared library" on Posix. Although I 
think it's "dynamic library" on OS X.

-- 
/Jacob Carlborg



 Aug 10 2015



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 10 August 2015 at 12:29, Jacob Carlborg via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 10/08/15 10:43, John Colvin wrote:

 I think most people these days associate "DLL" exclusively with windows.

 I certainly do.


 Exactly. "DLL" on Windows and "shared library" on Posix. Although I think
 it's "dynamic library" on OS X.


So many competing standards!  We should invent a new name for them that
will be universally used by all platforms.

https://xkcd.com/927



 Aug 10 2015



prev sibling next sibling parent reply "NVolcz" <niklas.volcz gmail.com>  writes:


On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 <snip />
 It's not so much language problems, it's tooling problems. It's 
 the most important and perhaps most neglected aspect of the D 
 ecosystem.

 1. DMD has unsatisfactory codegen for anything other than debug 
 builds.
 2. DMD generates x87 code, and uses real everywhere. We can't be
 generating new x87+real instructions in 2015. It's deprecated
 hardware!
 2. LDC has a lot more bugs than DMD (which still has quite a few
 bugs), and the Windows build is new and even more immature 
 still.
 3. LDC has no debuginfo. **biggest practical issue by far!**
 4. LDC/GDC are always a few versions behind DMD. This creates an
 awkward/almost-impossible situation when you rely on DMD to 
 build
 debug code, and LDC to build releasable code. Depending on 2 
 flaky
 compilers is even less fun than one.
 <snip />


There seems like there are many problems with DMD and many 
problems asked here in the newsgroup are answered with "don't use 
DMD".
Maybe it's time to deprecate DMD? Maybe at least make sure it's 
up to date with the ecosystem.



 Aug 09 2015



  parent  "NVolcz" <niklas.volcz gmail.com>  writes:


On Sunday, 9 August 2015 at 10:21:06 UTC, NVolcz wrote:

 There seems like there are many problems with DMD and many 
 problems asked here in the newsgroup are answered with "don't 
 use DMD".
 Maybe it's time to deprecate DMD? Maybe at least make sure it's 
 up to date with the ecosystem.


Sorry didn't read the whole thread before posting!
Also I meant to write bring LDC (and/or GDC) into the release 
cycles



 Aug 09 2015



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 People keep talking about Rust, I'm thinking of giving it a 
 shot.


I feel there is something wrong with the Rust and Go agendas, 
both languages have interesting features, but then they seem to 
get too moralistic/political. Is there a way to turn off 
bounds-checks in Rust? Apparently not?

And apparently the same misguided obsession with iterators (aka 
ranges):

https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146

…Rust has a long way to go…

…Go is frozen…

…D has a long way to go…

…C++ is fit, moving and annoying…

I guess the only way forward is to write your own language.



 Aug 10 2015



 next sibling parent  "rsw0x" <anonymous anonymous.com>  writes:


On Monday, 10 August 2015 at 19:25:45 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 People keep talking about Rust, I'm thinking of giving it a 
 shot.


 I feel there is something wrong with the Rust and Go agendas, 
 both languages have interesting features, but then they seem to 
 get too moralistic/political. Is there a way to turn off 
 bounds-checks in Rust? Apparently not?


To keep it short, this is the reason I am not using Rust.



 Aug 10 2015



prev sibling  parent reply David Gileadi <gileadis NSPMgmail.com>  writes:


On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:

 People keep talking about Rust, I'm thinking of giving it a shot.


 I feel there is something wrong with the Rust and Go agendas, both
 languages have interesting features, but then they seem to get too
 moralistic/political. Is there a way to turn off bounds-checks in Rust?
 Apparently not?

 And apparently the same misguided obsession with iterators (aka ranges):

 https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146


 …Rust has a long way to go…

 …Go is frozen…

 …D has a long way to go…

 …C++ is fit, moving and annoying…

 I guess the only way forward is to write your own language.


…[insert your language here] has a long way to go… :)



 Aug 10 2015



 next sibling parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:

 On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 [...]


 …[insert your language here] has a long way to go… :)


Which is why I think people are attracted towards D. It's very 
close to being "there". The large elephant in the room is the 
garbage collector. Every way to work around it feels like a 
massive, ugly hack.



 Aug 10 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote:

 On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:

 On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 [...]


 …[insert your language here] has a long way to go… :)


 Which is why I think people are attracted towards D. It's very 
 close to being "there". The large elephant in the room is the 
 garbage collector. Every way to work around it feels like a 
 massive, ugly hack.


I am hoping once std.allocators gets done, language support for 
it will get added. Some way to get new and delete to forward to 
specific allocators.

And some way to define a scope that uses an allocator such that 
every thing in that scope that gets allocated uses that 
allocator, including allocations down the call tree.



 Aug 10 2015



  parent  "rsw0x" <anonymous anonymous.com>  writes:


On Monday, 10 August 2015 at 20:20:36 UTC, Tofu Ninja wrote:

 On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote:

 On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:

 On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 [...]


 …[insert your language here] has a long way to go… :)


 Which is why I think people are attracted towards D. It's very 
 close to being "there". The large elephant in the room is the 
 garbage collector. Every way to work around it feels like a 
 massive, ugly hack.


 I am hoping once std.allocators gets done, language support for 
 it will get added. Some way to get new and delete to forward to 
 specific allocators.


overload new. It's "deprecated" but I used it the entire time I 
was required to use D without Phobos because it was just a 
massive pain.


 And some way to define a scope that uses an allocator such that 
 every thing in that scope that gets allocated uses that 
 allocator, including allocations down the call tree.


This exists, you can use a proxy GC.



 Aug 10 2015



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote:

 On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:

 On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 [...]


 …[insert your language here] has a long way to go… :)


 Which is why I think people are attracted towards D. It's very 
 close to being "there". The large elephant in the room is the 
 garbage collector. Every way to work around it feels like a 
 massive, ugly hack.


Yes, it is not a good fit for D. Although, I find the Pony-lang 
approach interesting, but that is an actor language so it should 
not be compared to D, but to vibe.d.

Pony uses a per heap GC, a cross actor GC, and actor collection 
(collecting the whole actor and heap when the actor cannot 
receive more messages). Each actor (fiber in D) does not have a 
stack, the stack is per thread so I believe you "yield" when the 
stack has been unwound, they only use C-ABI when calling C 
functions.

But they also have an advanced pointer type system that can 
distinguish between at least 6 different reference-aliasing 
situations (or was it 12?).

https://www.youtube.com/watch?v=KvLjy8w1G_U

Anyway, it is refreshing. Maybe D can pick up some ideas from 
Pony.



 Aug 11 2015



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:

 …[insert your language here] has a long way to go… :)


Yes, the real culprit is getting really good IDE support, and for 
that one need to write a high quality analyzer that can provide 
more information than a compiler.

As far as the language goes, I'd prefer a minimalistic core 
language backed up with a normalizing and caching solver. I don't 
really think fast initial compile time is all that important, if 
he compiler caches intermediate results intelligently I think one 
can get decent compilation speeds still.



 Aug 11 2015



prev sibling next sibling parent reply "Rick" <nope mt2015.com>  writes:


On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


After leaving C++ behind for a few years to work in some 
higher-level languages for job-related coding, I was excited when 
I stumbled upon D and how it seemed to make for a perfect balance 
of higher-level language features while still being compilable 
down to machine code and able to directly interface with the vast 
sea of awesome open-source game-oriented development libraries 
that offer up a C/C++ API.

I spent several weeks tearing through the language reference and 
standard APIs to gain a solid grasp on what was possible with D.  
The existence of DUB and the Derelict bindings further made D 
seem like the perfect solution.

Unfortunately I'm regrettably having to reconsider my decision to 
start a game project (or any project requiring significant time 
investment) in D.  Not because of the language or compiler, but 
rather because of the lack maturity in the supporting tools; 
specifically, a debugger.  I should say upfront that this seems 
to be more gravely affecting OSX than other platforms, but 
scouring forums and wikis has made it apparent that no platform 
is completely devoid of obstacles when it comes to functionally 
debugging D programs.  To a certain extent, one can alternatively 
diagnose and fix bugs with verbose logging, assertions, and 
exceptions; but memory related bugs become exponentially more 
difficult to work through without being able to properly 
breakpoint, step through execution, and observe all variables in 
the current scope.

Hopefully the ecosystem of supporting D tools will continue to 
grow and mature enough to be practical for large scale projects; 
but until then be prepared to face hurdle after hurdle trying to 
use D as a complete solution for game development.



 Aug 04 2015



 next sibling parent  "Maxim Fomin" <mxfomin gmail.com>  writes:


On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:

 After leaving C++ behind for a few years to work in some 
 higher-level languages for job-related coding, I was excited 
 when I stumbled upon D ...


This is a typical path ...


 I spent several weeks tearing through the language reference 
 and standard APIs ...


... of a new user, who becomes very impressed


 Unfortunately I'm regrettably having to reconsider my decision 
 to start a game project (or any project requiring significant 
 time investment) in D.


... but the story usually continues with disillusionment
(let me guess: buggy toolchain, not everything is ready)


 Not because of the language or compiler, but rather because of 
 the lack maturity in the supporting tools; specifically, a 
 debugger.


Yep.



 Aug 04 2015



prev sibling  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:

 Unfortunately I'm regrettably having to reconsider my decision 
 to start a game project (or any project requiring significant 
 time investment) in D.  Not because of the language or 
 compiler, but rather because of the lack maturity in the 
 supporting tools; specifically, a debugger.  I should say 
 upfront that this seems to be more gravely affecting OSX than 
 other platforms, but scouring forums and wikis has made it 
 apparent that no platform is completely devoid of obstacles 
 when it comes to functionally debugging D programs.  To a 
 certain extent, one can alternatively diagnose and fix bugs 
 with verbose logging, assertions, and exceptions; but memory 
 related bugs become exponentially more difficult to work 
 through without being able to properly breakpoint, step through 
 execution, and observe all variables in the current scope.


gdb works fine on OS X and has D support.



 Aug 05 2015



  parent reply "Rick" <nope mt2015.com>  writes:


On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote:

 On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:

 Unfortunately I'm regrettably having to reconsider my decision 
 to start a game project (or any project requiring significant 
 time investment) in D.  Not because of the language or 
 compiler, but rather because of the lack maturity in the 
 supporting tools; specifically, a debugger.  I should say 
 upfront that this seems to be more gravely affecting OSX than 
 other platforms, but scouring forums and wikis has made it 
 apparent that no platform is completely devoid of obstacles 
 when it comes to functionally debugging D programs.  To a 
 certain extent, one can alternatively diagnose and fix bugs 
 with verbose logging, assertions, and exceptions; but memory 
 related bugs become exponentially more difficult to work 
 through without being able to properly breakpoint, step 
 through execution, and observe all variables in the current 
 scope.


 gdb works fine on OS X and has D support.


Can you enlighten me as to what configuration you've confirmed 
this on?  I'm on
OSX: 10.9.5 (Mavericks)
GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building 
newer from source tends to fail to compile)
DMD: DMD64 D Compiler v2.067
GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 
3.5svn)

At best, I can _sometimes_ hit breakpoints when using Mono-D, 
it's inconsistent.  Even when a breakpoint is hit however, GDB 
only recognizes the current 'this' value; it doesn't recognize 
any frame / local variables other than 'this', global variables, 
etc., though it does recognize the call-stack at least.  When 
using GDB directly from a terminal, the only D source file it 
recognizes for the purpose of setting breakpoints or listing 
source code is app.d (which contains the main() entry-point).

Also have tried compiling with all combinations of -g, -gc, 
-debug, -gs, and -cov.  None seem to improve the situation.



 Aug 05 2015



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote:

 GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 
 3.5svn)


I'm afraid apple is fucking with you...



 Aug 05 2015



prev sibling  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote:

 On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote:

 On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:

 Unfortunately I'm regrettably having to reconsider my 
 decision to start a game project (or any project requiring 
 significant time investment) in D.  Not because of the 
 language or compiler, but rather because of the lack maturity 
 in the supporting tools; specifically, a debugger.  I should 
 say upfront that this seems to be more gravely affecting OSX 
 than other platforms, but scouring forums and wikis has made 
 it apparent that no platform is completely devoid of 
 obstacles when it comes to functionally debugging D programs.
  To a certain extent, one can alternatively diagnose and fix 
 bugs with verbose logging, assertions, and exceptions; but 
 memory related bugs become exponentially more difficult to 
 work through without being able to properly breakpoint, step 
 through execution, and observe all variables in the current 
 scope.


 gdb works fine on OS X and has D support.


 Can you enlighten me as to what configuration you've confirmed 
 this on?  I'm on
 OSX: 10.9.5 (Mavericks)
 GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building 
 newer from source tends to fail to compile)
 DMD: DMD64 D Compiler v2.067
 GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 
 3.5svn)

 At best, I can _sometimes_ hit breakpoints when using Mono-D, 
 it's inconsistent.  Even when a breakpoint is hit however, GDB 
 only recognizes the current 'this' value; it doesn't recognize 
 any frame / local variables other than 'this', global 
 variables, etc., though it does recognize the call-stack at 
 least.  When using GDB directly from a terminal, the only D 
 source file it recognizes for the purpose of setting 
 breakpoints or listing source code is app.d (which contains the 
 main() entry-point).

 Also have tried compiling with all combinations of -g, -gc, 
 -debug, -gs, and -cov.  None seem to improve the situation.


Yeah that's apple messing with you, that gdb is old. See 
http://ntraft.com/installing-gdb-on-os-x-mavericks/ for proper 
installation instructions.

P.s. I help maintain homebrew packages for a bunch of D stuff, 
its generally more up to date than macports and even has the 
current betas/rcs as well as support for building from master.



 Aug 05 2015



prev sibling next sibling parent reply "karabuta" <karabutaworld gmail.com>  writes:


On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


D bindings to C++ is a little problematic, am I safe to learn 
bindings to SFML? Or is it that the D bindings is done with 
CSFML(C bindings).



 Aug 04 2015



  parent reply "karabuta" <karabutaworld gmail.com>  writes:


On Tuesday, 4 August 2015 at 20:22:05 UTC, karabuta wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


 D bindings to C++ is a little problematic, am I safe to learn 
 bindings to SFML? Or is it that the D bindings is done with 
 CSFML(C bindings).


  I mean both DSFML and derelictSFML



 Aug 04 2015



  parent  "Mike Parker" <aldacron gmail.com>  writes:


On Tuesday, 4 August 2015 at 20:25:07 UTC, karabuta wrote:

 D bindings to C++ is a little problematic, am I safe to learn 
 bindings to SFML? Or is it that the D bindings is done with 
 CSFML(C bindings).


  I mean both DSFML and derelictSFML


DerelictSFML2 [1] binds to CSFML [2].

DSFML [3] binds against a custom SFML wrapper called DSFML-C [4].

[1] https://github.com/DerelictOrg/DerelictSFML2
[2] http://www.sfml-dev.org/download/csfml/
[3] https://github.com/Jebbs/DSFML
[4] https://github.com/Jebbs/DSFML-C



 Aug 04 2015



prev sibling  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


One thing I would really like for D would be an opengl binding in 
phobos, there was some momentum a while ago to try to get 
graphics into phobos with Aurora, but literally nothing came of 
that. People want an all D gui, and graphics support but 
literally nothing will ever happen until we at least get some 
basic graphics interfaces like a simple windowing library and 
some opengl. We are already getting color and images, full on hw 
supported graphics is the next step.

Also a thing I would really like is if all the new graphics 
related things went into a std.graphics, it would be nice if it 
was std.graphics.color, std.graphics.image, std.graphics.opengl, 
std.graphics.window, std.graphics.gui, ect...

That and some simple linear alg into phobos, gl3n pls?

We literally have most of the needed parts already just laying 
around on dub and in other places.



 Aug 05 2015



 next sibling parent reply "Meta" <jared771 gmail.com>  writes:


On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote:

 One thing I would really like for D would be an opengl binding 
 in phobos, there was some momentum a while ago to try to get 
 graphics into phobos with Aurora, but literally nothing came of 
 that.


As I recall it wasn't for lack of trying. Binding D to the 
existing C++ was just too difficult, and those issues were what 
spurred the greater push for improving C++ compatibility.



 Aug 05 2015



  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 6 August 2015 at 01:13:04 UTC, Meta wrote:

 On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote:

 One thing I would really like for D would be an opengl binding 
 in phobos, there was some momentum a while ago to try to get 
 graphics into phobos with Aurora, but literally nothing came 
 of that.


 As I recall it wasn't for lack of trying. Binding D to the 
 existing C++ was just too difficult, and those issues were what 
 spurred the greater push for improving C++ compatibility.


What existing c++? Wasn't Aurora supposed to be an all D solution.



 Aug 05 2015



prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 6/08/2015 12:05 p.m., Tofu Ninja wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a game. Are
 there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being developed
 in the DUB repo. What more is happening? I don't see derelictSDl and
 derelictSFML activities much. Whatup?


 One thing I would really like for D would be an opengl binding in
 phobos, there was some momentum a while ago to try to get graphics into
 phobos with Aurora, but literally nothing came of that. People want an
 all D gui, and graphics support but literally nothing will ever happen
 until we at least get some basic graphics interfaces like a simple
 windowing library and some opengl. We are already getting color and
 images, full on hw supported graphics is the next step.

 Also a thing I would really like is if all the new graphics related
 things went into a std.graphics, it would be nice if it was
 std.graphics.color, std.graphics.image, std.graphics.opengl,
 std.graphics.window, std.graphics.gui, ect...

 That and some simple linear alg into phobos, gl3n pls?

 We literally have most of the needed parts already just laying around on
 dub and in other places.


Here is what we need to do going forward (beyond what me and Manu are 
doing):

1. Derelict-Util needs to be put into Phobos. This is not optional
2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a 
damn good idea!
3. Windows API needs to be moved into either Phobos or druntime. Not 
optional.
4. X11 bindings added to Phobos. Not optional.
5. Cocoa bindings added to Phobos. Not optional.

This all needs to happen _before_ we start working on a window library 
for Phobos.
Let alone a GUI.

We're mostly got problems with Cocoa. X11 bindings just need to be 
changed to dynamically bound.

Windows API bindings if gone into druntime wouldn't need to go through 
the review cycle luckily. But would need some decent review on e.g. Github.



 Aug 05 2015



 next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 06-Aug-2015 09:29, Rikki Cattermole wrote:

 On 6/08/2015 12:05 p.m., Tofu Ninja wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:




[snip]

 Also a thing I would really like is if all the new graphics related
 things went into a std.graphics, it would be nice if it was
 std.graphics.color, std.graphics.image, std.graphics.opengl,
 std.graphics.window, std.graphics.gui, ect...

 That and some simple linear alg into phobos, gl3n pls?

 We literally have most of the needed parts already just laying around on
 dub and in other places.


 Here is what we need to do going forward (beyond what me and Manu are
 doing):


[snip]

 3. Windows API needs to be moved into either Phobos or druntime. Not
 optional.


FYI
https://github.com/D-Programming-Language/druntime/pull/1076

-- 
Dmitry Olshansky



 Aug 06 2015



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 6/08/2015 8:27 p.m., Dmitry Olshansky wrote:

 On 06-Aug-2015 09:29, Rikki Cattermole wrote:

 On 6/08/2015 12:05 p.m., Tofu Ninja wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:




 [snip]

 Also a thing I would really like is if all the new graphics related
 things went into a std.graphics, it would be nice if it was
 std.graphics.color, std.graphics.image, std.graphics.opengl,
 std.graphics.window, std.graphics.gui, ect...

 That and some simple linear alg into phobos, gl3n pls?

 We literally have most of the needed parts already just laying around on
 dub and in other places.


 Here is what we need to do going forward (beyond what me and Manu are
 doing):


 [snip]

 3. Windows API needs to be moved into either Phobos or druntime. Not
 optional.


 FYI
 https://github.com/D-Programming-Language/druntime/pull/1076


Hopefully in the next major release! :)



 Aug 06 2015



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 06/08/15 08:29, Rikki Cattermole wrote:


 5. Cocoa bindings added to Phobos. Not optional.

 This all needs to happen _before_ we start working on a window library
 for Phobos.
 Let alone a GUI.

 We're mostly got problems with Cocoa. X11 bindings just need to be
 changed to dynamically bound.


I think now with the new extern(Objective-C) it's a minor issue. Even 
though the whole Objective-C support isn't implemented yet, I think the 
current support is good enough to create bindings which a window library 
can be built upon. We could keep the bindings internal to avoid chancing 
the public API later when better support is implemented.

-- 
/Jacob Carlborg



 Aug 06 2015



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 6/08/2015 11:29 p.m., Jacob Carlborg wrote:

 On 06/08/15 08:29, Rikki Cattermole wrote:


 5. Cocoa bindings added to Phobos. Not optional.

 This all needs to happen _before_ we start working on a window library
 for Phobos.
 Let alone a GUI.

 We're mostly got problems with Cocoa. X11 bindings just need to be
 changed to dynamically bound.


 I think now with the new extern(Objective-C) it's a minor issue. Even
 though the whole Objective-C support isn't implemented yet, I think the
 current support is good enough to create bindings which a window library
 can be built upon. We could keep the bindings internal to avoid chancing
 the public API later when better support is implemented.


Yeah. I only mentioned it as a bigger problem then say X11 because we 
already have X11 bindings. They are just statically linked. Not to 
mention old.

Vs Cocoa support which requires a very "young" compiler additions.

But hey, I'm not worried. At the worse case scenario we'll keep to my 
current method of using Objective-C directly and exporting a c API to be 
used instead. So D side is merely a wrapper.


But yes, I like the idea of internal bindings to Cocoa. But given my 
timeline for a window creation library for Phobos is middle of next 
year. Lets just say I'm in no rush.



 Aug 06 2015



prev sibling next sibling parent reply "karabuta" <karabutaworld gmail.com>  writes:


On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole 
wrote:

 On 6/08/2015 12:05 p.m., Tofu Ninja wrote:

 [...]







 [...]


 Here is what we need to do going forward (beyond what me and 
 Manu are doing):

 [...]


Don't you think that's a lot to ask from phobos?



 Aug 06 2015



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 7/08/2015 9:44 a.m., karabuta wrote:

 On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:

 On 6/08/2015 12:05 p.m., Tofu Ninja wrote:

 [...]







 [...]


 Here is what we need to do going forward (beyond what me and Manu are
 doing):

 [...]


 Don't you think that's a lot to ask from phobos?


Not really.
It's pretty rudimentary stuff.

Of course, I could add in e.g. a scenegraph, rasterizer (a postscript 
one could be VERY useful!).
Point being what I have listed are the most reusable and important to 
our ecosystem code we need to allow high reuse between libraries and to 
settle the age old problem of, 'we didn't create it'.



 Aug 06 2015



prev sibling  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole 
wrote:

 Here is what we need to do going forward (beyond what me and 
 Manu are doing):

 1. Derelict-Util needs to be put into Phobos. This is not 
 optional
 2. Derelict-GL3 needs to be put into Phobos. Optional, but 
 might be a damn good idea!
 3. Windows API needs to be moved into either Phobos or 
 druntime. Not optional.
 4. X11 bindings added to Phobos. Not optional.
 5. Cocoa bindings added to Phobos. Not optional.

 This all needs to happen _before_ we start working on a window 
 library for Phobos.
 Let alone a GUI.

 We're mostly got problems with Cocoa. X11 bindings just need to 
 be changed to dynamically bound.

 Windows API bindings if gone into druntime wouldn't need to go 
 through the review cycle luckily. But would need some decent 
 review on e.g. Github.


I really feel like D needs to get over it's "not invented here" 
syndrome, a much easier path would to just use a pre existing 
cross platform windowing library. Its laughable that the people 
in D want to reinvent this stuff. It's been done, just use the 
already working version! Why have all this great c and c++ 
interop if we never use it.

I have the same gripe with how the experimental.image is doing 
image loading/saving, there are plenty of already existing image 
libraries that already support every image format you could ever 
dream of. Just use them, they will work 1000x better than any 
reinvention that we do here.



 Aug 06 2015



 next sibling parent reply "lobo" <swamplobo gmail.com>  writes:


On Thursday, 6 August 2015 at 22:48:50 UTC, Tofu Ninja wrote:


 I really feel like D needs to get over it's "not invented here" 
 syndrome, a much easier path would to just use a pre existing 
 cross platform windowing library. Its laughable that the people 
 in D want to reinvent this stuff. It's been done, just use the 
 already working version! Why have all this great c and c++ 
 interop if we never use it.

 I have the same gripe with how the experimental.image is doing 
 image loading/saving, there are plenty of already existing 
 image libraries that already support every image format you 
 could ever dream of. Just use them, they will work 1000x better 
 than any reinvention that we do here.


+1

If only the effort writing "native-D" reinvented unproven, 
untested wheels was spent writing quality D wrappers over 
existing proven and tested libraries....


bye,
lobo



 Aug 06 2015



  parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 7/08/2015 3:01 p.m., lobo wrote:

 On Thursday, 6 August 2015 at 22:48:50 UTC, Tofu Ninja wrote:


 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library. Its laughable that the people in D want to
 reinvent this stuff. It's been done, just use the already working
 version! Why have all this great c and c++ interop if we never use it.

 I have the same gripe with how the experimental.image is doing image
 loading/saving, there are plenty of already existing image libraries
 that already support every image format you could ever dream of. Just
 use them, they will work 1000x better than any reinvention that we do
 here.


 +1

 If only the effort writing "native-D" reinvented unproven, untested
 wheels was spent writing quality D wrappers over existing proven and
 tested libraries....


*whispers* Hey hey you. You want tests? Well here is something you'll 
like[0]. Oh and check out[1].

[0] http://www.libpng.org/pub/png/pngsuite.html
[1] http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx forum.dlang.org



 Aug 06 2015



  parent reply "lobo" <swamplobo gmail.com>  writes:


On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote:

 *whispers* Hey hey you. You want tests? Well here is something 
 you'll like[0]. Oh and check out[1].

 [0] http://www.libpng.org/pub/png/pngsuite.html
 [1] 
 http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx forum.dlang.org


Well done you've written a library to pass some tests. Now fix 
the bugs that you haven't found yet and scalability issues you 
aren't aware of...the things that really only spring up when you 
get 1000+ users thrashing it each week.

In the meantime I'll use D bindings to FreeImage or similar ilk 
that's gone through the wringer several times over.

Sorry I don't mean to sound harsh but that's the reality I'm in 
right now pushing D on teams in my workplace. It would be much 
simpler if there were quality (idiomatic) D interfaces to 
existing quality C/C++ libraries.

bye,
lobo



 Aug 08 2015



 next sibling parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 8/08/2015 8:05 p.m., lobo wrote:

 On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote:

 *whispers* Hey hey you. You want tests? Well here is something you'll
 like[0]. Oh and check out[1].

 [0] http://www.libpng.org/pub/png/pngsuite.html
 [1] http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx forum.dlang.org


 Well done you've written a library to pass some tests. Now fix the bugs
 that you haven't found yet and scalability issues you aren't aware
 of...the things that really only spring up when you get 1000+ users
 thrashing it each week.

 In the meantime I'll use D bindings to FreeImage or similar ilk that's
 gone through the wringer several times over.

 Sorry I don't mean to sound harsh but that's the reality I'm in right
 now pushing D on teams in my workplace. It would be much simpler if
 there were quality (idiomatic) D interfaces to existing quality C/C++
 libraries.

 bye,
 lobo


I've been saying from the beginning that we need both D implementation 
of some simpler formats such as PNG AND bindings + implementation for 
e.g. FreeImage.

I have NEVER said that we should only use D code. Only an out of the box 
experience must not require external code.

I wish people understood that I'm truly trying to meet people half way. 
That I'm not advocating NIH syndrome in any form and that other 
libraries can benefit us. If used the right way.



 Aug 08 2015



prev sibling  parent  "ponce" <contact toto.com>  writes:


On Saturday, 8 August 2015 at 08:05:27 UTC, lobo wrote:

 Sorry I don't mean to sound harsh but that's the reality I'm in 
 right now pushing D on teams in my workplace. It would be much 
 simpler if there were quality (idiomatic) D interfaces to 
 existing quality C/C++ libraries.


Have you looked at  
http://code.dlang.org/packages/gfm%3Afreeimage ?



 Aug 08 2015



prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 7/08/2015 10:48 a.m., Tofu Ninja wrote:

 On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:

 Here is what we need to do going forward (beyond what me and Manu are
 doing):

 1. Derelict-Util needs to be put into Phobos. This is not optional
 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a
 damn good idea!
 3. Windows API needs to be moved into either Phobos or druntime. Not
 optional.
 4. X11 bindings added to Phobos. Not optional.
 5. Cocoa bindings added to Phobos. Not optional.

 This all needs to happen _before_ we start working on a window library
 for Phobos.
 Let alone a GUI.

 We're mostly got problems with Cocoa. X11 bindings just need to be
 changed to dynamically bound.

 Windows API bindings if gone into druntime wouldn't need to go through
 the review cycle luckily. But would need some decent review on e.g.
 Github.


 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library. Its laughable that the people in D want to
 reinvent this stuff. It's been done, just use the already working
 version! Why have all this great c and c++ interop if we never use it.

 I have the same gripe with how the experimental.image is doing image
 loading/saving, there are plenty of already existing image libraries
 that already support every image format you could ever dream of. Just
 use them, they will work 1000x better than any reinvention that we do here.


Ok, here is what I'm willing to do.
If you are willing to get Derelict-Util into Phobos and create the 
bindings for what ever (appropriate) c-library. I'm willing to create 
the wrappers around it to make it work with the interfaces.

My intention was these to become third party libraries via dub.

Please understand that I want a reasonable experience out of the box and 
not have the same situation we currently have with zlib/curl. Which 
means we do need 1 or 2 image file format implementations and per 
platform a single window/context implementation. It doesn't have to be 
flash or highly customizable. But it does need to work for most people.



 Aug 06 2015



 next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 07-Aug-2015 08:08, Rikki Cattermole wrote:

 On 7/08/2015 10:48 a.m., Tofu Ninja wrote:

 On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote:

 Here is what we need to do going forward (beyond what me and Manu are
 doing):

 1. Derelict-Util needs to be put into Phobos. This is not optional
 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a
 damn good idea!
 3. Windows API needs to be moved into either Phobos or druntime. Not
 optional.
 4. X11 bindings added to Phobos. Not optional.
 5. Cocoa bindings added to Phobos. Not optional.

 This all needs to happen _before_ we start working on a window library
 for Phobos.
 Let alone a GUI.

 We're mostly got problems with Cocoa. X11 bindings just need to be
 changed to dynamically bound.

 Windows API bindings if gone into druntime wouldn't need to go through
 the review cycle luckily. But would need some decent review on e.g.
 Github.


 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library. Its laughable that the people in D want to
 reinvent this stuff. It's been done, just use the already working
 version! Why have all this great c and c++ interop if we never use it.




Both are good ways. From what I see e.g. this attempts to add STL 
bindings to druntime:
https://github.com/D-Programming-Language/druntime/pull/1316

D brings enough to the table to warrant re-writing most of libraries. 
The result typically is smaller, faster and more general, of course, it 
still depends on author's skill. It's important to pick battles though, 
there are thousands of good libraries already out there.


 I have the same gripe with how the experimental.image is doing image
 loading/saving, there are plenty of already existing image libraries
 that already support every image format you could ever dream of. Just
 use them, they will work 1000x better than any reinvention that we do
 here.


 Ok, here is what I'm willing to do.
 If you are willing to get Derelict-Util into Phobos and create the
 bindings for what ever (appropriate) c-library. I'm willing to create
 the wrappers around it to make it work with the interfaces.


Not likely to happen (soon). Nice loaders for shared libraries are 
something that Druntime would very much need, not sure if there is 
something else in Derelic-Util.


 My intention was these to become third party libraries via dub.

 Please understand that I want a reasonable experience out of the box and
 not have the same situation we currently have with zlib/curl.


Truth be told if we were willing to walk extra mile we'd have proper 
curl/zlib experience. But linking problems plague std.net.curl usage and 
both libs are permanently somewhat out of date.


 Which
 means we do need 1 or 2 image file format implementations and per
 platform a single window/context implementation. It doesn't have to be
 flash or highly customizable. But it does need to work for most people.



-- 
Dmitry Olshansky



 Aug 07 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote:

 Truth be told if we were willing to walk extra mile we'd have 
 proper curl/zlib experience. But linking problems plague 
 std.net.curl usage and both libs are permanently somewhat out 
 of date.


boost http is currently in review.



 Aug 07 2015



  parent reply "Suliman" <evermind live.ru>  writes:


On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky 
 wrote:

 Truth be told if we were willing to walk extra mile we'd have 
 proper curl/zlib experience. But linking problems plague 
 std.net.curl usage and both libs are permanently somewhat out 
 of date.


 boost http is currently in review.


Does it's mean that std.net.curl would be replaced by it? Could 
you give link to discussion?



 Aug 07 2015



  parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 07-Aug-2015 11:39, Suliman wrote:

 On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote:

 Truth be told if we were willing to walk extra mile we'd have proper
 curl/zlib experience. But linking problems plague std.net.curl usage
 and both libs are permanently somewhat out of date.


 boost http is currently in review.


 Does it's mean that std.net.curl would be replaced by it? Could you give
 link to discussion?


I guess it's Boost C++ http. Certainly has nothing to do with D and 
anyhow porting the whole C++ Boost (even just the relevant parts) to D 
is quite an effort.

-- 
Dmitry Olshansky



 Aug 07 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Friday, 7 August 2015 at 08:41:11 UTC, Dmitry Olshansky wrote:

 I guess it's Boost C++ http. Certainly has nothing to do with D 
 and anyhow porting the whole C++ Boost (even just the relevant 
 parts) to D is quite an effort.


It is relevant since Boost libraries often are precursors to C++ 
standards and Walter has been clear on C++ compatibility as a 
goal. So it would be a mistake to not look at Boost http before 
designing a pure D http interface.



 Aug 07 2015



  parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 07-Aug-2015 12:16, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 7 August 2015 at 08:41:11 UTC, Dmitry Olshansky wrote:

 I guess it's Boost C++ http. Certainly has nothing to do with D and
 anyhow porting the whole C++ Boost (even just the relevant parts) to D
 is quite an effort.


 It is relevant since Boost libraries often are precursors to C++
 standards and Walter has been clear on C++ compatibility as a goal. So
 it would be a mistake to not look at Boost http before designing a pure
 D http interface.


Already have that it's called vibe.d. There must be other stuff floating 
around as well (e.g.Adam's tiny http server).

-- 
Dmitry Olshansky



 Aug 07 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Friday, 7 August 2015 at 09:43:13 UTC, Dmitry Olshansky wrote:

 Already have that it's called vibe.d. There must be other stuff 
 floating around as well (e.g.Adam's tiny http server).


That's not what I mean. I mean being able to interface with C++ 
counterparts in general. E.g. use the same structures, enums, etc 
on both sides.



 Aug 07 2015



prev sibling  parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Friday, 7 August 2015 at 05:08:27 UTC, Rikki Cattermole wrote:

 Ok, here is what I'm willing to do.
 If you are willing to get Derelict-Util into Phobos and create 
 the bindings for what ever (appropriate) c-library. I'm willing 
 to create the wrappers around it to make it work with the 
 interfaces.


Well we already have DerelictFI (FreeImage), but I completely 
disagree with the premise than having image loaders/savers is 
unworthy NIH. Dropping the number of dependencies is almost 
always worth it in my opinion.



 Aug 07 2015



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 8/6/15 6:48 PM, Tofu Ninja wrote:

 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library.


I agree (though I don't know much about which library would be the best 
choice), at least on the basis of scarce resources. Large ambitious 
projects are a lot more fun to start than complete. -- Andrei



 Aug 07 2015



 next sibling parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu 
wrote:

 On 8/6/15 6:48 PM, Tofu Ninja wrote:

 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing 
 cross
 platform windowing library.


 I agree (though I don't know much about which library would be 
 the best choice), at least on the basis of scarce resources. 
 Large ambitious projects are a lot more fun to start than 
 complete. -- Andrei


Bare windowing libraries that are well tested already exist, like 
GLFW.



 Aug 07 2015



 next sibling parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 8/08/2015 1:07 a.m., rsw0x wrote:

 On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote:

 On 8/6/15 6:48 PM, Tofu Ninja wrote:

 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library.


 I agree (though I don't know much about which library would be the
 best choice), at least on the basis of scarce resources. Large
 ambitious projects are a lot more fun to start than complete. -- Andrei


 Bare windowing libraries that are well tested already exist, like GLFW.


To be fare, the most difficult part about a windowing library, is to 
make it behave identically on all platforms.
For a Phobos out of the box implementation, we only need to get it close 
enough that programs can use it for prototyping.

For anything serious, something like GLFW is definitely a better option. 
As long as we keep it well known about this and a migration path that 
isn't at all hard, I see no problem with doing this.



 Aug 07 2015



prev sibling  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Friday, 7 August 2015 at 13:07:59 UTC, rsw0x wrote:

 On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu 
 wrote:

 On 8/6/15 6:48 PM, Tofu Ninja wrote:

 I really feel like D needs to get over it's "not invented 
 here"
 syndrome, a much easier path would to just use a pre existing 
 cross
 platform windowing library.


 I agree (though I don't know much about which library would be 
 the best choice), at least on the basis of scarce resources. 
 Large ambitious projects are a lot more fun to start than 
 complete. -- Andrei


 Bare windowing libraries that are well tested already exist, 
 like GLFW.


+1



 Aug 07 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu 
wrote:

 On 8/6/15 6:48 PM, Tofu Ninja wrote:

 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing 
 cross
 platform windowing library.


 I agree (though I don't know much about which library would be 
 the best choice), at least on the basis of scarce resources. 
 Large ambitious projects are a lot more fun to start than 
 complete. -- Andrei


The problem is that we get caught up with the API.

The way forward that makes the most sense IMO, is to design some 
nice API and use whatever already exists behind. Less work, 
without the lock in.



 Aug 07 2015



  parent reply "jmh530" <john.michael.hall gmail.com>  writes:


On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote:

 The problem is that we get caught up with the API.

 The way forward that makes the most sense IMO, is to design 
 some nice API and use whatever already exists behind. Less 
 work, without the lock in.


I wouldn't think what you're saying is controversial...just a lot 
of work to do well.

I imagine what you're saying as a two-step process: 1) Get a 
library working with D, 2) Write a "nice API". I would likely get 
stuck on the first one before even getting to the second, but I 
wouldn't want to bore you with how confusing I find the 
documentation on interfacing to C.

Anyway, I was thinking that magicport seems to be very important 
the process of creating ddmd. I would think we should be able to 
leverage this work for interfacing with C. In particular, 
interfacing with C requires the transformation of .h files to .di 
files. My assumption is that magicport is capable of converting 
lots of C++ files to D files, although my recollection of Daniel 
Murphy's talk is that there are some cases where it does not work 
perfectly and he has to adjust things manually. Regardless, if it 
works for C++, it should work for C, maybe even better since C is 
less complicated. So maybe magicport can be used to make it 
easier to get C libraries working with D. Then, you would just 
need to focus on writing the APIs.



 Aug 07 2015



 next sibling parent  "Mike Parker" <aldacron gmail.com>  writes:


On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote:

 Anyway, I was thinking that magicport seems to be very 
 important the process of creating ddmd. I would think we should 
 be able to leverage this work for interfacing with C. In 
 particular, interfacing with C requires the transformation of 
 .h files to .di files. My assumption is that magicport is 
 capable of converting lots of C++ files to D files, although my 
 recollection of Daniel Murphy's talk is that there are some 
 cases where it does not work perfectly and he has to adjust 
 things manually. Regardless, if it works for C++, it should 
 work for C, maybe even better since C is less complicated. So 
 maybe magicport can be used to make it easier to get C 
 libraries working with D. Then, you would just need to focus on 
 writing the APIs.


We already have htod and DStep.



 Aug 07 2015



prev sibling  parent  "karabuta" <karabutaworld gmail.com>  writes:


On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote:

 On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote:

 [...]


 I wouldn't think what you're saying is controversial...just a 
 lot of work to do well.

 [...]


+2000



 Aug 08 2015



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 07/08/15 00:48, Tofu Ninja wrote:


 I really feel like D needs to get over it's "not invented here"
 syndrome, a much easier path would to just use a pre existing cross
 platform windowing library.


A bit more than a windowing library [1]

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg



 Aug 07 2015



prev sibling  parent  "karabuta" <karabutaworld gmail.com>  writes:


On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote:

 On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:

 D is really cool and makes a good candidate for developing a 
 game. Are there any guys out there using D for indie games?

 For some time I have been seeing some cool game engine being 
 developed in the DUB repo. What more is happening? I don't see 
 derelictSDl and derelictSFML activities much. Whatup?


 One thing I would really like for D would be an opengl binding 
 in phobos, there was some momentum a while ago to try to get 
 graphics into phobos with Aurora, but literally nothing came of 
 that. People want an all D gui, and graphics support but 
 literally nothing will ever happen until we at least get some 
 basic graphics interfaces like a simple windowing library and 
 some opengl. We are already getting color and images, full on 
 hw supported graphics is the next step.



Yes, +2000 for a D binding to opengl. That will be really cool 
for game development and plain D GUI tookits. I wish efforts were 
made to implement things like these.



 Aug 06 2015