uniform-array-read!
Hi there, Is the following the correct way of using `uniform-array-read!'? Seems it simply hangs there.. (let ((ar (make-uniform-array #\nul length))) (uniform-array-read! ar sockfd)) Any ideas? -- William ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: uniform-array-read!
Hi, William Xu <[EMAIL PROTECTED]> writes: > Is the following the correct way of using `uniform-array-read!'? Seems > it simply hangs there.. > > (let ((ar (make-uniform-array #\nul length))) > (uniform-array-read! ar sockfd)) In your example, it can very well be hanging because there is nothing to read from SOCKFD (e.g., it's making a blocking `read' system call beneath). Using Guile 1.7: guile> (define a (make-uniform-array #\nul 10)) guile> (uniform-array-read! a (open-input-string (string #\001 #\002 #\003))) 3 guile> a #s8(1 2 3 32 51 10 -102 96 48 10) guile> IOW, it seems to work fine --- except that: 1. The array is not properly initialized; 2. The result is not a string as one would expect from the Guile 1.6 manual[*] (in fact it could hardly be a string since internally strings may not contain null characters AFAIK). So 1.7 is _not_ compatible with 1.6 in that respect. I guess we need to fix this. In 1.7, `make-uniform-array' is deprecated and replaced by `make-typed-array' (BTW, this deprecation is not currently documented in the 1.7 manual): -- Scheme Procedure: make-typed-array type fill bound ... -- C Function: scm_make_typed_array (type, fill, bounds) Create and return an array that has as many dimensions as there are BOUNDs and (maybe) fill it with FILL. Hope this helps, Ludovic. [*] From node `Uniform Arrays': Unshared uniform arrays of characters with a single zero-based dimension are identical to strings: (make-uniform-array #\a 3) => "aaa" Unshared uniform arrays of booleans with a single zero-based dimension are identical to *Note bit-vectors: Bit Vectors. (make-uniform-array #t 3) => #*111 ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: uniform-array-read!
William Xu <[EMAIL PROTECTED]> writes: > Not in debian yet.. Guile 1.6.7 here. Yeah, I know, unfortunately... >> guile> (define a (make-uniform-array #\nul 10)) >> guile> (uniform-array-read! a (open-input-string (string #\001 #\002 >> #\003))) >> 3 >> guile> a >> #s8(1 2 3 32 51 10 -102 96 48 10) >> guile> >> >> IOW, it seems to work fine --- except that: >> >> 1. The array is not properly initialized; > > It is. Not with Guile 1.7, see above (it should only contain zeros starting from the fourth element). > What is that "result"? See this comparison of Guile 1.6 and 1.7: $ guile-1.6 guile> (make-uniform-array #\a 10) "aa" guile> (make-uniform-array #\nul 10) #y(0 0 0 0 0 0 0 0 0 0) guile> (make-uniform-array #\001 10) "" $ guile-1.7 guile> (make-uniform-array #\a 10) "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" guile> (make-uniform-array #\nul 10) #s8(15 -44 -17 16 16 4 118 8 0 0) guile> (make-uniform-array #\001 10) "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" All the results differ. Notably, Guile 1.7 fails to properly initialize the arrays returned. However, note that Guile 1.6 already handles the `#\nul' case specially: in that case, `make-uniform-array' doesn't return a string (as explained in the manual) but an array. >guile> (uniform-array-read! a (open-input-string (string #\001 #\002 > #\003))) > > The second argument for uniform-array-read! is a string. In my codes, i > tried to read binary data, precisely, a network packet. Does this > matter? The second argument is an input port, not a string: `open-input-string' returns an input port, like `open-input-file'. Thanks, Ludovic. ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: uniform-array-read!
[EMAIL PROTECTED] (Ludovic Courtès) writes: > William Xu <[EMAIL PROTECTED]> writes: > >> Is the following the correct way of using `uniform-array-read!'? Seems >> it simply hangs there.. >> >> (let ((ar (make-uniform-array #\nul length))) >> (uniform-array-read! ar sockfd)) > > In your example, it can very well be hanging because there is nothing to > read from SOCKFD (e.g., it's making a blocking `read' system call > beneath). Ooh, that was only partial of the codes. Actually i've also written the codes in C first to make sure we could *read*. > Using Guile 1.7: Not in debian yet.. Guile 1.6.7 here. > guile> (define a (make-uniform-array #\nul 10)) > guile> (uniform-array-read! a (open-input-string (string #\001 #\002 > #\003))) > 3 > guile> a > #s8(1 2 3 32 51 10 -102 96 48 10) > guile> > > IOW, it seems to work fine --- except that: > > 1. The array is not properly initialized; It is. > 2. The result is not a string as one would expect from the Guile 1.6 > manual[*] (in fact it could hardly be a string since internally > strings may not contain null characters AFAIK). What is that "result"? I noticed that in your example, guile> (uniform-array-read! a (open-input-string (string #\001 #\002 #\003))) The second argument for uniform-array-read! is a string. In my codes, i tried to read binary data, precisely, a network packet. Does this matter? [...] -- William ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: uniform-array-read!
Hi y'all, Using Guile 1.7: guile> (define a (make-uniform-array #\nul 10)) guile> (uniform-array-read! a (open-input-string (string #\001 #\002 #\003))) 3 guile> a #s8(1 2 3 32 51 10 -102 96 48 10) guile> IOW, it seems to work fine --- except that: 1. The array is not properly initialized; 2. The result is not a string as one would expect from the Guile 1.6 manual[*] (in fact it could hardly be a string since internally strings may not contain null characters AFAIK). So 1.7 is _not_ compatible with 1.6 in that respect. I guess we need to fix this. Here is the same in 1.6, just for good measure: guile> (define a (make-uniform-array #\nul 10)) guile> a #y(0 0 0 0 0 0 0 0 0 0) guile> (uniform-array-read! a (open-input-string (string #\001 #\002 #\003))) 3 guile> a #y(1 2 3 0 0 0 0 0 0 0) The result is not a string, probably because the array was originally defined to be filled with null chars. If I define the array to originally contain some valid character, then subsequently it displays as a string. Regards, Jon ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Another load path idea
Greg Troxel <[EMAIL PROTECTED]> writes: > > I tend to build program foo (from CVS) into /usr/foo. I like that too except usually a subdir of wherever I keep the source. Nice and easy to rm -r when you're sick of it. But I presume you, as I, don't want a package build trying to modify /etc/profile etc to hook itself into $PATH. I might well add it in myself, even setup to test a range of locations and use what exists, I like that in my .emacs a lot too for instance. Anyway, the main point would be that I don't think it's the package's business to try to join itself to the world when installed in an out-of-the-way place. ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
ANN: libRUIN project development release 0.1.1
Hi everyone, I am pleased to announce that the libRUIN project has made its first formal development release, version 0.1.1. Our project description, from Savannah: libRUIN (Renderer for User Interfaces in Ncurses) is a rendering library for various XML-based user interface markup languages (such as Mozilla XUL), using the Ncurses terminal control library as a rendering target. GNU Guile and the SDOM Scheme module are used as the "glue" that manages user input and event handling. An application programmer passes an XML document (including, potentially, a set of CSS stylesheets) and an Ncurses WINDOW structure, and libRUIN paints the WINDOW according to the markup and CSS; the programmer may subsequently pass Ncurses-style input strings to that WINDOW via libRUIN, and libRUIN will handle the resulting event flows. What this means, in short, is that libRUIN is a little bit like a browser in that it provides rendering for various flavors of XML+CSS, but, more importantly, it's an embeddable native library that you can use to quickly and easily create dynamic Ncurses user interfaces for your application without having to write any UI code (except perhaps a few lines of Scheme). Of particular interest to Scheme programmers and Guile users -- while the exposed API and core of libRUIN is C, the XML parsing, CSS lookups, and DOM event handling (events are scripted in Scheme) are all implemented as Guile Scheme modules (see, respectively, the SSAX/SXML project, SCSS and SDOM). This release is concertedly alpha- or pre-alpha-quality, but includes an example application called 'ruinview' that you can use to check out libRUIN's rendering support for XHTML documents (selections from the W3C's CSS2.1 Test Suite are included in the distribution) and see how easy it is to integrate libRUIN with existing C code. For more information, swing by http://www.nongnu.org/libruin or check out our project page on Savannah, at http://savannah.nongnu.org/projects/libruin -- you can pick up the release from the downloads section. ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Another load path idea
I like that too except usually a subdir of wherever I keep the source. Nice and easy to rm -r when you're sick of it. But I presume you, as I, don't want a package build trying to modify /etc/profile etc to hook itself into $PATH. I might well add it in myself, even setup to test a range of locations and use what exists, I like that in my .emacs a lot too for instance. Anyway, the main point would be that I don't think it's the package's business to try to join itself to the world when installed in an out-of-the-way place. No, but it shoudl be easy for someone to add. so I'd like to be able to do something like: # guile-admin --add-prefix /usr/foo # guile-admin --remove-prefix /usr/foo # guile-admin --show-prefixes -- Greg Troxel <[EMAIL PROTECTED]> ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: uniform-array-read!
[EMAIL PROTECTED] (Ludovic Courtès) writes: [...] >>guile> (uniform-array-read! a (open-input-string (string #\001 #\002 >> #\003))) >> >> The second argument for uniform-array-read! is a string. In my codes, i >> tried to read binary data, precisely, a network packet. Does this >> matter? > > The second argument is an input port, not a string: `open-input-string' > returns an input port, like `open-input-file'. Hmm, then what could be the problem here.. I can do uniform-array-write to that `sockfd'. And by using some network sniffer, i see the packet successfully sent to the server, and also the packet sent from the server. But uniform-array-read! won't read out the packet sent from server. any way to look into or trace, uniform-array-read! ? -- William ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
