Closed mcoram closed 4 years ago
Yeah Clang gets upset about C extensions, any chance you can give it a shot with the old OS X GCC ( pre-LLVM )?
Using the -Wmicrosoft-anon-tag
and -Wenum-conversion
flags will get rid of those warnings.
Clang doesn't allow static const
data to be treated as a compile-time constant, this seems silly to me because the alternative is using untyped #define
symbols instead.
I might need to revisit some of these things though to allow for OSX compatibility.
Try adding CFLAGS += -std=c11
to the Makefile at the top.
I also added a "getting started" section to the README. I have been working on this solo so far, and haven't documented much. But now that someone else is poking around I would like to be as helpful as possible to explain how things work.
With "CFLAGS += -std=c11" still clang.
(base) TL:cpoke mcoram$ make clean
Cleaning Up...
rm -rvf *.o cpoke parse_gm fetch_gm test;
(base) TL:cpoke mcoram$ make
gcc -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -std=c11 -c src/main.c
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:9:
In file included from include/moves.h:10:
In file included from include/ptypes.h:59:
include/defs/ptype_traits.h:71:20: warning: implicit conversion from enumeration type 'ptype_t' to different enumeration type
'ptype_mask_t' [-Wenum-conversion]
.immunities = PT_NONE
^~~~~~~
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:9:
include/moves.h:129:3: warning: anonymous structs are a Microsoft extension [-Wmicrosoft-anon-tag]
base_move_t; /* Inherit */
^~~~~~~~~~~
include/moves.h:135:3: error: initializer element is not a compile-time constant
NO_MOVE,
^~~~~~~
include/moves.h:148:3: warning: anonymous structs are a Microsoft extension [-Wmicrosoft-anon-tag]
base_move_t; /* Inherit */
^~~~~~~~~~~
include/moves.h:154:3: error: initializer element is not a compile-time constant
NO_MOVE,
^~~~~~~
include/moves.h:167:3: warning: anonymous structs are a Microsoft extension [-Wmicrosoft-anon-tag]
base_move_t; /* Inherit */
^~~~~~~~~~~
include/moves.h:172:51: error: initializer element is not a compile-time constant
static const pvp_fast_move_t NO_MOVE_PVP_FAST = { NO_MOVE, .turns = 0 };
^~~~~~~
include/moves.h:212:17: error: initializer element is not a compile-time constant
.buff = NO_BUFF,
^~~~~~~
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:73:36: error: unknown type name 'typeof'; did you mean 'typedef'?
static const uint8_t NUM_REGIONS = array_size( REGIONS );
^
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:45: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:73:36: error: expected a type
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:51: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:73:36: error: type name does not allow storage class to be specified
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:45: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:73:48: error: type-id cannot have a name
static const uint8_t NUM_REGIONS = array_size( REGIONS );
^~~~~~~~
include/util/macros.h:241:61: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:36: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:53: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
include/util/macros.h:347:63: note: expanded from macro 'types_compat_p'
#define types_compat_p( x, y ) __builtin_types_compatible_p( x, y )
^
include/util/macros.h:87:65: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO( e ) ( sizeof( struct { int : -!!( e ); } ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:113:24: error: initializer element is not a compile-time constant
.hh_name = HH_NULL,
^~~~~~~
include/pokedex.h:232:39: error: unknown type name 'typeof'; did you mean 'typedef'?
static const uint8_t NUM_REGIONALS = array_size( REGIONALS );
^
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:45: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:232:39: error: expected a type
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:51: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:232:39: error: type name does not allow storage class to be specified
include/util/macros.h:241:44: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:22: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:45: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
In file included from include/pokemon.h:10:
include/pokedex.h:232:51: error: type-id cannot have a name
static const uint8_t NUM_REGIONALS = array_size( REGIONALS );
^~~~~~~~~~
include/util/macros.h:241:61: note: expanded from macro 'array_size'
( sizeof( arr ) / sizeof( ( arr )[0] ) + __must_be_array( arr ) )
^
include/util/macros.h:238:36: note: expanded from macro '__must_be_array'
BUILD_BUG_ON_ZERO( typesof_eq( ( a ), &( a )[0] ) )
^
include/util/macros.h:363:53: note: expanded from macro 'typesof_eq'
#define typesof_eq( x, y ) types_compat_p( typeof( x ), typeof( y ) )
^
include/util/macros.h:347:63: note: expanded from macro 'types_compat_p'
#define types_compat_p( x, y ) __builtin_types_compatible_p( x, y )
^
include/util/macros.h:87:65: note: expanded from macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO( e ) ( sizeof( struct { int : -!!( e ); } ) )
^
In file included from src/main.c:6:
In file included from include/iv_rank.h:9:
In file included from include/battle.h:8:
include/pokemon.h:134:20: error: initializer element is not a compile-time constant
.buffs = NO_BUFF_STATE,
^~~~~~~~~~~~~
4 warnings and 14 errors generated.
make: *** [main.o] Error 1
So there are two things we can do about this.
I had thought earlier today that it was not possible to get the "real" ( non-clang ) GCC on OSX; but after doing some reading it looks like you can. Apple did something really controversial, and they link gcc
to clang
( we won't get into the politics of why ). You can get the "real" GCC through homebrew
, and set PATH
such that you will get the real GCC from your shell. ( If you use Xcode or other IDEs there's an additional step or two to make them use GCC as well )
If you try out GCC and it still blows up I'll probably need to fallback to Fix 1.
Give this a shot:
brew install gcc;
# if it gripes that you already have `gcc`, do `brew reinstall gcc`
export PATH="/usr/local/bin:${PATH}";
# Just for good measure:
sed -i 's/^CC = gcc$/CC = \/usr\/local\/bin\/gcc/' Makefile;
make clean;
make test;
./test;
Thanks! I did the "brew install gcc" and put "CC = /usr/local/bin/gcc-10" by hand (gcc-10 (Homebrew GCC 10.2.0) 10.2.0). I also tried adding "-DPTYPES_USE_TABLE" either way, I got:
(base) TL:cpoke mcoram$ make test
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -DMK_TEST_BINARY -c src/test/test.c -o test_main.o
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -c src/pokemon.c
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -c src/ptypes.c
src/ptypes.c:126:16: error: only weak aliases are supported in this configuration
126 | const_fn float get_damage_modifier_mono( ptype_t def_type, ptype_t atk_type )
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/ptypes.c:129:16: error: only weak aliases are supported in this configuration
129 | const_fn float get_damage_modifier_duo( ptype_t def_type1,
| ^~~~~~~~~~~~~~~~~~~~~~~
src/ptypes.c:135:16: error: only weak aliases are supported in this configuration
135 | const_fn float get_damage_modifier( ptype_mask_t def_types, ptype_t atk_type)
| ^~~~~~~~~~~~~~~~~~~
make: *** [ptypes.o] Error 1
For what it's worth, I don't have a stake in the question of (1) vs (2). Since you're the main developer, I support you doing what makes you productive. Of course, (2) is nice to work toward, if it's easy.
Anyway, if I contribute, it'd probably be either adding high-level C (on top of yours) or python, so (1) is workable for me modulo the "weak alias" thing. Casual searching lead me to this build issue report for mdbtools, but I stopped short of trying to figure out the guts.
Nice! I'm glad that mostly worked. Honestly the alias junk there is totally unnecessary, I will push right now to remove it. I just wanted to give the option of time/space complexity trade-offs. Do a pull in about 5 minutes.
Edit: go ahead and give it a try now.
Build success (commit 2f51a76d7872cdb613460a96bc50087e9ca30556) Just the Makefile tweak in place.
diff --git a/Makefile b/Makefile
index 85c78a5..46ab851 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@
.DEFAULT_GOAL := cpoke
.PHONY = all clean gamemaster
-CC = gcc
+CC = /usr/local/bin/gcc-10
SRCPATH = src
INCLUDEPATH = include
Results:
[successful build omitted]
./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
Assertion failed: (0 < move->power), function parse_pvp_charged_move, file src/parse_gm.c, line 709.
/bin/sh: line 1: 63608 Abort trap: 6 ./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
make: *** [data/cstore_data.c] Error 134
Hmm. I refreshed GAME_MASTER.json and got this
./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
file_size: No such file or directory
Assertion failed: (tokens_cnt != 0), function main, file src/parse_gm.c, line 1237.
/bin/sh: line 1: 64965 Abort trap: 6 ./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
make: *** [data/cstore_data.c] Error 134
file_size
?
Shit I should remove that temporarily from the Makefile.
There is an issue with for everybody right now where it is impossible to parse the new V2_GAME_MASTER.json
files that Niantic started using. They are basically just encoded versions of the old files.
In order to use them someone needs to take the time to decrypt them. For now I've just been working off an old copy. Recover the old GAME_MASTER.json
with git checkout origin/master -- data/GAME_MASTER.json
.
I'm confident someone will decrypt it soon, this happened just a few weeks ago. The dudes at pokemongo-dev
are hot on the trail.
Edit: I just pushed to remove it from the Makefile temporarily.
Hmmm.
(base) TL:cpoke mcoram$ make test
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -c src/battle.c
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -c src/player.c
/usr/local/bin/gcc-10 -g -Iinclude -Idata/defs -fms-extensions -DJSMN_STATIC -c src/naive_ai.c
/usr/local/bin/gcc-10 -g -lm test_main.o pokemon.o ptypes.o pokedex.o moves.o files.o json_util.o jsmn_iterator.o test_json.o test_pokemon.o test_ptypes.o test_parse_gm.o test_cstore.o test_battle.o test_player.o test_naive_ai.o parse_gm.o gm_store.o cstore.o cstore_data.o battle.o player.o naive_ai.o -o test
Undefined symbols for architecture x86_64:
"_MOVES", referenced from:
_cstore_init in cstore.o
"_NUM_MOVES", referenced from:
_cstore_init in cstore.o
"_NUM_POKEMON", referenced from:
_cstore_init in cstore.o
"_POKEDEX", referenced from:
_test_cstore_roster in test_pokemon.o
_test_roster_append in test_pokemon.o
_cstore_init in cstore.o
_cstore_get_pokemon in cstore.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [test] Error 1
(base) TL:cpoke mcoram$ nm cstore.o
000000000000ae40 s EH_frame1
000000000000a840 s _BUFF_MOD
0000000000004568 d _BUG_TRAITS
0000000000004740 s _DAMAGE_MODIFIERS
0000000000004570 d _DARK_TRAITS
0000000000004578 d _DRAGON_TRAITS
0000000000004580 d _ELECTRIC_TRAITS
0000000000004588 d _FAIRY_TRAITS
0000000000004590 d _FIGHTING_TRAITS
0000000000004598 d _FIRE_TRAITS
00000000000045a0 d _FLYING_TRAITS
00000000000045a8 d _GHOST_TRAITS
00000000000045b0 d _GRASS_TRAITS
00000000000045b8 d _GROUND_TRAITS
0000000000004700 s _HH_NULL
00000000000045c0 d _ICE_TRAITS
000000000000a778 s _IMMUNE_DMG_MOD
000000000000aa00 s _MAX_DEX
000000000000a928 s _MAX_STAT
U _MOVES
00000000000045c8 d _NORMAL_TRAITS
000000000000a825 s _NO_BUFF
000000000000a864 s _NO_BUFF_STATE
000000000000a866 s _NO_MOVE
...
Those are defined by data/cstore_data.c
, so linking cstore_data.o
( you are ) should satisfy those. Can you dump nm cstore_data.o
? ( Thank you for bearing with me here, some kinks are to be expected migrating from Linux to OSX )
This is my cstore_data.c
for reference so you can sanity check that the extern lines at the top match yours: https://gist.github.com/alexameen/aa5036df1b05e1c2f15612ddf687472c
I suspect that ld
is pissed off about extern
declarations is cstore.c
and test_pokemon.c
. Let me know if our cstore_data.c
files match up. I'm going to do some googling and make sure that homebrew's GCC plays nicely with the default ld
on OSX.
This would be really stupid if it works: but see if moving cstore_data.o
before the two dependents in the Makefile does anything:
/usr/local/bin/gcc-10 -g -lm test_main.o pokemon.o ptypes.o pokedex.o moves.o files.o json_util.o jsmn_iterator.o test_json.o test_pokemon.o test_ptypes.o test_parse_gm.o test_cstore.o test_battle.o test_player.o test_naive_ai.o parse_gm.o gm_store.o cstore.o **cstore_data.o** battle.o player.o naive_ai.o -o test
/usr/local/bin/gcc-10 -g -lm test_main.o pokemon.o ptypes.o pokedex.o moves.o files.o json_util.o jsmn_iterator.o test_json.o **cstore_data.o** test_pokemon.o test_ptypes.o test_parse_gm.o test_cstore.o test_battle.o test_player.o test_naive_ai.o parse_gm.o gm_store.o cstore.o battle.o player.o naive_ai.o -o test
I just found this in the ld
manual for OSX. Apparently order of object files matters for y'all. ld
on Linux behaves differently I believe.
Layout
The object files are loaded in the order in which they are specified on the command line. The segments and the sections in those segments
will appear in the output file in the order they are encountered in the object files being linked. All zero fill sections will appear after
all non-zero fill sections in their segments. Sections created from files with the -sectcreate option will be laid out at after sections
from .o files. The use of the -order_file option will alter the layout rules above, and move the symbols specified to start of their section.
I think that messing with the order of those objects in the Makefile's rules will fix it. You can give it a shot in your shell first, if it works we can update it in the repo.
Sorry for the latency. I know remote debugging isn't fun. I don't have a linux machine handy right now or I check some things... Anyway:
(base) TL:cpoke mcoram$ nm cstore_data.o
no symbols
And running your second line (without **) gives the same result
/usr/local/bin/gcc-10 -g -lm test_main.o pokemon.o ptypes.o pokedex.o moves.o files.o json_util.o jsmn_iterator.o test_json.o cstore_data.o test_pokemon.o test_ptypes.o test_parse_gm.o test_cstore.o test_battle.o test_player.o test_naive_ai.o parse_gm.o gm_store.o cstore.o battle.o player.o naive_ai.o -o test
So, my apologies -- actually the problem is that my data/cstore_data.c
is empty. I thought I had pulled the old GAME_MASTER.json and gotten it to run, but something must be off. Digging in.
(base) TL:cpoke mcoram$ git pull
Already up to date.
(base) TL:cpoke mcoram$ git checkout origin/master -- data/GAME_MASTER.json .
(base) TL:cpoke mcoram$ ls -al data/GAME_MASTER.json
-rw-r--r-- 1 mcoram staff 4025100 Oct 2 21:42 data/GAME_MASTER.json
(base) TL:cpoke mcoram$ shasum data/GAME_MASTER.json
7587a60946980e847657199849d535b9d7b9bb17 data/GAME_MASTER.json
(base) TL:cpoke mcoram$ md5 data/GAME_MASTER.json
MD5 (data/GAME_MASTER.json) = a9c7e3f71f7245a1c6daff64f5b1ab2a
(base) TL:cpoke mcoram$ rm data/cstore_data.c
(base) TL:cpoke mcoram$ ./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
Assertion failed: (0 < move->power), function parse_pvp_charged_move, file src/parse_gm.c, line 709.
Abort trap: 6
(base) TL:cpoke mcoram$ wc -l data/cstore_data.c
0 data/cstore_data.c
The ** in the post was the Markdown formatting being wonky. Those were meant to be bold lol.
For now try downloading my cstore_data.c and just build/run the tests. Im hoping those unit tests can help point out issues.
curl https://gist.githubusercontent.com/alexameen/aa5036df1b05e1c2f15612ddf687472c/raf233f7eda4f3a66/cstore_data.c> data/cstore_data.c
make test
succeeds.
./test
(base) TL:cpoke mcoram$ ./test
jsoneq : PASS
jsoneq_typed : PASS
jsmn_iterator_object : PASS
jsmn_iterator_array : PASS
jsmn_iterator_array_nested : PASS
json_find : PASS
jsmn_iterator_find_next : PASS
jsmn_iterator_count : PASS
json : PASS
construct_pokemon : PASS
get_cpm_for_level : PASS
cstore_roster : PASS
cstore_base_mon_from_store : PASS
roster_append : PASS
get_pvp_mon_move : PASS
get_cp_from_stats : PASS
get_effective_stats : PASS
get_pvp_damage : PASS
brute_maximize_ivs : PASS
pokemon : PASS
get_ptype_mask : PASS
pt_traitsp : PASS
get_damage_modifier_mono : PASS
get_damage_modifier_duo : PASS
get_damage_modifier : PASS
ptypes : PASS
Expectation failed: regexec( ®s.tmpl_pvp_fast, test_str3, 0, ((void *)0), 0 ) == 0
regex_patterns : FAIL
parse_gm_type : PASS
parse_gm_dex_num : PASS
parse_gm_stats : PASS
parse_gm_buff : PASS
parse_pvp_charged_move : PASS
parse_pvp_fast_move : PASS
lookup_move_id : PASS
parse_gm : FAIL
cstore_get_pokemon : PASS
cstore_get_pokemon_by_name : PASS
cstore_get_move : PASS
cstore_get_move_by_name : PASS
cstore_get : PASS
cstore : PASS
get_remaining_pokemon : PASS
use_shield : PASS
switch_timer : PASS
player : PASS
is_valid_action : PASS
is_battle_over : PASS
is_p1_winner : PASS
get_battle_winner : PASS
eval_turn : PASS
simulate_battle_simple : PASS
battle : PASS
decide_action : PASS
naive_ai : PASS
So... yay!
Looks good. Completely bizarre that the regex pattern failed though. That would explain why the parser wasn't working.
I'll look into the regex thing. This is good news though, you were able to run the test battles!
Jesus it looks like OSX has a slightly different regex.h
than Linux.
From what i can tell they disagree on \
escaping. Let me do some reading and get back to you.
I think i need to swap in PCRE.
Wow. Sorry. I normally develop on Linux myself. If it's hard for you, I can try on my side. I recently struggled to get gdb to run and had to use multiple weird certificate incantations.
Feel free to take a crack at it. The existing regex stuff needs to get replaced with PCRE to be compatible with both systems.
Luckily it's use is not wide-spread. You can send a PR when it passes those tests, and ill merge it in.
If you'd rather not let me know and i can do it.
Again, thank you for your patience
Edit: Don't worry about messing with it, I took a look and realized the some of my utils needed to be extended. I'm almost done adding PCRE support now.
Just pushed. Take it for a spin.
All tests pass, and this works ./parse_gm -f data/GAME_MASTER.json -e c > data/cstore_data.c
There's one last thing with cpoke, I guess.
(dev) (base) TL:cpoke mcoram$ make
/usr/local/bin/gcc-10 -g -lm -L/usr/local/Cellar/pcre/8.44/lib -lpcre main.o pokemon.o ptypes.o pokedex.o moves.o files.o json_util.o jsmn_iterator.o -o cpoke
Undefined symbols for architecture x86_64:
"_fprint_iv_db_c", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [cpoke] Error 1
Works with fprint_iv_rankings_c( stdout, rankings, 10, GREAT_LEAGUE, 3, 0 );
instead.
Oh yeah that is what I was hacking away on most recently. I'll patch that real quick. Good catch
So now that we've got your build going, you can check out test_simulate_battle_simple
in src/test/test_battle.c
for an example of the battle simulator.
I literally just finished it a few days ago, so I need to expand the tests next, because there's surely some kinks in there still.
I've got a lot on my TODO list, one of them is migrating over the PvPoke AI, because right now naive_ai
is the only complete AI. It basically behaves like a Rocket Grunt which isn't super interesting; but tbh 99% of the work was building the infrastructure, so adding another AI is pretty easy.
What we're you hoping to do with the lib? Or were you just scoping it out?
Cool. Short term I might try the Python CFFI issue. Try one or the other approaches you mention there. Just get something to run. Longer term I'm hoping you can get an AI vs AI 3 monster PVP simulator running (ideally including swapping and shields); maybe some logic would be python or something, I don't know. I'd like to play with Nash equilibrium finding on top. I piloted something using PvPoke once, but because my proxy for AI just relied on pre-computed 1v1 battle matrices and didn't know about swapping or shields in any meaningful way, it gave only mildly interesting results.
Radical, I was literally doing some CFFI stuff yesterday so that works out perfectly. Luckily the existing simulation handles 3v3 battles and shields already so youre good to go on that front.
A good milestone would be allowing users to implement the AI interface in Python.
To do that we need to write class wrappers for the core types, and the types in battle.h
.
I will write a dlopen
wrapper for AI soon so that we can load the shared objects that Pythoni ffi.compile
spits out into C.
If you want we can split up the types and start on those Python classes.
Sounds good. But you shouldn't expect me to contribute at a regular cadence right now -- things are busy. I'll go ahead and close this issue and start monitoring Python CFFI.
Executive summary of current state:
If you are on OS X, check your gcc with gcc --version
. If it is Apple clang, you're going to have build problems. You can install GNU gcc with brew
or MacPorts
, e.g. brew install gcc
. Make sure the installed gcc is in your path ahead of the clang one while developing or modify the CC = gcc
line in the Makefile, and things should work.
Apologies in advance if I'm missing something obvious. Best of luck with the project. commit e01022192ae5156255fdc1446a2e2e65671adc78 gcc: Apple clang version 11.0.0 (clang-1100.0.33.17)