www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reviving YAGE

reply "Ryan Voots" <simcop2387 simcop2387.info> writes:
I've started a fork of YAGE in an attempt to revive it.  So far 
I'm still working on porting it to build with dub and D2, but 
it's coming along faster than I had expected.  I figured I should 
let people know in case anyone wants to help.

https://bitbucket.org/simcop2387/yage
Jan 29 2014
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 29 January 2014 at 18:07:10 UTC, Ryan Voots wrote:
 I've started a fork of YAGE in an attempt to revive it.  So far 
 I'm still working on porting it to build with dub and D2, but 
 it's coming along faster than I had expected.  I figured I 
 should let people know in case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

I couldn't find anything that says what YAGE is. I suspect a game engine from some of the commits.
Jan 29 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
 I couldn't find anything that says what YAGE is.  I suspect a 
 game engine from some of the commits.

http://yage3d.net/
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Brad Anderson <eco gnuk.net> wrote:
 I couldn't find anything that says what YAGE is.  I suspect a
 game engine from some of the commits.

It looked promising the last time I saw it (which was years ago): http://yage3d.net/
Jan 29 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 but it's coming along faster than I had expected.

Is it already buildable? Any samples work? Nice that you're working on it.
Jan 29 2014
parent JoeCoder <dnewsgroup2 yage3d.net> writes:
On 1/29/2014 3:27 PM, Ryan Voots wrote:
 On Wednesday, 29 January 2014 at 18:15:57 UTC, Andrej Mitrovic wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 but it's coming along faster than I had expected.

Is it already buildable? Any samples work? Nice that you're working on it.

