Dear Sarah. What do you mean by « Mac OSX OK » ? As far as I know, on mac, XGP does some jobs, not that much. Linux : i use t use command line style.
Am I wrong? Is there any thing about Mc/Linux and a worked-around GUI ? regards. Alex Le 24 mars 2010 à 15:19, Sarah Smith a écrit : > OK, reporting back. :-) > > After some battling I have gotten Qt + MSVC + gprolog all to play nice. I've > documented the lessons learned in the INSTALL file, and the other necessary > changes to build files are also there, in this latest commit: > > http://gitorious.org/ethex2040/ethex2040/commit/c737effd59e7b4d14e4042653c1c5a76e4c233fd > > Initially I thought I had a running app but somehow the wrong version of gplc > was being called, and when the resultant object file was linked the prolog > system could not find any predicates. > > The solution turned out to be an issue with msvc 2008 manifest files and the > workaround is also documented in the INSTALL file. In the future perhaps the > gprolog build under msvc could take this into account. > > Now I'm basically back where I was with mingw, where the app compiles and > runs, and calls into the prolog to initiate the logic, the prolog calls back > out successfully with the initial report, but the more complex commands like > "look" are failing. > > I have not yet put any time into debugging this so it may prove to be easy to > fix with the different toolchain. > > On Sun, Mar 21, 2010 at 11:10 PM, Sarah Smith <[email protected]> wrote: > Following a suggestion off list I am trying a different toolchain - VC9, > which is a free download from Microsoft. As per the instructions for msvc in > the WINDOWS file I have also installed the platform SDK. That and mingw are > my only options for Qt on Windows so I hope it works. :-) > > Switching toolchains was not trivial. Much downloading and configuring and a > few minor glitches later I finally have a debug build of gprolog built with > Visual Studio C++ 2008. > > I had to comment out the line: > > #define fgetc getc > > in arch_dep.h to get around an error: > > c:\program files\microsoft visual studio 9.0\vc\include\stdio.h(272) : error > C3163: 'getc': attributes inconsistent with previous declaration > c:\program files\microsoft visual studio 9.0\vc\include\stdio.h(214) > : see declaration of 'getc' > > (( I guess the autoconf test was failing to set HAVE_FGETC )) > > Now I have to persuade Qt to use the VS tool chain... will report back. > > On Sat, Mar 20, 2010 at 10:11 PM, Sarah Smith <[email protected]> wrote: > Hi, > > First off would like to say thanks to the authors of gprolog for a great > prolog implementation and an nice cross-platform distribution. > > I'm working on a text adventure game as a personal project, using prolog for > the game logic, and C++/Qt for the UI. > > The plan is to release it on Mac (my main development platforrm), Windows (I > run XP in a VM just for this purpose) and Linux. My day job is writing C++ > code, and I know my way around compilers. > > As soon as I got past first base, with some game logic and a UI working, I > wanted to build a release on all platforms to make sure things are all > working. > > But while things work well on Mac - after a couple of teething problems - I'm > stuck with a crash bug on Windows. > > The problem is occurring in my "do_command" function when I call > Pl_Query_Call: > > extern "C" void do_command(const char *command) > { > int func; > int res; > PlTerm arg[512]; > char cmd[512]; > PlTerm list; > > func = Find_Atom("do_command"); > > if (func) > { > Pl_Query_Begin(PL_TRUE); > i = 0; > k = 0; > list[0] = NULL; > while (command[i]) > { > /* parse each token out into cmd */ > arg[k++] = Mk_String(cmd); > } > if (k) > list = Mk_Proper_List(k, arg); > res = Pl_Query_Call(func, 1, list); > while (res) > res = Pl_Query_Next_Solution(); > Pl_Query_End(PL_RECOVER); > } > } > > I've cut out some detail but the full source code is here: > http://gitorious.org/ethex2040/ethex2040/blobs/master/prolog.cpp#line43 > > I compiled gprolog from source so I could use it in debug mode, but the stack > trace is not helpful. At least it shows the site of the crash. > > When the above function processes a command, I get a SIGSEGV crash on line 69 > of file unify.c in the function Pl_Unify: > > Bind_UV(u_adr, v_word) > > I presume there's something wrong with the u_adr pointer. But the other > frames in the stack are assembler and so far I'm mystified as to how to trace > what is going wrong. > > Any ideas? > > Regards, > > Sarah Smith > > > _______________________________________________ > Users-prolog mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/users-prolog ------------------------------- Alexandre Saidi Maitre de Conférences Ecole Centrale de Lyon-Dép. MI LIRIS-CNRS UMR 5205 Tél : 0472186530, Fax : 0472186443
_______________________________________________ Users-prolog mailing list [email protected] http://lists.gnu.org/mailman/listinfo/users-prolog
