But our current doesn't
s/current/current read-response-body
Regards.
On Fri, Mar 16, 2012 at 1:54 PM, 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 versio
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 because it catches *any* exception and
return the rec
>From 183abb7e7d649fe4a1d1799b97e6da96f51b683c Mon Sep 17 00:00:00 2001
From: NalaGinrut
Date: Fri, 16 Mar 2012 13:41:34 +0800
Subject: [PATCH] read-response-body returns received data when error occurs
---
module/web/response.scm | 10 +-
1 files changed, 5 insertions(+), 5 deletions(
Hey guys,
I'd like to apply to work on Guile for this years GSOC. I saw Mark's TODO
list and thought that working towards a register-based VM in guile looks
like a fun project. I was wondering about your thoughts on doing this as a
GSOC project. Do you think it is possible to complete such a proje
After a long long discussion with ijp, I realized that this could be an
easy patch because get-bytevector-n handles most of the work. So I'll raise
another thread about this topic for a new version patch.
Thanks for discussion!
On Fri, Mar 16, 2012 at 10:23 AM, Nala Ginrut wrote:
> Thanks for re
On 16 March 2012 10:23, Nala Ginrut wrote:
> @Daniel: I realized that seems make "get-bytevector-n" return the received
> data rather than read-response-body is better. But I'm afraid that it'll
> conflict with the definition "get-bytevector-n". Say, we ask for n bytes,
> but it returned m bytes l
Thanks for reply!
@ijp: Yes, I think return received data within exception is ugly. But I
have to do it because my consideration is to return received data when
*any* exception happens. So if it's not a common connection error, I have
to catch it to return the received data, then re-throw the same
On Thu 15 Mar 2012 17:41, l...@gnu.org (Ludovic Courtès) writes:
> So if my recollection is correct, the ‘canonicalize-path’ call in
> ‘current-filename’, which was controversial, can now be removed.
>
> Andy: WDYT?
Well it's not what I wanted, but I don't care much. Please fix the
documentation
Neil Jerram writes:
> FYI, something seems awry in my automatic daily Guile build.
>
> I noticed that the build machine is spending much longer churning away
> than it normally does. Today I found that this is while building the
> master branch, and that it apparently spent all day trying
> unsu
FYI, something seems awry in my automatic daily Guile build.
I noticed that the build machine is spending much longer churning away
than it normally does. Today I found that this is while building the
master branch, and that it apparently spent all day trying
unsuccessfully to
GUILEC language/
On 16 March 2012 02:37, Ian Price wrote:
> Daniel Hartwig writes:
>> For example, reusing the same bytevector and looping over
>> read-response-body! saving the results to disk each time. This limits
>> the memory use to the size of the bytevector *and* removes the copy
>> operation from your im
Andy Wingo writes:
> Hello,
>
> I had a realization yesterday, that our documentation misses the point
> of guardians. Guardians exist to allow finalization of resources
> without introducing concurrency. However if you pump a guardian from
> the after-gc-hook, as recommended by "GC Hooks" in t
Daniel Hartwig writes:
> So this is an interesting start. The idea of buffering the transfer
> is great -- however, it falls short in this implementation because it
> is internal to read-response-body.
The buffering is useless, it's already performed by get-bytevector-n. In
this sense, it is als
Nala Ginrut writes:
> I've been troubled with a weird problem in read-response-body for a long time.
> I think read-response-body never return the received data when any break
> happens. No matter the break caused by connection problem or user
> interruption.
> The only possible read-response-b
Hello,
I had a realization yesterday, that our documentation misses the point
of guardians. Guardians exist to allow finalization of resources
without introducing concurrency. However if you pump a guardian from
the after-gc-hook, as recommended by "GC Hooks" in the manual, a
guardian is simply
Hello,
So if my recollection is correct, the ‘canonicalize-path’ call in
‘current-filename’, which was controversial, can now be removed.
Andy: WDYT?
Ludo’.
On 11 March 2012 23:35, Nala Ginrut wrote:
>
> The new read-response-body will add the received data to the exceptional
> information which used by "throw", if read-response-body can't continue to
> work anymore, the received data will return with throw.
> And there's a useful helper function to w
Hello,
I'm not as familiar with the compiler code as some other people here,
but I think that would be great! Guile can always use more speed, and
that seems like a project that you could complete in a summer.
I've thought a bit about how to do it. One step might be to write a
register VM in Sche
Noah Lavine writes:
> Hello,
>
> What ever happened to this issue? Is it considered resolved now, or is
> there more to do?
For my use case it's resolved, in the sense that I really needed a
runtime directory that may not be the same as the source compilation
location; and hence 'current-filenam
19 matches
Mail list logo
