From tayloj at cs.rpi.edu  Wed Mar  4 03:10:33 2009
From: tayloj at cs.rpi.edu (Joshua TAYLOR)
Date: Tue, 3 Mar 2009 22:10:33 -0500
Subject: [drakma-devel] Conditional (#+/#-) expressions in DRAKMA
Message-ID: <1c3ea73c0903031910v30675801xb15c6860f1a0bc4f@mail.gmail.com>

Hello,

With the new release of DRAKMA I was looking over some of the source,
and came across code like

(some-function ...#+:clisp #+:clisp :clisp-arg clisp-val)

which I'd never seen before. I started to investigate, and a
discussion even started on c.l.l [1]. It turns out that not all Lisps
treat these constructions in the same way. Particularly, in the case
of #-feature #-feature, some process the second #-feature with
*READ-SUPPRESS* bound to T, so the behavior is like #-CL:NIL. At any
rate, it seems a bit safer and more portable not to nest the
conditionalized expressions. The only place I found these was in
request.lisp, and even there only in three places.

I've attached a diff in which they are changed to the safer form. I've
also added leading colons to openmcl, since the rest of the source
seemed to use that style.

Thanks for a great HTTP client?DRAKMA's the one I turn to when I need
a Lisp HTTP client.
//JT

[1] http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/8d50284a29f51673#

-- 
=====================
Joshua Taylor
tayloj at cs.rpi.edu, jtaylor at alum.rpi.edu

"A lot of good things went down one time,
  back in the goodle days."
    John Hartford
-------------- next part --------------
160,161c160,161
<                              #+:clisp #+:clisp
<                              (flexi-stream-element-type stream) element-type))
---
>                              #+:clisp (flexi-stream-element-type stream)
> 			     #+:clisp element-type))
207c207
<                               #+openmcl
---
>                               #+:openmcl
448,450c448,449
<                                                           #-:lw-does-not-have-write-timeout
<                                                           #-:lw-does-not-have-write-timeout
<                                                           :write-timeout write-timeout
---
>                                                           #-:lw-does-not-have-write-timeout :write-timeout
>                                                           #-:lw-does-not-have-write-timeout write-timeout
456,457c455,456
<                                                              #+openmcl #+openmcl
<                                                              :deadline deadline
---
>                                                              #+:openmcl :deadline
> 							     #+:openmcl deadline
459c458
<               #+openmcl
---
>               #+:openmcl

