Re: Can scm_shell be interrupted?

Re: Can scm_shell be interrupted?

[Remco Bras]

Hello,

after the last exchange in this thread, I wrote and tested a prototype of a 
repl for my app. The code for this is as follows:

int
exec_guile_shell (void *unused_arg)
{
  scm_init_guile();
  /*Horribly inefficient*/
  while(1)
    {
      SCM_TICK;
      SDL_mutexP(repl_signal);
      
scm_simple_format(scm_current_output_port(),scm_from_locale_string(PROMPT),SCM_EOL);
      
scm_simple_format(scm_current_output_port(),scm_from_locale_string("~S"),scm_list_1
(scm_primitive_eval(scm_read(scm_current_input_port()))));
      scm_newline(scm_current_output_port());
      SDL_mutexV(repl_signal);
    }
  return 0;                     //never reached, just here to please gcc.
}

This is run when the app starts, after using scm_c_define_gsubr to define the 
primitive interface my app exports and after scm_c_primitive_load is used to 
read in user-defined scheme files. When this function runs, the repl_signal 
mutex is already locked, after which a user's file may use (run-repl) to tell 
the main loop to unlock the mutex. 

For the most part, this works fine, but if I use this REPL to evaluate a call 
to one of the functions I have defined using scm_c_define_gsubr, for example 
(stop-repl), the function is unbound in the environment the REPL uses. I've 
tried using scm_interaction_environment() as a second argument to scm_eval 
rather than using scm_primitive_eval, but that did not solve this problem. 

I'm using guile 1.8.4 on GNU/Linux, in case that's relevant. Also, when 
evaluating files using scm_c_primitive_load, the previously defined functions 
are bound, regardless of whether they were defined by scm_c_define_gsubr or 
another file.

Regards,

Remco.

Re: Can scm_shell be interrupted?

[Neil Jerram]

2008/5/16 Remco Bras <vrsoft@gmail.com>:
> Hello,
>
> after the last exchange in this thread, I wrote and tested a prototype of a
> repl for my app. The code for this is as follows:
>
> int
> exec_guile_shell (void *unused_arg)
> {
>  scm_init_guile();
[...]
> This is run when the app starts, after using scm_c_define_gsubr to define the
> primitive interface my app exports and after scm_c_primitive_load is used to
> read in user-defined scheme files.
[...]
> For the most part, this works fine, but if I use this REPL to evaluate a call
> to one of the functions I have defined using scm_c_define_gsubr, for example
> (stop-repl), the function is unbound in the environment the REPL uses. I've
> tried using scm_interaction_environment() as a second argument to scm_eval
> rather than using scm_primitive_eval, but that did not solve this problem.

What environment (or module) are your gsubrs defined in, and how
exactly does your C code achieve this?

Does exec_guile_shell() run in a separate thread from the thread where
the gsubrs were defined?

       Neil

Can scm_shell be interrupted?

[Remco Bras]

Hello,

I have a question about guile. I'd like to know if it is feasible to run a 
guile REPL and control when it runs. For example, consider the following 
scenario. A package may or may not have a thread running scm_shell, when the 
user requests that the package runs an REPL. The package responds by running 
scm_shell in a thread and keeping that thread's ID. If the user wants the 
package to stop the REPL at any moment, is there a way to do this safely? 

Thanks in advance,

Remco Bras

Re: Can scm_shell be interrupted?

[Neil Jerram]

Remco Bras <vrsoft@gmail.com> writes:

> Hello,
>
> I have a question about guile. I'd like to know if it is feasible to run a 
> guile REPL and control when it runs. For example, consider the following 
> scenario. A package may or may not have a thread running scm_shell, when the 
> user requests that the package runs an REPL. The package responds by running 
> scm_shell in a thread and keeping that thread's ID. If the user wants the 
> package to stop the REPL at any moment, is there a way to do this safely? 

Where does the REPL's input come from?

If its stdin, being read in a blocking way (as is the default), it
would be tricky if the REPL thread did the read directly.  But you
could have a special stdin-reader thread, responsible for reading and
buffering lines of input, and then supplying them to whichever REPL
runs next.

What happens if the user wants to stop a package's REPL when the user
has already typed half a line of input into that REPL?

It might also be possible to make stdin non-blocking, and use select
to avoid trying to read before there is a whole line available.

If its a GUI app, it becomes less a matter of a REPL reading from a
port, and more a matter of a widget collecting input which can then be
passed into the REPL.  (Although the two approaches can be reconciled;
see graphical-repl.scm in guile-gnome.)  I think that fits slightly
more naturally with your idea of a selectable REPL, so may be easier
to implement in your app.

In summary: lots of options, need more detail about how your overall
app works and what you want it to look like.

Regards,
     Neil

Re: Can scm_shell be interrupted?

[Remco Bras]

Hi Neil,

The REPL's input comes directly from stdin, usually attached to a
terminal. My app is a game engine whose games are written in guile.
Currently, the engine runs scm_shell in a separate thread on startup,
so the user can interactively program his games.

However, this causes issues if someone decides to distribute a game
written for this engine and doesn't want players to play around
interactively with the game data.

Perhaps the simplest solution is to only run the REPL on demand, since
the engine executes user-defined scheme files on startup anyway. If
this is done, perhaps the repl thread could execute a loop, checking a
POSIX condition variable or something similar and using scm_eval to
evaluate code read from stdin, only switching the REPL off between
reading expressions.

That approach does solve the problem where a user types half an
expression on a line, without finishing it on the next line. If a
user's REPL is suddenly turned off while he is still typing an
expression, that would be annoying, but probably the game code's fault
as I intend to offer this functionality as a part of the interface,
rather than controlling the REPL in the engine.

Regards,

Remco

On 5/12/08, Neil Jerram <neil@ossau.uklinux.net> wrote:
> Remco Bras <vrsoft@gmail.com> writes:
>
>> Hello,
>>
>> I have a question about guile. I'd like to know if it is feasible to run a
>>
>> guile REPL and control when it runs. For example, consider the following
>> scenario. A package may or may not have a thread running scm_shell, when
>> the
>> user requests that the package runs an REPL. The package responds by
>> running
>> scm_shell in a thread and keeping that thread's ID. If the user wants the
>> package to stop the REPL at any moment, is there a way to do this safely?
>
> Where does the REPL's input come from?
>
> If its stdin, being read in a blocking way (as is the default), it
> would be tricky if the REPL thread did the read directly.  But you
> could have a special stdin-reader thread, responsible for reading and
> buffering lines of input, and then supplying them to whichever REPL
> runs next.
>
> What happens if the user wants to stop a package's REPL when the user
> has already typed half a line of input into that REPL?
>
> It might also be possible to make stdin non-blocking, and use select
> to avoid trying to read before there is a whole line available.
>
> If its a GUI app, it becomes less a matter of a REPL reading from a
> port, and more a matter of a widget collecting input which can then be
> passed into the REPL.  (Although the two approaches can be reconciled;
> see graphical-repl.scm in guile-gnome.)  I think that fits slightly
> more naturally with your idea of a selectable REPL, so may be easier
> to implement in your app.
>
> In summary: lots of options, need more detail about how your overall
> app works and what you want it to look like.
>
> Regards,
>      Neil
>
>