I am using a python wrapper for DDS, and noticed the following strange behavior:

(Note the wrapper has a different order of suits)

Giving (for diamonds)

Now this is used for simulations, so when I simulate for NT I get this

That looks very fine

Now I first calculate for NT and the for Diamonds and is getting this

Still all is fine, but when I now start using dds_mode = 2 I get this strange result

and if asking for diamonds before NT it returns this

So it looks like the internal tables being reused is not using the trump causing some strange results.

When using the dds_mode = 2 is is the users responsibility that tables can be reused, but I did not find anything in the manuals about how, and especially not that the tables are independent of trump.

Ubuntu 19.10.
Shared library installed

cd test
cp Makefiles/Makefile_linux Makefile
make

Get lots of errors of the form:

testcommon.cpp: In function ‘realMain.constprop’:
testcommon.cpp:155:7: error: ‘trace_list’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
155 | free(trace_list);
| ^
testcommon.cpp:89:16: note: ‘trace_list’ was declared here
89 | solvedPlay * trace_list;
| ^

Fix:

In testcommon.cpp, add initializations

int number = 0;
int * dealer_list = 0;
int * vul_list = 0;
dealPBN * deal_list = 0;
futureTricks * fut_list = 0;
ddTableResults * table_list = 0;
parResults * par_list = 0;
parResultsDealer * dealerpar_list = 0;
playTracePBN * play_list = 0;
solvedPlay * trace_list = 0;

There are other ways of fixing, for example changing the compiler settings, but best to just initialize the variables.

Hello, and thanks you so much for the great amount of work u've done.
The small algorithmic questing arised after I dived into the code.
That is about one small move per subtree. Is there any formal proof of correctness for this operation (i mean collecting subtree win-ranks and throwing all-except-one small cards away)?

Per README.md:

Note that Apple stopped using g++ in Xcode a while back, DDS does compile using the clang compiler, but since DDS does not support pthreads multi-threading, DDS becomes single-threaded. To get OpenMP multi-threading you need to use the Homebrew installer and do:

brew reinstall gcc --without-multilib
The without-multilib is important because you won't get OpenMP otherwise, and that's the whole point. (Thanks to Matthew Kidd for these instructions.)

Alas, --without-multilib is no longer an option. See:

Homebrew/homebrew-core#16751

I tried comping with a standard gcc install and got many errors, with or without boost (log on request.) For now, this seems to mean that dds cannot be multi-threaded under MacOS.

First, I want to express my sincere appreciation on your work. The dds is really good. I want to use it in my own program, an online double dummy analyzer with calculation in client end. However, I am not familiar with C++. I have read the code, the docs for several days but I still did not even know how to use it. When I try running the cpp in example, it raised a lot of errors.

But the cpps puzzled me and there is no main function in source code. Could you please give explanation on following questions:

1. How can I use this program?
2. How can I make this run without building it?
3. Which file is the entrance file?
4. Suppose I want to use web assembly to run this program, what should I do?

I built a small wrapper around SolveBoard. I'm getting negative scores out of it. How should I interpret this? If I have zero or one cards played in the first trick, the scores make sense to me (they're 9 or 4 depending on whose play it is).

$ ./next-plays "N:T843.K4.KT853.73 J97.J763.642.KJ5 Q52.Q982.QJ.9862 AK6.AT5.A97.AQT4" N W 5D 2D
dl.first: 0
dl.trump: 4
dl.remainCards[0][0]: 0x518
dl.remainCards[0][1]: 0x2010
dl.remainCards[0][2]: 0x2508
dl.remainCards[0][3]: 0x88
dl.remainCards[1][0]: 0xa80
dl.remainCards[1][1]: 0x8c8
dl.remainCards[1][2]: 0x50
dl.remainCards[1][3]: 0x2820
dl.remainCards[2][0]: 0x1024
dl.remainCards[2][1]: 0x1304
dl.remainCards[2][2]: 0x1800
dl.remainCards[2][3]: 0x344
dl.remainCards[3][0]: 0x6040
dl.remainCards[3][1]: 0x4420
dl.remainCards[3][2]: 0x4280
dl.remainCards[3][3]: 0x5410
dl.currentTrickSuit[0]: 2
dl.currentTrickRank[0]: 5
dl.currentTrickSuit[1]: 2
dl.currentTrickRank[1]: 2
dl.currentTrickSuit[2]: 0
dl.currentTrickRank[2]: 0
[
  {"suit": "D", "rank": "Q", "score": -2},
  {"suit": "D", "rank": "J", "score": -2}
]