From edi at agharta.de  Wed Mar  4 08:22:23 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 4 Mar 2009 09:22:23 +0100
Subject: [drakma-devel] Conditional (#+/#-) expressions in DRAKMA
In-Reply-To: <1c3ea73c0903031910v30675801xb15c6860f1a0bc4f@mail.gmail.com>
References: <1c3ea73c0903031910v30675801xb15c6860f1a0bc4f@mail.gmail.com>
Message-ID: <b56421a00903040022y3b43f2ddtfbac36cb9a77e635@mail.gmail.com>

On Wed, Mar 4, 2009 at 4:10 AM, Joshua TAYLOR <tayloj at cs.rpi.edu> wrote:

> With the new release of DRAKMA I was looking over some of the source,
> and came across code like
>
> (some-function ...#+:clisp #+:clisp :clisp-arg clisp-val)
>
> which I'd never seen before. I started to investigate, and a
> discussion even started on c.l.l [1]. It turns out that not all Lisps
> treat these constructions in the same way. Particularly, in the case
> of #-feature #-feature, some process the second #-feature with
> *READ-SUPPRESS* bound to T, so the behavior is like #-CL:NIL. At any
> rate, it seems a bit safer and more portable not to nest the
> conditionalized expressions. The only place I found these was in
> request.lisp, and even there only in three places.
>
> I've attached a diff in which they are changed to the safer form. I've
> also added leading colons to openmcl, since the rest of the source
> seemed to use that style.

Thanks for the patch.  I'm aware of the theoretical implications of
this usage, but is it actually a problem in practice, i.e. does the
code break for one of the supported Lisps?  And, without reading the
c.l.l discussion, is this maybe because the Lisp in question is not
following the standard correctly?

I'd be willing to accept the patch although I like the current form
more, but it'd be nice to know what we really lose or win.  Also,
could you please resend the patch as a unified diff and without tab
characters?

  http://weitz.de/patches.html

Thanks,
Edi.



From tayloj at cs.rpi.edu  Wed Mar  4 13:33:31 2009
From: tayloj at cs.rpi.edu (Joshua TAYLOR)
Date: Wed, 4 Mar 2009 08:33:31 -0500
Subject: [drakma-devel] Conditional (#+/#-) expressions in DRAKMA
In-Reply-To: <b56421a00903040022y3b43f2ddtfbac36cb9a77e635@mail.gmail.com>
References: <1c3ea73c0903031910v30675801xb15c6860f1a0bc4f@mail.gmail.com>
	<b56421a00903040022y3b43f2ddtfbac36cb9a77e635@mail.gmail.com>
Message-ID: <1c3ea73c0903040533t78abaa4i2a620c34ff78440b@mail.gmail.com>

On Wed, Mar 4, 2009 at 3:22 AM, Edi Weitz <edi at agharta.de> wrote:
> On Wed, Mar 4, 2009 at 4:10 AM, Joshua TAYLOR <tayloj at cs.rpi.edu> wrote:
>
>> With the new release of DRAKMA I was looking over some of the source,
>> and came across code like
>>
>> (some-function ...#+:clisp #+:clisp :clisp-arg clisp-val)
>>
>> which I'd never seen before. I started to investigate, and a
>> discussion even started on c.l.l [1]. It turns out that not all Lisps
>> treat these constructions in the same way. Particularly, in the case
>> of #-feature #-feature, some process the second #-feature with
>> *READ-SUPPRESS* bound to T, so the behavior is like #-CL:NIL. At any
>> rate, it seems a bit safer and more portable not to nest the
>> conditionalized expressions. The only place I found these was in
>> request.lisp, and even there only in three places.
>>
>> I've attached a diff in which they are changed to the safer form. I've
>> also added leading colons to openmcl, since the rest of the source
>> seemed to use that style.
>
> Thanks for the patch. ?I'm aware of the theoretical implications of
> this usage, but is it actually a problem in practice, i.e. does the
> code break for one of the supported Lisps? ?And, without reading the
> c.l.l discussion, is this maybe because the Lisp in question is not
> following the standard correctly?

The /present/ code does /not/ break for any of the supported Lisps.
However, I do see conditionalizations on :openmcl, and it's
openMCL/ClozureCL that has this problem:

CL-USER> (lisp-implementation-version)
"Version 1.3-RC1-r11719M  (DarwinX8664)"
CL-USER> (lisp-implementation-type)
"Clozure Common Lisp"
CL-USER> (list #+:openmcl #+:openmcl 1 2 3 4)
(1 2 3 4)
CL-USER> (list #-:openmcl #-:openmcl 1 2 3 4)
(2 3 4) ; I bet you weren't expecting this ^_^

This issue doesn't arise directly in the current code, but will come
up if #-:openmcl #-:openmcl ever arises. This is just an attempt to
make that less likely to happen (since it would differ from the
surrounding style).

> I'd be willing to accept the patch although I like the current form
> more, but it'd be nice to know what we really lose or win.

As above, it's really not a significant issue, and you'd probably be
fine staying with the existing convention. The folks on c.l.l seem to
agree that the last form is permissible by the standard. (I did send a
message to the CCL people too, though, since there was a related bug,
and they're doing something different than what many people have come
to expect.)

> Also,
> could you please resend the patch as a unified diff and without tab
> characters?
>
> ?http://weitz.de/patches.html

My apologies--I've even read that page before! I missed the `diff -u',
and I'd assumed that Emacs/Slime wasn't putting in literal #\Tab
characters (now something of which I'll have to be aware in the
future). Updated diff attached. Again, the cost of non-adoption is
very low, and benefits are only preventing /possible/ /future/ bugs.

//JT
-------------- next part --------------
--- request.lisp.old	2009-03-03 21:54:27.000000000 -0500
+++ request.lisp	2009-03-04 08:17:51.000000000 -0500
@@ -157,8 +157,8 @@
                      (when textp
                        (setf result
                              (octets-to-string result :external-format (flexi-stream-external-format stream))
-                             #+:clisp #+:clisp
-                             (flexi-stream-element-type stream) element-type))
+                             #+:clisp (flexi-stream-element-type stream)
+                             #+:clisp element-type))
                      result))
                   ((or chunkedp must-close)
                    ;; no content length, read until EOF (or end of chunking)
@@ -204,7 +204,7 @@
                               #+:lispworks (read-timeout 20)
                               #+(and :lispworks (not :lw-does-not-have-write-timeout))
                               (write-timeout 20 write-timeout-provided-p)
-                              #+openmcl
+                              #+:openmcl
                               deadline)
   "Sends an HTTP request to a web server and returns its reply.  URI
 is where the request is sent to, and it is either a string denoting a
@@ -446,17 +446,18 @@
                                                           :timeout connection-timeout
                                                           :read-timeout read-timeout
                                                           #-:lw-does-not-have-write-timeout
+                                                          :write-timeout
                                                           #-:lw-does-not-have-write-timeout
-                                                          :write-timeout write-timeout
+                                                          write-timeout
                                                           :errorp t)
                                     #-:lispworks
                                     (usocket:socket-stream
                                      (usocket:socket-connect host port
                                                              :element-type 'octet
-                                                             #+openmcl #+openmcl
-                                                             :deadline deadline
+                                                             #+:openmcl :deadline
+                                                             #+:openmcl deadline
                                                              :nodelay t))))
-              #+openmcl
+              #+:openmcl
               (when deadline
                 ;; it is correct to set the deadline here even though
                 ;; it may have been initialized by SOCKET-CONNECT

From edi at agharta.de  Wed Mar  4 16:43:16 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 4 Mar 2009 17:43:16 +0100
Subject: [drakma-devel] Conditional (#+/#-) expressions in DRAKMA
In-Reply-To: <1c3ea73c0903040533t78abaa4i2a620c34ff78440b@mail.gmail.com>
References: <1c3ea73c0903031910v30675801xb15c6860f1a0bc4f@mail.gmail.com>
	<b56421a00903040022y3b43f2ddtfbac36cb9a77e635@mail.gmail.com>
	<1c3ea73c0903040533t78abaa4i2a620c34ff78440b@mail.gmail.com>
Message-ID: <b56421a00903040843w58172a9k29925e729d2de510@mail.gmail.com>

Thanks for the detailed info.  I'll apply the patch to the dev version.

Edi.



From lispercat at gmail.com  Sat Mar  7 22:58:41 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sat, 7 Mar 2009 17:58:41 -0500
Subject: [drakma-devel] http-request returns a binary array...
Message-ID: <affe56e00903071458s5361a8del77d4f47f2265be2d@mail.gmail.com>

I wonder what am I missing when a call like (http-request
"http://lisp.org/") returns a binary array:

#(60 116 105 116 108 101 62 114 101 100 105 114 101 99 116 46 46 46 60 47 116
  105 116 108 101 62 60 109 101 116 97 32 104 116 116 112 45 101 113 117 105
  118 61 34 82 101 102 114 101 115 104 34 32 99 111 110 116 101 110 116 61 34
  48 59 32 117 114 108 61 47 97 108 117 47 104 111 109 101 34 62)
200
((:DATE . "Sat, 07 Mar 2009 22:56:52 GMT") (:CONNECTION . "Close")
 (:SERVER . "AllegroServe/1.2.50") (:TRANSFER-ENCODING . "chunked"))
#<PURI:URI http://lisp.org>
#<FLEXI-IO-STREAM {107E2C79}>
T
" OK"

Before I upgraded to the new hunchentoot and drakma and chunga it
would give me a text string.
Thank you,
Andrei



From tayloj at cs.rpi.edu  Sat Mar  7 23:04:01 2009
From: tayloj at cs.rpi.edu (Joshua TAYLOR)
Date: Sat, 7 Mar 2009 18:04:01 -0500
Subject: [drakma-devel] http-request returns a binary array...
In-Reply-To: <affe56e00903071458s5361a8del77d4f47f2265be2d@mail.gmail.com>
References: <affe56e00903071458s5361a8del77d4f47f2265be2d@mail.gmail.com>
Message-ID: <1c3ea73c0903071504t6c845a23re44c1b1a99b6f1ba@mail.gmail.com>

I had a similar experience until I upgraded to the latest versions of
some of the supporting libraries. I had to upgrade a number of them,
so unfortunately I can't point to exactly which one. Perhaps
FLEXI-STREAMS and underlying TRIVIAL-GRAY-STREAMS.

On Sat, Mar 7, 2009 at 5:58 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
> I wonder what am I missing when a call like (http-request
> "http://lisp.org/") returns a binary array:
>
> #(60 116 105 116 108 101 62 114 101 100 105 114 101 99 116 46 46 46 60 47 116
> ?105 116 108 101 62 60 109 101 116 97 32 104 116 116 112 45 101 113 117 105
> ?118 61 34 82 101 102 114 101 115 104 34 32 99 111 110 116 101 110 116 61 34
> ?48 59 32 117 114 108 61 47 97 108 117 47 104 111 109 101 34 62)
> 200
> ((:DATE . "Sat, 07 Mar 2009 22:56:52 GMT") (:CONNECTION . "Close")
> ?(:SERVER . "AllegroServe/1.2.50") (:TRANSFER-ENCODING . "chunked"))
> #<PURI:URI http://lisp.org>
> #<FLEXI-IO-STREAM {107E2C79}>
> T
> " OK"
>
> Before I upgraded to the new hunchentoot and drakma and chunga it
> would give me a text string.
> Thank you,
> Andrei
>
> _______________________________________________
> drakma-devel mailing list
> drakma-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>



-- 
=====================
Joshua Taylor
tayloj at cs.rpi.edu, jtaylor at alum.rpi.edu

"A lot of good things went down one time,
  back in the goodle days."
    John Hartford



From lispercat at gmail.com  Sun Mar  8 01:00:46 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sat, 7 Mar 2009 20:00:46 -0500
Subject: [drakma-devel] http-request returns a binary array...
In-Reply-To: <1c3ea73c0903071504t6c845a23re44c1b1a99b6f1ba@mail.gmail.com>
References: <affe56e00903071458s5361a8del77d4f47f2265be2d@mail.gmail.com>
	<1c3ea73c0903071504t6c845a23re44c1b1a99b6f1ba@mail.gmail.com>
Message-ID: <affe56e00903071700l1a941a58j8321713e86eec0cb@mail.gmail.com>

I got
bordeaux-threads_0.5.1
chunga-1.0.0
cl-who-0.11.1
drakma-1.0.0
flexi-streams-1.0.7
hunchentoot-1.0.0
trivial-gray-streams-2008-11-02
usocket-0.4.1

Still got that binary...


On Sat, Mar 7, 2009 at 6:04 PM, Joshua TAYLOR <tayloj at cs.rpi.edu> wrote:
> I had a similar experience until I upgraded to the latest versions of
> some of the supporting libraries. I had to upgrade a number of them,
> so unfortunately I can't point to exactly which one. Perhaps
> FLEXI-STREAMS and underlying TRIVIAL-GRAY-STREAMS.
>
> On Sat, Mar 7, 2009 at 5:58 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
>> I wonder what am I missing when a call like (http-request
>> "http://lisp.org/") returns a binary array:
>>
>> #(60 116 105 116 108 101 62 114 101 100 105 114 101 99 116 46 46 46 60 47 116
>> ?105 116 108 101 62 60 109 101 116 97 32 104 116 116 112 45 101 113 117 105
>> ?118 61 34 82 101 102 114 101 115 104 34 32 99 111 110 116 101 110 116 61 34
>> ?48 59 32 117 114 108 61 47 97 108 117 47 104 111 109 101 34 62)
>> 200
>> ((:DATE . "Sat, 07 Mar 2009 22:56:52 GMT") (:CONNECTION . "Close")
>> ?(:SERVER . "AllegroServe/1.2.50") (:TRANSFER-ENCODING . "chunked"))
>> #<PURI:URI http://lisp.org>
>> #<FLEXI-IO-STREAM {107E2C79}>
>> T
>> " OK"
>>
>> Before I upgraded to the new hunchentoot and drakma and chunga it
>> would give me a text string.
>> Thank you,
>> Andrei
>>
>> _______________________________________________
>> drakma-devel mailing list
>> drakma-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>>
>
>
>
> --
> =====================
> Joshua Taylor
> tayloj at cs.rpi.edu, jtaylor at alum.rpi.edu
>
> "A lot of good things went down one time,
> ?back in the goodle days."
> ? ?John Hartford
>
> _______________________________________________
> drakma-devel mailing list
> drakma-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>



