user interface, asynchronous objects, garbage collection

user interface, asynchronous objects, garbage collection

[Marco Maggi]

Ciao,

to plot math function's graphs for my Guile interface to the
GNU Scientific Library (GSL) I  use a Guile interface to the
Tool Command  Language (TCL), Tk and a  TCL extension called
BLT.  Tk handles the X Window GUI.

The superior  Scheme thread  spawns an inferior  thread that
holds a  TCL interpreter; TCL commands are  built as strings
in the  superior thread, handed  to the inferior  thread and
TCL-evaluated.

Plot widgets and coordinates  vectors are TCL objects, and I
use proxy GOOPS objects to manage them. The GOOPS things are
protected  by  a  guardian,  and  I  use  the  AFTER-GC-HOOK
mechanism  to  invoke  appropriate  destructors in  the  TCL
interpreter when they are garbage collected.

Fine.

When writing a Guile-GSL script I code forms like this:

(let* ((x     ...)
       (y     ...)
       (plot  (blt-plot x y ...)))
   (sleep-or-ask-the-user-when-its-ok-to-go-on))

the GOOPS  proxies are stored  in the LET*  environment, and
this  prevents the  GC to  collect  them while  the user  is
taking a look.

The problem  is that this  solution is not so  user friendly
when  one is  interacting at  the  REPL. The  need to  store
somewhere  the GOOPS  proxies demands  more typing  and mind
handling of variable names:

  gsh> (define (x ...))
  gsh> (define (y ...))
  gsh> ; all right so far
  ; but the following is ugly
  (define p (blt-plot x y ...))

I thought to create "bag"  objects in which plot proxies are
automatically stored by BLT-PLOT, so the user does something
like:

  gsh> (blt-plot-auto-collect #t)

or:

  gsh> (blt-plot-auto-collect 'name-of-bag)

and then I need a global collection of bags, so that one can
do:

  gsh> (blt-plot-delete 'name-of-bag)

or:

  gsh> (blt-plot-delete #t)

No matter how  I turn it, it seems to me  that I am imposing
to the user to remember annoying things.

AFAIK, GNU Octave does not even try to do this: it just lets
the user  see one plot at a  time.  And Mathlab/Simulink(tm)
just spawns  GUI windows and  lets the user destroy  them by
clicking on the X button.

So, I  wonder if  someone has already  found a  solution for
this. Suggestions are welcome.

--
Marco Maggi

"They say jump!, you say how high?"
Rage Against the Machine - "Bullet in the Head"



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: user interface, asynchronous objects, garbage collection

[Ludovic Courtès]

Hi,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> to plot math function's graphs for my Guile interface to the
> GNU Scientific Library (GSL) I  use a Guile interface to the
> Tool Command  Language (TCL), Tk and a  TCL extension called
> BLT.  Tk handles the X Window GUI.

Sorry for not answering the question at hand, but have you looked at
PS/Tk:

  http://www.t3x.org/pstk/

I don't think anyone ever tried to use it with Guile, but it might be
helpful.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: user interface, asynchronous objects, garbage collection

[Marco Maggi]

Ludovic Courtès wrote:
>have you looked at PS/Tk:
>
>  http://www.t3x.org/pstk/

I took a look at it when it was announced, and I
dismissed it because:

1. it executes a TCL shell as inferior process and this
   forces the superior one to convert all the values to
   strings, which can become time consuming, and to
   communicate through a pipe or socket pair or something
   like that, and again this is time consuming;

2. it pushes you to map Scheme to TCL, which IMHO, is
   the root of a waste of time; if one wants to interact
   with TK it has to use TCL procedures.

I have written GEE/Guile-TCL in a couple of days, and it
is finished with very simple code.

--
Marco Maggi

"They say jump!, you say how high?"
Rage Against the Machine - "Bullet in the Head"



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: user interface, asynchronous objects, garbage collection

[Ludovic Courtès]

Hi,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> When writing a Guile-GSL script I code forms like this:
>
> (let* ((x     ...)
>        (y     ...) 
>        (plot  (blt-plot x y ...)))
>    (sleep-or-ask-the-user-when-its-ok-to-go-on))
>
> the GOOPS  proxies are stored  in the LET*  environment, and
> this  prevents the  GC to  collect  them while  the user  is
> taking a look.

Isn't there a GOOPS object representing the Tk "display", the root
window or some such?  If so, I guess user code could look like:

  (window-add-plot! w (blt-plot x y ...))

  ;; `sleep-or-ask-the-user-when-its-ok-to-go-on' is replaced by
  ;; something like this:
  (window-event-loop w)

Then, as long as the window lives, the plots it displays are not GC'd.
And the user is likely to be willing to keep a reference to its window
object since it needs it to run the event loop, for instance.

I hope this is relevant,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: user interface, asynchronous objects, garbage collection

[Marco Maggi]

"Ludovic Courtès" wrote:
>"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:
>
>> When writing a Guile-GSL script I code forms like this:
>>
>> (let* ((x     ...)
>>        (y     ...)
>>        (plot  (blt-plot x y ...)))
>>    (sleep-or-ask-the-user-when-its-ok-to-go-on))
>>
>> the GOOPS  proxies are stored  in the LET*  environment, and
>> this  prevents the  GC to  collect  them while  the user  is
>> taking a look.
>
>Isn't there a GOOPS object representing the Tk "display",
the root
>window or some such?  If so, I guess user code could look like:
>
>  (window-add-plot! w (blt-plot x y ...))
>
>  ;; `sleep-or-ask-the-user-when-its-ok-to-go-on' is
replaced by
>  ;; something like this:
>  (window-event-loop w)
>
>Then, as long as the window lives, the plots it displays
are not GC'd.
>And the user is likely to be willing to keep a reference to
its window
>object since it needs it to run the event loop, for instance.
>
>I hope this is relevant,

Sorry,  no. I was  not clear  enough. Everything  is already
working, I can already execute code like this:

(let* ((x     ...)
       (y     ...)
       (plot  (blt-plot x y ...)))
   (sleep-or-ask-the-user-when-its-ok-to-go-on))

and  it  is  exactly  what  I  want to  do  when  writing  a
script.

My  problem  is  that  I  do  not  know  how  to  make  this
functionality  easily  usable  for   a  user  at  the  REPL.
Personally I hate  to write LET forms at  the REPL because I
cannot make it  fit on a single short line of  text, so I do
not want users to be forced to write it to plot a graph.

I look  the the Mathlab/Octave  interface, there are  only 3
commands:

plot(x, y) # to plot a graph

hold on    # to make 'plot' add graph to the same window

hold off   # to make 'plot' wipe out old graphs before
           # drawing the new one

I do not  think that they have designed  it this way because
they do not know how to  keep many plots at once, they know;
I guess  that they decided to  do it this way  for the exact
purpose of keeping it simple for the REPL users.

I can duplicate this interface at the REPL if I decide to. I
am trying to understand if to  keep it simple I have to make
it  "that" simple,  throwing  away (only  at  the REPL)  the
feature of  having asynchronous multiple  graphs in multiple
plots.

What I wanted  to ask is if someone here  has coded a Scheme
application  with REPL  interface and  has  discovered that:
"yes, you have to keep it  that simple to make it usable" or
that "no,  go on with asynchronous  objects handling because
the average user can do it just fine".

--
Marco Maggi

"They say jump!, you say how high?"
Rage Against the Machine - "Bullet in the Head"



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user