Full code in this gist

I'm very interested in this project,but I'm kinda novice into coding. and I try to nmake the makefile on windows using vc14.after setting up as the instruction said, it's kinda weird when i start to run nmake, the cmd told me that it can't recognize the $INCL_SOURCE. I got the mingw installed on my pc,and added bin to the path.
I'm very thankful to you if you could advice...

A normal usecase for the DDS SolveBoard() method is to:

1. Call SolveBoard() for the opening lead and play the suggested card for say West.
2. Have the user (North) play a card.
3. Call SolveBoard() again
   etc.

As I see it, it must be possible to reuse the transposition table and the rel/aggr structures in all calls after 1).
To make this possible, the test for NewDeal should only validate that all cards in the current deal was in the same hand as when the transposition table was initiated.

I've actually got it working with very minimal changes to the code. That is when the new deal is a subset of the old one. But is now working on a superset version also. By this I mean situations where all cards in the deal stored in the transpositiontable are placed in the same hands in the new deal and none of the extra cards was present in the former deal. This can be handled by "filling in the blanks" in the rel and aggr structures.

There is also a number of small errors like indexing with an negative value when cards count is 4 and setting upperbound to 13 when there is fewer cards

it will be nice to have automation inside the repo to generate binary automatically like using .travis-ci.yaml, therefore it can also be a binary release.

Or someone had clear instruction on how to build binary from base ubuntu 18.04

As an end-user, I want to have a linux binary to analyse my hand card.

The functions SidesParBin, DealerParBin, and ConvertToSidesTextFormat in Par.cpp throw an exception in some cases, which is not permitted in a function marked extern "C".

Hi,

I came across this hand.

[Dealer "N"]
[Vulnerable "None"]
[Deal "N:42.K953.Q6.96432 Q3.AT7.JT875.AQT KJ8765.J6.A43.87 AT9.Q842.K92.KJ5"]

The contract is 3NT by West, on S4 lead SolveBoard returns 9 declarer tricks, when in fact if South plays a low spade to the first trick declarer can take max 8.

I see the function SolveAllBoardsBin is defined in dll.h but I cannot find it in the compiled dll file from official website and description.
I know the function performs identically to SolveAllChunksBin.

I would request a public function that would spit out the current version.

I try the following under cygwin:

cd test
make clean
cd ../src
make clean
make depend # with warnings
make
make install
cd ../test
make depend # with warnings
make
./dtest.exe
./dtest.exe list10.txt calc 1

But I dont get any output at all.
To debug, I put a printf line first in the main() function, but still no output, so it does not seem rech main() at all, but just exits.
The exit-code is 0.

Any idea how to troubleshoot this?
I am running on Win-10 -- have you tested this platform?

instead of setting mode = 2, mode should be set to 1.

mode = 0 is only an alternative when no search is to be performed
(i.e when there is only one possible move, e.g. a singleton), while
setting mode = 2 implies making a search.

You are right that "CallAllTables" should be "CalcAllTables".
Thanks for catching this error, this will be corrected in the next release.

Best regards

Bo

From: John Schuler
Sent: Monday, September 12, 2016 12:50 AM
To: [email protected]
Subject: Mode setting;; Documentation error?

Hi Bo

1. On your website, this page:

   Callable Functions

under "Solver Modes" recommends against using a mode of 2. Should the mode be zero or 1?

2. The documentation (dll-description.*) on github has 2 references to "CallAllTables". I'm sure this should be "CalcAllTables".

Not all header files in the project currently have include guards. There's also a "rule" about the compiler reserving all identifiers beginning with an underscore followed by an uppercase letter. Practice dictates one should never do that, as with:

#ifndef _DDS_TRANSTABLES
#define _DDS_TRANSTABLES

Although it may seem like a small thing, C++ readers often freak out about it...immediately. They envision you making member variables _D or somesuch because you don't know it's illegal. The reason you don't get an error or warning is because the compiler is supposed to be accepting such symbols in library usage; it doesn't know you're not a library included with the compiler!