From tayloj at cs.rpi.edu  Sun Mar  8 01:54:04 2009
From: tayloj at cs.rpi.edu (Joshua TAYLOR)
Date: Sat, 7 Mar 2009 20:54:04 -0500
Subject: [drakma-devel] http-request returns a binary array...
In-Reply-To: <affe56e00903071700l1a941a58j8321713e86eec0cb@mail.gmail.com>
References: <affe56e00903071458s5361a8del77d4f47f2265be2d@mail.gmail.com>
	<1c3ea73c0903071504t6c845a23re44c1b1a99b6f1ba@mail.gmail.com>
	<affe56e00903071700l1a941a58j8321713e86eec0cb@mail.gmail.com>
Message-ID: <1c3ea73c0903071754h7604b1abt4dc5fcee52834eef@mail.gmail.com>

On Sat, Mar 7, 2009 at 8:00 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
> I got
> bordeaux-threads_0.5.1
> chunga-1.0.0
> cl-who-0.11.1
> drakma-1.0.0
> flexi-streams-1.0.7
> hunchentoot-1.0.0
> trivial-gray-streams-2008-11-02
> usocket-0.4.1
>
> Still got that binary...

(To be clear, I'm not a DRAKMA dev; I'm just chiming in since I had a
similar issue.) What platform are you using? Since you mention
usocket, I'd guess you're not on LispWorks. I ran into old versions of
libraries when I was running on CCL, but after updating all the way
tough, ended up with:

