- 26 Aug, 2019 1 commit
-
-
Vivien Kraus authored
Frama-c does not know about =_Alignof=, because this is detected as a compiler built-in. I have not found any way more elegant than that.
-
- 25 Aug, 2019 21 commits
-
-
Vivien Kraus authored
Update the models See merge request !130
-
Vivien Kraus authored
-
Vivien Kraus authored
Those programs are required to update the main website with the latest release.
-
Vivien Kraus authored
Yes, this is a stupid error, I know, thanks.
-
Vivien Kraus authored
Resolve "Learning: Write a program to extract game features" Closes #126 See merge request !129
-
Vivien Kraus authored
If there are no bids yet, then the feature for the minimum bid would not handle this case, leading to an uninitialized *minimum output variable.
-
Vivien Kraus authored
This is because of an early break that needed to be deleted.
-
Vivien Kraus authored
This is a port of the previous vala program. It is very big because all feature functions are different, obviously.
-
Vivien Kraus authored
-
Vivien Kraus authored
Merge branch '125-learning-write-a-program-that-can-generate-a-game-based-on-mcts-parameters' into 'develop' Resolve "Learning: write a program that can generate a game based on MCTS parameters" Closes #125 See merge request !128
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
Now the script uses the new programs, and fails when all generations failed for a specific category.
-
Vivien Kraus authored
This program behaves exactly like =tarot-mcts=, except of course it does not use the same algorithm.
-
Vivien Kraus authored
If we check early, then calling =tarot-mcts --generate= on a finished game will succeed immediately, instead of failing because we don't know the next player in the finished game.
-
Vivien Kraus authored
It was forgotten, but all source code should be internationalized.
-
Vivien Kraus authored
-
Vivien Kraus authored
I prefer it this way.
-
Vivien Kraus authored
In fact, this is not strictly speaking generating the game, because we still need the initial full deal. However, we don't handle the deal in that program for two reasons: 1. There is already a program that does exactly that (=tarot_deal=); 2. Duplicating the option parsing for =n-players= and =call-allowed= would not be great, I think.
-
Vivien Kraus authored
This was a copy-paste from =tarot_deal.c=, and I forgot to change it.
-
Vivien Kraus authored
It occurred to me that this priority level was only for the programs for which we build a manual, i.e. the $(bin_PROGRAMS).
-
- 24 Aug, 2019 10 commits
-
-
Vivien Kraus authored
Resolve "Update the tuning procedure" Closes #124 See merge request !127
-
Vivien Kraus authored
Since all programs are recursively made for their man page, I need to add them to the safe target.
-
Vivien Kraus authored
Now we use the new programs that we've just built. I will run the tuning again to check that everything works.
-
Vivien Kraus authored
This command will play the next move as the MCTS for a given game.
-
Vivien Kraus authored
With the mcts command, I will need to parse the maximum heap size allocated to the MCTS algorithm.
-
Vivien Kraus authored
tarot-program-commons will hold most code that is shared between different commands.
-
Vivien Kraus authored
This command deals a game at random.
-
Vivien Kraus authored
This command will print status information. It will be most useful to programs.
-
Vivien Kraus authored
Resolve "Rewrite the tarot app" Closes #123 See merge request !126
-
Vivien Kraus authored
Please refer to this specific branch.
-
- 07 Aug, 2019 6 commits
-
-
Vivien Kraus authored
When writing stub code, it is tempting to use the C identifier for the constants, instead of their actual value. This makes potential generated code slightly more easy to read.
-
Vivien Kraus authored
The Gir unfortunately has this 'utf8' or 'gchar' that can either mean a string or a char. We have to decide solely based on the equivalent C type.
-
Vivien Kraus authored
All class methods are described twice in the gir: once within the class, and once in the global namespace, but with an attribute indicating that it does not belong there. If we don't ignore these, we will have duplicate identifiers when writing bindings.
-
Vivien Kraus authored
As the C type was not present, it was impossible to write binding code that would compile nicely in C. Specifically, pointer-to-unsigned-ints would trigger at least a warning (not sure, not tested) when given instead of pointer-to-the-alias.
-
Vivien Kraus authored
-
Vivien Kraus authored
The "end" pointer was not recognized as an output parameter. Adding the annotation forces it to be an out (but nullable) parameter.
-
- 19 Jun, 2019 2 commits
-
-
Vivien Kraus authored
Resolve "Make a separate d-bus server" Closes #113 See merge request !120
-
Vivien Kraus authored
This reverts commit ae07be29.
-