Re: [Bug-gnubg] The future of Windows builds / Https etc.

[Michael Petch]

On 2015-01-14 7:43 AM, Ian Shaw wrote:
> How about simplifying life and offering only Mersenne Twister, manual and, 
> possibly, file dice?
> 

In principle I do agree with you on reducing/eliminating code.
Random.org is something that I end up referring people to most when they
don't trust PRNG's. If this was just me personally, then I'd say that
Mersenne, Manual, File would be all that is needed. If you want one of
the other PRNGS you could generate a file. The problem with generating a
file is that many novices may not be tech savvy enough to create afile
from a source like Random.org .

I answer a lot of hate mail regarding the dice and the Random.org is at
least a fall back for me to provide an answer for those who are
unwilling to enter the dice manually but don't want a PRNG.


> GnuBg and other bots are now mature programmes, and think we need to go to 
> the same lengths to convince people that the dice are fair. Sure, there will 
> always be some doubters, but such people won't be convinced by anything. No 
> established player has qualms. 

We do agree here. The people who think the bots cheat will likely not be
convinced no matter what the source of randomness. If you came up with a
solution for the randomness they'd find some other way to claim the bot
cheats. I think that most (not all) established players do understand
the issues.

> 
> Multiple dice algorithms just feels like feature bloat to me, to no benefit. 
> For example, rollouts always use MT, and, when posted on the forums I read,  
> there has never been a query raised.
>

If I were to eliminate one feature altogether it would be "Dice
Manipulation". To me this gives very poor optics and has been the source
of some criticism. The argument goes "if there is a dice manipulation
feature then it follows that the bots know how to manipulate the dice,
so they are probably already doing so during normal play." .

> Getting rid of the other algorithms would simplify the code, the UI and the 
> rollout export data, not to mention the https issues you've been debating.
> 

I haven't looked at the rollout export data so can't comment. As for
'https' the real issue here is that since I took over building the
official MS Windows releases (quit a few years now) I have only upgraded
the build environment once. That was when I first took on the task and
migrated to MSYS/MinGW. I didn't alter it after because I believe in the
adage "If it's not broke don't fix it".

The `https` issue only really highlighted the fact that the MSYS/MinGW
development environment I had (and it was quite the hack still) was long
in the tooth. One of the reasons I hadn't migrated to something else was
that there was no pressing need to. After the whole Random.org saga I
decided to see what options I had that create a more maintainable build
environment.

I've now settled on MinGW-w64/MSYS2 . In theory one can build 32 and 64
bit variants(although I'll stick with 32 bits as a common denominator).
I have managed to build a feature complete version of GNUbg including
Language&Translation processing;Documentation generation;3D boards;Long
RNG seeds;Python2(2.7.9);Sound;Multi Threading(using GLIB Threads);
External interface and SIMD(AVX/SSE/SSE2/None);Uses libcurl/gnutls to
access Random.org (less code as well). It also successfully compiles as
the command line variant.

Some other benefits of spending all this time on a new build environment
based on MinGW-w64/MSYS2 is that Python3 also becomes available to us
(And as of last year we do have Python3 support). We also get more up to
date libraries (especially GTK/Cairo/Pango/GLIB); the speed of builds is
vastly quicker; doesn't suffer from a serious memory leak when
compiling; should be cross compilable from a Linux distribution as build
host; ability to build a lot more libraries natively given that MSYS2
uses pacman as a package manager and the number of
applications/libraries that are supported are pretty reasonable; we no
longer rely on MSVC runtimes.

Although I can build GNUbg it requires some code changes. There are some
macros/function redefinition problems, missing prototype that I manually
tweaked, but the best solution is to modify the configure.ac to properly
detect these conditions and provide #define's in config.h to deal with
them. The INNO installer requires some modifications.

So although `https` was a pain in the ass (and mor work than it should
have been), I think the end result is positive for the project from an
MS Windows development perspective.

-- 
Michael Petch
GNU Backgammon Maintainer / Developer
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304