Not buildable yet, but i've managed to get it started building in dub and resolved almost all of the dependencies with it. The only one it's missing is the bindings for GLU directly which i'll likely end up writing out of the engine once it starts compiling and then breaking during linking from unresolved symbols and such. Most of the APIs it used have changed in the 2 years or so since it was last really updated so there's quite a bit of work ahead, and I plan on getting it to GL3+ once it's building and the demos run. The fun part will be to get it to be idiomatic D2 once it's building and working, I imagine that will be a nearly never-ending battle unless someone just rewrites large parts of it (this might end up happening if I get to it). It's definitely got enough of the boilerplate stuff for building a game that doing this port should certainly help me with my project so I figured I'll let it help other's too. That said I've made some good progess these past two days on getting it to build at least so it should hopefully not be much longer (hoping i'll have it building but not running properly in a week or so).

I had planned to remove the dependencies on GLU and port to GL3 as well. You might look into ASSIMP for importing assets and model files. Skeletal animation is broke because I never could get the collada skeleton to lineup with the rest of the model. I was missing a matrix transform somewhere.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Wednesday, 29 January 2014 at 18:15:57 UTC, Andrej Mitrovic 
wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 but it's coming along faster than I had expected.

Is it already buildable? Any samples work? Nice that you're working on it.

Not buildable yet, but i've managed to get it started building in dub and resolved almost all of the dependencies with it. The only one it's missing is the bindings for GLU directly which i'll likely end up writing out of the engine once it starts compiling and then breaking during linking from unresolved symbols and such. Most of the APIs it used have changed in the 2 years or so since it was last really updated so there's quite a bit of work ahead, and I plan on getting it to GL3+ once it's building and the demos run. The fun part will be to get it to be idiomatic D2 once it's building and working, I imagine that will be a nearly never-ending battle unless someone just rewrites large parts of it (this might end up happening if I get to it). It's definitely got enough of the boilerplate stuff for building a game that doing this port should certainly help me with my project so I figured I'll let it help other's too. That said I've made some good progess these past two days on getting it to build at least so it should hopefully not be much longer (hoping i'll have it building but not running properly in a week or so).
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.

It seems cloning from bitbucket seems to be slow for me. Downloading the zipped version of the repo is fast though. Maybe their servers are just slow today, that's all.
Jan 29 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I've started a fork of YAGE in an attempt to revive it.

Most of the links on the yage homepage seem to be dead. But I'm wondering whether any games were made that used Yage?
Jan 29 2014
parent JoeCoder <dnewsgroup2 yage3d.net> writes:
On 1/29/2014 4:05 PM, Andrej Mitrovic wrote:
 Most of the links on the yage homepage seem to be dead. But I'm
 wondering whether any games were made that used Yage?

None worth mentioning. It had too many missing features and I never got it to a complete-enough state.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Wednesday, 29 January 2014 at 21:03:00 UTC, Andrej Mitrovic
wrote:
 On 1/29/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.

It seems cloning from bitbucket seems to be slow for me. Downloading the zipped version of the repo is fast though. Maybe their servers are just slow today, that's all.

I'd agree about moving them to another repo. once I get it working I'll likely look at moving it somewhere else actually. its only in bit bucket because it was easy to fork there. no idea if any games of any substance were made with it. my plan is basically to get the demos going as a test of if the port is done and then work on improving it/adding features. my aims are a top-downish RPG that has been in design for roughly 2/3 of my life (coincidentally when I started programming). many versions made none finished for lack of a developed story but that has changed recently.
Jan 29 2014
prev sibling next sibling parent JoeCoder <dnewsgroup2 yage3d.net> writes:
On 1/29/2014 1:07 PM, Ryan Voots wrote:
 I've started a fork of YAGE in an attempt to revive it.  So far I'm
 still working on porting it to build with dub and D2, but it's coming
 along faster than I had expected.  I figured I should let people know in
 case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

As the original author of Yage, you have my blessing. I always wanted to return to it but never had the time.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Thursday, 30 January 2014 at 20:17:54 UTC, JoeCoder wrote:
 On 1/29/2014 4:05 PM, Andrej Mitrovic wrote:
 Most of the links on the yage homepage seem to be dead. But I'm
 wondering whether any games were made that used Yage?

None worth mentioning. It had too many missing features and I never got it to a complete-enough state.

Even saying that it still appears to be the most complete framework written in D.
 I had planned to remove the dependencies on GLU and port to GL3 
 as well. You might look into ASSIMP for importing assets and 
 model files. Skeletal animation is broke because I never could 
 get the collada skeleton to lineup with the rest of the model.  
 I was missing a matrix transform somewhere.

Good to know about the skeletal animation being broken, that'll help to when testing so I don't scratch my head about where I broke it. And good advice about ASSIMP i'll take a look at it.
Jan 30 2014
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 29.01.2014 19:07, schrieb Ryan Voots:
 I've started a fork of YAGE in an attempt to revive it.  So far I'm
 still working on porting it to build with dub and D2, but it's coming
 along faster than I had expected.  I figured I should let people know in
 case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

How do you deal with GC pause times?
Feb 05 2014
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 22:21, schrieb Ryan Voots:
 At the moment I don't think it really does deal with GC pause times and
 it's one of the things that will need to be dealt with.  I believe it's
 possible (I am still learning much of D) to tell it to not do any GC
 during critical paths which should help keeping it from mangling things
 mid-frame.  There also appears to be some threading support already in
 the engine to do rendering on a seperate thread which should help out at
 keeping frame rates up if the GC can be kept to a minimum there.

 In any case I'm not currently aiming for getting the engine capable of
 300fps with very low latency as it isn't necessary for what I'm after
 though once it's working I certainly won't turn down someone who wants
 to get it that far.

 What I'm hoping to get out of this is more a basic framework for
 relative ease for making games more like say the engine Unity provides
 or some of the other things out there.

If you didn't deal with GC pause times, you will have quite some fun with it. I wrote a small game engine in D, and I ended up running the garbage collector every frame to get stable framerates. Not doing it resultet in 3-10 second pauses during gameplay because of GC collection. http://www.youtube.com/watch?v=mR2EQy3RRyM Because the GC used up to 8 milliseconds every frame (which is 50% for a 60 FPS game), I finally removed the GC from druntime and I'm using a GC free version of D since then. This however comes with maintaining a custom version of druntime and phobos (stripped down to about 10% of the modules) and writing my own standard library. You can read more about the GC issues here: http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut
Feb 05 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 23:39, schrieb Martin Cejp:
 On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut wrote:
 Am 05.02.2014 22:21, schrieb Ryan Voots:
 At the moment I don't think it really does deal with GC pause times and
 it's one of the things that will need to be dealt with.  I believe it's
 possible (I am still learning much of D) to tell it to not do any GC
 during critical paths which should help keeping it from mangling things
 mid-frame.  There also appears to be some threading support already in
 the engine to do rendering on a seperate thread which should help out at
 keeping frame rates up if the GC can be kept to a minimum there.

 In any case I'm not currently aiming for getting the engine capable of
 300fps with very low latency as it isn't necessary for what I'm after
 though once it's working I certainly won't turn down someone who wants
 to get it that far.

 What I'm hoping to get out of this is more a basic framework for
 relative ease for making games more like say the engine Unity provides
 or some of the other things out there.

If you didn't deal with GC pause times, you will have quite some fun with it. I wrote a small game engine in D, and I ended up running the garbage collector every frame to get stable framerates. Not doing it resultet in 3-10 second pauses during gameplay because of GC collection. http://www.youtube.com/watch?v=mR2EQy3RRyM Because the GC used up to 8 milliseconds every frame (which is 50% for a 60 FPS game), I finally removed the GC from druntime and I'm using a GC free version of D since then. This however comes with maintaining a custom version of druntime and phobos (stripped down to about 10% of the modules) and writing my own standard library. You can read more about the GC issues here: http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut

Those numbers are pretty scary. How many objects are you allocating and trashing each frame?

Well, consciously allocating, almost none, only if a new object (like a particle effect) is spawned. But after moving to the no GC version I discovered how many hidden allocations there are. Especially array literals, lambdas, and array concardinationd allocate like crazy. Also phobos functions (format etc). So there where quite many allocations per frame. The allocations per frame don't really matter though, because the runtime of a Mark & Sweep collector does not depend on the amount of Garbage. A Mark & Sweep has to look at all alive objects, so that defines the runtime. And the Problem with a game is, you usually end up with a lot of alive objects and almost nothing of that is garbage. So the GC collect times are constantly high. Kind Regards Benjamin Thaut
Feb 05 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.02.2014 17:39, schrieb Martin Cejp:
 Looks to me like all of those could be worked around. Surely wouldn't
 make the code easier to read, but it shouldn't be *that* difficult.
 Don't append to arrays (use own pre-allocated vector if needed),
 allocate particle structs in bulk with plain malloc, no array literals
 in the hot path etc. No GC allocations = no GC runs

Yes of course you can workaround all these. Its just easier to workaround if you don't have a GC in the first place, and triggering any GC allocation instantly becomes a error.
Feb 06 2014
prev sibling parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
On 2/5/2014 4:27 AM, Benjamin Thaut wrote:
 How do you deal with GC pause times?

I had originally hoped to make the render loop GC-free and have games designed so they only run a gc cleanup when a dialog window was opened. I had been pushing for the nogc attribute so I could easily ensure no collections would occur inside the render loop. I hoped to use freelists for objects so they could be reclaimed after deletion. I was also hoping to push for a time-limited GC collection, e.g. gc.collect(10!msec);. This would run the gc for up to 10 milliseconds and then stop. I would set the time to 16.7ms minus the max of the current physics and render frame times, to ensure it always ran at 60 fps. But I don't know if it's technically possible to construct a GC this way.
Feb 05 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.02.2014 05:42, schrieb JoeCoder:
 On 2/5/2014 4:27 AM, Benjamin Thaut wrote:
 How do you deal with GC pause times?

I had originally hoped to make the render loop GC-free and have games designed so they only run a gc cleanup when a dialog window was opened. I had been pushing for the nogc attribute so I could easily ensure no collections would occur inside the render loop. I hoped to use freelists for objects so they could be reclaimed after deletion. I was also hoping to push for a time-limited GC collection, e.g. gc.collect(10!msec);. This would run the gc for up to 10 milliseconds and then stop. I would set the time to 16.7ms minus the max of the current physics and render frame times, to ensure it always ran at 60 fps. But I don't know if it's technically possible to construct a GC this way.

It is, lua has such a collector. But I'm not sure if it is possbile to do with a impercise collector like D has.
Feb 05 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Wednesday, 5 February 2014 at 09:27:50 UTC, Benjamin Thaut 
wrote:
 Am 29.01.2014 19:07, schrieb Ryan Voots:
 I've started a fork of YAGE in an attempt to revive it.  So 
 far I'm
 still working on porting it to build with dub and D2, but it's 
 coming
 along faster than I had expected.  I figured I should let 
 people know in
 case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

How do you deal with GC pause times?

At the moment I don't think it really does deal with GC pause times and it's one of the things that will need to be dealt with. I believe it's possible (I am still learning much of D) to tell it to not do any GC during critical paths which should help keeping it from mangling things mid-frame. There also appears to be some threading support already in the engine to do rendering on a seperate thread which should help out at keeping frame rates up if the GC can be kept to a minimum there. In any case I'm not currently aiming for getting the engine capable of 300fps with very low latency as it isn't necessary for what I'm after though once it's working I certainly won't turn down someone who wants to get it that far. What I'm hoping to get out of this is more a basic framework for relative ease for making games more like say the engine Unity provides or some of the other things out there.
Feb 05 2014
prev sibling next sibling parent "Martin Cejp" <minexew gmail.com> writes:
On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut 
wrote:
 Am 05.02.2014 22:21, schrieb Ryan Voots:
 At the moment I don't think it really does deal with GC pause 
 times and
 it's one of the things that will need to be dealt with.  I 
 believe it's
 possible (I am still learning much of D) to tell it to not do 
 any GC
 during critical paths which should help keeping it from 
 mangling things
 mid-frame.  There also appears to be some threading support 
 already in
 the engine to do rendering on a seperate thread which should 
 help out at
 keeping frame rates up if the GC can be kept to a minimum 
 there.

 In any case I'm not currently aiming for getting the engine 
 capable of
 300fps with very low latency as it isn't necessary for what 
 I'm after
 though once it's working I certainly won't turn down someone 
 who wants
 to get it that far.

 What I'm hoping to get out of this is more a basic framework 
 for
 relative ease for making games more like say the engine Unity 
 provides
 or some of the other things out there.

If you didn't deal with GC pause times, you will have quite some fun with it. I wrote a small game engine in D, and I ended up running the garbage collector every frame to get stable framerates. Not doing it resultet in 3-10 second pauses during gameplay because of GC collection. http://www.youtube.com/watch?v=mR2EQy3RRyM Because the GC used up to 8 milliseconds every frame (which is 50% for a 60 FPS game), I finally removed the GC from druntime and I'm using a GC free version of D since then. This however comes with maintaining a custom version of druntime and phobos (stripped down to about 10% of the modules) and writing my own standard library. You can read more about the GC issues here: http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut

Those numbers are pretty scary. How many objects are you allocating and trashing each frame?
Feb 05 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut 
wrote:
 If you didn't deal with GC pause times, you will have quite 
 some fun with it. I wrote a small game engine in D, and I ended 
 up running the garbage collector every frame to get stable 
 framerates. Not doing it resultet in 3-10 second pauses during 
 gameplay because of GC collection.

 http://www.youtube.com/watch?v=mR2EQy3RRyM

 Because the GC used up to 8 milliseconds every frame (which is 
 50% for a 60 FPS game), I finally removed the GC from druntime 
 and I'm using a GC free version of D since then. This however 
 comes with maintaining a custom version of druntime and phobos 
 (stripped down to about 10% of the modules) and writing my own 
 standard library.

 You can read more about the GC issues here:
 http://3d.benjamin-thaut.de/?p=20

 Kind Regards
 Benjamin Thaut

I actually saw your webpage after some googling about d's garbage collector. What I'll probably think about doing when I get the engine running is make it easy to do that kind of change like you're doing where you can bring it in and out since it could be great for performance but might really hurt development time. One of the large reasons I wanted to go with D was because of the GC helping deal with a lot of the boilerplate stuff I kept dealing with in previous iterations of the game i'm making (long story short it's had about 30 rewrites/redesigns because i can never make up my mind).
Feb 05 2014
prev sibling next sibling parent "Martin Cejp" <minexew gmail.com> writes:
On Thursday, 6 February 2014 at 06:30:04 UTC, Benjamin Thaut 
wrote:
 Am 05.02.2014 23:39, schrieb Martin Cejp:
 On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut 
 wrote:
 Am 05.02.2014 22:21, schrieb Ryan Voots:
 At the moment I don't think it really does deal with GC 
 pause times and
 it's one of the things that will need to be dealt with.  I 
 believe it's
 possible (I am still learning much of D) to tell it to not 
 do any GC
 during critical paths which should help keeping it from 
 mangling things
 mid-frame.  There also appears to be some threading support 
 already in
 the engine to do rendering on a seperate thread which should 
 help out at
 keeping frame rates up if the GC can be kept to a minimum 
 there.

 In any case I'm not currently aiming for getting the engine 
 capable of
 300fps with very low latency as it isn't necessary for what 
 I'm after
 though once it's working I certainly won't turn down someone 
 who wants
 to get it that far.

 What I'm hoping to get out of this is more a basic framework 
 for
 relative ease for making games more like say the engine 
 Unity provides
 or some of the other things out there.

If you didn't deal with GC pause times, you will have quite some fun with it. I wrote a small game engine in D, and I ended up running the garbage collector every frame to get stable framerates. Not doing it resultet in 3-10 second pauses during gameplay because of GC collection. http://www.youtube.com/watch?v=mR2EQy3RRyM Because the GC used up to 8 milliseconds every frame (which is 50% for a 60 FPS game), I finally removed the GC from druntime and I'm using a GC free version of D since then. This however comes with maintaining a custom version of druntime and phobos (stripped down to about 10% of the modules) and writing my own standard library. You can read more about the GC issues here: http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut

Those numbers are pretty scary. How many objects are you allocating and trashing each frame?

Well, consciously allocating, almost none, only if a new object (like a particle effect) is spawned. But after moving to the no GC version I discovered how many hidden allocations there are. Especially array literals, lambdas, and array concardinationd allocate like crazy. Also phobos functions (format etc). So there where quite many allocations per frame. The allocations per frame don't really matter though, because the runtime of a Mark & Sweep collector does not depend on the amount of Garbage. A Mark & Sweep has to look at all alive objects, so that defines the runtime. And the Problem with a game is, you usually end up with a lot of alive objects and almost nothing of that is garbage. So the GC collect times are constantly high. Kind Regards Benjamin Thaut

Looks to me like all of those could be worked around. Surely wouldn't make the code easier to read, but it shouldn't be *that* difficult. Don't append to arrays (use own pre-allocated vector if needed), allocate particle structs in bulk with plain malloc, no array literals in the hot path etc. No GC allocations = no GC runs
Feb 06 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I've started a fork of YAGE in an attempt to revive it.  So far
 I'm still working on porting it to build with dub and D2, but
 it's coming along faster than I had expected.  I figured I should
 let people know in case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

So, what's the current status of this? Curious!
Mar 31 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ryan Voots"  wrote in message news:asffkvstgjtktahlpciy forum.dlang.org... 

 It'd be really nice if someone knew how to get DMD to spew out 
 EVERY error it finds instead of stopping after the first 100 or 
 so so that I could go fix things in larger chunks.

In mars.c, find the comment //moderate blizzard of cascading messages and disable the condition.
Apr 03 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrej Mitrovic"  wrote in message 
news:mailman.71.1396596046.19942.digitalmars-d puremagic.com...

 We could make this into a hidden switch if it's useful (like the
 various -r/-x/-y switches).

On linux we can detect if stdout is a terminal and only limit the error count then, not sure about windows. Ideally we'd only limit lexer and parser errors and error propagation would take care of the rest.
Apr 04 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Monday, 31 March 2014 at 20:22:57 UTC, Andrej Mitrovic wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I've started a fork of YAGE in an attempt to revive it.  So far
 I'm still working on porting it to build with dub and D2, but
 it's coming along faster than I had expected.  I figured I 
 should
 let people know in case anyone wants to help.

 https://bitbucket.org/simcop2387/yage

So, what's the current status of this? Curious!

Typing fixes everywhere. Work got a little hectic for me so I haven't completed them but I'm at the point now where I have to start implementing changes to the sound code to get it to compile (the API for OGG changed) and OpenGL is in the same state. I started updating things so that the demos build seperately with dub but can't confirm anything about them building as expected yet. It'd be really nice if someone knew how to get DMD to spew out EVERY error it finds instead of stopping after the first 100 or so so that I could go fix things in larger chunks.
Apr 03 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/14, Daniel Murphy <yebbliesnospam gmail.com> wrote:
 In mars.c, find the comment

 //moderate blizzard of cascading messages

 and disable the condition.

We could make this into a hidden switch if it's useful (like the various -r/-x/-y switches).
Apr 04 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/14, Daniel Murphy <yebbliesnospam gmail.com> wrote:
 On linux we can detect if stdout is a terminal and only limit the error
 count then, not sure about windows.

I'm not sure whether the limit was put in place due to terminal limitations. I think it was put there to avoid emitting errors which are caused by other errors. IOW sometimes you just need to fix one error to eliminate a cascade of other errors. That's my experience anyway.
Apr 04 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I
 started updating things so that the demos build seperately with
 dub but can't confirm anything about them building as expected
 yet.

Yeah I've tried running "dub --config=demo1" but I get back: Error executing command run: Unknown build configuration: demo1 I think "subPackages" should be renamed to "configurations" in the dub json file? Either way building tango seems to fail, but I don't know why, all I get back are warnings. I've tried with various recent versions of DMD.
Apr 06 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Sunday, 6 April 2014 at 14:33:38 UTC, Andrej Mitrovic wrote:
 On 4/4/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I
 started updating things so that the demos build seperately with
 dub but can't confirm anything about them building as expected
 yet.

Yeah I've tried running "dub --config=demo1" but I get back: Error executing command run: Unknown build configuration: demo1 I think "subPackages" should be renamed to "configurations" in the dub json file? Either way building tango seems to fail, but I don't know why, all I get back are warnings. I've tried with various recent versions of DMD.

That's interesting. I haven't had any problems with the d2-tango package, but I'm not sure if I've had it rebuild it any time recently, I'll take a look. That's one of the reasons I want to try to deprecate all usage of tango in the engine. Since phobos is trying to move to having no GC allocations in the standard library (or at least be more explicit about it) it should help with keeping things better for soft-realtime requirements for rendering.
Apr 09 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/10/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 That's interesting.  I haven't had any problems with the d2-tango
 package

Which version of the compiler are you using?
Apr 10 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/10/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 4/10/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 That's interesting.  I haven't had any problems with the d2-tango
 package

Which version of the compiler are you using?

Also here's the error log using 2.065: http://codepad.org/UG2hZrwb
Apr 10 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/10/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Also here's the error log using 2.065:
 http://codepad.org/UG2hZrwb

And with 2.064.2: ----- Building tango configuration "static", build type debug. Running dmd... FAIL ..\..\..\Users\Administrator\AppData\Roaming\dub\packages\tango-d2port\.dub\build\static-debug-windows-x86-dmd-DA01CF3B9C085E0DC0B2505668ACA9F6 tango staticLibrary ----- It doesn't even tell me what went wrong..
Apr 10 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 April 2014 at 08:02:19 UTC, Andrej Mitrovic wrote:
 On 4/10/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 4/10/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 That's interesting.  I haven't had any problems with the 
 d2-tango
 package

Which version of the compiler are you using?

Also here's the error log using 2.065: http://codepad.org/UG2hZrwb

builds fine on dmd Git HEAD for me. Is your tango package out of date perhaps? I vaguely remember those errors from a while ago.
Apr 10 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 April 2014 at 09:37:37 UTC, John Colvin wrote:
 On Thursday, 10 April 2014 at 08:02:19 UTC, Andrej Mitrovic 
 wrote:
 On 4/10/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 4/10/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 That's interesting.  I haven't had any problems with the 
 d2-tango
 package

Which version of the compiler are you using?

Also here's the error log using 2.065: http://codepad.org/UG2hZrwb

builds fine on dmd Git HEAD for me. Is your tango package out of date perhaps? I vaguely remember those errors from a while ago.

To clarify: Tango builds fine, Yage does not.
Apr 10 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/10/14, John Colvin <john.loughran.colvin gmail.com> wrote:
 Is your tango package out of date perhaps?

All I'm doing is calling 'dub --force'. Tried with git-head and getting the same results. Oh well..
Apr 10 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Thursday, 10 April 2014 at 10:52:42 UTC, Andrej Mitrovic wrote:
 On 4/10/14, John Colvin <john.loughran.colvin gmail.com> wrote:
 Is your tango package out of date perhaps?

All I'm doing is calling 'dub --force'. Tried with git-head and getting the same results. Oh well..

Try wiping out your ~/.dub/ directory (move it out of the way). I ran into that after playing with the package.json to try to get the library to build now that it appears that dmd isn't giving any errors anymore. This'll force dub to fetch the files again and it should work with 2.065. That said, I've now hit an impasse where I'm lost as to what to do again. I'll likely go through and clean up some warnings tomorrow and get the build to look cleaner but at this point I'm not sure how to get dub to do what we need (linking in demo*/ directories as separate executables). You might be right about specifying them as separate configurations in there I'll experiment some more tonight but we're very close to having it build now. I don't expect it to work correctly even if someone does get it running. I've marked a number of suspect places with TODO in comments where I know things are going to break since I didn't know what I was doing.
Apr 12 2014
prev sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Thursday, 10 April 2014 at 09:46:15 UTC, John Colvin wrote:
 To clarify: Tango builds fine, Yage does not.

This is no longer the case now. It builds fine and you can build the first demo with DMD (it runs into bzip2 errors with GDC for me right now). The demo doesn't run yet but it does build and now has me ready to learn how to debug a D program. you can build the demo as a sub package, with dub build yage:demo1
Apr 14 2014