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