On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
> On 5-2-2013 20:45, Jos van Uden wrote:
> 
>> By the way, I think 'Qznc' may want to have a look at 'The dining
>> philosophers':
>>
>> http://rosettacode.org/wiki/Dining_philosophers

Am I the new rosetta concurency guy? :)

I should find the time to solve it this weekend.

On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
> On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
>> On 5-2-2013 20:45, Jos van Uden wrote:
>> 
>>> By the way, I think 'Qznc' may want to have a look at 'The dining
>>> philosophers':
>>>
>>> http://rosettacode.org/wiki/Dining_philosophers
>
> I should find the time to solve it this weekend.

Wow, my kid let me do some hacking right now and it was simpler than expected.
Posted a solution already.

On Saturday, 16 February 2013 at 07:58:56 UTC, qznc wrote:
> On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
>> On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
>>> On 5-2-2013 20:45, Jos van Uden wrote:
>>> 
>>>> By the way, I think 'Qznc' may want to have a look at 'The dining
>>>> philosophers':
>>>>
>>>> http://rosettacode.org/wiki/Dining_philosophers
>>
>> I should find the time to solve it this weekend.
>
> Wow, my kid let me do some hacking right now and it was simpler than expected.
> Posted a solution already.

Hum...

//----
	Mutex[5] forks = new Mutex();
//----

This will allocate a single Mutex, and place the same reference in all five entries of forks.

In a word: There is actually only one fork. The philosophers can still dine, because a single thread is allowed to lock the same resource twice, making the problem trivial. Basically, they are dual wielding the fork ;)

The correct line of code should be:
//----
	Mutex[5] forks;
	foreach(ref fork; forks) fork = new Mutex();
//----

Or some variation thereof of course. The code still works with this change.

I'm reporting it instead of correcting it directly, so as to better explain how and why.

monarch_dodra:

> I'm reporting it instead of correcting it directly, so as to better explain how and why.

Thank you, some bugs are interesting. I will change the code.

Bye,
bearophile

On 16-2-2013 3:34, bearophile wrote:
> A first revision, do you like the toString?
>
> http://codepad.org/qhH2XpMx
>

It's fine, but we need another write at the end of run otherwise the final state
doesn't get written.

> The modified code contains still an enum that gets converted to char and then to int.
I am not going to write code like that in my own "production code" :-)
>
> - - - - - - - - - - -
>
> To improve this type soup a bit I suggest to introduce one or more alias for the types of states, etc, like:
>
> alias State = char;
>

Good idea. I'll change that.

I'm still not happy with the TuringMachine creation although it looks
more organized than before.

I'm thinking about putting the definitions in xml, then have a parser
create an immutable TuringMachine that we can then pass to UTM. That
would also take care of the nested AA problem. The rules object can
then have a tuple or a struct.

BTW, the reason I used a class is that it forces you to instantiate through
the constructor.

If you use a class and write:

(new UTM().run()); // fails at compile time

If you use a struct and write:

UTM().run(); // fails at runtime

On 16-2-2013 8:58, qznc wrote:
> On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
>> On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
>>> On 5-2-2013 20:45, Jos van Uden wrote:
>>>
>>>> By the way, I think 'Qznc' may want to have a look at 'The dining
>>>> philosophers':
>>>>
>>>> http://rosettacode.org/wiki/Dining_philosophers
>>
>> I should find the time to solve it this weekend.
>
> Wow, my kid let me do some hacking right now and it was simpler than expected.
> Posted a solution already.

Wow, that was quick. Thanks!

Jos van Uden:

> It's fine, but we need another write at the end of run otherwise the final state doesn't get written.

OK. Feel free to fix the code:
http://codepad.org/MvpSET1I

Writing good enough code is an iterative process... And this code will probably need few more iterations.


> I'm thinking about putting the definitions in xml,

Please no :-) Especially in a such small program.


> BTW, the reason I used a class is that it forces you to instantiate through the constructor.
>
> If you use a class and write:
>
> (new UTM().run()); // fails at compile time
>
> If you use a struct and write:
>
> UTM().run(); // fails at runtime

OK, feel free to change back the code to a final class. We'll try to find a better solution in successive iterations.

Bye,
bearophile

Jos van Uden:

> BTW, the reason I used a class is that it forces you to instantiate through the constructor.

One possible solution:
http://codepad.org/9PO8hpI7

Bye,
bearophile

On 16-2-2013 14:04, bearophile wrote:
> Jos van Uden:
>
>> BTW, the reason I used a class is that it forces you to instantiate through the constructor.
>
> One possible solution:
> http://codepad.org/9PO8hpI7

Initializing the struct that way didn't work because I changed the AA back to nested.

This is what I have now (incorperated part of your suggestions):

http://codepad.org/wjaSgppT

Jos van Uden:

> This is what I have now (incorperated part of your suggestions):
>
> http://codepad.org/wjaSgppT

It looks good. It's not a strongly typed code (because states are just chars), and it's not much flexible because UTM is not templated on Symbol and State, but for this task it's OK.

Some small changes:
http://codepad.org/r4NkxTcn

Before putting it in Rosettacode the UTM constructor needs a pre-condition that verifies the full correctness of all its inputs. Then do you want to put it in Rosettacode yourself?

Bye,
bearophile