Any news on a new GDC version ? (David?)

Seems like there were some things changed
in DMD 0.103 - 0.109, that could be useful ?
And some pending patches for GDC, of course

Is it still awaiting the major rewrites,
like changing GC implementation and fixing
classes that reference each other and such ?


I was toying around with GCC 4.0, but it
looks like the new "GIMPLE" expressions
will require some major rewrites for GDC...

--anders

PS.
Is there a CVS/SVN between the releases ?

Anders F Björklund wrote:
> Any news on a new GDC version ? (David?)
> 
> Seems like there were some things changed
> in DMD 0.103 - 0.109, that could be useful ?
> And some pending patches for GDC, of course
> 
> Is it still awaiting the major rewrites,
> like changing GC implementation and fixing
> classes that reference each other and such ?
> 
> 
> I was toying around with GCC 4.0, but it
> looks like the new "GIMPLE" expressions
> will require some major rewrites for GDC...
> 
> --anders
> 
> PS.
> Is there a CVS/SVN between the releases ?

Still working...  I should probably just get a release out with the accumulated bug fixes and DMD merges.

David

David Friedman wrote:

> Still working...  I should probably just get a release out with the accumulated bug fixes and DMD merges.

Yes, we could all help you test it (possibly even develop) then...

You might want one "stable" release and one development snapshot ?

--anders

In article <cpo8k6$jfc$1@digitaldaemon.com>, David Friedman says...
>
>Anders F Björklund wrote:
>> Any news on a new GDC version ? (David?)
>> 
>> Seems like there were some things changed
>> in DMD 0.103 - 0.109, that could be useful ?
>> And some pending patches for GDC, of course
>> 
>> Is it still awaiting the major rewrites,
>> like cand fixing
>> classes that reference each other and such ?
>> 
>> 
>> I was toying around with GCC 4.0, but it
>> looks like the new "GIMPLE" expressions
>> will require some major rewrites for GDC...
>> 
>> --anders
>> 
>> PS.
>> Is there a CVS/SVN between the releases ?
>
>Still working...  I should probably just get a release out with the accumulated bug fixes and DMD merges.
>
>David

It expects.
Somewhat, even if processing becomes slow, what has short GC time is good.
Since GC time when there are many use memories thinks that it is the hindrance
of spread.

Sakurai

Hiroshi Sakurai wrote:
> In article <cpo8k6$jfc$1@digitaldaemon.com>, David Friedman says...
> 
>>Anders F Björklund wrote:
>>
>>>Any news on a new GDC version ? (David?)
>>>
>>>Seems like there were some things changed
>>>in DMD 0.103 - 0.109, that could be useful ?
>>>And some pending patches for GDC, of course
>>>
>>>Is it still awaiting the major rewrites,
>>>like cand fixing
>>>classes that reference each other and such ?
>>>
>>>
>>>I was toying around with GCC 4.0, but it
>>>looks like the new "GIMPLE" expressions
>>>will require some major rewrites for GDC...
>>>
>>>--anders
>>>
>>>PS.
>>>Is there a CVS/SVN between the releases ?
>>
>>Still working...  I should probably just get a release out with the accumulated bug fixes and DMD merges.
>>
>>David
> 
> 
> It expects.
> Somewhat, even if processing becomes slow, what has short GC time is good.
> Since GC time when there are many use memories thinks that it is the hindrance
> of spread.
> 
> Sakurai
> 
> 


I don't think the translator worked too well on that post. :-)

Most of your other posts have been fairly understandable, though.  So don't give up! :-)

-John

In article <cptq45$13e4$1@digitaldaemon.com>, John Reimer says...
>I don't think the translator worked too well on that post. :-)
>
>Most of your other posts have been fairly understandable, though.  So don't give up! :-)
>
>-John


Thank you John.

I expect your GC very much.
GC time longger is not good in the GAME.
I expect your GC implements time is short.

By the GAME program,
if processing becomes slow then
if GC time becomes short then
good
else
but
else
if GC time becomes short then
good
else
but.

GC time is short is good.
A = Processing becomes slow.
B = GC time becomes short.
A is also easy to be B.

Processing becomes slow is also easy to be GC time becomes short.

It is good if GC time will be short even if processing speed becomes slow.


"Don't give up soul" DE GANBARU!
John too GANBARE!!

I do my best.
Do your best.
Do your best John.
I do my best by "don't give up!" soul.
Do your best by "don't give up!" soul John.

Don't give up!
Don't give up! :-)

-Sakurai

Oh! no!
I mistook.
David and John.
Sorry.

-Sakurai

Hiroshi Sakurai wrote:
> Oh! no!
> I mistook.
> David and John.
> Sorry.
> 
> -Sakurai
> 
> 

:-D

That's okay, Hiroshi.

Your last posts were quite readable!

Have a great day!

:-)

-John

Hiroshi Sakurai wrote:
> In article <cptq45$13e4$1@digitaldaemon.com>, John Reimer says...
> 
>>I don't think the translator worked too well on that post. :-)
>>
>>Most of your other posts have been fairly understandable, though.  So don't give up! :-)
>>
>>-John
> 
> 
> 
> Thank you John.
> 
> I expect your GC very much.
> GC time longger is not good in the GAME.
> I expect your GC implements time is short.
> 
> By the GAME program,
> if processing becomes slow then
> if GC time becomes short then
> good
> else
> but
> else
> if GC time becomes short then
> good
> else
> but.
> 
> GC time is short is good.
> A = Processing becomes slow.
> B = GC time becomes short.
> A is also easy to be B.
> 
> Processing becomes slow is also easy to be GC time becomes short.
> 
> It is good if GC time will be short even if processing speed becomes slow.
> 
> 
> "Don't give up soul" DE GANBARU!
> John too GANBARE!!
> 
> I do my best.
> Do your best.
> Do your best John.
> I do my best by "don't give up!" soul.
> Do your best by "don't give up!" soul John.
> 
> Don't give up!
> Don't give up! :-)
> 
> -Sakurai
> 
> 

^o^

I just want to be clear: I'm not going to change the actual GC algorithm.  What will change is the way the stack and static data segments are found.  The reason for doing this is to remove the dependency on the Java package.

For games, you could try allocating a large pool of memory early on and avoid using the usual allocation routines.  I'm thinking of the "ActorPool" in Kenta Cho's games.

If someone wants to contribute a new GC implementation that, for example, allows different contexts, I could add a --with-gc-impl option to the Phobos configure script.

David