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 reply "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
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 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 reply "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
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 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 reply 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
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 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 reply 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
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 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 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 "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
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
next sibling parent reply "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
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 reply "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
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 "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 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 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 "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
next sibling 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 reply 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
parent reply "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
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 parent reply 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
parent reply "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
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 reply 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
parent reply "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
next sibling parent reply "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
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
prev sibling parent reply 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
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 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