July 13, 2020
Thanks for the suggestions regarding the cyclic dependency, I figured out a way to remove the cycles. It was mostly doing this in each class:

>class Foo
>{
>	static Rand rand;
>	public static this()
>	{
>		rand = new Rand;
>	}
>	public static void setRandSeed(long n)
>	{
>		rand.setSeed(n);
>	}
>}

which I replaced with

>class Foo
>{
>	static Rand rand;
>	public static void setRandSeed(long n)
>	{
>		if (!rand)
>		{
>			rand = new Rand;
>		}
>		rand.setSeed(n);
>	}
>}

Simple and it works!

On Saturday, 11 July 2020 at 20:17:40 UTC, Walter Bright wrote:
> On 7/11/2020 10:52 AM, Remi wrote:
>> On Saturday, 11 July 2020 at 16:23:21 UTC, Adam D. Ruppe wrote:
>>> On Saturday, 11 July 2020 at 16:18:52 UTC, Remi wrote:
>>>> I'm now trying to find docs on the "bit" type.
>>>
>>> it is really the same as bool
>> 
>> Thanks! It seems it was in an old SDL binding (1.x) and I replaced it with SDL_bool, seems to have done the trick. It seems to have been useful in the past to make bitfields for example.
>
> BTW, your work updating it would make for a nice D Blog article. If accepted, you'll even get paid!
>
> Also, if the license of the game permits it, please make it available on github.

I finally got the game to run and I was able to play, up until it crashed. I think just that part of getting up to this point would make a good article. I've started writing a quick draft to see if that's what you'd expect. Where should I contact you regarding the blog post?
July 13, 2020
On 7/13/20 3:45 AM, Remi wrote:
> Thanks for the suggestions regarding the cyclic dependency, I figured out a way to remove the cycles. It was mostly doing this in each class:
> 
>> class Foo
>> {
>>     static Rand rand;
>>     public static this()
>>     {
>>         rand = new Rand;
>>     }
>>     public static void setRandSeed(long n)
>>     {
>>         rand.setSeed(n);
>>     }
>> }
> 
> which I replaced with
> 
>> class Foo
>> {
>>     static Rand rand;
>>     public static void setRandSeed(long n)
>>     {
>>         if (!rand)
>>         {
>>             rand = new Rand;
>>         }
>>         rand.setSeed(n);
>>     }
>> }
> 
> Simple and it works!

This is slightly different. In the first case, rand is initialized even if you don't call setRandSeed. A more correct approach:

public static Rand rand()
{
   static Rand result;
   if(result is null)
       result = new Rand;
   return result;
}

Though it depends on usage -- perhaps a Rand is useless without a seed set?

As I suspected, the static ctor could easily be marked standalone (as in, it can't be part of a cycle, because it doesn't depend on any other module to run). This is quite frequently one of the biggest problems with D's static ctors.

-Steve
July 13, 2020
On Monday, 13 July 2020 at 12:25:33 UTC, Steven Schveighoffer wrote:
>
> Though it depends on usage -- perhaps a Rand is useless without a seed set?
>
> As I suspected, the static ctor could easily be marked standalone (as in, it can't be part of a cycle, because it doesn't depend on any other module to run). This is quite frequently one of the biggest problems with D's static ctors.
>
> -Steve

Interesting, is that a language feature? I found the "shared static constructors" in the documentation which I think could be used here and would achieve the same thing but might also be covered by cyclicity checks, do you know?
July 13, 2020
On Monday, 13 July 2020 at 13:33:45 UTC, Remi wrote:
> On Monday, 13 July 2020 at 12:25:33 UTC, Steven Schveighoffer wrote:
>>
>> Though it depends on usage -- perhaps a Rand is useless without a seed set?
>>
>> As I suspected, the static ctor could easily be marked standalone (as in, it can't be part of a cycle, because it doesn't depend on any other module to run). This is quite frequently one of the biggest problems with D's static ctors.
>>
>> -Steve
>
> Interesting, is that a language feature? I found the "shared static constructors" in the documentation which I think could be used here and would achieve the same thing but might also be covered by cyclicity checks, do you know?

I tried and got the same runtime error regarding cycling dependencies between static constructors/destructors.
July 13, 2020
On 7/13/20 9:33 AM, Remi wrote:
> On Monday, 13 July 2020 at 12:25:33 UTC, Steven Schveighoffer wrote:
>>
>> Though it depends on usage -- perhaps a Rand is useless without a seed set?
>>
>> As I suspected, the static ctor could easily be marked standalone (as in, it can't be part of a cycle, because it doesn't depend on any other module to run). This is quite frequently one of the biggest problems with D's static ctors.
>>
> 
> Interesting, is that a language feature? I found the "shared static constructors" in the documentation which I think could be used here and would achieve the same thing but might also be covered by cyclicity checks, do you know?

The difference between shared and not-shared is that shared constructors run once per program, whereas non-shared constructors run once per thread.

This is D1, so likely it's equivalent to running shared constructors. But it depends on whether there are multiple threads.

There is no feature right now that allows you to mark a ctor as standalone. But the compiler will mark some of them as standalone if it can determine that it's that way.

-Steve
July 19, 2020
On Saturday, 11 July 2020 at 09:37:42 UTC, Remi wrote:
> Hello all,
>
> I found source code for an old game written in D, I'm talking circa 2004 here. It seems like it was written against D v0.110 according to the documentation I found.
>
> My project is to modernise it, maybe make it multiplatform, or even compile to wasm and browser based. But first, I'm trying to compile it as is and I found something odd.
>

I have now made it so it compiles, runs, doesn't depend on old OMF .lib files (except one I can't replace yet). I have also started writing an article about it, it's already 2 parts, and a 3rd in the works hopefully soon. Thanks for all the help!
July 19, 2020
On Sunday, 19 July 2020 at 13:37:30 UTC, Remi wrote:
> On Saturday, 11 July 2020 at 09:37:42 UTC, Remi wrote:
>> Hello all,
>>
>> I found source code for an old game written in D, I'm talking circa 2004 here. It seems like it was written against D v0.110 according to the documentation I found.
>>
>> My project is to modernise it, maybe make it multiplatform, or even compile to wasm and browser based. But first, I'm trying to compile it as is and I found something odd.
>>
>
> I have now made it so it compiles, runs, doesn't depend on old OMF .lib files (except one I can't replace yet). I have also started writing an article about it, it's already 2 parts, and a 3rd in the works hopefully soon. Thanks for all the help!

I look forward to your writings!
1 2 3
Next ›   Last »