(The odds of the standard libraries internally using _D or _SYM1020 are substantially higher that they would pick _DDS_TRANSTABLES. But the point is that it has the right to do anything with underscores and uppercase letters. So they want to hit you with the "don't do that" stick as quickly as possible to break the habit.)

Boost's concept is reasonable enough to follow, mostly:

http://stackoverflow.com/a/4871964

...and DDS_TRANSTABLE_H_INCLUDED is clear.

I was trying to compile and run DDS for an Android device with the Android NDK.
Everything compiles fine, but I was getting invalid memory access exceptions at run-time.
It turns out that the DDS implementation defines type 'char' in some structs and then assigns '-1' to it. (Init.cpp SetDealTables() for example).
Many compilers treat char's by default as signed, thus assigning '-1'. However, this is something compiler-specific and not in the standard (see: http://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default). The g++ and clang compilers for the Android NDK are configured to treat them as unsigned. Thus, effectively assigning 255 to the char.
This gives issues when at a later point the 'char' is assigned to an 'int'. The int now has value 255 instead of the expected -1. This crashes the program later on.

For me, the following fixed the issue:

//dds.h
struct absRankType // 2 bytes
{
char rank;
signed char hand; // signed char instead of char
};

However, there could be more situations where a signed char is meant instead of an undefined (signed/unsigned) char. Perhaps these could be changed as well.

There are a few use-cases where people are using DDS as an aid for analysis in python for machine learning for bridge

One of the things which goes wrong is that people import (for example) bridgebots, endplay and redeal and use them for various functionality which is not shared between them.

On macOS 11.2 (but probably many other macOS) if two libraries are concurrently loaded, it seg-faults as soon as the second one is called, which seems to be a problem with threading, see

anntzer/redeal#15

I am calling dll functions from c# and giving correct parameters (checked many times) but I am getting different results than other programs which uses Bo Haglund DDS. Such as http://mirgo2.co.uk/bridgesolver/ or Magic Contest. I tried SolveBoard and SolveBoardPBN methods.. What can cause this problem ?

I am in the final stages of converting the main DLL doc to markdown. I noticed that the current docs have filenames with the version in them, like DLL-dds_28_x.rtf.
It seems to me this is wrong. The content in the repo should always be "current" and some git-history magic could reveal past versions.
Reaming files in git is cumbersum so I guess the old files are removed and new ones added. This makes version history difficult.
My suggestion would be renaming once more, making them a bit more desciptive in te process and keep the names as they are.

dll-description.
algorithm.
par-calulation.
performing-benchmarking.

I can repeat this in a large code base, but I don't yet have a small tidy repro.

'Memory::GetPtr: 0 vs. 0'

The same code works without issue on Ubuntu 18.04.3 LTS

It seems for me, that line 101
if (equals & dbitMapRank[i])
is not correct. Probably
if ((equals >> 2 )& dbitMapRank[i])
is correct

One thing I'd ask before a 2.8 formal drop would be if it would be possible to go over all the files and just take out all the alignment spacing.

Reason is, that the maintenance and concern of something like:

int      something;
mystruct somethingElse;

Is just kind of crazy, because of the reformatting it takes when you add a longer-named thing:

int                something;
mystruct           somethingElse;
mylongernamedthing somethingStillDifferent;

Not only is it busywork you may or may not want to do, it also winds up meaning that if you have one functional line of change in the code...you are touching three lines in source control to mess with spacing.

The standard is generally just:

int something;
mystruct somethingElse;
mylongernamedthing somethingStillDifferent;

I happen to use a proportional font and syntax highlighting which makes the above look more along the lines of:

    int something;
    mystruct somethingElse;
    mylongernamedthing somethingStillDifferent;

Which to me calls out the necessary information and fits more on a page. Anyway, in an ideal world we'd be dealing with source code in a more "structured" form where everyone could just view it how they liked...but as long as it's text files I think it's best to do what works best for text file versioning and maintenance.

I'm willing to do the pre-release sweep using a prettyprinting tool to standardize all the files, and that way it can be something mechanical... two spaces is acceptable for indentation if that is the preference (I use 4 in my own code).

Use the shared library version on Linux

Running on Ubuntu 19.10

cd src
cp Makefiles/Makefile_linux_shared Makefile
make

Side note: I needed to have boost installed to make this compile:
sudo apt-get install --no-install-recommends libboost-all-dev

