Firenzina 2.2.2 xTreme, a clone of Fire 2.2 xTreme

[velmarin]

Hi Jose-

the source code is not 2 branches, it's portable
#define WINDOWS (or not)
simply determines the target


Norm

My friend Norman,

I still believe that it is easier to separate.
Could not compile it yourself,
In fact I must admit that I have not had time to look at it.

See Stokfish GitHub, has a dozen branches,
In a work could Dimitry
Mattew the other,
I think it is better idea.


I think we are all somewhat novices.

Anyway thanks for your advice, on
# define Windows
As I said in another post, my first compilation "Ivanhoe" was thanks to a post of yours, then compile a Fire where people complained about the "Time control" just added the option "derided time" you gave him the nod.
And your tips are always welcome.
Frankly, I recognize that this is very good,
# define windows, I had overlooked.

Just kidding, Norman, I like how you write the code, I have set before you, I repeat, I like your Demon, a Cyclone, Robos, Fires, Togas,ect, I feel comfortable in your code, honestly.

Thanks Norman, very Thanks.

[ZirconiumX]

Ok - I can't even use standard ISO C headers.

I can see three possible solutions:

1. Revert the commit and use the half cooked boolean type with bugfixes.
2. Use MinGW (which is standards compliant, but something of a pain to use)
3. Convert to C++, which has a built in bool type.

The choice is Dmitri's (or is it Yuri?).

Matthew:out

[ZirconiumX]

Actually, Jose's idea makes sense. As long as we keep all of the search, eval, etc. the same, we could have different utility code, and if someone needed to compile a Windows and a Linux version, they'd simply substitute the Windows ones for the Linux ones.

One thing I would like is to phase out the #ifdefs which IMO look ugly, and could be replaced with variables instead.

Matthew:out

[Gusev]

Actually, Jose's idea makes sense. As long as we keep all of the search, eval, etc. the same, we could have different utility code, and things like that.

Are we definitely unable to achieve Windows/Linux portability in one code? Because when it comes to changes in search or eval, they'll have to be made two times if we fork. It may be important to do the right thing now.

[ZirconiumX]

Actually, Jose's idea makes sense. As long as we keep all of the search, eval, etc. the same, we could have different utility code, and things like that.

Are we definitely unable to achieve Windows/Linux portability in one code? Because when it comes to changes in search or eval, they'll have to be made two times if we fork. It may be important to do the right thing now.

If we have a common codebase, we'll have to test twice (does it run on Windows, does it run on Linux?) rather than commit twice, and if APIs are kept the same, we won't have much trouble keeping them the same.

But if you want a common codebase, that's fine with me.

Matthew:out

[Gusev]

good luck with Bouquet!

BTW, there should be a quick way to fix Bouquet's time management for time controls shorter than 20 minutes. (For long controls, it works fine, apparently.) How about, take public domain time management code for IvanHoe and use it as follows. If time remaining is below 20 or 15 minutes, use IvanHoe code, otherwise use the native Bouquet code.

[Gusev]

But if you want a common codebase, that's fine with me.

Let's try to keep it common first. If that proves impossible/inefficient, then we'll fork. Should I pull back your initial request at this point? (I have to learn how to use this feature anyhow.)

[ZirconiumX]

But if you want a common codebase, that's fine with me.

Let's try to keep it common first. If that proves impossible/inefficient, then we'll fork. Should I pull back your initial request at this point? (I have to learn how to use this feature anyhow.)

It seems that reverting the merge would be dangerous (it would remove all of my commits, even the useful ones. So instead, I'll create a fix and send you a pull request.

Matthew:out

[ZirconiumX]

But if you want a common codebase, that's fine with me.

Let's try to keep it common first. If that proves impossible/inefficient, then we'll fork. Should I pull back your initial request at this point? (I have to learn how to use this feature anyhow.)

It seems that reverting the merge would be dangerous (it would remove all of my commits, even the useful ones. So instead, I'll create a fix and send you a pull request.

Matthew:out

...like so.

Matthew:out

[Gusev]

Pulled the fix of fix.