Re: More on GuIfying the repl

[Ariel Rios]

El 13 Apr 2001 20:27:16 +0100, Neil Jerram escribió:

> This is cool, although I think that some applications might want to
> embed only part of GuileRepl, not necessarily all of it.  Some
> applications might not want the editor widget, for example.

Yes indeed. I have already functions in GuileRepl that enables
to hide both the editor or the repl text widgets
 
 
>     >> On a detailed level, I think there is one issue with the
>     >> specified interface.  Namely, what is the relationship (current
>     >> module etc.)  between Scheme expressions evaluated by the REPL
>     >> inside the interface and other evaluation performed by the
>     >> application outside the interface?
> 
>     Ariel> I am not really sure what you mean with that.
> 
> Is evaluation in the rest of the application performed in the same
> environment and current module as evaluation in the REPL?  (Or perhaps
> there isn't any evaluation in the rest of the application?)
THe internal scheme functions used by the widget are performed
on the same env/module as in the REPL.

The idea behind here is to be able to call
GuileRepl functions from the repl provided by the widget, i.e.
being able to do (guile-repl-help "socket") in the repl 

 
>     >> To avoid using explicit continuations (if so desired), use
>     >> guile-gui's widgets with paren matching and history handlers
>     >> (but not as a port) as the front end for a non-blocking REPL.
>     Ariel> Not complety sure on this one. For the moment maybe we can
>     Ariel> simple do (call-with-dynamic-root) if necesary...
> 
> I don't understand how `call-with-dynamic-root' is relevant here -
> please explain.The 

What I think is that in some cases doing some evaluation on scheme code
in the repl widget might block the rest of the widget/component
so, to avoid this happenig it might be simpler to do
a call/w/d/root...



> I'd be very happy for it to do so, but I don't think it supersedes
> guile-gui just yet.  For my tastes, there are three reasons why I
> would currently prefer to continue working with guile-gui.
> 
> 1. guile-repl is too monolithic.  It provides a single
>    take-it-or-leave-it composite widget.  My preference is to provide
>    components of the smallest sensible size - such as (gui entry-port)
>    - so that both one's own package and other people can build them up
>    in their own ways.
Maybe we can have a GuileReplEditor and a GuileReplRepl (?) widgets
so GuileRepl could  be defined as
struct GuileRepl
{
    GtkVbox vbox;

    GuileReplEditor *editor;
    GuileReplRepl *repl;

    }

    Although I prefger the current implementation, and to hide/destroy
    those widgets if not needed.
     
> 2. guile-repl is dependent on a Gnome dev environment.  Again,
>    breaking things down into smaller pieces would help here.  The
>    GuileRepl widget proper only requires Gtk and so could be packaged
>    as non-Gnome-specific.  Obviously the Bonobo aspect does need Gnome
>    (or at least some of it), so this should be packaged as an extra
>    which builds on the widget package.
Well, The main idea of guilerepl is to main used with bonobo and thus with 
GNOME.
I can enable the GuileRepl to build with Gtk support only. So if you
have a good GNOME installation you can get bonobo component plus 
other side benefits (using GNOME widgets for dialogs, messagebox, etc)

    In the same vein, I note that CVS guile-gtk currently doesn't build
>    because of Gnome problems.  IMO this is a significant bug.
HMMM
What kind of problems? I should fix them if any

> 3. guile-repl has too high a `hacktivation enery' because a lot of it
>    is written in C.  This is obviously just my opinion, and I need to
>    check out your latest changes, but that was my feeling when I last
>    looked.

Well, yes there is a lot written in C. All of the widget stuff.
Lots of wrappers for rthe Scheme functions. The guile_repl_eval is in C
And the parent mathch algorithm. The guile-repl;s big cheese
is on guile-repl.scm.
>     Ariel>                              My aproach is intended for
>     Ariel> adding scripting and a graphicl repl to C
>     Ariel> applications. Whilst guile-gui can also do this I think it
>     Ariel> is harder for the non Guile literate to do this step.
> 
> I agree - Bonobo is a Good Thing.  But the interfaces should be
> defined in such a way that multiple implementation are possible.

However, I am not really sure which is the real benefits in this case
to enable the bonobo component to work with multiple implementations.

> 
>     Ariel>                                                        -We
>     Ariel> can however offer almost the same behaviour for native
>     Ariel> Scheme development (with expcetion of the bonobo component)
>     Ariel> since guile-repl code interesting functionality is coded in
>     Ariel> scheme.
> 
> I don't see the necessary connection between Scheme implementation and
> use for Scheme development.

guile-gui is coded in Scheme. It is trivial to add it unto
an Scheme program but it is not as easy to add it unto an existing C
program I think...

  
 
>     Ariel>          -Maybe, we can simply wrap GuileRepl inside
>     Ariel> guile-gtk (something weird I think) but can be achieved if
>     Ariel> we can separate all Scheme code from the widget definition.
> 
> I think it would make good sense to add REPL and port-related widgets
> to guile-gtk (and to ensure that guile-gtk ats a whole is
> Gnome-independent).
guile-gtk is completely GNOME independent.

Look. I have gnome-guile which is formed by:
guile-gtk: Gtk bindings 
guile-gnome: Gnome bidings for gnome-print, gtkhtml, libglade, etc 
silex: Scheme implementation of lex
guile-orbit: Orbit bindings

guile-gtk does not depend on GNOME 

So, what I think is that this GUI effort might be done at three levels
(name of leves should be change of course)

guile-gui: Scheme code to implement an repl inside a GtkWidget
guile-repl: C code that implements the GtkWidget using the guile-gui
algorithms and providing some other interesting functions
guile-repl-bonobo: Bonobo component.

ariel