GLOBALSZ space problem...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GLOBALSZ space problem...

emacstheviking
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?

Gutted!

Sigh, I hope somebody out there replies, this list seems dead in recent months.



_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog
Reply | Threaded
Open this post in threaded view
|

Re: GLOBALSZ space problem...

Lindsey Spratt-4
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)) —>
  bar1(X),
  bar2(Y),
  bar3(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.

Lindsey

> On Aug 5, 2015, at 5:35 PM, emacstheviking <[hidden email]> 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?
>
> Gutted!
>
> Sigh, I hope somebody out there replies, this list seems dead in recent months.
>
>
> _______________________________________________
> Users-prolog mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/users-prolog


_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog
Reply | Threaded
Open this post in threaded view
|

Re: GLOBALSZ space problem...

Donald Winiecki
On Wed, Aug 5, 2015 at 7:16 PM, Lindsey Spratt <[hidden email]> 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.

​<
​snip>
 
> 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.
>

​<snip>

I am looking for an alreay-built set of resources to be able to draw and paint to the screen and save to files from within Prolog itself, but I'm on Linux. Any chances XGP  and perhaps gprolog/SDL2  will be adapted to Linux in the future?

Best,

_don​


_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog
Reply | Threaded
Open this post in threaded view
|

Re: GLOBALSZ space problem...

Paulo Moura-2
In reply to this post by Lindsey Spratt-4
Hi,

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:

https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/assignvars

For the libraries that support this example see:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/assignvars.txt

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).

Cheers,

Paulo

> On 06/08/2015, at 02:16, Lindsey Spratt <[hidden email]> 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)) —>
>  bar1(X),
>  bar2(Y),
>  bar3(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.
>
> Lindsey
>
>> On Aug 5, 2015, at 5:35 PM, emacstheviking <[hidden email]> 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?
>>
>> Gutted!
>>
>> Sigh, I hope somebody out there replies, this list seems dead in recent months.
>>
>>
>> _______________________________________________
>> Users-prolog mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/users-prolog
>
>
> _______________________________________________
> Users-prolog mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/users-prolog

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:[hidden email]>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------





_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog
Reply | Threaded
Open this post in threaded view
|

Re: GLOBALSZ space problem...

emacstheviking
In reply to this post by Donald Winiecki

Donald,
There is every chance. As much as I like my Mac my first love is Ubuntu and I have always planned to port it..

You have given me a reason to do that and become client number one lol.

Give me the weekend to try to get a Linux build up and running and I will push the project from private bitbucket to github with pleasure

:)

On 6 Aug 2015 21:27, "Donald Winiecki" <[hidden email]> wrote:
On Wed, Aug 5, 2015 at 7:16 PM, Lindsey Spratt <[hidden email]> 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.

​<
​snip>
 
> 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.
>

​<snip>

I am looking for an alreay-built set of resources to be able to draw and paint to the screen and save to files from within Prolog itself, but I'm on Linux. Any chances XGP  and perhaps gprolog/SDL2  will be adapted to Linux in the future?

Best,

_don​


_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog


_______________________________________________
Users-prolog mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/users-prolog