[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GLOBALSZ leak issue?
From: |
Paulo Moura |
Subject: |
Re: GLOBALSZ leak issue? |
Date: |
Thu, 6 Aug 2015 18:30:10 +0100 |
> On 06/08/2015, at 18:18, emacstheviking <address@hidden> wrote:
>
> I downloaded and built a fresh binary from here:
>
> git://git.code.sf.net/p/gprolog/code <http://git.code.sf.net/p/gprolog/code>
> master
>
> I then loaded this code:
>
> gtest :-
> statistics,
> gtest.
>
> It looks like it would run forever as the values didn't change.
>
> Then I ran this code:
>
> gtest :-
> statistics(global_stack, GS),
> gtest.
>
> Fatal Error: trail stack overflow (size: 16384 Kb, reached: 16384 Kb,
> environment variable used: TRAILSZ)
>
> TRAILSZ is used for, AIUI, "variable bindings to undo", so that's
> understandable; I am creating GS on each pass and then calling myself so
> it's stashing the current value of GS jut in case we ever came back.
>
> gtest :-
> statistics(global_stack, _),
> gtest.
>
> This still causes TRAILSZ to exhaust, which I expected because it is still a
> binding that has to be stashed I guess.
>
> Continuing...
>
> gtest :-
> statistics(global_stack, _),
> !,
> gtest.
>
> Same again, TRAILSZ exhausted. From my obviously incorrect understanding of
> prolog, only fail/0 would cause any memory allocation to be released at this
> point?
>
> SO... how does one use tail-recursion to keep an application running without
> running out of stack space?
How about:
gtest :-
statistics(global_stack, GS),
fail.
gtest :-
gtest.
> This really feels like "worrying about consing" when you first learn Lisp.
> Ultimately, unless you are out for performance the runtime will do it for you
> etc. BUT for Prolog, which is still new to me, I am now completely at a loss
> as to how to proceed.
>
> Paulo, we've spoken briefly in the past and I keep meaning to use LogTalk but
> would that allow me to use my custom "gprolog" binary with my SDL extensions?
> It ought to I guess.
Logtalk, not LogTalk :-) You can easily embed Logtalk and a Logtalk application
in a GNU Prolog executable. See:
https://github.com/LogtalkDotOrg/logtalk3/wiki/Embedding-Logtalk
Just make sure you use the latest Logtalk git or stable version (as I added a
workaround a few days ago for a gplc bug triggered when embedding Logtalk).
> Firstly, I will try Lindsey-s advice and better my understanding of DCG
> productions as state transformers but I can't help feeling a little bemused
> and stuck at the moment as I have failed so far to understand the nature of
> the problem i.e. why is it apparently so hard to be able to use gprolog for
> a long-running application?
>
> Many thanks chaps for your time so far!
You're welcome. Cheers,
Paulo
-----------------------------------------------------------------
Paulo Moura
Logtalk developer
Email: <mailto:address@hidden>
Web: <http://logtalk.org/>
-----------------------------------------------------------------