DRAKMA 1.0.0
CL+SSL (no version number)
FLEXI-STREAMS and FLEXI-STREAMS-TEST 1.0.7
TRIVIAL-GRAY-STREAMS 2008-11-02
CFFI 0.10.4
BABEL 0.3.0
ALEXANDRIA 0.0.0
TRIVIAL-FEATURES 0.4
USOCKET 0.4.1
SPLIT-SEQUENCE 20011114.1
CHUNGA 1.0.0
CL-BASE64 and CL-BASE64-TESTS  3.3.2
PURI and PURI-TESTS 1.5.1

(and, for the record , under LispWorks it's (with the same version numbers):

DRAKMA
FLEXI-STREAMS and FLEXI-STREAMS-TEST
TRIVIAL-GRAY-STREAMS
CHUNGA
CL-BASE64 and CL-BASE64-TESTS
PURI and PURI-TESTS)

I guess I can't really be of any help, but maybe if any of those
version numbers look newer than the ones you've got, it can be a
starting point for you.

Best luck to you, //JT



From edi at agharta.de  Sun Mar  8 16:14:19 2009
From: edi at agharta.de (Edi Weitz)
Date: Sun, 8 Mar 2009 17:14:19 +0100
Subject: [drakma-devel] [hunchentoot-devel] "Proxy Error" with new
	Hunchentoot
