Re: Pl_Query_Call crash on windows (MacOSX OK)

Hi,

On Thu, Mar 25, 2010 at 10:25 PM, Alexandre Saidi <
[email protected]> wrote:

> Dear Sarah.
> What do you mean by « Mac OSX OK »  ?
>

I use Mac OSX for my every day development work.  There was no problems on
Mac - it worked fine.

I meant that I was having trouble with Windows, however it worked fine on
Mac OSX.  I have not tried on Linux yet, but I don't anticipate any problems
there.

Windows was the problem.

However!!!!

I have now got to the point where I have Windows working as well as Mac!!  I
am happy.  :-)

Switching to MSVC tool chain (from MinGW) seemed to do the trick, or it may
have been going to the latest tarball of gprolog, as suggested by Daniel.

So I can produce a Windows installer and do some test installs - which is
where I wanted to get to before going back to working on the prolog source
on my Mac.

At present the project does almost nothing, but I wanted proof that it
worked at all on Windows before I spent too much time on it.

For anyone curious or self-harming enough to want to look:
http://sites.google.com/a/storybridge.org/games/ethex2040



> As far as I know, on mac, XGP does some jobs, not that much.
>

On Mac I use the QtCreator GUI for C++ development.  I use gvim, plus
gprolog from the command line for prolog.  I envisage that the prolog will
be most of the work, and the UI is just a wrapper.


> Linux : i use t use command line style.
>

Me too.  :-)


>
> 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<http://gitorious.org/ethex2040/ethex2040/blobs/master/INSTALL#line89>.
>  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