[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GLOBALSZ space problem...
Re: GLOBALSZ space problem...
Thu, 6 Aug 2015 18:08:38 +0100
Another alternative, that you can use together with DCGs as described in
Lindsey excellent advice, is Logtalk's parametric objects. Object parameters
are *logical* variables shared by all object predicates. Thus, it makes it
trivial to pass around "state" without the maintenance headaches of adding and
removing arguments to predicates to handle it or the downsides of using dynamic
predicates. It's different from DCGs in that DCGs excel for threading state (as
in Lindsey example, you have a *sequence* of states that you thread from a
predicate call to the following predicate call) while with parameters you have
each one representing some aspect of a state. For a simple example see:
For the libraries that support this example see:
The Logtalk example includes several other examples of parametric objects and
there's also a paper about it (mail me privately if you want a PDF copy).
> On 06/08/2015, at 02:16, Lindsey Spratt <address@hidden> wrote:
> I implemented XGP, an IDE for gprolog on the mac, that is implemented *in*
> gprolog. It runs fine. Menus, Windows, Graphics (drawing pictures); all done
> in gprolog as extended by XGP.
> I make very slight use of globals - I would recommend parameter passing for
> state or asserting/retracting clauses where feasible. The parameter passing
> approach makes the best use of the prolog execution model with its
> semi-magical heap garbage collection.
> I use the DCG notation a lot in various programs where I want to pass a
> context around among a collection of predicates.
> Consider a predicate foo/3 that has a rule that passes a ‘modifiable’ context
> among three sub-goals, bar1/3, bar2/3, and bar3/3:
> foo(s(X, Y, Z), InputContext, OutputContext) :-
> bar1(X, InputContext, InterimContext1),
> bar2(Y, InterimContext1, InterimContext2),
> bar3(Z, InterimContext2, OutputContext).
> This can be written using DCG notation as:
> foo(s(X,Y,Z)) —>
> Then add a context modifying predicate such as
> context_p(c(P1,Q,R), c(P2,Q,R), P1, P2).
> So bar1/3 can access the context using:
> bar1(X, C1, C2) :-
> context_p(C1, C2, X, Y),
> Y is X + 1.
> I’m a big fan of DCG programming in ‘stateful’ systems.
>> On Aug 5, 2015, at 5:35 PM, emacstheviking <address@hidden> wrote:
>> I have written a lovely binding to SDL and I started developing an
>> application and it runs for a while then runs out of globals space.
>> In my wisdom, I decided to use globals to hold key items like app.
>> configuration and also the various SDL handles, window, renderer handles etc
>> instead of passing around more and more parameters.
>> If I can't solve this I am doomed! I will have to write my world class
>> application in something other than GNI Prolog.
>> Is gprolog "suitable" for a graphics based user application that might run
>> for a full working day and be subject to untold requests by users?
>> I've invested a *serious* amount of time in my gprolog/SDL2 project: it has
>> 87 SDL functions for lines, points, textures, window creation the lot, as
>> well as predicates for working with TTF fonts, music and samples, hey, I
>> even added some circle drawing in the c-code as well, solid and outline.
>> Why do I keep running out of space? I thought a "!" operation in my main
>> loop would do it, I discovered this when writing a proof oc concept video
>> game too, that seemed to be stable when printing out the statistics. I will
>> have to play spot the difference.
>> I tried commenting out stuff to pin it down but so far no luck, it just
>> slowly but surely leeks away until it dies.
>> I guess I just don't understand how garbage collection works.
>> Are g_assign and g_read designed to be hammered hard in a graphics
>> applications rendering loop?
>> Sigh, I hope somebody out there replies, this list seems dead in recent
>> Users-prolog mailing list
> Users-prolog mailing list