<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user">
    <title>gmane.lisp.guile.user</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9478"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9477"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9476"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9475"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9474"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9473"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9472"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9471"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9470"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9469"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9468"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9467"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9466"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9464"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9461"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9460"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9458"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9457"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9456"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.guile.user/9455"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9478">
    <title>Re: Extending a GTK+ Application with Guile</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9478</link>
    <description>&lt;pre&gt;

Yes, this was my meaning.


I used VTE as a proof of concept to interect with guile. If better
methods of doing so are possible (as you have suggested) then they will
be addopted.

Thank you,
I will look at coot to better understand the organisation and
interactions with guile.

Kevin.



&lt;/pre&gt;</description>
    <dc:creator>Kevin J. Fletcher</dc:creator>
    <dc:date>2012-05-25T21:30:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9477">
    <title>Re: Extending a GTK+ Application with Guile</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9477</link>
    <description>&lt;pre&gt;

I did see --listen but didn't look to far into it. As my first attempt
(routing STDIN, STDOUT, STDERR through VTE) worked I stopped working on
this aspect. I will add it to my list of options.


I agree, this appears overkill. I just wondered if it would be seen as
buggy: "I attempted to quit the terminal and the whole program
closed!". It is not a major concern.

Thanks



&lt;/pre&gt;</description>
    <dc:creator>Kevin J. Fletcher</dc:creator>
    <dc:date>2012-05-25T21:43:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9476">
    <title>Re: Extending a GTK+ Application with Guile</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9476</link>
    <description>&lt;pre&gt;Hi!

Kevin J. Fletcher &amp;lt;dev&amp;lt; at &amp;gt;kjfletch.co.uk&amp;gt; skribis:


Sounds good at first sight.  In fact, you could look at (system repl
server), which implements something like that.  That’s what the
‘--listen’ command-line option uses.


Actually, ‘,q’ does ‘exit’, which just throws an exception, so it’s
harmless (you can check it with ‘--listen’: typing ,q in the REPL over
telnet doesn’t terminate the process, it just terminates the REPL
server.)

But then of course, if the user calls ‘primitive-exit’ or similar, the
whole process terminates.  You could rebind ‘primitive-exit’ to
something harmless, but I’m not convince that protecting users against
themselves makes sense.


It’s supposed to build and run with MinGW, though it’s definitely not
widely tested.

Thanks,
Ludo’.



&lt;/pre&gt;</description>
    <dc:creator>Ludovic Courtès</dc:creator>
    <dc:date>2012-05-25T14:30:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9475">
    <title>Re: Extending a GTK+ Application with Guile</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9475</link>
    <description>&lt;pre&gt;
Very good.  That is what I do with Coot.


Bleugh!


Yes.


By "at the same time" do you mean in "a different thread"?

If so, don't do that.

I use scm_shell() but only for command-line/non-gtk-graphics mode.
To interact with guile I use guile-gui.


It is not clear to me that you need VTE and threads.

I have my guile-scripts/functions (well, 99% of them) run in the 
main/gtk thread - many using timeout functions.


My understanding is that it is possible, but non-trivial.  We have not 
made a guile-enabled Coot on Windows (yet).

HTH,

Paul.



&lt;/pre&gt;</description>
    <dc:creator>Paul Emsley</dc:creator>
    <dc:date>2012-05-25T11:14:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9474">
    <title>Extending a GTK+ Application with Guile</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9474</link>
    <description>&lt;pre&gt;Hello Guilers.

I'm currently writing some prototype code before starting a project and
have a few questions that I hope some of you may be able to answer.

My intent is to add guile as a method of [optionally, at build time]
extending a GTK+ application. With the addition of being able to run
guile scripts I hope to provide a guile-shell to give real-time
interactive power. First a question of program architecture;

As the guile extensions are optional I run GTK on a main thread and the
shell on a second pthread. I connect the shell through a PTY to the
virtual terminal widget.

I apologise to those with mail clients not using monospace fonts.

  THREAD1            THREAD2
 ---------           -------
