Re: Programming a Game in D? :D
I'm just gonna leave this here: https://github.com/Circular-Studios/Dash I should note that Dash is extremely not 1.0, but we're definitely close. Expect some API changes, though.
Re: Programming a Game in D? :D
On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: Hi, not too sure if there's still someone reading this post, but i do have another question. So, I heared so much good stuff about D, it's powerfull, fast the syntax is nice, but well, why is D actually not used for common games yet? (I mean I know about some smaller projects, but nothing big) A lot of commercial game middleware is already written in C++. Without such third-party libs, it's hard to make a AAA games. Linking to C++ middleware is way easier if your game is in C++ itself. C++ programmers are accustomed to C++ and the ones who weren't flocked to Java, C#, whatever.
Re: Preferred program config file format and parsing library?
On Sunday, 3 August 2014 at 09:31:20 UTC, Marc Schütz wrote: On Saturday, 2 August 2014 at 12:42:00 UTC, Gary Willoughby wrote: What is the preferred format people here use for program config files? Json, Xml, ini, etc? JSON is nice for data exchange, but I dislike it for configuration. It doesn't even support comments, or disabling sections of the file. YML is friendlier in this regard. DUB is considering switching from JSON to SDL: http://sdl.ikayzo.org/display/SDL/Home http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ Interesting, are there D libs available to parse yaml and sdl?
Re: Pointer, if pointed type is unknown?
On Saturday, 2 August 2014 at 20:21:37 UTC, seany wrote: In my previous post (http://forum.dlang.org/thread/jcaomfduqeofobcul...@forum.dlang.org) I asked for an array of pointers to different types, as a stack for my own, where I can generate and insert runtime variables. However, seems like I need to know the type of variable the pointer is pointing to. That is, double pi = 3.14159; size_t ptr = cast(ulong)pi; // so far oky double pi_2 = *ptr; // this is where things break down won't work. What can I do if the type of the variable is not known? I there is a sort of data structure then you can use a type tuple as a map, used to interpret your pointers. However it relies on the context.
Re: Preferred program config file format and parsing library?
On Sunday, 3 August 2014 at 10:54:10 UTC, Gary Willoughby wrote: On Sunday, 3 August 2014 at 09:31:20 UTC, Marc Schütz wrote: On Saturday, 2 August 2014 at 12:42:00 UTC, Gary Willoughby wrote: What is the preferred format people here use for program config files? Json, Xml, ini, etc? JSON is nice for data exchange, but I dislike it for configuration. It doesn't even support comments, or disabling sections of the file. YML is friendlier in this regard. DUB is considering switching from JSON to SDL: http://sdl.ikayzo.org/display/SDL/Home http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ Interesting, are there D libs available to parse yaml and sdl? http://code.dlang.org/packages/dyaml
Re: Programming a Game in D? :D
On Saturday, 2 August 2014 at 20:58:34 UTC, Foo wrote: On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: Hi, not too sure if there's still someone reading this post, but i do have another question. So, I heared so much good stuff about D, it's powerfull, fast the syntax is nice, but well, why is D actually not used for common games yet? (I mean I know about some smaller projects, but nothing big) Because D has a GC, is unstable and has many many bugs (even an ape could find some). I am not in the game industry, but in other time-constrained industry (realtime). For me, it nails down to GC and lack of volatiles. I tried to use it for some scripting, but finally reverted back to simple Bash and some Python. My opinion on the matter is that, in order to succeed, D really must become a tool that could be used everywhere. The discourse that yes, but you could do that part in C (speaking about realtime) usually receives this kind of reply: yes, but, then, why bother? If I have C for this part, I have Bash for the other and C# for the GUIs. As long as it does not try to cover all the range, the differential that it offers wrt C+C#/Java+Bash/Python does not seems conclusive enough to justify the effort. Add to this the quality of tools, which are still in their infancy (just consider dynamic libs, debug support, IDE support, static analysis tools etc.) Well, feel free to destroy it. But I tried to use it at my workplace. It is a nice language, but the differential is simply not enough. The main selling point would be its potential ubiquity (hey, boss, one language to rule them all!), but here it fails short in systems programming, embedded realtime programming and, as far as I hear, in massive multi-threading/couroutines where Go is better. And C# has that async... I agree it is a bit o chicken and egg problem: we don't invest in D because is not popular/ the language is not popular because nobody invest in it. That's true, but, as I tried it, in the end the marginal gain was too small for us to continue on this road. It matters less for us to be able to use slices than it matters to have robust and time-predictable code.
Re: Preferred program config file format and parsing library?
On Sunday, 3 August 2014 at 11:38:47 UTC, John Colvin wrote: On Sunday, 3 August 2014 at 10:54:10 UTC, Gary Willoughby wrote: On Sunday, 3 August 2014 at 09:31:20 UTC, Marc Schütz wrote: On Saturday, 2 August 2014 at 12:42:00 UTC, Gary Willoughby wrote: What is the preferred format people here use for program config files? Json, Xml, ini, etc? JSON is nice for data exchange, but I dislike it for configuration. It doesn't even support comments, or disabling sections of the file. YML is friendlier in this regard. DUB is considering switching from JSON to SDL: http://sdl.ikayzo.org/display/SDL/Home http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ Interesting, are there D libs available to parse yaml and sdl? http://code.dlang.org/packages/dyaml Great, ta.
Re: Programming a Game in D? :D
On Sunday, 3 August 2014 at 05:17:08 UTC, Mike Parker wrote: On 8/3/2014 5:38 AM, David wrote: about platform support, I know the story. But throwing all the weight behind a more-standard back-end would improve things. Yes, it would require some transition effort. But, then, ldc and gdc won't be condemned to play catch-up forever.
Re: Programming a Game in D? :D
On Sunday, 3 August 2014 at 12:37:51 UTC, eles wrote: On Saturday, 2 August 2014 at 20:58:34 UTC, Foo wrote: On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: on this road. It matters less for us to be able to use slices And this while D really nailed down two things very well: strings and templates (I dream that one day C++ will adopt D's syntax for templates...). And scope() too, albeit recently people are talking about its deprecation. We go back to C++'s RAII... Plus, there are some features that never were nailed down and, as long as they remain in fish tail, many will simply just wait for them to be, you know, cleared in a way or another: @property, the recent assert/assume, the allocation in Phobos, the destructors of a class etc. Facing all this stuff, one simply wonders sometimes how other languages managed to stick for a solution and still get some use in real life... Flame or not, too much hesitation on some topics. Yes, much concern to nail them perfectly, I agree. But sometimes is rather paralysis by analysis...
Help with porting grammar from PEGjs to D for dustjs project!
I want to try to implement web template engine dustjs: http://akdubya.github.io/dustjs/ At the first step implementing parser for it's grammar is needed. As far as code for parsing grammar was generated via PEGjs grammar generator the resulting code is enough long (about 4200 lines of code). I though that it is productive way to make porting manually. It's long and something could change in the source JavaScript code. And it will be not so easy to maintain. So I remembered about PEGGED project for D. As I see formats for writing grammar differs for these two systems and I have no experience with using grammar generators. So I need some help with rewriting grammar from PEGjs into PEGGED. Also I don't understand in PEGGED (I have not tried to use it yet) how to generate some logic from AST. Where should I describe it or should I walk around all nodes for somehow and generate code for them. Goal of this is to use dust template system as template engine at server side. I also considered handlebars.js, but I can't evaluate what is more suitable for my purposes. The choice is just very subjective.
auto ref function parameters in a free function
This doesn't work:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a b;
}
Error: auto can only be used for template function parameters
What am I doing wrong? Is this not a template function?
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:07:32 UTC, Vlad Levenfeld wrote:
This doesn't work:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a b;
}
Error: auto can only be used for template function parameters
What am I doing wrong? Is this not a template function?
I think you can just skip 'auto'.
Have a look at http://dlang.org/function.html , especially the
function parameters section.
Re: auto ref function parameters in a free function
This would make the function always take its argument by reference. I'm trying to use the feature here: http://dlang.org/template.html from the section Function Templates with Auto Ref Parameters
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:07:32 UTC, Vlad Levenfeld wrote:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a b;
}
Error: auto can only be used for template function parameters
Works for me with dmd versions back to 2.060. What compiler are
you using?
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:26:28 UTC, anonymous wrote: Works for me with dmd versions back to 2.060. What compiler are you using? dmd 2.065
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:30:38 UTC, Vlad Levenfeld wrote:
On Sunday, 3 August 2014 at 19:26:28 UTC, anonymous wrote:
Works for me with dmd versions back to 2.060. What compiler are
you using?
dmd 2.065
Here's how I'm testing this:
$ dmd | head -n 1
DMD64 D Compiler v2.065
$ cat less_than.d
bool less_than (T)(auto ref T a, auto ref T b)
{
return a b;
}
void main()
{
int a = 1, b = 2;
assert(less_than(a, b));
assert(less_than(a, 2));
assert(less_than(1, b));
assert(less_than(1, 2));
}
$ dmd less_than.d echo ok
ok
If this exact code errors for you, it ... uhh ... could be
platform specific? Are you on Windows?
Threadpools, difference between DMD and LDC
I'm trying to grok message passing. That's my very first foray into this, so I'm probably making every mistake in the book :-) I wrote a small threadpool test, it's there: http://dpaste.dzfl.pl/3d3a65a00425 I'm playing with the number of threads and the number of tasks, and getting a feel about how message passing works. I must say I quite like it: it's a bit like suddenly being able to safely return different types from a function. What I don't get is the difference between DMD (I'm using 2.065) and LDC (0.14-alpha1). For DMD, I compile with -O -inline -noboundscheck For LDC, I use -03 -inline LDC gives me smaller executables than DMD (also, 3 to 5 times smaller than 0.13, good job!) but above all else incredibly, astoundingly faster. I'm used to LDC producing 20-30% faster programs, but here it's 1000 times faster! 8 threads, 1000 tasks: DMD: 4000 ms, LDC: 3 ms (!) So my current hypothesis is a) I'm doing something wrong or b) the tasks are optimized away or something. Can someone confirm the results and tell me what I'm doing wrong?
Threadpools, difference between DMD and LDC
I'm trying to grok message passing. That's my very first foray into this, so I'm probably making every mistake in the book :-) I wrote a small threadpool test, it's there: http://dpaste.dzfl.pl/3d3a65a00425 I'm playing with the number of threads and the number of tasks, and getting a feel about how message passing works. I must say I quite like it: it's a bit like suddenly being able to safely return different types from a function. What I don't get is the difference between DMD (I'm using 2.065) and LDC (0.14-alpha1). For DMD, I compile with -O -inline -noboundscheck For LDC, I use -03 -inline LDC gives me smaller executables than DMD (also, 3 to 5 times smaller than 0.13, good job!) but above all else incredibly, astoundingly faster. I'm used to LDC producing 20-30% faster programs, but here it's 1000 times faster! 8 threads, 1000 tasks: DMD: 4000 ms, LDC: 3 ms (!) So my current hypothesis is a) I'm doing something wrong or b) the tasks are optimized away or something. Can someone confirm the results and tell me what I'm doing wrong?
Re: Help with porting grammar from PEGjs to D for dustjs project!
Uranuz:
http://akdubya.github.io/dustjs/
So I need some help with rewriting grammar from PEGjs into PEGGED.
Is this the grammar?
https://github.com/akdubya/dustjs/blob/master/src/dust.pegjs
If so, then I think I can provide some help. But I don't get what
output you want (see below).
Also I don't understand in PEGGED (I have not tried to use it yet) how to
generate some logic from AST. Where should I describe it or should I walk
around all nodes for somehow and generate code for them.
You can put semantic actions in the grammar (code between curly
brackets). dust.pegjs seems
to have that in their grammar definition also (all these { return
something } blocks)
Or you can walk the parse tree afterwards.
See the Pegged tutorial here:
https://github.com/PhilippeSigaud/Pegged/wiki/Pegged-Tutorial
More particularly:
https://github.com/PhilippeSigaud/Pegged/wiki/Using-the-Parse-Tree
The example explains (I hope) how to use a wiki grammar to parse wiki
text and output LaTeX code.
Goal of this is to use dust template system as template engine at server
side.
More concretely, what's the goal? A template as input and... what
should be output? If I understand correctly, dustjs produces
Javascript code. Is that what you want? Or do you want D code?
Also, did you have a look at vide.d and its Diet templates?
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:25:32 UTC, Vlad Levenfeld wrote: This would make the function always take its argument by reference. I'm trying to use the feature here: http://dlang.org/template.html from the section Function Templates with Auto Ref Parameters I thought I finally saw a question I could (help) answer... What is the benefit of 'auto ref' over 'in' as you are changing a nor b?
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 19:43:53 UTC, anonymous wrote:
If this exact code errors for you, it ... uhh ... could be
platform specific? Are you on Windows?
Debian, and your code works for me. I figured out the problem - I
made less_than to serve as a default sorting predicate, so in a
few places there is something like this:
void sort (R, T = ElementType!R, alias compare = less_than!T)(R
range, T item)
{...}
And since auto ref parameters need actual parameters to deduce
whether they should be ref or not, less_than!T isn't an
instantiated template - its still an alias, because it still must
choose between having ref and value parameters.
So, it looks like I can't use auto ref with less-than. Which is
fine, if I need to quickly compare large structures I will just
pass in a ref_less_than predicate or something.
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 20:10:39 UTC, Martijn Pot wrote: What is the benefit of 'auto ref' over 'in' as you are changing a nor b? Because less_than (T)(T a, T b) (or in, or const T) will copy a and b on their way into the function. Usually this is ok but certain data structures I use are not intended to be copied, or they are just very large or have very elaborate constructors that take up time and resources, or something. I don't know if inlining would solve this or not but as far as I know there is no way to rely on inlining currently.
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 21:24:03 UTC, Vlad Levenfeld wrote: certain data structures I use are not intended to be copied, . although these cases are probably better off being compared by some kind of key rather than directly... so, auto ref isn't necessary here, it was just something I had tried and was surprised at the error message I got.
Re: auto ref function parameters in a free function
On 08/03/14 23:19, Vlad Levenfeld via Digitalmars-d-learn wrote:
I made less_than to serve as a default sorting predicate, so in a few places
there is something like this:
void sort (R, T = ElementType!R, alias compare = less_than!T)(R range, T item)
{...}
void sort (R, T = ElementType!R, alias compare = less_than)(R range, T item)
[should work iff the sort implementation only calls the predicate]
artur
mismatched function return type inference of string and double
So I just started learning D this weekend, and I'm trying to
understand why the following example will not work... Essentially
what I am trying to do is cast the templated child stored in the
parent container as the correct form, return some T value, and
use auto to return the correct value type.. It seems from the
errors I get regarding mismatched return type inference of string
and double, that the compiler, for whatever reason, is assuming
auto is a double?
int main(string[] argv)
{
Parent[] Array;
Array ~= new Child!(double)(3.0);
Array ~= new Child!(string)(text);
foreach(item;Array)
{
auto val = value(item,item.type);
//writeln(std.conv.to!string(value(item,item.type)));
}
return 0;
}
auto value(Parent item, int type)
{
if(item.type == 1)
{
return Fun!double(cast(Child!double)item);
}
else if(item.type==2)
return Fun!string(cast(Child!string)item);
else
return 0;
}
auto Fun(T)(Child!T c)
{
return c.Value;
}
public class Parent
{
int type=-1;
}
public class Child(T) : Parent
{
T value;
public this(T value)
{
this.value=value;
SetType();
}
private void SetType()
{
if(typeid(T) == typeid(int))
type=0;
if(typeid(T) == typeid(double))
type=1;
if(typeid(T) == typeid(string))
type=2;
}
@property public T Value(){return value;}
}
Re: mismatched function return type inference of string and double
On Sunday, 3 August 2014 at 22:01:23 UTC, matt wrote:
auto value(Parent item, int type)
{
if(item.type == 1)
{
return Fun!double(cast(Child!double)item);
Here you're returning a double.
}
else if(item.type==2)
return Fun!string(cast(Child!string)item);
Here you're returning a string.
You're trying to return different, incompatible types depending
on runtime data (`type`). That's not possible. The return type
must be known at compile time.
Re: Threadpools, difference between DMD and LDC
On Sunday, 3 August 2014 at 19:52:42 UTC, Philippe Sigaud wrote: Can someone confirm the results and tell me what I'm doing wrong? LDC is likely optimizing the summation: int sum = 0; foreach(i; 0..task.goal) sum += i; To something like: int sum = cast(int)(cast(ulong)(task.goal-1)*task.goal/2);
Can't build phobos
I am currently working on a phobos fork to include associative ranges, however the unittest fail when i try to build. How am a supposed test any unittests that i add. link:https://github.com/Superstar64/phobos/tree/associative_ranges $ ../dmd/src/dmd |head -1 DMD32 D Compiler v2.066-devel-9d6cef9 0.030s PASS std.algorithm 0.023s PASS std.array 0.034s PASS std.ascii 0.001s PASS std.base64 0.006s PASS std.bigint 0.003s PASS std.bitmanip 0.000s PASS std.complex 0.002s PASS std.concurrency 0.023s PASS std.conv 0.000s PASS std.cstream 0.001s PASS std.csv ** FAIL std.datetime core.exception.AssertError@std/datetime.d(1398): [2012-Apr-30 01:00:00] [2012-Apr-30 00:00:00] generated/linux/debug/32/unittest/libphobos2-ut.so(void std.datetime.SysTime.__unittestL1363_26()+0xd08) [0x41b35ea0] generated/linux/debug/32/unittest/libphobos2-ut.so(void std.datetime.__modtest()+0xdd) [0x41d6e6ed] generated/linux/debug/32/unittest/test_runner(bool test_runner.tester()+0x104) [0x8049524] generated/linux/debug/32/unittest/libphobos2-ut.so(runModuleUnitTests+0xd1) [0x42cce4c1] generated/linux/debug/32/unittest/libphobos2-ut.so(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x2d) [0x42cedd45] generated/linux/debug/32/unittest/libphobos2-ut.so(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x42cedcea] generated/linux/debug/32/unittest/libphobos2-ut.so(_d_run_main+0x152) [0x42cedc5a] generated/linux/debug/32/unittest/test_runner(main+0x14) [0x804968c] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x430a2a83]
spawnProcess command-line arguments help
When I use the spawnProcess function in std.process, the command line arguments that I provide to the function seem to get quoted. Is there a way to tell the spawnProcess function that I want the command line arguments to be non-quoted? Example: spawnProcess([SomePath\\Test.exe], [-silent]); and the command line becomes: SomePath\Test.exe -silent (with the quotes exaclt like shown). Unfortunately (for some strange reason), the spawned process only responds to non-quoted arguments passed through the command line. So the command line should be exactly: SomePath\Test.exe -silent Is there any way to achieve this?
Re: Threadpools, difference between DMD and LDC
On Sunday, 3 August 2014 at 22:24:22 UTC, safety0ff wrote: On Sunday, 3 August 2014 at 19:52:42 UTC, Philippe Sigaud wrote: Can someone confirm the results and tell me what I'm doing wrong? LDC is likely optimizing the summation: int sum = 0; foreach(i; 0..task.goal) sum += i; To something like: int sum = cast(int)(cast(ulong)(task.goal-1)*task.goal/2); This is correct – the LLVM optimizer indeed gets rid of the loop completely. Although I'd be more than happy to be able to claim a thousandfold speedup over DMD on real-world applications. ;) Cheers, David
Re: Threadpools, difference between DMD and LDC
This is correct – the LLVM optimizer indeed gets rid of the loop completely. OK,that's clever. But I get this even when put a writeln(some msg) inside the task. I thought a write couldn't be optimized away that way and that it's a slow operation? Anyway, I discovered Thread.wait() in core in the meantime, I'll use that. I just wanted to have tasks taking a different amount of time each time. I have another question: it seems I can spawn hundreds of threads (Heck, even 10_000 is accepted), even when I have 4-8 cores. Is there: is there a limit to the number of threads? I tried a threadpool because in my application I feared having to spawn ~100-200 threads but if that's not the case, I can drastically simplify my code. Is spawning a thread a slow operation in general?
Re: Help with porting grammar from PEGjs to D for dustjs project!
I am real noob about grammar description languages so I need some explanation about it. As far as I understand expressions in curly bracers are used to modify syntax tree just in process of parsing instead of modifying it after? How I could use PEGGED to map some code to these parsed expressions to generate code that will perform operations defined by this grammar? Should I walk around all the syntax tree and just append code to some string and mix it in then or are there some features for code generation? Something that I was thinking about is comparision of resulting syntax tree to check if it was correctly implemented. It would be great if different gramar parsers will output result in common format (JSON or XML for example) and it will be possiple to compare them for equality. But different parsers have different internal format of tree so maybe creating some transformation is possible. With this feature it could be possible to say if parser is working correctly.
Re: Help with porting grammar from PEGjs to D for dustjs project!
On Mon, Aug 4, 2014 at 7:13 AM, Uranuz via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I am real noob about grammar description languages so I need some
explanation about it. As far as I understand expressions in curly bracers
are used to modify syntax tree just in process of parsing instead of
modifying it after?
Yes, that's it. Or at least that's the way Pegged does it. I'm not
such a specialist myself, I just dabbled in it to write Pegged.
As I understand it, many parsers do not produce a parse tree, they
only 'return' what their embedded action tell them to.
Personally, I have a slight preference to using the parse tree once
it's complete. a) Because that way I have access to all the
information (parent nodes, sibling nodes, even far way) whereas when
doing it with an action means you only have the local, current node
context and b) because it decouples steps that are in my mind
separated anyway: parsing, then producing a value out of the parse
tree. A bit like ranges in D, and Walter and his components
programming speech.
How I could use PEGGED to map some code to these parsed expressions to
generate code that will perform operations defined by this grammar? Should I
walk around all the syntax tree and just append code to some string and mix
it in then or are there some features for code generation?
You can insert semantic actions inside the grammar definition, as is
done by Dustjs, or you can have a function walking the tree
afterwards.
For D, since Pegged works at compile time, you can have your parse
tree at compile time. Use the walking function to generate D code (a
string) and mix it in.
enum parseTree = Grammar(input); // CT parsing
string codeMaker(ParseTree pt) { ... } // recursive walker
mixin(codeMaker(parseTree));
See https://github.com/PhilippeSigaud/Pegged/wiki/Using-the-Parse-Tree
If what you need is generating Javascript code, no need to do that at
compile-time: you can assemble the JS code as a string at runtime and
then write it to a file somewhere, I guess.
Something that I was thinking about is comparision of resulting syntax tree
to check if it was correctly implemented. It would be great if different
gramar parsers will output result in common format (JSON or XML for example)
and it will be possiple to compare them for equality. But different parsers
have different internal format of tree so maybe creating some transformation
is possible. With this feature it could be possible to say if parser is
working correctly.
Different formats and also different languages. I don't see how you
can compare a parse tree that's a D object and another tree made by
dustjs: you never see the AST produced by dust, you only see the
resulting JS code.
Re: auto ref function parameters in a free function
On Sunday, 3 August 2014 at 21:47:06 UTC, Artur Skawina via Digitalmars-d-learn wrote: void sort (R, T = ElementType!R, alias compare = less_than)(R range, T item) [should work iff the sort implementation only calls the predicate] artur This works! Thanks!