make install

The make install fails because it is using the STATIC variable and not the SHARED

The fix is below:
change ./src/Makefiles/Makefile_linux_shared at lines 122 and 123 and replace STATIC_LIB with SHARED_LIN

diff Makefile Makefiles/Makefile_linux_shared
122,123c122,123
< cp $(SHARED_LIB) ../test
< cp $(SHARED_LIB) ../examples

cp $(STATIC_LIB) ../test
cp $(STATIC_LIB) ../examples

I'm trying to build this on windows 10 with mingw-w64
there is no lib/def file and the dll fails to load.
any help will be highly appreciated.

When executing

brew reinstall gcc --without-multilib

I got this response: Error: invalid option: --without-multilib

 gcc -v
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix

Well this is probably only a performance problem

I went on and copied the makefile for Mac clang, and now hit the next problem as sprint is deprecated.

After replacing sprint with snprintf (second parameter is now a length of first parameter) the compile error went away, and I hit the next problem.

In file included from System.cpp:19:
./parallel.h:21:12: fatal error: 'boost/thread.hpp' file not found
  #include <boost/thread.hpp>
           ^~~~~~~~~~~~~~~~~~

Anyone got a compiled version for the M1-processor?

I am making a project, part of which is to calculate given 1000s of deals with a same (fixed) West hand, calculate percentage time West is able to defeat the contract using dds (Assume South is declarer, hands are according to bidding sequence 1NT(by South) - Pass - 3NT - Pass - Pass - Pass)
I have tried to use SolveAllBoard with this:

bo.deals[handno].trump = NOTRUMP;
bo.deals[handno].first = WEST;

and

bo.target [handno] = -1;
bo.solutions[handno] = 3;
bo.mode [handno] = 0;

and it gives me score for each of the 13 cards of West's hand. Is this correct way to do it?
Sorry, if it is silly I don't have much experience with Contract bridge.

The public API has some functions that would seem to more natural take unsigned ints, eg

EXTERN_C DLLEXPORT void STDCALL SetMaxThreads(int userThreads);
EXTERN_C DLLEXPORT int STDCALL SetThreading(int code);
EXTERN_C DLLEXPORT void STDCALL SetResources(int maxMemoryMB, int maxThreads);

A negative number of threads or memory is nonsensical. Are you ok with changing the public API to be unsigned where appropriate or are you trying to maintain stability? I am glad to work up a pull request if you would allow the change.

Similarly with various structures, eg

struct boards
{
int noOfBoards;
...
}

Is there an option to disable the caching of the already computed trees?

Hi.
I'm not very familiar with c-programming, just trying to build the library :)
Using cygwin, when I run: make depend
I get a list of warnings.
Are these OK to ignore, or am I missing some configuration or setup?

makedepend: warning: dds.cpp (reading dds.h, line 13): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading dds.h, line 14): cannot find include file "stdlib.h"
makedepend: warning: dds.cpp (reading dds.h, line 15): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading dds.h, line 16): cannot find include file "time.h"
makedepend: warning: dds.cpp (reading dds.h, line 17): cannot find include file "assert.h"
makedepend: warning: dds.cpp (reading dds.h, line 18): cannot find include file "math.h"
makedepend: warning: dds.cpp (reading TransTable.h, line 19): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading TransTable.h, line 20): cannot find include file "stdlib.h"
makedepend: warning: dds.cpp (reading TransTable.h, line 21): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading Timer.h, line 41): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading Timer.h, line 42): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading Timer.h, line 43): cannot find include file "time.h"
makedepend: warning: dds.cpp (reading Timer.h, line 44): cannot find include file "inttypes.h"
makedepend: warning: dds.cpp (reading Timer.h, line 49): cannot find include file "sys/time.h"
makedepend: warning: dds.cpp (reading ABstats.h, line 13): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading ABstats.h, line 14): cannot find include file "stdlib.h"
makedepend: warning: dds.cpp (reading ABstats.h, line 15): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading Moves.h, line 13): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading Moves.h, line 14): cannot find include file "stdlib.h"
makedepend: warning: dds.cpp (reading Moves.h, line 15): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading Scheduler.h, line 13): cannot find include file "stdio.h"
makedepend: warning: dds.cpp (reading Scheduler.h, line 14): cannot find include file "stdlib.h"
makedepend: warning: dds.cpp (reading Scheduler.h, line 15): cannot find include file "string.h"
makedepend: warning: dds.cpp (reading Scheduler.h, line 16): cannot find include file "time.h"
makedepend: warning: dds.cpp (reading Scheduler.h, line 21): cannot find include file "sys/time.h"
makedepend: warning: CalcTables.cpp, line 11: cannot find include file "stdexcept"
makedepend: warning: Moves.cpp, line 11: cannot find include file "stdexcept"
makedepend: warning: Par.cpp, line 11: cannot find include file "stdexcept"
makedepend: warning: SolverIF.cpp, line 10: cannot find include file "stdexcept"
makedepend: warning: Stats.cpp, line 10: cannot find include file "stdexcept"
makedepend: warning: Stats.cpp, line 18: cannot find include file "time.h"
makedepend: warning: Stats.cpp, line 27: cannot find include file "sys/time.h"
makedepend: warning: Timer.cpp, line 15: cannot find include file "stdexcept"
makedepend: warning: TransTable.cpp, line 10: cannot find include file "stdexcept"