| GTK     |   pty   | guile |
|     VTE |&amp;lt;-------&amp;gt;| shell |
|  -----  |          -------
| guile   |
|  scripts|
 ---------

0) Is there anything wrong with this architecture?

   a) Is it valid to use both scm_shell and other guile code at the same
   time or is scm_shell designed to run in isolation?

   b) &lt;/pre&gt;</description>
    <dc:creator>Kevin J. Fletcher</dc:creator>
    <dc:date>2012-05-24T19:11:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9473">
    <title>Re: letter occurence in a text</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9473</link>
    <description>&lt;pre&gt;
Why store the alist keys as one-character strings, rather than just as
characters?  Storing as characters would be simpler:

;; Given an alist 'lst' containing character counts and character 'c',
;; return an alist with the count of 'c' incremented (set to 1 if it
doesn't exist).
(define (lettre-test c lst)
  (let ((current (assoc-ref lst c)))
     (assoc-set! lst c (+ 1 (or current 0)))))

Character frequency analysis can be performed with a "fold" operation:

((#\! . 1)
 (#\d . 1)
 (#\r . 1)
 (#\w . 1)
 (#\space . 1)
 (#\, . 1)
 (#\o . 2)
 (#\l . 3)
 (#\e . 1)
 (#\h . 1))

I think it would be best to separate the filtering for alphabetic
chars from the "lettre-test" function; they're separate ideas:

((#\d . 1)
 (#\r . 1)
 (#\w . 1)
 (#\o . 2)
 (#\l . 3)
 (#\e . 1)
 (#\h . 1))

The drawback of this solution, as currently written, is that it can't
lazily read a file; you'd have to read the entire file into a string
first.  It should be possible to modify this to use streams rather
than lists, though.


&lt;/pre&gt;</description>
    <dc:creator>gregory benison</dc:creator>
    <dc:date>2012-05-23T13:57:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9472">
    <title>Re: letter occurence in a text</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9472</link>
    <description>&lt;pre&gt;
Hi!

I did a short frequency-analysis function some time ago and after a
little digging found it. With a little haqqing you could modify it to
your needs:

(code)
;; Frequency analysis. Not Frequently Analed.

(define (frequency-analysis text)
  (if (null? text)
      '()
      (let loop ((table (list (cons (car text) 1)))
                 (text (cdr text)))
        (cond ((null? text) table)
              ((not (assoc (car text) table))
               (loop (append table
                             (list (cons (car text) 1)))
                     (cdr text)))
              (else
               (set-cdr! (assoc (car text) table)
                         (+ (cdr (assoc (car text) table)) 1))
               (loop table (cdr text)))))))
(/code)

I should probably talk you through the code. But, if think it's simple
enough and I am drunk enough not to require it!

Good day!

- mgsk.


&lt;/pre&gt;</description>
    <dc:creator>Mark Skilbeck</dc:creator>
    <dc:date>2012-05-22T23:57:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9471">
    <title>letter occurence in a text</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9471</link>
    <description>&lt;pre&gt;
hello my problem is to count occurence of letter in a text and come out with
an assoc-list like
'((a.16) (b.10) ... (z.5))
i started a fee function but they don't work so please help me

;; an alist
(define lettre '((""."") ) )
(define lettre2 '(("a". 1) ("b". 1) ("c". 1) ) )

;; this function take a key and an alist
;; add the key to the alist if it is not a space,a newline,and does not
already exist
;; update the value of the given key
(define (lettre-test x alist)
(cond ((and 
          ( and (not (char=?  x #\space))(not (char=?  x #\newline)))   
          (eq? (assoc (make-string 1 x) alist) #f))  
          (set! alist
          (assoc-set! alist (make-string 1 x) 0 )))
          ((char=?  x #\space) '())
          ((char=?  x #\newline) '()) 
           (else
           (set! alist   
       (assoc-set! alist (make-string 1 x) (+ (assoc-ref alist
(make-string 1 x)) 1))))))

;; this function open a file
;; read the caracter and count the occurence of each character
(define (compte-&lt;/pre&gt;</description>
    <dc:creator>nrichard</dc:creator>
    <dc:date>2012-05-22T14:26:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9470">
    <title>Re: guile-lib test failed</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9470</link>
    <description>&lt;pre&gt;

A segmentation fault!  This is bad.

Can you run "ulimit -c unlimited" to enable core dumps, then try again,
then "gdb /usr/local/bin/guile core" (assuming the core file is there;
if not, check your /proc/sys/kernel/core_pattern), then "thr apply all
bt full".

Thanks!

Andy
&lt;/pre&gt;</description>
    <dc:creator>Andy Wingo</dc:creator>
    <dc:date>2012-05-21T09:05:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9469">
    <title>guile-lib test failed</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9469</link>
    <description>&lt;pre&gt;With guile 2.0.5 installing guile-lib 0.2.1 ./configure and make
run without problems. But "make check" say one test failed. See
attached file. There are some spanish messages. I don't know how
configure it to display all in english. Regards.&lt;/pre&gt;</description>
    <dc:creator>Germán A. Arias</dc:creator>
    <dc:date>2012-05-20T12:31:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9468">
    <title>Re: dynamic ffi and C struct</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9468</link>
    <description>&lt;pre&gt;And if you want to dereference the returned struct pointer, use parse-c-struct
say, there's a returned C struct like:
aa { (int)1 ,(int)2 }

you may convert it to list like this:
(parse-c-struct aa (list int int))
==&amp;gt; (1 2)

Then the rest is list operation, has no part in C.


On Sun, May 20, 2012 at 8:45 AM, Mark H Weaver &amp;lt;mhw&amp;lt; at &amp;gt;netris.org&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Nala Ginrut</dc:creator>
    <dc:date>2012-05-20T03:40:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9467">
    <title>Re: dynamic ffi and C struct</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9467</link>
    <description>&lt;pre&gt;
Although it is not documented in the manual, I see from the source code
that a C struct parameter can be specified using a nested list in the
foreign type passed to 'pointer-&amp;gt;procedure'.


For this example, there's an additional complication of the inline array
within the struct, which is not supported by libffi, upon which Guile's
dynamic FFI is based.  I'm not an expert on this subject, but I strongly
suspect that on most (if not all) platforms, the struct above has the
same layout as the following one:

  typedef struct {
    int dat_0;
    int dat_1;
  } foo_t;

Assuming this is the case, here's one way to wrap 'func':

  (use-modules (system foreign))

  (define foo-library-obj (dynamic-link "libfoo"))
  (define foo-struct-type (list int int))
  
  (define (make-foo-struct dat-0 dat-1)
    (make-c-struct foo-struct-type (list dat-0 dat-1)))
  
  (define func
    (pointer-&amp;gt;procedure int
                        (dynamic-func "func" foo-library-obj)
                        (list foo-struct-type)))

and he&lt;/pre&gt;</description>
    <dc:creator>Mark H Weaver</dc:creator>
    <dc:date>2012-05-20T00:45:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9466">
    <title>dynamic ffi and C struct</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9466</link>
    <description>&lt;pre&gt;Hello,

Is it possible to use the current dynamic ffi to call a C function
whose parameter is a C struct (not a pointer to a C struct) ?

I cannot find much about it in the documentation.  After a brief look
at the source of foreign.c of guile, I found guile actually does some
parsing of nested argument list for `pointer-&amp;gt;procedure' and generates
compound ffi types.  But I don't know the right data structure to give
when actually calling the foreign function.

For example, what should I do for the following function?

typedef struct {
  int dat[2];
} foo_t;

int func ( foo_t arg );

&lt;/pre&gt;</description>
    <dc:creator>cong gu</dc:creator>
    <dc:date>2012-05-19T11:32:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9464">
    <title>Re: SRFI-64 module and SRFI-78 module -- archive file attached</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9464</link>
    <description>&lt;pre&gt;URL changed:

SRFI 64: "A Scheme API for test suites by Per Bothner" Guile implementation
-
https://gitorious.org/srfi-64-port/srfi-64-guile

SRFI 78: "Lightweight testing by Sebastian Egner" Guile module -
https://gitorious.org/srfi-78-guile

Test code added:
Modified test suite for the testing SRFI 64 to use (test-suite lib) module
of Guile source archive -
https://gitorious.org/srfi-64-port/srfi-64-guile/blobs/master/test-suite/tests/srfi-64.test
&lt;/pre&gt;</description>
    <dc:creator>Sunjoong Lee</dc:creator>
    <dc:date>2012-05-14T14:07:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9461">
    <title>Re: http-post</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9461</link>
    <description>&lt;pre&gt;Hello,


Yes, I like that idea. At least our procedures will be consistent with
themselves. :-)

You shouldn't work too hard writing tests for code that you didn't
write, but it sounds like the best way to test your code is to feed
its results to the web server.

Thanks for working on this,
Noah


&lt;/pre&gt;</description>
    <dc:creator>Noah Lavine</dc:creator>
    <dc:date>2012-05-10T02:22:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9460">
    <title>RE: guile-gnome-platform 2.16.2 released</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9460</link>
    <description>&lt;pre&gt;Hello,

I'm glad to hear guile-gnome-platform works with Guile 2.0. To celebrate
it, I've attatched my ebuild files for Gentoo Linux users. You
know, Gentoo's last stable guile ebuild file is guile-1.8.8-r1.ebuild for
Guile 1.8.8 but the last stable version of Guile itself is 2.0.5. There
are guile-2.0.5.ebuild, g-wrap-1.9.14.ebuild
and guile-gnome-platform-2.16.2.ebuild in my attatched file. You need
a ebuild file for guile-lib 0.1.9 but it is in your default portage tree.
If not so, sync your portage tree; "emerge --sync".

0. Update your system:
    # emerge --sync
    # emerge -uND world
    # emerge --depclean
    # revdep-rebuild

1. Put new ebuild files in your local portage overlay tree:
    # cp guile-gnome-platform-ebuild.tar.gz /usr/local
    # cd /usr/local
    # tar xvjf guile-gnome-platform-ebuild.tar.gz
    # rm guile-gnome-platform-ebuild.tar.gz

2. Check your PORTDIR_OVERLAY environment variable in /etc/make.conf file.
I assume that:
    $ grep PORTDIR_OVERLAY /etc/make.conf
    PORTDIR_OVER&lt;/pre&gt;</description>
    <dc:creator>Sunjoong Lee</dc:creator>
    <dc:date>2012-05-09T23:57:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9458">
    <title>[ANN] Guile-Reader 0.6</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9458</link>
    <description>&lt;pre&gt;Version 0.6 of Guile-Reader for Guile 2.0.x and 1.8.x is now available.
This release adds new features, most notably Guile 2.0 and Unicode support.

  http://dl.sv.nongnu.org/releases/guile-reader/guile-reader-0.6.tar.gz
  http://dl.sv.nongnu.org/releases/guile-reader/guile-reader-0.6.tar.gz.sig

SHA1 sums:

  aaedfe0c656775ba895b02293481a7d7c36b1f7e  guile-reader-0.6.tar.gz
  284404e6403d396819ff4e060d4a496f66727d8f  guile-reader-0.6.tar.gz.sig

Documentation is available from:

  http://www.nongnu.org/guile-reader/

Guile-Reader is a reader creation framework for Guile.  It can be
thought of as an alternative to Guile's built-in reader.  The purpose of
Guile-Reader is to allow for the creation of readers for different
variants of the Scheme/Lisp syntax.  Its design allows the re-use and
composition of various parts of a lexer called “token readers”.  It
comes with a library of re-usable token readers that can be used to
build a Scheme reader with various extensions.  For instance, syntax
extensions for&lt;/pre&gt;</description>
    <dc:creator>Ludovic Courtès</dc:creator>
    <dc:date>2012-05-08T21:06:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9457">
    <title>Re: Working http-get example and still unsolved problem</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9457</link>
    <description>&lt;pre&gt;
Well, I mentioned it in the thread where I posted the patch, but to
briefly summarise

(define a &amp;lt;port&amp;gt;)
(define b (make-chunked-input-port a))
(close-port b)

What is the state of a?

(define c &amp;lt;port&amp;gt;)
(define d (make-chunked-output-port c))
(close-port d)

Likewise for c.

If you take, say, Java's BufferedReader, when the BufferedReader is
closed, it also closes the underlying Reader. This behaviour is
convenient, as you layer ports on top of one another, you only need to
worry about closing the top-most one. Since chunked transfer encoding is
only one of the possible encodings for http requests (though the only
one required by HTTP 1.1), it is possible that we would eventually want
to layer, say, gzip on top of chunked transfer encoding ports.

The issue with having this behaviour, is that while propagating the
close may be necessary to ensure proper behaviour, we don't necessarily
want to close the original socket. In particular, we might want to reuse
the same socket for multiple requests to the same h&lt;/pre&gt;</description>
    <dc:creator>Ian Price</dc:creator>
    <dc:date>2012-05-07T20:09:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9456">
    <title>Re: Working http-get example and still unsolved problem</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9456</link>
    <description>&lt;pre&gt;Hi, Ian;

2012/5/7 Ian Price &amp;lt;ianprice90&amp;lt; at &amp;gt;googlemail.com&amp;gt;


I don't understand the "close-port issue" exactly so this might be
nonsense. I think you mean comment-out-ed (close-port port) of close
in make-chunked-input-port.

http-get in client.scm calls close-port when keep-alive? keyword be false
value. http-post of Greg Benison's use keep-alive? keyword only when making
headers and does not call close-port; this is why my cc-ing to Greg.

In this today morning, I had thought what points need to patch if being
https support. I had no experience to making that kind of codes and can't
imagine I myself write it, so just a thought.

open-socket-for-uri need to make a session using gnu-tls; it does handshake
with a server and so on. http-get (and http-post) need to send bye to that
session when keep-alive? keyword be false value. So, close-port might be a
role of http-get?
&lt;/pre&gt;</description>
    <dc:creator>Sunjoong Lee</dc:creator>
    <dc:date>2012-05-07T14:40:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9455">
    <title>Re: Working http-get example and still unsolved problem</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9455</link>
    <description>&lt;pre&gt;

Odd that I hadn't noticed this issue when I was testing. The problem
occurs in the case where the number to be read is less than the
remaining size of a chunk. I was updating the count with the buffer
size, rather than the difference, which leads to negative values on the
recursive call. There was also a mistake in the same case in updating
the buffer-pointer.

Thanks for pointing this out, and if you have other comments on the
implementation (and the close-port issue), I'll be happy to have them.

&lt;/pre&gt;</description>
    <dc:creator>Ian Price</dc:creator>
    <dc:date>2012-05-07T05:16:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.guile.user/9454">
    <title>Re: Working http-get example and still unsolved problem</title>
    <link>http://permalink.gmane.org/gmane.lisp.guile.user/9454</link>
    <description>&lt;pre&gt;Ian had made a new patch for Chunked Encoding,
http://lists.gnu.org/archive/html/guile-devel/2012-05/msg00040.html ;
thanks Ian. But I suspect it has a bug.

make-chunked-input-port use bytevector-copy! in read!. I saw the crash like
this;
  ERROR: In procedure bytevector-copy!:
  ERROR: Value out of range 0 to 4294967295: -5915

I can't tell the url of the web page made that crash because I had seen it
in my testing login to that page but can tell you that was not written by
english and the charset of that is not UTF-8. I suspect the cause of the
crash be in using bytevector-copy!.

The previous patch made in 06 Nov 2011 does not make a crash. With that, I
could not read the content body of the page but it might be my fault.

2012/5/2 Sunjoong Lee &amp;lt;sunjoong&amp;lt; at &amp;gt;gmail.com&amp;gt;
&lt;/pre&gt;</description>
    <dc:creator>Sunjoong Lee</dc:creator>
    <dc:date>2012-05-06T23:37:18</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.guile.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.guile.user</link>
  </textinput>
</rdf:RDF>

