digitalmars.D - Won a programming contest using D - Thank you for the tool!
- Ivan Kazmenko (16/16) Aug 17 2014 Hi,
- Walter Bright (2/7) Aug 17 2014 Congratulations!
- Vladimir Panteleev (5/21) Aug 17 2014 Cool! Congratulations!
- Rikki Cattermole (2/16) Aug 17 2014 Awesome good job!
- Andrei Alexandrescu (2/16) Aug 17 2014 Awesome, congratulations! -- Andrei
- bearophile (4/7) Aug 18 2014 Did you report the bugs?
- Ivan Kazmenko (22/27) Aug 18 2014 Yeah, that one got reduced to
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (6/9) Aug 18 2014 That sounds like a false pointer issue. D's current GC is conservative:
- Ivan Kazmenko (19/30) Aug 19 2014 Hmm, that might be it, thank you for the tip.
- safety0ff (6/9) Aug 19 2014 GC.BlkAttr.NO_INTERIOR can also be useful for eliminating false
- deadalnix (2/14) Aug 19 2014 http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using...
- Joakim (6/19) Aug 18 2014 Nice, though I don't know how fair it is to have a university
- Ivan Kazmenko (49/54) Aug 18 2014 Hmm, the program does contain a few features which are convenient
- Ivan Kazmenko (45/50) Aug 19 2014 The contest is open for everyone. For example, Tomas Rokicki
- Joakim (4/8) Aug 19 2014 No hurry. Put some thought into how D actually helped you win
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
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
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.htmlCool! 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
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.htmlAwesome good job!
Aug 17 2014
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.htmlAwesome, congratulations! -- Andrei
Aug 17 2014
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
On Monday, 18 August 2014 at 07:10:02 UTC, bearophile wrote:Ivan Kazmenko: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.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?
Aug 18 2014
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
On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:On 08/18/2014 03:11 AM, Ivan Kazmenko wrote: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.my program usually hit an out-of-memory error very soon. It worked fine when compiled with 64-bit DMD but failed tocollectthe 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.
Aug 19 2014
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
On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:On 08/18/2014 03:11 AM, Ivan Kazmenko wrote:http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/my program usually hit an out-of-memory error very soon. It worked fine when compiled with 64-bit DMD but failed tocollectthe 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 19 2014
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.htmlIt 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
On Monday, 18 August 2014 at 07:44:14 UTC, Joakim wrote: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.A technical report draft: http://acm.math.spbu.ru/~gassa/az/alphabet-city/technical-report.htmlIt 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
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
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