Hi,

I just won a three-month-long programming contest (Al Zimmermann's Programming Contest - Alphabet City) using the D programming language as my main tool.  I want to share my happiness, and express my deep gratitude, to the people who work on this tool.  You are a part of what made this a pleasant and educative experience.  Thank you!

The contest is basically about writing a program that plays a solitaire version of Scrabble given a fixed order in which tiles come to the rack.

Links for the interested:
Contest homepage: http://azspcs.net/Contest/AlphabetCity
My contest program, now on GitHub: https://github.com/GassaFM/alphabet-city/
A technical report draft: http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html

On 8/17/2014 5:10 PM, Ivan Kazmenko wrote:
> I just won a three-month-long programming contest (Al Zimmermann's Programming
> Contest - Alphabet City) using the D programming language as my main tool.  I
> want to share my happiness, and express my deep gratitude, to the people who
> work on this tool.  You are a part of what made this a pleasant and educative
> experience.  Thank you!

Congratulations!

On Monday, 18 August 2014 at 00:10:21 UTC, Ivan Kazmenko wrote:
> Hi,
>
> I just won a three-month-long programming contest (Al Zimmermann's Programming Contest - Alphabet City) using the D programming language as my main tool.  I want to share my happiness, and express my deep gratitude, to the people who work on this tool.  You are a part of what made this a pleasant and educative experience.  Thank you!
>
> The contest is basically about writing a program that plays a solitaire version of Scrabble given a fixed order in which tiles come to the rack.
>
> Links for the interested:
> Contest homepage: http://azspcs.net/Contest/AlphabetCity
> My contest program, now on GitHub: https://github.com/GassaFM/alphabet-city/
> A technical report draft: http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html

Cool! Congratulations!

Many years ago I wrote a bot in D which had to play Asteroids for a contest. Unfortunately, because of procrastination I only got 17th place :) But I did get a special mention.

On 18/08/2014 12:10 p.m., Ivan Kazmenko wrote:
> Hi,
>
> I just won a three-month-long programming contest (Al Zimmermann's
> Programming Contest - Alphabet City) using the D programming language as
> my main tool.  I want to share my happiness, and express my deep
> gratitude, to the people who work on this tool.  You are a part of what
> made this a pleasant and educative experience.  Thank you!
>
> The contest is basically about writing a program that plays a solitaire
> version of Scrabble given a fixed order in which tiles come to the rack.
>
> Links for the interested:
> Contest homepage: http://azspcs.net/Contest/AlphabetCity
> My contest program, now on GitHub:
> https://github.com/GassaFM/alphabet-city/
> A technical report draft:
> http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html

Awesome good job!

On 8/17/14, 5:10 PM, Ivan Kazmenko wrote:
> Hi,
>
> I just won a three-month-long programming contest (Al Zimmermann's
> Programming Contest - Alphabet City) using the D programming language as
> my main tool.  I want to share my happiness, and express my deep
> gratitude, to the people who work on this tool.  You are a part of what
> made this a pleasant and educative experience.  Thank you!
>
> The contest is basically about writing a program that plays a solitaire
> version of Scrabble given a fixed order in which tiles come to the rack.
>
> Links for the interested:
> Contest homepage: http://azspcs.net/Contest/AlphabetCity
> My contest program, now on GitHub:
> https://github.com/GassaFM/alphabet-city/
> A technical report draft:
> http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html

Awesome, congratulations! -- Andrei

Ivan Kazmenko:

> My contest program, now on GitHub: https://github.com/GassaFM/alphabet-city/

>dmd bug: wrong file and line for array bounds check<

Did you report the bugs?

Bye,
bearophile

On Monday, 18 August 2014 at 00:10:21 UTC, Ivan Kazmenko wrote:
> Hi,
>
> I just won a three-month-long programming contest (Al Zimmermann's Programming Contest - Alphabet City) using the D programming language as my main tool.  I want to share my happiness, and express my deep gratitude, to the people who work on this tool.  You are a part of what made this a pleasant and educative experience.  Thank you!

Nice, though I don't know how fair it is to have a university professor take part in such a contest. ;)

> Links for the interested:
> Contest homepage: http://azspcs.net/Contest/AlphabetCity
> My contest program, now on GitHub: https://github.com/GassaFM/alphabet-city/
> A technical report draft: http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html

It would be good if you could expand on your thoughts on D from part 11 of your technical report and post it somewhere, so that others can learn from your experience.

On Monday, 18 August 2014 at 07:10:02 UTC, bearophile wrote:
> Ivan Kazmenko:
>
>> My contest program, now on GitHub: https://github.com/GassaFM/alphabet-city/
>
>>dmd bug: wrong file and line for array bounds check<
>
> Did you report the bugs?
>

Yeah, that one got reduced to https://issues.dlang.org/show_bug.cgi?id=13229 .

Anyway, I got only a couple of bugs I could blame the compiler for, and some of that couple disappeared after upgrading to a more recent version.

If I had to remember a language-related problem, the biggest one for me was that my program usually hit an out-of-memory error very soon.  It worked fine when compiled with 64-bit DMD but failed to collect the garbage in time with 32-bit DMD and with recent LDC.  GDC was a minor version behind, so it didn't compile at all from a certain point because of a compiler's stack overflow - same as with e.g. DMD 2.064 or older.  But again, I switched from 32-bit to 64-bit DMD, and the problem vanished, with a little speedup as a nice bonus.

It is not the first time I had an unexpected out-of-memory problem, but it occurs only when my programs get complex, so (1) in each case, I was not sure I can blame the garbage collector, and (2) this is usually hard to reduce.  I'll probably have another try at reduction (but I won't have time for that in the next two weeks).

Ivan Kazmenko.

On Monday, 18 August 2014 at 07:44:14 UTC, Joakim wrote:
>> A technical report draft: http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.html
>
> It would be good if you could expand on your thoughts on D from part 11 of your technical report and post it somewhere, so that others can learn from your experience.

Hmm, the program does contain a few features which are convenient or possible at all because of the choice of language.  For example, I found inner functions and internal iteration (opApply and foreach body converted to a delegate) very useful when iterating over small changes on complex objects.  Still, the examples are very solution-specific, so it would require a bit of thought to convert them to points of general interest.

I'll elaborate a bit.  Suppose we have a large and complex object (a Scrabble game state), and we want to iterate over small changes to that object (single word plays).  In pseudocode, that would be:

(1)
consider object o
for each change to object o:
    yield o

Here, "each change to object" actually spans a few hundred lines in a few inner recursive functions.

The yield must transfer control to another part of the code (also complex) which, for example, accounts for good states.  There are many states generated, but only a few valid and good states get actually copied, so the yield must be by reference to avoid excessive copying.  For example:

(2)
for each o yielded:
    if (o is valid and good):
        copy o to storage

Here, the checks for being valid and good, or maybe some other stuff, can also be long enough.

The catch is that the iteration on changes (which can be one of several possible iteration schemes) must be separated from the use of yielded states (which can again be one of several uses).

After a bit of attempting to simulate yield efficiently for my case, I realized that there is no need for the generator to actually hang in the heap waiting for another call.  The desired flow of the program is non-concurrent: for each o yielded by (1), we process it in the body of (2) immediately and return control right after that.

The concept of delegates makes this possible: (2) can be made a delegate and passed as an argument to (1).  Well, it can be emulated in other languages by passing an object containing the state, but the code would be harder to follow.

The mechanism for inner iteration makes it convenient: just write

foreach (o; call (1) as a function)
    put (2) as a body

and the body (2) is automatically converted into a delegate.  This syntax coincides with my way of thinking about the problem, so I'm delighted to use it.

Ivan Kazmenko.

On 08/18/2014 03:11 AM, Ivan Kazmenko wrote:

> my program usually hit an out-of-memory error very soon.  It
> worked fine when compiled with 64-bit DMD but failed to collect
> the garbage in time with 32-bit DMD and with recent LDC.

That sounds like a false pointer issue. D's current GC is conservative: It takes any value that could be a pointer as a pointer and persists the memory that is falsely being pointed at.

The problem becomes 2^^32 times less likely when pointers are 64-bit wide.

Ali