I downloaded the headers of boost1.83.0 under Windows11, and failed to compile the files in src/.

I used MinGW and the Makefile Makefile_mingw to build, and got the error outputs:

System.cpp: In member function 'int System::RunThreadsSTL()':
System.cpp:463:10: error: 'thread' was not declared in this scope
   vector<thread *> threads;
          ^~~~~~
System.cpp:463:10: note: suggested alternatives:
In file included from C:\boost_1_83_0/boost/thread/thread_only.hpp:22:0,
                 from C:\boost_1_83_0/boost/thread/thread.hpp:12,
                 from C:\boost_1_83_0/boost/thread.hpp:13,
                 from parallel.h:21,
                 from System.cpp:19:
C:\boost_1_83_0/boost/thread/detail/thread.hpp:163:29: note:   'boost::thread'
     class BOOST_THREAD_DECL thread
                             ^~~~~~
In file included from C:\boost_1_83_0/boost/thread.hpp:19:0,
                 from parallel.h:21,
                 from System.cpp:19:
C:\boost_1_83_0/boost/thread/tss.hpp:18:19: note:   'boost::detail::thread'
         namespace thread
                   ^~~~~~
System.cpp:463:18: error: template argument 1 is invalid
   vector<thread *> threads;
                  ^
System.cpp:463:18: error: template argument 2 is invalid
System.cpp:470:11: error: request for member 'resize' in 'threads', which is of non-class type 'int'
   threads.resize(nu);
           ^~~~~~
System.cpp:473:14: error: invalid types 'int[unsigned int]' for array subscript
     threads[k] = new thread(fptr, k);
              ^
System.cpp:473:22: error: expected type-specifier before 'thread'
     threads[k] = new thread(fptr, k);
                      ^~~~~~
System.cpp:477:14: error: invalid types 'int[unsigned int]' for array subscript
     threads[k]->join();
              ^
System.cpp:478:21: error: invalid types 'int[unsigned int]' for array subscript
     delete threads[k];
                     ^
Makefile:94: recipe for target 'System.o' failed
make: *** [System.o] Error 1

Did I do anything wrong?

I was hoping to use DDS to solve for a trick after some cards are played.

Example: https://github.com/pmbethe09/dds-test/blob/master/test_dds.cpp

      KJ
      -
      5
      -
97         QT
9           -
-            -
-            T
      5
      -
      A
      9

At NT, South leads. DDS of course indicates that the DA takes 3 tricks (by squeezing E).

But what I want to do is solve from W or E's perspective, after S leads the DA that all plays lead to 0 tricks.
I have tried:

• setting currentTrickSuit[0]
• setting currentTrickSuit[0] and removing the DA
• setting currentTrickSuit[0], removing the DA, first = WEST

But all roads lead to "currentTrickSuit or currentTrickRank has wrong data"

Am I missing something, or does the library not support this?

I am trying to build a program that is dependent on dds on a Raspberry Pi running Debian.

I seem to have a problem with -mtune=generic from your makefile. Suggestions?

