[PATCH] Guildhall: fix download path and keep connection alive

[PATCH] Guildhall: fix download path and keep connection alive

[Nala Ginrut]

[-- Attachment #1.1: Type: text/plain, Size: 536 bytes --]

hi guys!
I realized there're two problems in our shinning Guildhall.

1. When "http-download" calls "relative-uri", the first arg should be a
string, say "srfi", but ("srfi").
2. I can install single package perfectly, but if there're several
dependencies, guildhall will throw a timeout.
    eg. guild hall install spells, the first dependency will be installed
perfectly, but the second will give me a long time no response then timeout.

So I changed the connection to keep-alive mode. And everything's OK now.

A patch is attached.

[-- Attachment #1.2: Type: text/html, Size: 714 bytes --]

[-- Attachment #2: 0001-fix-download-path-and-keep-connection-alive.patch --]
[-- Type: application/octet-stream, Size: 1067 bytes --]

From 8a137175b4ed77b30be676ef97c0719b56eb329d Mon Sep 17 00:00:00 2001
From: NalaGinrut <NalaGinrut@gmail.com>
Date: Tue, 16 Aug 2011 02:54:41 +0800
Subject: [PATCH] fix download path and keep connection alive

---
 guild/repository.scm |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/guild/repository.scm b/guild/repository.scm
index 842230f..6d5a8f4 100644
--- a/guild/repository.scm
+++ b/guild/repository.scm
@@ -132,12 +132,12 @@
           (if (file-exists? destination)
               destination
               (http-download destination
-                             (relative-uri location base-uri)))))))))
+                             (relative-uri (car location) base-uri)))))))))
 
 (define (http-download destination uri)
   (message "Fetching " (uri->string uri))
   (call-with-values (lambda ()
-                      (http-get uri #:decode-body? #f))
+                      (http-get uri #:decode-body? #f #:keep-alive? #t))
     (lambda (response body)
       (case (response-code response)
         ((200)
-- 
1.7.0.4

Re: [PATCH] Guildhall: fix download path and keep connection alive

[Ian Price]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Nala Ginrut <nalaginrut@gmail.com> writes:

> hi guys!
> I realized there're two problems in our shinning Guildhall. 
>
> 1. When "http-download" calls "relative-uri", the first arg should be a string, say "srfi", but ("srfi").

I don't see a reply to this issue like there is for the other, and it
isn't fixed in gitorious yet, so I thought I'd weigh in.

The root cause of this problem are the
  (location ("wak-syn-param-20110103.zip"))
entries in the file 'available.scm'. Judging by the rest of
dorodango/sigil, this means that the file may be in an arbitrary
subdirectory i.e. ("foo" "bar" "baz.zip"), and so just doing 'car' isn't
going to cut it.

I think a better solution is to
a) Change the 'location' format to be a string only, this entails
changes to a few procedures that add location properties to
packages. I'm not sure if getting rid of the subdirs is desirable (it
might be), but changing the format is still feasible since doro/sigil
isn't in widespread use yet.
or
b) fix 'relative-uri' to take a list of paths, which matches the current
format of locations.

I went for the latter, but what do you think?

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Fix sigil downloads --]
[-- Type: text/x-patch, Size: 1174 bytes --]

From 63613aae434d502598a0a8d33368c8a6b4d3dfff Mon Sep 17 00:00:00 2001
From: Ian Price <ianprice90@googlemail.com>
Date: Sun, 4 Sep 2011 01:40:54 +0100
Subject: [PATCH] path argument to relative-uri should be a list of strings

---
 sigil/repository.scm |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sigil/repository.scm b/sigil/repository.scm
index 8261144..3a9e713 100644
--- a/sigil/repository.scm
+++ b/sigil/repository.scm
@@ -108,13 +108,13 @@
                      "/"
                      (encode-and-join-uri-path
                       (append (split-and-decode-uri-path (uri-path rel))
-                              (split-and-decode-uri-path path))))))
+                              path)))))
 
 (define (make-http-repository name uri-string)
   (let* ((base-uri (uri-with-directory-path
                     (or (string->uri uri-string)
                         (error "bad URI string" uri-string))))
-         (available-uri (relative-uri "available.scm" base-uri))
+         (available-uri (relative-uri '("available.scm") base-uri))
          (available-filename "available.scm"))
     (make-repository
      name
-- 
1.7.6

Re: [PATCH] Guildhall: fix download path and keep connection alive

[Andy Wingo]

Hi!

Sorry for the terrible delay here.

On Sun 04 Sep 2011 07:33, Ian Price <ianprice90@googlemail.com> writes:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>
>> hi guys!
>> I realized there're two problems in our shinning Guildhall. 
>>
>> 1. When "http-download" calls "relative-uri", the first arg should be a string, say "srfi", but ("srfi").
>
> I don't see a reply to this issue like there is for the other, and it
> isn't fixed in gitorious yet, so I thought I'd weigh in.
>
> The root cause of this problem are the
>   (location ("wak-syn-param-20110103.zip"))
> entries in the file 'available.scm'. Judging by the rest of
> dorodango/sigil, this means that the file may be in an arbitrary
> subdirectory i.e. ("foo" "bar" "baz.zip"), and so just doing 'car' isn't
> going to cut it.
>
> I think a better solution is to
> a) Change the 'location' format to be a string only, this entails
> changes to a few procedures that add location properties to
> packages. I'm not sure if getting rid of the subdirs is desirable (it
> might be), but changing the format is still feasible since doro/sigil
> isn't in widespread use yet.
> or
> b) fix 'relative-uri' to take a list of paths, which matches the current
> format of locations.
>
> I went for the latter, but what do you think?

I think this is the right fix, though it's tough to tell now, as the
experimental dorodango repository appears to be down.  But I've pushed
it.  Thanks!

Andy
-- 
http://wingolog.org/