Re: Programming a Game in D? :D
On Saturday, 24 May 2014 at 08:54:53 UTC, ponce wrote: Hi David, Learning programming, learning D and learning 3D are 3 significant endeavours. You might want to begin with http://www.basic4gl.net/ which will get you going with 3D, quite a topic in itself. Then learn D regardless :) So, I'v used Blender for a half year or sth. and I think I can make a little area :) As far as I know, I do now need a graphic and physics engines, 1 of the graphic APIs and for sure my programming stuff and here I'm stuck :D And I still can't install Mono-D :( if I try I just get a whole bunch of errors that any packages couldn't be found, don't know if I'm doing sth. wrong (I probably do :P)
Re: Programming a Game in D? :D
On Tuesday, 27 May 2014 at 10:03:36 UTC, David wrote: On Saturday, 24 May 2014 at 08:54:53 UTC, ponce wrote: Hi David, Learning programming, learning D and learning 3D are 3 significant endeavours. You might want to begin with http://www.basic4gl.net/ which will get you going with 3D, quite a topic in itself. Then learn D regardless :) So, I'v used Blender for a half year or sth. and I think I can make a little area :) As far as I know, I do now need a graphic and physics engines, 1 of the graphic APIs and for sure my programming stuff and here I'm stuck :D And I still can't install Mono-D :( if I try I just get a whole bunch of errors that any packages couldn't be found, don't know if I'm doing sth. wrong (I probably do :P) I would STRONGLY advise to go with a ready engine like Unity. You still have to learn a lot before you will have just building blocks to create a game like loading and rendering 3D models, a gameplay framework etc etc. Start with Unity, lean how to make a game there. Learn how to programm gameplay there and after that, when you see what is needed before even being able to make a game, only then try to make things from scratch. Use C# in Unity too as it is similar to D so you will have easier transition when necessary.
What are the best std algo for testing a range implementation ?
Let's say I have a set of containers, using a
D-unfriendly-semantic. They rather use a kind of ADA vocabulary
(according to https://en.wikipedia.org/wiki/Deque). I want to
make them "range-aware".
If the input/output ranges are easy to implement(so it's just
reading/writing an element, keeping an index for the writer and
another for the reader, and reseting it, isn't it ? So if
(isInputRange!MyCont && isOutputRange!MyCont) then it's a
"Deque", right ?).
The bidirectionnal ranges or the forward ranges become more
difficult to interpret with the idioms I
use(Insert,Add,Remove)...Is this a kind of 3rd plane ("time":
"return to previous state", "make a backup": copy/roll-back -
undo/redo ?)
Could you recommend me the algos from std.algo to test
efficiently my implementations ? (example, if you want to be sure
that the input ranges work then you'd use this...if you want to
be sure that output ranges work then you'd use that ...Some kind
of "reference" unit tests ?). At the present time, each time I
try one I get rejected by the template constraints...
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a
D-unfriendly-semantic. They rather use a kind of ADA vocabulary
(according to https://en.wikipedia.org/wiki/Deque). I want to
make them "range-aware".
If the input/output ranges are easy to implement(so it's just
reading/writing an element, keeping an index for the writer and
another for the reader, and reseting it, isn't it ? So if
(isInputRange!MyCont && isOutputRange!MyCont) then it's a
"Deque", right ?).
The bidirectionnal ranges or the forward ranges become more
difficult to interpret with the idioms I
use(Insert,Add,Remove)...Is this a kind of 3rd plane ("time":
"return to previous state", "make a backup": copy/roll-back -
undo/redo ?)
Could you recommend me the algos from std.algo to test
efficiently my implementations ? (example, if you want to be
sure that the input ranges work then you'd use this...if you
want to be sure that output ranges work then you'd use that
...Some kind of "reference" unit tests ?). At the present time,
each time I try one I get rejected by the template
constraints...
I'm not sure, if I understand your question correctly, but I
think what you need are RandomAccessRange's (cf.
http://ddili.org/ders/d.en/ranges.html). You can save their state
and access members randomly. However, as far as I know, the range
itself should not be modified while you iterate over it.
Re: Down the VisualD0.3.38-1.exe ,found virus!
Hi,everyone, down VisulaD from http://rainers.github.io/visuald/visuald/StartPage.html found the virus:Win32.Troj.Undef.(kcloud) Why? Frank https://www.virustotal.com/en/file/bbd76ddb41a80f0526f6cf1e37a2db2736cfa8f29ed3f5fd7a4336bf4c8bbe43/analysis/ Just 5 of 52. Probably a false alarm. Kaspersky IS accepts the installer VisualD-v0.3.38-1.exe without complaint, but after installation removes 'c:\program files (x86)\visuald\visuald.dll' by claiming it as 'UDS:DangerousObject.Multi.Generic'. I don't know how to prevent this removal (and whether I should do so). Version 0.3.37 that was contained in the DMD 2.065 installer could be installed without problem. Do you have any hint?
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a
D-unfriendly-semantic. They rather use a kind of ADA vocabulary
(according to https://en.wikipedia.org/wiki/Deque). I want to
make them "range-aware".
If the input/output ranges are easy to implement(so it's just
reading/writing an element, keeping an index for the writer and
another for the reader, and reseting it, isn't it ? So if
(isInputRange!MyCont && isOutputRange!MyCont) then it's a
"Deque", right ?).
The bidirectionnal ranges or the forward ranges become more
difficult to interpret with the idioms I
use(Insert,Add,Remove)...Is this a kind of 3rd plane ("time":
"return to previous state", "make a backup": copy/roll-back -
undo/redo ?)
Could you recommend me the algos from std.algo to test
efficiently my implementations ? (example, if you want to be
sure that the input ranges work then you'd use this...if you
want to be sure that output ranges work then you'd use that
...Some kind of "reference" unit tests ?). At the present time,
each time I try one I get rejected by the template
constraints...
cartesianProduct is a reasonable test of a forward range.
The first step however is to get your range type to pass the
relevant range checks in std.range (e.g. isInputRange,
isForwardRange etc)
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a
D-unfriendly-semantic. They rather use a kind of ADA vocabulary
(according to https://en.wikipedia.org/wiki/Deque). I want to
make them "range-aware".
If the input/output ranges are easy to implement(so it's just
reading/writing an element, keeping an index for the writer and
another for the reader, and reseting it, isn't it ? So if
(isInputRange!MyCont && isOutputRange!MyCont) then it's a
"Deque", right ?).
The bidirectionnal ranges or the forward ranges become more
difficult to interpret with the idioms I
use(Insert,Add,Remove)...Is this a kind of 3rd plane ("time":
"return to previous state", "make a backup": copy/roll-back -
undo/redo ?)
Just keep in mind that a container is not a range. A container is
an object that can hold items, and you can add and remove items
from said object. The Range is a way to iterate your container.
For example, a range definitely does NOT make insertion, removals
or duplactes of your items. You can "save" a range, but that's
NOT the same thing as making a duplicate of your container that
you can roll back.
I'd suggest you take a look at std.container.array to see what
I'm talking about.
Could you recommend me the algos from std.algo to test
efficiently my implementations ? (example, if you want to be
sure that the input ranges work then you'd use this...if you
want to be sure that output ranges work then you'd use that
...Some kind of "reference" unit tests ?). At the present time,
each time I try one I get rejected by the template
constraints...
If the algos are turning you down, then you must have missed
something. Check that:
alias Range = YourRangeTypeHere;
static assert(isInputRange!Range);
static assert(isForwardRange!Range);
static assert(isBidirectionalRange!Range);
static assert(hasLength!Range);
static assert(isRandomAccessRange!Range);
static assert(hasSlicing!Range);
At the *very least*, the first 3 should pass for a deque. The 3
others depend on what primitives you want to offer.
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 11:43:12 UTC, monarch_dodra wrote:
On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a
D-unfriendly-semantic. They rather use a kind of ADA
vocabulary (according to https://en.wikipedia.org/wiki/Deque).
I want to make them "range-aware".
If the input/output ranges are easy to implement(so it's just
reading/writing an element, keeping an index for the writer
and another for the reader, and reseting it, isn't it ? So if
(isInputRange!MyCont && isOutputRange!MyCont) then it's a
"Deque", right ?).
The bidirectionnal ranges or the forward ranges become more
difficult to interpret with the idioms I
use(Insert,Add,Remove)...Is this a kind of 3rd plane ("time":
"return to previous state", "make a backup": copy/roll-back -
undo/redo ?)
Just keep in mind that a container is not a range. A container
is an object that can hold items, and you can add and remove
items from said object. The Range is a way to iterate your
container.
For example, a range definitely does NOT make insertion,
removals or duplactes of your items. You can "save" a range,
but that's NOT the same thing as making a duplicate of your
container that you can roll back.
I'd suggest you take a look at std.container.array to see what
I'm talking about.
Could you recommend me the algos from std.algo to test
efficiently my implementations ? (example, if you want to be
sure that the input ranges work then you'd use this...if you
want to be sure that output ranges work then you'd use that
...Some kind of "reference" unit tests ?). At the present
time, each time I try one I get rejected by the template
constraints...
If the algos are turning you down, then you must have missed
something. Check that:
alias Range = YourRangeTypeHere;
static assert(isInputRange!Range);
static assert(isForwardRange!Range);
static assert(isBidirectionalRange!Range);
static assert(hasLength!Range);
static assert(isRandomAccessRange!Range);
static assert(hasSlicing!Range);
At the *very least*, the first 3 should pass for a deque. The 3
others depend on what primitives you want to offer.
My Q was not accurate enough. Maybe I'll ask something more
concret in another one. BTW the 2nd and the 3rd assertions are
exactly what fails when I try to test an algo (isInputRange!Range
or isOutputRange!Range pass but has the test doesn't know about
the implementation I can't know If it's really working...I mean
that those tests are just like testing an interface...).
RandomAccessRange / Mobile Elements
Hello, I read in std.range that given a random access range r , r.opIndex(n) should return a reference to the nth element. Is there a qualifier for a "read only" random access range? If not, why? I also don't really get the point of "Mobile Elements", how is "destructively reading" related to mobility, and what is it good for? Thanks.
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 12:18:15 UTC, BicMedium wrote: I mean that those tests are just like testing an interface...). If your interface isn't complete, than it is irrelevant what your implementations are, since the algorithms can't use your ranges anyways. BTW the 2nd and the 3rd assertions are exactly what fails when I try to test an algo (isInputRange!Range or isOutputRange!Range pass but has the test doesn't know about the implementation I can't know If it's really working... Probably you are missing `save`, or you implemented it as a non-property function (though arguably, it shouldn't be a property, but that's another issue).
Re: RandomAccessRange / Mobile Elements
On Tuesday, 27 May 2014 at 13:04:50 UTC, Johann wrote: Hello, I read in std.range that given a random access range r , r.opIndex(n) should return a reference to the nth element. Is there a qualifier for a "read only" random access range? If not, why? The documentation is a bit wrong. It doesn't actually have to be a reference. You may return by value if you want, which is a "form" of read-only access. If you want to return actual const references or elements, you may do so if you so wish, but this would done via the range's type itself, rather than the function. Eg, you'd have "Range" and "ConstRange". It's currently a big subject of discussion. I also don't really get the point of "Mobile Elements", how is "destructively reading" related to mobility If you move something from A to B, then whatever was at A is not there anymore. How is that not destructively reading? and what is it good for? Arguably, performance. If you don't need to re-use your elements at a future date, then instead of creating a duplicate copy via postblit (which could be arbitrarily expensive), we simply move the data, which is much cheaper. Thanks. You're welcome :)
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 14:05:56 UTC, monarch_dodra wrote: On Tuesday, 27 May 2014 at 12:18:15 UTC, BicMedium wrote: I mean that those tests are just like testing an interface...). If your interface isn't complete, than it is irrelevant what your implementations are, since the algorithms can't use your ranges anyways. We agree on this point. The template constrains for isInputRange or isOutputRange just check, at compile-time, if the methods matchings to the prototypes defined in std.ranges (or in std.container empty, popFront, etc...) are implemented. But there could be a templated-unittest for those kind of things...Ranges are relatively straightforward in to use, but when you want to implement one, it's another thing...So it's just about indexes ? And a kind of State machine for indexes (push/pop) ? I hardly get how to make my easy containers range-aware. but I want to, because of std.algo.
Re: Is there any way to differentiate between a type and an alias?
On Sun, 25 May 2014 18:13:17 -0400, Rene Zwanenburg
wrote:
On Sunday, 25 May 2014 at 14:40:06 UTC, Steven Schveighoffer wrote:
On Sun, 25 May 2014 04:04:09 -0700, Rene Zwanenburg
wrote:
Given
alias GLenum = uint;
void glSomeFunction(GLenum, uint);
Now, is there some way to differentiate between GLenum and uint when
using ParameterTypeTuple!glSomeFunction?
I'm writing a function which shows the arguments a GL function was
called with when an error occurs. The GLenum needs to be printed as a
stringified version of the constant's name, while the uint is just an
uint.
An alias is simply another name for the same thing. There is no type
difference.
You may be able to do some template trickery with template aliases to
detect when an alias is used. But I'd recommend using enum instead of
alias:
enum GLenum : uint { constant = value}
This creates a genuine new type, and also gives you a place to put
constants. However, it's not implicitly castable from uint, so it has
some drawbacks. You can cast back to uint implicitly though.
There is also a library typedef mechanism (in std.typecons perhaps?),
you can look into that. It should have the same limitations as enum.
I'm using Derelict as OpenGL binding, so I can't change the API.Derelict
has chosen not to use enum so any C code sample can be used as-is.
I get it. I don't necessarily agree with that, but it's not my library :)
I think it would be difficult to achieve without changing the actual
function definition. Perhaps you could wrap the functions with your own,
and use your own enum type. The enum as I defined it above, should
implicitly cast to uint.
-Steve
Re: What are the best std algo for testing a range implementation ?
On Tuesday, 27 May 2014 at 16:49:42 UTC, BicMedium wrote: But there could be a templated-unittest for those kind of things...Ranges are relatively straightforward in to use, but when you want to implement one, it's another thing...So it's just about indexes ? And a kind of State machine for indexes (push/pop) ? We can't wright a generic unittest to make sure that a range "works". Indeed, depending on *what* your range iterates, the test would be different. You just have to test that yourself. I hardly get how to make my easy containers range-aware. but I want to, because of std.algo. The easiest way is to give your container the "Range opSlice()" function, where Range is the range you defined to iterate on your container. See std.container.array.
Re: Programming a Game in D? :D
On Tuesday, 27 May 2014 at 10:13:13 UTC, Szymon Gatner wrote: I would STRONGLY advise to go with a ready engine like Unity. You still have to learn a lot before you will have just building blocks to create a game like loading and rendering 3D models, a gameplay framework etc etc. Start with Unity, lean how to make a game there. Learn how to programm gameplay there and after that, when you see what is needed before even being able to make a game, only then try to make things from scratch. Use C# in Unity too as it is similar to D so you will have easier transition when necessary. I'd definitely agree. The things you'll learn there will make using something else actually possible. Starting from scratch you'll spend about the first year or so building up the boilerplate to let you actually get to the parts you want. I've built up about half a dozen engines to that point to only lose interest or run into issues with the story I'm trying to tell and stop making progress. That said I'm hoping to have YAGE[1] up and working again with D2 soon which would mean that there should be a nice starting point for building games with D; Even if that starting point is some basic ideas of what doesn't work well.
