gh_repl

gh_repl

[Mike Gran]

Hi-
 
What is the replacement for gh_repl?  Which is to say, if I'm using
Guile as an extension language, what command should I execute in C
to drop me into the Guile REPL?
 
Thanks,
 
Mike

Re: gh_repl

[Andy Wingo]

On Sun 25 Sep 2011 05:54, Mike Gran <spk121@yahoo.com> writes:

> What is the replacement for gh_repl?

I don't know!  When I started with Guile in 2003 I think the GH API was
already deprecated :)

> Which is to say, if I'm using Guile as an extension language, what
> command should I execute in C to drop me into the Guile REPL?

What should happen when the user does a C-d at the REPL?  If the answer
is that the application quits, then it's probably scm_shell().
Otherwise there isn't a very good answer.

scm_call_1 (scm_public_ref ("ice-9 top-repl", "top-repl")) ?

Do we need a better answer here? :)

Andy
-- 
http://wingolog.org/

Re: gh_repl

[Mike Gran]

> From: Andy Wingo <wingo@pobox.com>
> To: Mike Gran <spk121@yahoo.com>
> Cc: Guile User <guile-user@gnu.org>
> Sent: Monday, January 9, 2012 9:35 AM
> Subject: Re: gh_repl
> 
> On Sun 25 Sep 2011 05:54, Mike Gran <spk121@yahoo.com> writes:
> 
>>  What is the replacement for gh_repl?
> 
> I don't know!  When I started with Guile in 2003 I think the GH API was
> already deprecated :)
> 
>>  Which is to say, if I'm using Guile as an extension language, what
>>  command should I execute in C to drop me into the Guile REPL?
> 
> What should happen when the user does a C-d at the REPL?  If the answer
> is that the application quits, then it's probably scm_shell().
> Otherwise there isn't a very good answer.
> 
> scm_call_1 (scm_public_ref ("ice-9 top-repl", "top-repl")) ?
> 
> Do we need a better answer here? :)

For guile-2.0, I eventually settled on 
 
scm_call_1 (scm_c_public_ref ("system repl repl", "start-repl"),
   scm_from_locale_symbol ("scheme"));
 
This trick I learned from this e-mail from Tristan
 
http://lists.gnu.org/archive/html/bug-guile/2011-10/msg00040.html
 
And with that, ",q" returns control to the calling C function.
 
(I'm in a push to release a new rev of everything I've ever done in 2012.
I'd like to get to the point where all my guile-1.8 using progs only use
functions documented in the 1.8 manual and ditto for guile-2.0)
 
Thanks,
 
Mike

Re: gh_repl

[Andy Wingo]

On Mon 09 Jan 2012 19:11, Mike Gran <spk121@yahoo.com> writes:

>> scm_call_1 (scm_public_ref ("ice-9 top-repl", "top-repl")) ?
>> 
>> Do we need a better answer here? :)
>
> For guile-2.0, I eventually settled on 
>  
> scm_call_1 (scm_c_public_ref ("system repl repl", "start-repl"),
>    scm_from_locale_symbol ("scheme"));

This won't catch SIGINT, and it won't add on the session, regex, and
threads bindings to your guile-user.  Is that what you wanted?

See ice-9/top-repl.scm (which eventually does dispatch to that
start-repl command).

Andy
-- 
http://wingolog.org/

Re: gh_repl

[Mike Gran]

> From: Andy Wingo <wingo@pobox.com>
 >>  For guile-2.0, I eventually settled on 
>>   
>>  scm_call_1 (scm_c_public_ref ("system repl repl", 
> "start-repl"),
>>     scm_from_locale_symbol ("scheme"));
> 
> This won't catch SIGINT, and it won't add on the session, regex, and
> threads bindings to your guile-user.  Is that what you wanted?
> 
> See ice-9/top-repl.scm (which eventually does dispatch to that
> start-repl command).

Thanks.  I noticed the limitations you mentioned, but, didn't know
what to do about it.  The solution I posted was the first solution
I found from a cursory search of the web.
 
I'll try it out.
 
Thanks,
 
Mike 

Re: gh_repl

[Andy Wingo]

On Mon 09 Jan 2012 20:16, Mike Gran <spk121@yahoo.com> writes:

>> From: Andy Wingo <wingo@pobox.com>
>  >>  For guile-2.0, I eventually settled on 
>>>   
>>>  scm_call_1 (scm_c_public_ref ("system repl repl", 
>> "start-repl"),
>>>     scm_from_locale_symbol ("scheme"));
>> 
>> This won't catch SIGINT, and it won't add on the session, regex, and
>> threads bindings to your guile-user.  Is that what you wanted?
>> 
>> See ice-9/top-repl.scm (which eventually does dispatch to that
>> start-repl command).
>
> Thanks.  I noticed the limitations you mentioned, but, didn't know
> what to do about it.  The solution I posted was the first solution
> I found from a cursory search of the web.
>  
> I'll try it out.

