I'm having trouble using the latest version of Snowman to install packages -- or, well, to do very much of anything at all. I'm using GNU Guile. When run with any (valid) arguments, it produces the following error:
ERROR: In procedure scm_lreadr: ERROR: #<unknown port>:19:87: illegal character in escape sequence: #\3
When I modify the core snow script to launch Guile with the --debug flag, it produces the following stack trace:
In unknown file: ?: 0* [primitive-load "/usr/share/snow/current/bin/snowman"] In /usr/share/snow/current/bin/snowman: 31: 1* [snowman-main] In /usr/share/snow/v1.1.1/pack/snowman-app/v1.0.2/snow/snowman-app.scm: 1077: 2 (let* ((args #)) (split-args args (lambda # #))) In unknown file: ... ?: 3 [snowman-install-or-download-packages (install verify highest ...) () ...] In /usr/share/snow/v1.1.1/pack/snowman-app/v1.0.2/snow/snowman-app.scm: 460: 4 (let* (#) (define # # #) (define # # #) ...) 460: 5* [get-pkg-list-from-snowfort] 245: 6 (let* ((response #)) (if (and # #) (map # #) (begin # #))) ... 253: 7 [map #<procedure #f (x)> ... 265: 8* [snow-string->object-list
[ SNIP -- HUGE LIST OF SNOW MODULE CODE]
In unknown file: ?: 11* [#<procedure #f (port)> #<input: string 8072130>] In /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm: 127: 12* [loop ()] 128: 13 (let* ((x (read port))) (display x) ...) In unknown file: ... ?: 14 [loop (("time" # # ...) ("mime" # #) ("json" # #) ...)] In /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm: 128: 15 (let* ((x (read port))) (display x) ...) 128: 16* [read #<input: string 8072130>]
/usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm:128:17: In procedure scm_lreadr in expression (read port): /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm:128:17: #<unknown port>:19:87: illegal character in escape sequence: #\3
...any ideas?
Afficher les réponses par date
Hi Julian,
"Julian Graham" joolean@gmail.com writes:
I'm having trouble using the latest version of Snowman to install packages -- or, well, to do very much of anything at all. I'm using GNU Guile. When run with any (valid) arguments, it produces the following error:
ERROR: In procedure scm_lreadr: ERROR: #<unknown port>:19:87: illegal character in escape sequence: #\3
Did you eventually fix it?
Thanks, Ludovic.
Hi,
"Julian Graham" joolean@gmail.com writes:
I'm having trouble using the latest version of Snowman to install packages -- or, well, to do very much of anything at all. I'm using GNU Guile. When run with any (valid) arguments, it produces the following error:
ERROR: In procedure scm_lreadr: ERROR: #<unknown port>:19:87: illegal character in escape sequence: #\3
Running "snowman list" through `strace', I see `read(2)' calls that receive things like this:
(author: "Danny Dub\351 <Danny.Dube at ift.ulaval.ca>") (author: "Adrien Pi\303\251rard <pierarda@iro.umontreal.ca")
Of course, one level of "backslashification" comes from `strace', so in the end what we get is:
(author: "Danny Dub\351 <Danny.Dube at ift.ulaval.ca>") (author: "Adrien Pi\303\251rard <pierarda@iro.umontreal.ca")
It's these escape sequences that make Guile's reader unhappy.
However, I don't understand where they come from. When I download the snowballs that contain these strings "by hand" from the Snow website, I can see that they do not contain the escape sequences, but rather a UTF-8 or Latin-1 representation of these author names. So I suppose the escape sequences get added somehow as the strings are sent over HTTP.
Can someone shed some light on this?
Thanks, Ludovic.
On 14-Apr-08, at 11:36 AM, Ludovic Courtès wrote:
(author: "Danny Dub\351 <Danny.Dube at ift.ulaval.ca>") (author: "Adrien Pi\303\251rard <pierarda@iro.umontreal.ca")
It's these escape sequences that make Guile's reader unhappy.
However, I don't understand where they come from. When I download the snowballs that contain these strings "by hand" from the Snow website, I can see that they do not contain the escape sequences, but rather a UTF-8 or Latin-1 representation of these author names. So I suppose the escape sequences get added somehow as the strings are sent over HTTP.
Can someone shed some light on this?
The escapes are generated by the snowfort server. The server, a Scheme program, serializes the list of packages using "write" and the snowman client will deserialize it using "read". In this case the server is running on Gambit and the client is running on Guile. Gambit's syntax for strings is compatible with C and the \ooo octal notation is how non-ASCII LATIN-1 characters are written. Although this syntax is not universal among Scheme implementations, it is a fairly common extension to the standard Scheme syntax (supported by Bigloo, Chez, Gambit, Kawa, MzScheme, Scsh and probably others). Unfortunately Guile does not implement this extension. Note that the snowfort server could be run using some other Scheme system, but that does not solve the problem because the issue is the incompatibility of the server's write and the client's read. That's what standards are meant to solve.
So what to do? There is no standard way in Scheme to write non-ASCII characters (in fact one could say that no character can be portably written since Scheme does not define the character set!). Specific serializer/deserializer algorithms other than write/read could be implemented but that would be a real pain and it would make I/O really slow on interpreted systems.
The pragmatic solution is to avoid non-ASCII characters in Scheme code, and Snow packages in particular.
Marc
Guile supports SRFI-14, as do most of the other "big" implementations. Gambit isn't listed at http://srfi.schemers.org/srfi-implementers.html at all though. Might it help?
"This library is designed to be portable across implementations that use different character types and representations, especially ASCII, Latin-1 and Unicode."
On Mon, Apr 14, 2008 at 8:12 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
On 14-Apr-08, at 11:36 AM, Ludovic Courtès wrote:
(author: "Danny Dub\351 <Danny.Dube at ift.ulaval.ca>") (author: "Adrien Pi\303\251rard <pierarda@iro.umontreal.ca")
It's these escape sequences that make Guile's reader unhappy.
However, I don't understand where they come from. When I download the snowballs that contain these strings "by hand" from the Snow website, I can see that they do not contain the escape sequences, but rather a UTF-8 or Latin-1 representation of these author names. So I suppose the escape sequences get added somehow as the strings are sent over HTTP.
Can someone shed some light on this?
The escapes are generated by the snowfort server. The server, a Scheme program, serializes the list of packages using "write" and the snowman client will deserialize it using "read". In this case the server is running on Gambit and the client is running on Guile. Gambit's syntax for strings is compatible with C and the \ooo octal notation is how non-ASCII LATIN-1 characters are written. Although this syntax is not universal among Scheme implementations, it is a fairly common extension to the standard Scheme syntax (supported by Bigloo, Chez, Gambit, Kawa, MzScheme, Scsh and probably others). Unfortunately Guile does not implement this extension. Note that the snowfort server could be run using some other Scheme system, but that does not solve the problem because the issue is the incompatibility of the server's write and the client's read. That's what standards are meant to solve.
So what to do? There is no standard way in Scheme to write non-ASCII characters (in fact one could say that no character can be portably written since Scheme does not define the character set!). Specific serializer/deserializer algorithms other than write/read could be implemented but that would be a real pain and it would make I/O really slow on interpreted systems.
The pragmatic solution is to avoid non-ASCII characters in Scheme code, and Snow packages in particular.
Marc
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
Hi Marc,
Marc Feeley feeley@iro.umontreal.ca writes:
The escapes are generated by the snowfort server. The server, a Scheme program, serializes the list of packages using "write" and the snowman client will deserialize it using "read". In this case the server is running on Gambit and the client is running on Guile. Gambit's syntax for strings is compatible with C and the \ooo octal notation is how non-ASCII LATIN-1 characters are written. Although this syntax is not universal among Scheme implementations, it is a fairly common extension to the standard Scheme syntax (supported by Bigloo, Chez, Gambit, Kawa, MzScheme, Scsh and probably others). Unfortunately Guile does not implement this extension. Note that the snowfort server could be run using some other Scheme system, but that does not solve the problem because the issue is the incompatibility of the server's write and the client's read. That's what standards are meant to solve.
Thanks for the explanation.
So what to do? There is no standard way in Scheme to write non-ASCII characters (in fact one could say that no character can be portably written since Scheme does not define the character set!). Specific serializer/deserializer algorithms other than write/read could be implemented but that would be a real pain and it would make I/O really slow on interpreted systems.
The pragmatic solution is to avoid non-ASCII characters in Scheme code, and Snow packages in particular.
That's one solution, but as someone with an accent in his name, I don't like it so much. ;-)
I can think of two solutions:
1. provide a `read' replacement for implementations that are known to not support this syntax (but as you say, this may result in much slower I/O, especially on Guile);
2. implement said syntax in Guile.
The latter is doable (and makes sense if everyone else does it), but the former would allow Snow to run with current versions of Guile.
Thanks, Ludovic.
snow-users-list@iro.umontreal.ca