Wrong thread but interesting ;-)
Could you resend it to the correct thread? Maybe helpful to people there.
Regards.
On Sat, Mar 17, 2012 at 12:27 AM, Tristan Colgate wrote:
> I got this the other day with lalr.scm. My build got stuck (100% CPU
> for quite a while). I ended up clearing out all ol
Well, to clarify, I confess I did a wrong prejudging. I thought
read-response-body is the only API to retrieve the body/data, so we should
use it anyway to get the data rather than writing other procedure to handle
it. Because the manual has only one API relate to this topic.
But I was *wrong*. Thi
On 16/03/2012 10:34, Nala Ginrut wrote:
I didn't saw any error with your information, and I think it's normal.
The *.go compiling is very slow even if you have a good machine. So be
patient.
Actually, I've noticed this too. The guile executable gets stuck and
uses 0% CPU. You can interrupt it a
* module/language/tree-il/primitives.scm (resolve-primitives!): Resolve
public module-refs to primitives.
* test-suite/tests/tree-il.test: New tests for primitive resolution.
---
module/language/tree-il/primitives.scm | 16 +---
test-suite/tests/tree-il.test | 10 ++
l...@gnu.org (Ludovic Courtès) writes:
> Hi Neil!
>
> Thanks for keeping those benchs running!
No prob; it all just runs itself.
Except... that there does now seem to be a significant problem with
master's compilation time. In practice this is now taking so long that
it has no chance of complet
On 17 March 2012 00:57, Ian Price wrote:
>
> This still doesn't answer my concerns. I don't think the user should
> have to be checking the length of the result themselves.
>
> (let ((bv (get-bytevector-n (response-port r) nbytes)))
> (cond ((eof-object? bv)
> (incomplete-response ...))
>
Nala Ginrut writes:
> + (let* ((bv (get-bytevector-n (response-port r) nbytes)))
> + (if (eof-object? bv)
> (bad-response "EOF while reading response body: ~a bytes of
> ~a"
> - (bytevector-length bv) nbytes))
> +
I got this the other day with lalr.scm. My build got stuck (100% CPU
for quite a while). I ended up clearing out all old .go files and
trying again and it got past it (didn't even take that long, a few
seconds compared to a 15 minute wait).
On 16 March 2012 08:47, Nala Ginrut wrote:
> Well, I saw
Hi Neil!
Thanks for keeping those benchs running!
Neil Jerram skribis:
> Also, looking at the benchmark graphs at
> http://ossau.homelinux.net/~neil/bm_master_i.html, there's a bunch of
> benchmarks related to latin-1 / UTF-8 that are apparently taking 100s of
> times longer than they used to.
Hi BT,
BT Templeton skribis:
> * module/language/tree-il/primitives.scm (resolve-primitives!): Resolve
> public module-refs to primitives.
What about resolving private module-refs too? Here’s the motivation:
scheme@(guile-user)> (use-modules(ice-9 match))
scheme@(guile-user)> ,expand (m
Hi Ian,
Ian Price skribis:
> I've been working on this in my own time, on an as-needed basis. See
> https://github.com/ijp/pfds/ . SamTH on #scheme recently pointed me to a
> bunch of ones implemented for racket: ralists/fectors/etc. that I will
> get around to adding.
Adding more functional da
Hi David,
David Kastrup skribis:
> l...@gnu.org (Ludovic Courtès) writes:
[...]
>> The order in which files get compiled does not matter; the semantics of
>> programs do not depend on whether code is being bytecode-interpreted or
>> just interpreted by (ice-9 eval).
>
> Little things like
>
>
I didn't saw any error with your information, and I think it's normal. The
*.go compiling is very slow even if you have a good machine. So be patient.
On Fri, Mar 16, 2012 at 5:55 PM, Kun Liang wrote:
> Hi guys:
> I have checked out trunk of guile, try to build it with following
> steps unde
Hi guys:
I have checked out trunk of guile, try to build it with following steps
under guile top directory:
./autogen.sh
mkdir build
cd build
../configure
make
Then the making process halt at this point (sometimes halt at
compiling a different scheme module). I was bui
Well, I saw your point. So read-response-body is defined to read the whole
body, and shouldn't return anything when it didn't get all the data.
For this reason, one should use bytevector handler to get the data on one's
own rather than read-response-body.
Well, I just thought read-response-body is
On 16 March 2012 13:54, Nala Ginrut wrote:
> This patch will return any data get-bytevector-n received and throw error
> when get .
> Actually, it's not the same feature in the old version thread
> http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00116.html
> The old version is complicated
16 matches
Mail list logo
