www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Won a programming contest using D - Thank you for the tool!

reply "Ivan Kazmenko" <gassa mail.ru> writes:
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
Aug 17 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Aug 17 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Aug 17 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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!
Aug 17 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 17 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 18 2014
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
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.
Aug 18 2014
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Aug 18 2014
next sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:
 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.
Hmm, that might be it, thank you for the tip. I suppose there is a way to disable scanning certain parts of memory for possible pointers. Still, the core.memory documentation speaks a lower-level language than I'm currently familiar with. A quick look on your book's memory management chapter provided some explanation but still didn't enlighten me on this specific problem. It looks like I want to have most of my data under something like GC.BlkAttr.NO_SCAN. But I don't yet see a clean way to introduce something like that in the code. It seems like I want a custom allocator, but various pages show they existed in D1 and are now deprecated in D2. And perhaps there is also a granularity problem: I have classes containing structs and structs pointing to classes, so struct data (single bytes to hundreds of bytes) lies next to class pointers most of the time. So, is there a tutorial on how to better hint the D garbage collector? Ivan Kazmenko.
Aug 19 2014
parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 19 August 2014 at 17:39:13 UTC, Ivan Kazmenko wrote:
 It looks like I want to have most of my data under something 
 like GC.BlkAttr.NO_SCAN.  But I don't yet see a clean way to 
 introduce something like that in the code.
GC.BlkAttr.NO_INTERIOR can also be useful for eliminating false pointers pointing into large structures. It only works when you know that there is always a pointer to the base of the object while it is "alive." N.B. That attribute is ignored for small allocations.
Aug 19 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:
 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
http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
Aug 19 2014
prev sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
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.
Aug 18 2014
next sibling parent "Ivan Kazmenko" <gassa mail.ru> writes:
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.
Aug 18 2014
prev sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 18 August 2014 at 07:44:14 UTC, Joakim wrote:
 Nice, though I don't know how fair it is to have a university 
 professor take part in such a contest. ;)
The contest is open for everyone. For example, Tomas Rokicki (one of the previous contests' winners) is a member of the "God's number is 20" band (see http://www.cube20.org/). Besides, formally speaking, I don't have a PhD.
 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.
Another notably useful feature for such applications is the scope statement. It is generally useful for any complex search recursively iterating over changes to combinatorial objects. My contest code gives a count of 65 to a "grep 'scope (exit)' | wc" command. Again, with the scrabble board example, a play is constructed recursively: we put a letter from the rack into some cell and move towards the next cell. In code: play (row,col): 1. check if we have a word ... 2. put letter to (row,col) 3. remove letter from the rack 4. recursively call play (row,col+1) ... and whatnot ... 5. erase letter from (row,col) 6. restore letter in the rack As the code gets complex, the semantic dependence between lines 2-3 and lines 5-6 (the latter canceling out the former) may suffer from the blocks moving further apart, preliminary returns from the function appearing in between, and needing a change to the blocks. With scope statement, they can be kept close together, and are guaranteed to work if a preliminary return occurs. Again in pseudocode: play (row,col): 1. check if we have a word ... 2. put letter to (row,col) 3. remove letter from the rack scope (exit): 5. erase letter from (row,col) 6. restore letter in the rack 4. recursively call play (row,col+1) ... and whatnot ... ----- Indeed, you seem to be right that these points can be converted to a text of some interest to general audience. But that's a task for a few weeks later, as I'm busy with other stuff until the beginning of September. Ivan Kazmenko.
Aug 19 2014
parent "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 19 August 2014 at 17:19:40 UTC, Ivan Kazmenko wrote:
 Indeed, you seem to be right that these points can be converted 
 to a text of some interest to general audience.  But that's a 
 task for a few weeks later, as I'm busy with other stuff until 
 the beginning of September.
No hurry. Put some thought into how D actually helped you win and I think whatever you write would be a nice showcase for the language. Looking forward to reading it. :)
Aug 19 2014