In-Reply-To: <affe56e00903071455j3be21351v63882d4b449a3e4c@mail.gmail.com>
References: <affe56e00903070810j454b7ce4k311bf9d305673041@mail.gmail.com>
	<b2ff917c0903071031o50d2b4e2gd6c5810bdd0c9d68@mail.gmail.com>
	<affe56e00903071455j3be21351v63882d4b449a3e4c@mail.gmail.com>
Message-ID: <b56421a00903080914rd3af331l9253319bde80e579@mail.gmail.com>

On Sat, Mar 7, 2009 at 11:55 PM, Andrei Stebakov <lispercat at gmail.com> wrote:

> After I upgraded to new chunga things started to move, but now I have
> a problem with drakma:http-request. It returns a binary array on a
> request like (http-request "http://lisp.org/"), so all my functions
> depending on http-request fail. I'll ask about it in drakma ml.

As I said in the release announcements, the new and the old (with
1.x.x being the dividing line) versions of Drakma, Hunchentoot, and
Chunga are mutually incompatible.  If you upgrade one of them, you
need to upgrade all three libraries.

HTH,
Edi.



From lispercat at gmail.com  Sun Mar  8 19:32:52 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 8 Mar 2009 15:32:52 -0400
Subject: [drakma-devel] error while using ssl connections in new drakma
Message-ID: <affe56e00903081232j2403d651oc950edab01e15eed@mail.gmail.com>

When calling:
(http-request "https://www.fortify.net/cgi/ssl_2.pl")

I have
Unhandled memory fault at #x14.
   [Condition of type SB-SYS:MEMORY-FAULT-ERROR]