Sounds like we should have a C function, no?

(Sorry, not trying to deluge you in mail here :-)

Let's consider this to be an open bug, that we should fix somehow.

Andy
-- 
http://wingolog.org/

Re: gh_repl

[Mark H Weaver]

Mike Gran <spk121@yahoo.com> writes:
>    scm_from_locale_symbol ("scheme"));

Note that it's good practice to always use `scm_from_utf8_symbol' or
`scm_from_latin1_symbol' when the argument is a C string literal.  The
choice of which (`utf8' or `latin1') depends on the encoding of your C
source file.  Similarly, for creating strings and keywords from C string
literals, use `scm_from_{utf8,latin1}_string' or
`scm_from_{utf8,latin1}_keyword'.

(though unfortunately Guile 1.8 did not include any of these functions).

In this case it doesn't matter because the C string literal contains
only ASCII characters, and all locale encodings are ASCII compatible.
However, if you added non-ASCII characters to the string literal, your
program would fail unless the user's locale encoding happened to match
that of your source code.

More importantly, since many people tend to copy code snippets from what
they see here and elsewhere, it's good to start spreading good i18n
habits.  The key idea to spread is: it's wrong to use the user's locale
to interpret a C string literal.

    Thanks,
      Mark

Re: gh_repl

[Mike Gran]

> From: Mark H Weaver <mhw@netris.org>
>>     scm_from_locale_symbol ("scheme"));
> 
> Note that it's good practice to always use `scm_from_utf8_symbol' or
> `scm_from_latin1_symbol' when the argument is a C string literal.
 
 [... ]

> More importantly, since many people tend to copy code snippets from what
> they see here and elsewhere, it's good to start spreading good i18n
> habits.  The key idea to spread is: it's wrong to use the user's locale
> to interpret a C string literal.
 
Good point.
 
Virtually all of my personal code is written in the subset of documented API
between 1.8 and 2.0 and is written in US-ASCII, but, you're right
about spreading good habits when discussing code in public.
 
Thanks,
 
Mike

Re: gh_repl

[Chris Vine]

On Mon, 09 Jan 2012 16:18:04 -0500
Mark H Weaver <mhw@netris.org> wrote:
> Mike Gran <spk121@yahoo.com> writes:
> >    scm_from_locale_symbol ("scheme"));
> 
> Note that it's good practice to always use `scm_from_utf8_symbol' or
> `scm_from_latin1_symbol' when the argument is a C string literal.  The
> choice of which (`utf8' or `latin1') depends on the encoding of your C
> source file.

Unless guile does something clever, I think it would depend on the
encoding of the narrow character execution character set, which may not
be the same as the source character set (§5.2.1/1 and 5.2.1.2/1 of C11).

The execution character set (the encoding appearing in the binary) is
implementation defined according to C99/11.  If using gcc,
http://gcc.gnu.org/onlinedocs/cpp/Character-sets.html
suggests you should be OK in assuming UTF-8 as the default for the
encoding of the narrow character execution character set, provided that
-finput-charset is set to the correct input file encoding.  You can use
the -fexec-charset compiler flag to put something else in the binary
though.

The C standard refers to narrow and wide source character sets and
narrow and wide execution character sets.  gcc takes it a bit further
and first converts the encoding of the input files passed to it into its
own notion of the source character set. One curiosity is that if the
input charset is not specified via -finput-charset, gcc appears to try
to obtain the locale character set to perform this conversion:

  "-finput-charset=charset:  Set the input character set, used for
  translation from the character set of the input file to the source
  character set used by GCC. If the locale does not specify, or GCC
  cannot get this information from the locale, the default is UTF-8.
  This can be overridden by either the locale or this command line
  option. Currently the command line option takes precedence if there's
  a conflict. charset can be any encoding supported by the system's
  iconv library routine."

This means that with gcc source code may not be portable in the absence
of -finput-charset being passed to the compiler.  I avoid this by always
using ASCII (ie English) for string literals in source files and
obtaining translated text from gettext(), which deals with the
conversion programatically and therefore portably.

The overarching point is that, as you say, it would be wrong to assume
the execution character set bears any relation to the locale encoding
of a particular user on a particular machine.  C++ works similarly
(§2.2/5 of C++11).

We are not concerned with windows here, but if we were, I believe visual
studio uses Windows ANSI as the narrow character execution character
set in C and C++.

Chris