pi@Master-198:~ $ sudo python -mpip install --user git+https://github.com/anntzer/redeal
Downloading/unpacking git+https://github.com/anntzer/redeal
Cloning https://github.com/anntzer/redeal to /tmp/pip-z1N6Rs-build
Running setup.py (path:/tmp/pip-z1N6Rs-build/setup.py) egg_info for package from git+https://github.com/anntzer/redeal

Requirement already satisfied (use --upgrade to upgrade): colorama>=0.2.4 in /usr/lib/python2.7/dist-packages (from redeal==0.2.0)
Downloading/unpacking enum34>=1.0.4 (from redeal==0.2.0)
Downloading enum34-1.1.6-py2-none-any.whl
Installing collected packages: enum34, redeal
Running setup.py install for redeal
g++ -fPIC -g -O3 -flto -fopenmp -mtune=generic -Wno-write-strings -Wshadow -Wsign-conversion -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=1 -Wswitch-default -Wundef -Werror -Wno-unused -Wno-unknown-pragmas -Wno-long-long -Wno-format -c dds.cpp
g++: error: unrecognized argument in option ‘-mtune=generic’
g++: note: valid arguments to ‘-mtune=’ are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a5 cortex-a53 cortex-a57 cortex-a57.cortex-a53 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 cortex-r7 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale
Makefiles/Makefile_linux_shared:96: recipe for target 'dds.o' failed
make: *** [dds.o] Error 1

Line ends in ":" instead of ";" line 27.
I'll try to push a branch called typo.

yes thanks, I am interested to see your code!
Are you aware of the .net wrapper code for DDS written by Andrew Orsich?

https://github.com/anorsich/dds.net

I haven’t yet learned how to upload code to GitHub so I can’t presently help you on this.
An alternative way may perhaps be to add a link at my site to a web address owned by you
where the code can be downloaded for review.

Best regards

Bo

From: Andre Steffens
Sent: Sunday, May 08, 2016 12:13 PM
To: [email protected]
Subject: .Net support for DDS

Hello Bo,

Recently I had to work with dds again as we will include some of its functions in our bridge application (Bridge-It/NBB-Rekenprogramma from Ron Bouwland at Bridge Systems BV). To this end I created a .Net wrapper for just the SolveBoard and CalcDDTable functions. Moreover, I adapted the source code ( including some headers and removing the DllMain function) to enable 32 bit and 64 bit compilation in Visual Studio 2015. Would you be interested in it? I could send the code for review. I would upload the code to GitHub if you think this is useful, but I wil need help with this as our own source control system is Tortoise Hg (Mercurial).

Regards,

André Steffens

It appears that setup.py refers to Makefiles/Makefile_mac_clang but the directory dds/src/Makefiles only contains files like Makefile_mac_clang_static and Makefile_mac_clang_shared.

(This is causing a problem on OSX, obviously)

Attached a simple fix in the comments of "hands.h".

The spades/hearts/diamonds/clubs comments were marking the hands for north, east, south, and west.

Github does not allow me to attach a ".patch" file, so I need to rename it to .txt

hand_fix.txt

My hand generator/DD-solver dynamically loads the dds shared library. Currently, there is no Makefile for building such a library on Mac (only for building a static library); but a patch was proposed on redeal's issue tracker (anntzer/redeal#3) to fix this.
While I cannot make the patch work, it seems to work for OP, so perhaps it (or some working variant...) could be integrated upstream?

In a few [...]PBN.cpp files there is a nested for loop:

