Delimiter development diary

[shinkarom]

Converted setboard.cpp.
Only 11 files to go. After that it's a life-long stage of debugging and integrating all of that into a working chess engine.

https://github.com/shinkarom/delimiterc ... ec5790399e

[maksimKorzh]

Converted setboard.cpp.
Only 11 files to go. After that it's a life-long stage of debugging and integrating all of that into a working chess engine.

https://github.com/shinkarom/delimiterc ... ec5790399e

And the most interesting, isn't it)?

[shinkarom]

I don't think so. Debugging is always a pain. Unless you're one of those rare people who prefer hunting for bugs to adding new features.

[maksimKorzh]

I don't think so. Debugging is always a pain. Unless you're one of those rare people who prefer hunting for bugs to adding new features.

New features on top of buggy code leads to collapsing and dropping the project.
In chess programming it's incredibly important to debug every single building block before bringing them all together.
If you're not sure in your building blocks 100% tons of coming bugs would be incredibly tricky to track because
without making sure every building block works 100% correctly in separate it's almost impossible to debug all together.
Well maybe you have the opposite experience at this point, anyway - good luck!

I'd like to obtain a linux executable to test against when you're done.

[shinkarom]

Even so I wouldn't call the integrating stage the most interesting of all. For me the most interesting stage would be after release, when the engine is working (and not much worse than Lime) and I can confidently maintain the code and add new features.
During the integrating stage I would have much anxiety that the project is yet in broken state. Right now I can at least dream that it would all work perfectly right out of the box. After converting all the files the dream will be shattered. And there will be much worrying about all the tiny details that need tweaking before Delimiter is ready to be installed in Arena.

[maksimKorzh]

Even so I wouldn't call the integrating stage the most interesting of all. For me the most interesting stage would be after release, when the engine is working (and not much worse than Lime) and I can confidently maintain the code and add new features.
During the integrating stage I would have much anxiety that the project is yet in broken state. Right now I can at least dream that it would all work perfectly right out of the box. After converting all the files the dream will be shattered. And there will be much worrying about all the tiny details that need tweaking before Delimiter is ready to be installed in Arena.

You're too driven by result. It's perfectly fine for jobs but hobbies are more likely to be the matter of emphasizing
the process rather than result IMO. What you describe leads to having a working engine, ok you'll add a couple
of features but then you'll very quickly reach the limits of it's strength and then the project is doomed to be dropped.
If your goal is to write an engine and never get back to it that such approach is very good but if you're planning
to work on it for years (like most developers here do) than the hurry is a bad thing - it would make more sense to
focus on existing arch so if it's not your own than at very least you know it as if it was your own.

I don't know how Lime is different from Vice but in Vice despite the fact it's the engine I respect the most among all the
others just because it helped me to jump in initially - still now I don't like almost everything in it and I wouldn't base my
engine on Vice - that's the reason why my engines has quite a different approach in arch. Generally saying Vice is a
monolithic engine while I like modularity so that any part of the engine could be easily unplugged and replaced by another one.

Anyway everyone goes his own way so whatever way you go this is probably the best for you, well at very least because it's your choice.

[shinkarom]

You're too driven by result. It's perfectly fine for jobs but hobbies are more likely to be the matter of emphasizing
the process rather than result IMO. What you describe leads to having a working engine, ok you'll add a couple
of features but then you'll very quickly reach the limits of it's strength and then the project is doomed to be dropped.
If your goal is to write an engine and never get back to it that such approach is very good but if you're planning
to work on it for years (like most developers here do) than the hurry is a bad thing - it would make more sense to
focus on existing arch so if it's not your own than at very least you know it as if it was your own.

I don't know how Lime is different from Vice but in Vice despite the fact it's the engine I respect the most among all the
others just because it helped me to jump in initially - still now I don't like almost everything in it and I wouldn't base my
engine on Vice - that's the reason why my engines has quite a different approach in arch. Generally saying Vice is a
monolithic engine while I like modularity so that any part of the engine could be easily unplugged and replaced by another one.

Anyway everyone goes his own way so whatever way you go this is probably the best for you, well at very least because it's your choice.

Who said anything about hurry? I never said I was gonna rush the integration stage. Remember, I said "it's a life-long stage of debugging and integrating all of that into a working chess engine". Only after the necessary work the engine can be released, before it's just a brick.
What ever gave you the idea that I was going to do the integration lightly? It's my reputation at stake. No one will use Delimiter over Lime itself if it's broken.
All I said was that the stage between rewriting the files and release isn't considered the most interesting of all to me. I could name a few more interesting stages.

[shinkarom]

Converted io.cpp
Also added license information to the readme.

https://github.com/shinkarom/delimiterc ... aadea7d92c

[shinkarom]

Converted hash.cpp.

https://github.com/shinkarom/delimiterc ... 14be290d2c

[shinkarom]

Converted doundo.cpp

There are only 8 files left:

• book.cpp
• calc.cpp
• debugit.cpp
• eval.cpp
• movegen.cpp
• movegenlegal.cpp
• perft.cpp
• search.cpp

https://github.com/shinkarom/delimiterc ... 91e35fbcc9