Restarts:
 0: [RETRY] Retry SLIME interactive evaluation request.
 1: [ABORT] Return to SLIME's top level.
 2: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (SB-SYS:MEMORY-FAULT-ERROR)
  1: (SB-SYS:MEMORY-FAULT-ERROR)[:EXTERNAL]
  2: ("foreign function: #x806452C")
  3: ("foreign function: #x8064860")
  4: ("foreign function: #xB77B6A10")
  5: ("foreign function: #xB77B6CE8")
  6: (CL+SSL::SSL-SET-FD #<unavailable lambda list>)
  7: (CL+SSL::INSTALL-HANDLE-AND-BIO #<unavailable lambda list>)
  8: (CL+SSL:MAKE-SSL-CLIENT-STREAM #<unavailable lambda list>)[:EXTERNAL]
  9: (HTTP-REQUEST "https://www.fortify.net/cgi/ssl_2.pl")[:EXTERNAL]

I use sbcl-1.0.23 on Ubuntu 32 bit.
cffi_0.10.4
drakma-1.0.0
latest cl+ssl from cvs

What am I missing?
Thank you,
Andrei



From lispercat at gmail.com  Tue Mar 10 01:22:43 2009
From: lispercat at gmail.com (Andrei Stebakov)
Date: Mon, 9 Mar 2009 21:22:43 -0400
Subject: [drakma-devel] error while using ssl connections in new drakma
In-Reply-To: <affe56e00903081232j2403d651oc950edab01e15eed@mail.gmail.com>
References: <affe56e00903081232j2403d651oc950edab01e15eed@mail.gmail.com>
Message-ID: <affe56e00903091822o78548431p4cf6ed6c1e17f204@mail.gmail.com>

I wonder if it only happens on my system? Looks like I have everything
up to date...
The error may happen in other places like:

Unhandled memory fault at #x7F000000.
   [Condition of type SB-SYS:MEMORY-FAULT-ERROR]

Restarts:
 0: [RETRY] Retry SLIME interactive evaluation request.
 1: [ABORT] Return to SLIME's top level.
 2: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (SB-SYS:MEMORY-FAULT-ERROR)
  1: (SB-SYS:MEMORY-FAULT-ERROR)[:EXTERNAL]
  2: ("foreign function: #x806452C")
  3: ("foreign function: #x8064860")
  4: ("foreign function: #xB75496B5")
  5: ("foreign function: #xB754842C")
  6: (CL+SSL::SSL-NEW #<unavailable lambda list>)
  7: (CL+SSL:MAKE-SSL-CLIENT-STREAM #<unavailable lambda list>)[:EXTERNAL]
  8: (HTTP-REQUEST "https://www.fortify.net/cgi/ssl_2.pl")[:EXTERNAL]
  9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (HTTP-REQUEST
"https://www.fortify.net/cgi/ssl_2.pl") #<NULL-LEXENV>)
 10: ((LAMBDA ()))

I tried previous versions of ssl, but it's similar errors.

Thank you,
Andrei

On Sun, Mar 8, 2009 at 3:32 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
> When calling:
> (http-request "https://www.fortify.net/cgi/ssl_2.pl")
>
> I have
> Unhandled memory fault at #x14.
> ? [Condition of type SB-SYS:MEMORY-FAULT-ERROR]
>
> Restarts:
> ?0: [RETRY] Retry SLIME interactive evaluation request.
> ?1: [ABORT] Return to SLIME's top level.
> ?2: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
> ?0: (SB-SYS:MEMORY-FAULT-ERROR)
> ?1: (SB-SYS:MEMORY-FAULT-ERROR)[:EXTERNAL]
> ?2: ("foreign function: #x806452C")
> ?3: ("foreign function: #x8064860")
> ?4: ("foreign function: #xB77B6A10")
> ?5: ("foreign function: #xB77B6CE8")
> ?6: (CL+SSL::SSL-SET-FD #<unavailable lambda list>)
> ?7: (CL+SSL::INSTALL-HANDLE-AND-BIO #<unavailable lambda list>)
> ?8: (CL+SSL:MAKE-SSL-CLIENT-STREAM #<unavailable lambda list>)[:EXTERNAL]
> ?9: (HTTP-REQUEST "https://www.fortify.net/cgi/ssl_2.pl")[:EXTERNAL]
>
> I use sbcl-1.0.23 on Ubuntu 32 bit.
> cffi_0.10.4
> drakma-1.0.0
> latest cl+ssl from cvs
>
> What am I missing?
> Thank you,
> Andrei
>



From edi at agharta.de  Tue Mar 10 09:24:31 2009
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Mar 2009 10:24:31 +0100
Subject: [drakma-devel] error while using ssl connections in new drakma
In-Reply-To: <affe56e00903091822o78548431p4cf6ed6c1e17f204@mail.gmail.com>
References: <affe56e00903081232j2403d651oc950edab01e15eed@mail.gmail.com>
	<affe56e00903091822o78548431p4cf6ed6c1e17f204@mail.gmail.com>
Message-ID: <b56421a00903100224x77c5014dr58c56fa6723f23b9@mail.gmail.com>

On Tue, Mar 10, 2009 at 2:22 AM, Andrei Stebakov <lispercat at gmail.com> wrote:
> I wonder if it only happens on my system?

Can anyone reproduce this?  Or rather, does the SBCL/SSL combo work for others?

Thanks,
Edi.