for (int h = 0; h < DDS_HANDS; h++)
  for (int s = 0; s < DDS_SUITS; s++)
    strcopy(DDdealsPBN.deals[handno].cards, PBN[handno]

This is needed in the [...]Bin.cpp files where the cards are copied one by one. In the PBN files this is not needed because here it is a simple string copy (the PBN string).

I'll try to add a pull-request to this issue.

Compiling dds ends with sequence of "ar" complains like
ar: dds.o: plugin needed to handle lto object
etc... for other objects

Question: Which plugin is needed for lto object for ar not to complain?

(Trivial issue created for issue-database exercise.)

For programmer-readable text files to do things like README, the emergent standard is to write it as
README.md in "MarkDown" format. This is supported by GitHub and many other places use it (such as StackOverflow). As text-based markup languages go it has the advantage of remaining fairly human-readable even if you are viewing it without a renderer.

I suggested switching the README (at least) to README.md. It may be a good idea for some other documentation to be done in MarkDown as well.

For learning MarkDown, the StackEdit tour offers a nice open source online editor--with samples--so you can see the "text version" alongside the projection:

https://stackedit.io/editor

Note that MarkDown is supported in comments and issues on GitHub (like this one)

Although the file in the development branch now uses MarkDown, as can be seen on line 12, it should have the right file extension. This is also a demonstration to linking to a line as it existed in a particular commit:

For information about that feature and why it's important to hit the "Y" key instead of just clicking on a line number and sending that link to people, see "Don't Link that Line Number!"

Windows and Linux/OSX differ on the convention of whether newlines are signified by CR or CR LF.

There are some files checked in at the moment which have ^M in them, because someone (me) didn't check over it before committing them.

So we should remedy this. I am not rewriting the history again, so we'll have to do this in the "conventional" way...

I have been trying to build and run test in linux 64. Please let me know if i missed something, or this seems to be bug?

Here is what i'm doing
cd dds-2.9.0/
cd src
cp ./Makefiles/Makefile_linux_static ./Makefilemake clean
env CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 make
objdump -f libdds.a | grep ^architecture
Result::architecture: i386:x86-64, flags 0x00000010:(multiple lines)

make install
cd ../test
cp Makefiles/Makefile_linux ./Makefile
env CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 make
objdump -f dtest | grep ^architecture
Result::architecture: i386:x86-64, flags 0x00000112:

./dtest -f ../hands/list100.txt -s solve -n 4 -m 1000
Result::Memory::GetPtr: 0 vs. 0

uname -a
Linux x86_64 x86_64 x86_64 GNU/Linux

Hi,

score = -2 is not included in the DLL description of futureTricks on page 8 in:

"Description of the DLL functions supported in Double Dummy Problem Solver 2.8.4",
http://privat.bahnhof.se/wb758135/bridge/DLL-dds_x.rtf

Thanks for noticing us on this!

The case of setting score to -2 for mode = 0 is described though in
the SolveBoard part on page 12, comments on mode = 0.

Setting score to -2 is never done for any other case than this.
There is no immediate plan to remove mode = 0.

Best regards

Bo

-----Ursprungligt meddelande----- From: Ed Logg
Sent: Monday, June 06, 2016 11:45 PM
To: Bo Haglund
Subject: Double Dummy Solver issues

I see that you do not document the SolveBoard completely. It is
possible to get a score = -2 when there is only one play and mode is 0.

I see by your documentation that you are thinking of removing mode from
SolveBoard. I will ask that you not remove it if it will continue to
return a score of -2 instead of a valid score.

I compiled libdds.so on Linux with the default parameter and I'm trying to use it with ctypes in Python. I noticed, when I unload the library at the end of a Python script, I get a segmentation fault.

Here is a toy example of Python script:

from ctypes import *
dll = cdll.LoadLibrary("libdds.so")

When I run it:

$ python libdds.py
Segmentation fault (core dumped)

According to the debugger, the issue come from FreeMemory function:

$ gdb
(gdb) file python
Reading symbols from python...done.
(gdb) run libdds.py
Starting program: /home/pierre/anaconda3/bin/python libdds.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e59454 in Memory::ReturnThread(unsigned int) ()
   from /home/pierre/Documents/python/bridge/python-dds-master_copy/libdds.so
(gdb) bt
#0  0x00007ffff5e59454 in Memory::ReturnThread(unsigned int) ()
   from /home/pierre/Documents/python/bridge/python-dds-master_copy/libdds.so
#1  0x00007ffff5e5cb31 in FreeMemory () from /home/pierre/Documents/python/bridge/python-dds-master_copy/libdds.so
#2  0x00007ffff7de7de7 in _dl_fini () at dl-fini.c:235
#3  0x00007ffff6a0cff8 in __run_exit_handlers (status=0, listp=0x7ffff6d975f8 <__exit_funcs>, 
    run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#4  0x00007ffff6a0d045 in __GI_exit (status=<optimized out>) at exit.c:104
#5  0x00007ffff69f3837 in __libc_start_main (main=0x400ab0 <main>, argc=2, argv=0x7fffffffde68, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde58) at ../csu/libc-start.c:325
#6  0x00000000004009e9 in _start ()

An idea about how to correct that issue?