Freecell Solver 3.14.1 was Released

Freecell Solver version 3.14.0, shortly followed by Freecell Solver 3.14.1, which fixed a build problem on Microsoft Windows, have been released. Freecell Solver 3.14.1 is available in the form of a source archive, and a Win32 self-installing executable, from the download page. Freecell Solver is an open source framework (library and some command line applications), for automatically solving several variants of card Solitaire / Patience games, including Freecell.

This release features several new features: we added a 6th Best-First-Search weight of the inverse of the number of cards not above parents, which has proven useful. We now also allow test groups inside the --tests-order and --depth-tests-order with the random-dfs scan to be ordered using the function =asw(…) based on those BeFS weights.

As a result, the preset -l amateur-star or -l as for short has been added, that uses that and is our fastest preset yet. Another new preset is -l micro-finance (or -l mf for short), which yields especially short solutions.

There are also some not-as-major features: input boards can now contain a leading colon (":") at the beginning of the line of columns, so they can be copy-and-pasted directly from the output of fc-solve with the -p flag. The dbm_fc_solver and depth_dbm_fc_solver now store the positions more compactly (which aided in researching two-freecell deals), and the core libfreecell-solver code was made more 64-bit enabled and many of the limits were converted to 64-bit friendly ones.

A final note: we have dropped support for building Freecell Solver with Microsoft Visual C++ and other non-GCC compatible compilers, which do not support the newer C standards, and other useful features of GCC. Building Freecell Solver with GCC, clang and other compatible compilers will be continued to be supported on Microsoft Windows as well as on Linux and other UNIX-like systems.

More information about all these can be found in the distributed documents of Freecell Solver.

Enjoy!

Freecell Solver 2.32.0 was Released

Freecell Solver version 2.32.0 has been released. It is available in the form of a source tarball from the download page.

This version features a large code cleanup which also resulted in a substantial speed boost. The code cleanup was guided by a script that was written to list all occurrences of identifiers with the same name, in order to find uncommon identifiers.

There were several bug-fixes done to the CMake-based build system, and there's now support for Google's tcmalloc and hidden internal identifiers in the DLL/shared-library. The inline keyword for defining inline functions is now supported on more compilers and more functions or macros have been converted to inline functions.

We hope you enjoy this release.

Adventures in Compiling

I've generally been using GCC (= The GNU Compiler Collection) exclusively for compiling Freecell Solver under Linux for its constant development. For a time, I used to compile the Windows binaries using Microsoft Visual C ("cl.exe") and a really hideous batch file I wrote for the purpose (so it would work on the Technion's computers). Lately, however, I've switched to compiling using MinGW on Windows, which is gcc based.

A few weeks ago, I decided to try out other compilers and see what they had to offer. I downloaded the proprietary icc (Intel's C Compiler), which is gcc-compatible and has a Linux trial version. It was a huge download and ended up occupying a lot of space on the hard-disk. At first, I could not get it to emit working code, but after messing a little with my makefiles, I was successful. It is about the same speed as gcc for compiling my ANSI C program (maybe a bit slower), and generates somewhat faster code.

.

icc kept emitting many of the so-called "remarks" which I eventually took upon myself to eliminate. This improved the quality of my code. But it worked properly with these many remarks being emitted. After installing icc, msec (the Mandriva security mechanism) complained about world-writable files in the icc installation, so I reported it on the Intel forum.

The next compiler I tried was tcc, the Tiny/Turbo C Compiler. The version in the Mandriva repositories was old and did not yield a working binary, and so I tried upgrading to version 0.9.24 and then to the git version, but none of them worked either. I reported this attempt to the tcc mailing list.

I also tried icc's -fast flag, which is supposed to make the output faster, but it actually made the binaries slower (much slower than even gcc).

However, later on, after cleaning up my makefile, tcc produced perfectly working binaries. I don't know what the problem was, but it was solved. (I reported that in a reply). Compiling with tcc is much faster than with gcc, but the resulting code is much slower than gcc's, and occupies more space on the disk.

The next compiler was TenDRA. Now the homepage a 403 (and still does) and so I went on Freenode and asked. I eventually did:

$ svn co http://svn.tendra.org/trunk/

Only to discover that http://svn.tendra.org/trunk/tendra/INSTALL is empty except for a reference to the Trac web-site (which was also off-line). So I needed to use the guidance of the people from Freenode's #tendra to build it.

In the process, I had to install bmake, because that's the only make that would compile TenDRA. The ./configure in the standard distribution failed to work here, but I was able to find an .src.rpm which compiled and installed fine. The TenDRA boot process also complained about one of my system's header which had a list or enum with a trailing comma, and I had to manually fix the code.

But I was able to build TenDRA and install it, and it was able to compile a working program. Before it did, though, I had to fix many compilation errors it reported, as TenDRA is stricter than gcc. It also didn't recognise my use of strdup, and I had to specify -Ysystem for it to work (the previous -Y's I tried did not work properly). But then it worked.

TenDRA generated larger and slower executables than gcc but it worked.

I failed to get lcc (which isn't strictly open source ) and pcc (which is open source ) to either compile or produce working code. Seems like neither of them are ready for prime time - at least not here on Mandriva Linux Cooker.

So after a lot of frustration, my experiments with different compilers were mostly successful. As a result, my code is more strict, and better tested. So I guess it was worth it.