New J.A Compiles

[Frank Quisinsky]

NOD (Eset) detected GenKryptik.HPSN
Petrel 2.4 / 3.4 versions!

Can be used if ignore but should be fixed!

[Jim Ablett]

NOD (Eset) detected GenKryptik.HPSN
Petrel 2.4 / 3.4 versions!

Can be used if ignore but should be fixed!

Hi Frank,
Looks like the problem is with Eset not my files >

petrel_34_64_ja.zip:
https://www.virustotal.com/gui/file/ee5 ... ?nocache=1

petrel_24_pst_64_ja.zip
https://www.virustotal.com/gui/file/9e6 ... ?nocache=1

Jim.

[Frank Quisinsky]

Hi Jim,

think so.
Unfortunately, the fourth engine ... not the fourth JA files.
I have around installed 600 on my test PC.

It doesn't matter, but it's annoying because I have to rule it out.

And one GitHub site ...
PZChessBot ... Eset doesn't like.
Bad for my automatic update check.

Thanks for your your Petrel compiles.

BTW:
Maybe you have time for Igel 3.6.4.
Should be faster as Igel 3.6.3 if I understand.

Best
Frank

[Jim Ablett]

Hi Jim,

think so.
Unfortunately, the fourth engine ... not the fourth JA files.
I have around installed 600 on my test PC.

It doesn't matter, but it's annoying because I have to rule it out.

And one GitHub site ...
PZChessBot ... Eset doesn't like.
Bad for my automatic update check.

Thanks for your your Petrel compiles.

BTW:
Maybe you have time for Igel 3.6.4.
Should be faster as Igel 3.6.3 if I understand.

Best
Frank

Report issues to Eset. They should fix it.
I'm only compiling official releases of engines from now on, not dev versions.

Jim.

[Frank Quisinsky]

Hi Jim,

goes automatically to Eset with Ultimate edition and "Standard Settings".

Your decsion but often dev versions can be interesting!

Honestly, we have no dev, no beta, alpha, cesar, delta, pre-versions so long programmers added new sources on a site.
They must not do it, if they not wish that others create the compiles.

Exactly this one made no sense if a version isn't ready for a test, means to add the sources on GitHub.

Furthermore, it make sense to test dev versions, as reason that the programmer get receives feedback; perhaps a bug has crept into a so-called dev build. The opinions by programmers about it is clearly different. It is no longer possible to come up with a nonsensical rule.

To test so-called release versions in computer chess ... is pure nonsens.
Comes from CEGT / CCRL testers like for an example to test non-public versions of engines. That is also bullshit in my opinion.

dev versions has to be decided on a case-by-case basis!
A good example is your last RubiChess build.

On the other hand I can understand it ... with all the dev versions to many things are to test. We have around 20-25 releases by months from TOP-250 engines and new engines every month.

If each day a new dev is available, it make no sense to compile it again and again. In this point I share your view. Thinking on all the compiles a clearly improvement is to see, Laser for an example ... 30 Elo higher.

My personal opinion about it.
Again, your decision, absolutely clear!

All it takes is a little tact!!

Best
Frank

And:
To compile each months a new Petrel ...
After my logic ... such things made also no sense.
Or all the rating list are full of Petrel versions ... to the topic ... release versions only.
12 in the year x2 versions = 24 version to test.
Time can be used for others better!

[Aleks Peshkov]

Jim makes own patches to source code and it is waste of time to work on source code that can radically change at any moment. And many developers prefer to not distribute their half cooked intellectual products that can potentially shadow their future stable versions.

[Frank Quisinsky]

That’s probably true. There are always good arguments for everything.

But now:
I have to report a bug in the release version of Tcheran 11.0, you know!