Re: D for Game Development
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/zxbexpwmirzdkewhq...@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
Re: D for Game Development
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/zxbexpwmirzdkewhq...@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.
Re: D for Game Development
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 ?
Re: pthread_create oddity
On 8/7/15 2:20 PM, Steven Schveighoffer wrote: On 8/7/15 1:36 PM, Andrei Alexandrescu wrote: I ran into an oddity of pthread_create, see https://github.com/D-Programming-Language/druntime/pull/1340. It appears that if stack size is not explicitly set, the 32-bit version of pthread_create fails. That's happening at least on Ubuntu64 under VMWare hosted on Linux. What is the stack size using pthread_getstacksize before the setting of it? I would think with pthread_attr_init, it should be a reasonable default. pthread_getstacksize indicates 8,388,608 bytes. It doesn't seem excessive, but the 32-bit build does find that too big. If I try to set stack size to that value with pthread_setstacksize, indeed the thread fails. So it's not that you need to call pthread_setstacksize, you need to call it with a smaller value. -- Andrei
Proposal : mnemonic for start index for slices
Hi ! I want to add some sugar to D : sometimes it's necessary to use complex start index. For example: auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1]; Proposal is to add a mnemonic for start index, for instance : auto sub = arr[idx + 123 * 10..# + 1]; // # == start index # is for example. Maybe it can be @ or some other symbol. Any ideas ? Should i try to create a DIP ?
Re: Proposal : mnemonic for start index for slices
On 9/08/2015 1:08 a.m., Temtaime wrote:
Hi !
I want to add some sugar to D : sometimes it's necessary to use complex
start index.
For example:
auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1];
Proposal is to add a mnemonic for start index, for instance :
auto sub = arr[idx + 123 * 10..# + 1]; // # == start index
# is for example. Maybe it can be @ or some other symbol.
Any ideas ? Should i try to create a DIP ?
Oh the start value not the start index.
Humm, I'm ok with this. It would pair and match with $ which means end
in regex with ^ meaning start.
Although I'm sure Walter will say no.
import std.stdio;
void main() {
int[] values = [1, 2, 3];
writeln(values[0 .. ^ + 3]);
}
Re: Proposal : mnemonic for start index for slices
On Saturday, 8 August 2015 at 13:08:08 UTC, Temtaime wrote: Hi ! I want to add some sugar to D : sometimes it's necessary to use complex start index. For example: auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1]; Proposal is to add a mnemonic for start index, for instance : auto sub = arr[idx + 123 * 10..# + 1]; // # == start index # is for example. Maybe it can be @ or some other symbol. Any ideas ? Should i try to create a DIP ? auto sub = arr[idx + 123 * 10 .. $][0 .. 1];
Re: Proposal : mnemonic for start index for slices
On Saturday, 8 August 2015 at 13:08:08 UTC, Temtaime wrote: Hi ! I want to add some sugar to D : sometimes it's necessary to use complex start index. For example: auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1]; Proposal is to add a mnemonic for start index, for instance : auto sub = arr[idx + 123 * 10..# + 1]; // # == start index # is for example. Maybe it can be @ or some other symbol. Any ideas ? Should i try to create a DIP ? That would be neat, but the thing is you can already do this: auto sub = arr[idx + 123 * 10 .. $][0 .. 1]; The only argument that might hold weight is that calculating opDollar and doing two index/slice operations might be relatively expensive for some user-defined type.
Re: Visual Studio Code
On 8/7/15 4:07 PM, bitwise wrote: On Monday, 3 August 2015 at 00:24:56 UTC, bitwise wrote: Just stumbled upon this: https://code.visualstudio.com/ I see support for Rust and Go, but no D. If you download it, there is a little smiley/frowny in the bottom right corner for feedback/feature requests. Or just vote here: http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7763160-support-the-d-programming-language Bit Approaching 200 votes! I think at least 500 would be needed for D support to be considered...tell your friends! ;) Great, I popularized the link on Facebook and Twitter and votes seem to be adding up. -- Andrei
Re: Proposal : mnemonic for start index for slices
On Saturday, 8 August 2015 at 13:08:08 UTC, Temtaime wrote: Hi ! I want to add some sugar to D : sometimes it's necessary to use complex start index. For example: auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1]; Proposal is to add a mnemonic for start index, for instance : auto sub = arr[idx + 123 * 10..# + 1]; // # == start index # is for example. Maybe it can be @ or some other symbol. Any ideas ? Should i try to create a DIP ? More sugar is more overhead for new people to learn just to understand code written in the language. Why don't you do: auto startIdx = idx + 123 * 10; auto sub = arr[startIdx .. startIdx + 1]; -Shammah
Re: D for Game Development
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
Re: D for Game Development
On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d 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 >> 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 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
Re: Proposal : mnemonic for start index for slices
On Saturday, 8 August 2015 at 13:08:08 UTC, Temtaime wrote: Hi ! I want to add some sugar to D : sometimes it's necessary to use complex start index. For example: auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1]; Proposal is to add a mnemonic for start index, for instance : auto sub = arr[idx + 123 * 10..# + 1]; // # == start index # is for example. Maybe it can be @ or some other symbol. Any ideas ? Should i try to create a DIP ? this will work but lack of array bundle check. auto sub = (&arr[idx + 123 * 10)[0..1] ;
Re: D for Game Development
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 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 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 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 impor
Re: D for Game Development
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.
Re: D for Game Development
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.
Re: D for Game Development
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.
Re: D for Game Development
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
