Problem with wide characters on upgrading to guile 2.x
GNU/Denemo has a number of guile scripts in which wide characters are embedded in strings. These used to work in guile 1.8 but with guile 2.0 I am seeing the following error message trying to use a string with " " in it (if that string will get through the email software) (format #t "~%=> ~A~%"" ") ; the throw arguments are (scm_to_stringn cannot convert wide string to output locale 84 #f #f) what is "locale 84" and how can I return to the desired behavior? Richard Shann
Re: Problem with wide characters on upgrading to guile 2.x
2013/8/22 Richard Shann > GNU/Denemo has a number of guile scripts in which wide characters are > embedded in strings. These used to work in guile 1.8 but with guile 2.0 > I am seeing the following error message trying to use a string with " > " > in it (if that string will get through the email software) > > (format #t "~%=> ~A~%"" ") > ; the throw arguments are > > (scm_to_stringn cannot convert wide string to output locale 84 #f #f) > > what is "locale 84" and how can I return to the desired behavior? > > I don't know much about the internal details, but did you try to set the locale of the environment to e.g. C.UTF-8 like that $ LC_ALL="C.UTF-8" guile # or your particular script (the list of possible values can be obtained by typing "locale -a" on modern unix systems)
Re: Problem with wide characters on upgrading to guile 2.x
Thank you for your reply. I didn't try altering anything in the program, because this problem has arisen when changing from guile-1.8 to guile-2.0 and so I am hoping it is an understood problem. FWIW I see that the following code is executed at Denemo program startup setlocale (LC_ALL, ""); bindtextdomain(GETTEXT_PACKAGE, get_system_locale_dir ()); bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8"); textdomain(GETTEXT_PACKAGE); so it would seem that LC_ALL is being specifically unset. The code works both under GNU/Linux and Windows using guile-1.8. Putting setlocale (LC_ALL, "C.UTF-8") in the above initialization sequence does not affect the behavior. Richard On Thu, 2013-08-22 at 14:50 +0200, Panicz Maciej Godek wrote: > 2013/8/22 Richard Shann > GNU/Denemo has a number of guile scripts in which wide > characters are > embedded in strings. These used to work in guile 1.8 but with > guile 2.0 > I am seeing the following error message trying to use a string > with " > " > in it (if that string will get through the email software) > > (format #t "~%=> ~A~%"" ") > ; the throw arguments are > > (scm_to_stringn cannot convert wide string to output locale 84 > #f #f) > > what is "locale 84" and how can I return to the desired > behavior? > > > > I don't know much about the internal details, but did you try > to set the locale of the environment to e.g. C.UTF-8 like that > > > $ LC_ALL="C.UTF-8" guile # or your particular script > > > (the list of possible values can be obtained by typing "locale -a" > on modern unix systems) > >
Re: Problem with wide characters on upgrading to guile 2.x
I have been doing some experiments with the guile interpreter guile --version guile (GNU Guile) 2.0.5-deb+1-3 and it seems to understand the wide characters, using the unicode e176 character with the string "hello" attached I get this: scheme@(guile-user)> (string-append " " "hello") $1 = " \ue176hello" scheme@(guile-user)> (display " ") scheme@(guile-user)> (display (string-append " " "hello")) helloscheme@(guile-user)> I notice that I do not have LC_ALL set in my environment. >From inside Denemo scm_c_eval_string() is being used to evaluate a string that includes this wide character and that is throwing the exception. Richard On Thu, 2013-08-22 at 14:50 +0200, Panicz Maciej Godek wrote: > 2013/8/22 Richard Shann > GNU/Denemo has a number of guile scripts in which wide > characters are > embedded in strings. These used to work in guile 1.8 but with > guile 2.0 > I am seeing the following error message trying to use a string > with " > " > in it (if that string will get through the email software) > > (format #t "~%=> ~A~%"" ") > ; the throw arguments are > > (scm_to_stringn cannot convert wide string to output locale 84 > #f #f) > > what is "locale 84" and how can I return to the desired > behavior? > > > > I don't know much about the internal details, but did you try > to set the locale of the environment to e.g. C.UTF-8 like that > > > $ LC_ALL="C.UTF-8" guile # or your particular script > > > (the list of possible values can be obtained by typing "locale -a" > on modern unix systems) > >
Re: Problem with wide characters on upgrading to guile 2.x
Hi Richard-
> scheme@(guile-user)> (string-append " " "hello")
> $1 = " \ue176hello"
> scheme@(guile-user)> (display " ")
> scheme@(guile-user)> (display (string-append " "
> "hello"))
> helloscheme@(guile-user)>
> I notice that I do not have LC_ALL set in my environment.
>
> From inside Denemo scm_c_eval_string() is being used to evaluate a
> string that includes this wide character and that is throwing the
> exception.
I've been gone a while, so I don't know what the latest is.
But based on old knowledge...
1. Make sure that you Guile script files are UTF-8. If they
are not, you'll need to explicitly put a "coding:"
declaration at the top of each file.
2. In the inner_main of your scm_with_guile call,
try calling scm_setlocale. Maybe something like this?
(This shouldn't make a difference, I think.
But, if it does, it says something interesting.)
scm_setlocale( scm_variable_ref(scm_c_lookup("LC_ALL")),
scm_from_locale_string("") ); If that actually works, lemme know.
-Mike
Re: Problem with wide characters on upgrading to guile 2.x
On Thu, 2013-08-22 at 11:45 -0700, Mike Gran wrote:
> Hi Richard-
>
>
> > scheme@(guile-user)> (string-append " " "hello")
>
> > $1 = " \ue176hello"
> > scheme@(guile-user)> (display " ")
> > scheme@(guile-user)> (display (string-append " "
> > "hello"))
> > helloscheme@(guile-user)>
> > I notice that I do not have LC_ALL set in my environment.
> >
> > From inside Denemo scm_c_eval_string() is being used to evaluate a
> > string that includes this wide character and that is throwing the
> > exception.
>
> I've been gone a while, so I don't know what the latest is.
> But based on old knowledge...
>
> 1. Make sure that you Guile script files are UTF-8. If they
> are not, you'll need to explicitly put a "coding:"
> declaration at the top of each file.
I guess they are (else it would never have worked under 1.8) - typically
they are input to a Gtk widget which I think default to taking utf-8.
>
> 2. In the inner_main of your scm_with_guile call,
> try calling scm_setlocale. Maybe something like this?
> (This shouldn't make a difference, I think.
> But, if it does, it says something interesting.)
>
> scm_setlocale( scm_variable_ref(scm_c_lookup("LC_ALL")),
> scm_from_locale_string("") );
> If that actually works, lemme know.
I just pasted the above into the start of inner_main() and like magic,
it has fixed the problem. Is this call ok for guile-1.8 linking too?
Thanks very much for the magic
Richard
>
> -Mike
>
Re: Problem with wide characters on upgrading to guile 2.x
>> 2. In the inner_main of your scm_with_guile call,
>> try calling scm_setlocale. Maybe something like this?
>> (This shouldn't make a difference, I think.
>> But, if it does, it says something interesting.)
>>
>> scm_setlocale( scm_variable_ref(scm_c_lookup("LC_ALL")),
> scm_from_locale_string("") );
>
>> If that actually works, lemme know.
>
> I just pasted the above into the start of inner_main() and like magic,
> it has fixed the problem. Is this call ok for guile-1.8 linking too?
I'm not 100% sure, but, I think so.
-Mike
guile-2.0 on mingw: the sequel
Recently I've had a little more time to experiment
with guile-2.0 on mingw32. Following the advice of
Eli Zaretskii from
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00028.html,
I compiled guile-2.0.9 without thread support,
and modified my demos so they no longer use theads
explicitly (they only use SDL timers).
I managed to go through the compilation process,
and (after modifying meta/Makefile.am according to Eli's
patch) to make install.
When I ran guile-2.0, I got the following message:
===
Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find
file ~S in load path" ("ice-9/boot-9") #f)Aborting.
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Cannot exit gracefully when init is in progress; aborting.
===
Supplying GUILE_LOAD_PATH=/usr/share/guile/2.0 explicitly
helped a little, but only during the first run -- it
compiled some files from that directory and proceeded to
the prompt.
When I tired later, I got a lot of messages like
===
;;; compiling C:/MinGW/share/guile/2.0\ice-9\vlist.scm
;;; it seems C:/MinGW/share/guile/2.0\ice-9\vlist.scm
;;; is part of the compiler; skipping auto-compilation
===
and a single instance of the following message
===
;;; WARNING: compilation of C:/MinGW/share/guile/2.0\system\vm\vm.scm
failed:
;;; ERROR: no code for module (system vm vm)
===
and it even displayed the welcome message, but when I tried
to (+ 2 3), I got:
===
While compiling expression:
ERROR: In procedure module-lookup: Unbound variable: compile
===
What turned out the most painful, however, was that I wasn't
able to run a program linked to libguile, not even the simplest
one, like
===
#include
int main() {
scm_init_guile();
return 0;
}
===
which caused an abort with the following message:
===
Throw without catch before boot:
Throw to key stack-overflow with args (#f "Stack overflow" #f #f)Aborting.
This application has requested [...]
===
When I tried a similar piece of code, but with
scm_with_guile instead, I had the second part of
the message ("The application has requested ...")
in a "Microsoft Visual C++ Runtime Library" popup.
Exporting GUILE_LOAD_PATH didn't help at all
The Windows environment doesn't seem to be particularly
developer-friendly (or maybe I just don't know the right
tools), but I'd truly appreciate some help. (My goal is
to provide a binary distribution of the SLAYER framework
that I've presented before; it would allow programmers
to develop portable multimedia applications in Guile
Scheme. The development version of SLAYER is available
at https://puszcza.gnu.org.ua/projects/slayer )
Also, it would be helpful if someone could point
to the git revision which is known to build under
windows.
Thanks in advance,
M.
Re: guile-2.0 on mingw: the sequel
> Date: Thu, 22 Aug 2013 22:25:02 +0200
> From: Panicz Maciej Godek
>
> I managed to go through the compilation process,
> and (after modifying meta/Makefile.am according to Eli's
> patch) to make install.
This compilation process includes compiling all the Scheme files that
come with Guile. Since you say it succeeded, I don't understand what
you say later, see below. Do you see a lot of *.go files in the
directory where you built Guile?
> When I ran guile-2.0, I got the following message:
> ===
> Throw without catch before boot:
> Throw to key misc-error with args ("primitive-load-path" "Unable to find
> file ~S in load path" ("ice-9/boot-9") #f)Aborting.
This seems to say that Guile cannot find its Scheme files.
> Supplying GUILE_LOAD_PATH=/usr/share/guile/2.0 explicitly
> helped a little
If that helped to avoid the failure to load, you probably didn't
specify a correct --prefix at configure time, or your "make install"
somehow didn't DTRT.
> but only during the first run -- it compiled some files from that
> directory and proceeded to the prompt.
This is what I don't understand: which files it needed to compile, and
why? The compilation of Scheme files is part of the build process,
which you say you ran successfully to completion. What am I missing?
> The Windows environment doesn't seem to be particularly
> developer-friendly (or maybe I just don't know the right
> tools)
Which developer-friendly features do you lack? Perhaps it's a matter
of installing or configuring what is already available out there.
> but I'd truly appreciate some help.
Let's start with the basics. Please describe:
. Which build of what version of the GC library did you use, and
where did you get the Windows build of that library? Likewise for
other build dependencies, like libunistring, libiconv, etc. --
please tell where you got each one of them.
. How did you configure Guile? If you used any --prefix argument,
please tell to which Windows directory does that prefix map on your
system?
. Did you see any warning or error messages during the build, and if
so, please show them.
. Did you see all the Scheme files being byte-compiled?
. What command(s) did you use to install the built Guile?
. How do you run Guile after installing it? In particular, do you
run it from the MSYS Bash or from the Windows cmd window?
IOW, you didn't tell enough details about the build and the usage to
be able to guess what possible problems could be in your way.
FWIW, I've successfully ran Guile from the Windows prompt after
building it, and successfully built GNU Make with Guile support. So
it's definitely possible to do that with MinGW.
