Hi, IOLib
The line 31 of iolib/io.streams/pkgdcl.lisp miss a "lispworks" feature. This caused io.streams package cannot import symbols from lispworks' stream package, and cause a error when I use net.smtp-client:
Error: The class #<STANDARD-CLASS IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM 40D0347A5B> cannot be finalized because the following superclass is not defined: #<FORWARD-REFERENCED-CLASS IO.STREAMS:FUNDAMENTAL-BINARY-INPUT-STREAM 40D03479CB>. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
A trivial patch may fix this.
--8<---------------cut here---------------start------------->8--- --- pkgdcl.lisp.orig 2007-06-08 02:12:43.910573918 +0800 +++ pkgdcl.lisp 2007-06-08 02:01:45.817445668 +0800 @@ -28,7 +28,7 @@ `(defpackage :io.streams (:use #:common-lisp #:cffi #:iolib-utils #:io.encodings) - #+(or sbcl cmu openmcl clisp allegro) + #+(or sbcl cmu openmcl clisp allegro lispworks) (:import-from #+sbcl #:sb-gray #+cmu #:ext #+openmcl #:ccl --8<---------------cut here---------------end--------------->8---
On Fri, Jun 08, 2007 at 02:20:24AM +0800, Chun Tian (binghe) wrote:
Hi, IOLib
The line 31 of iolib/io.streams/pkgdcl.lisp miss a "lispworks" feature. This caused io.streams package cannot import symbols from lispworks' stream package, and cause a error when I use net.smtp-client:
Error: The class #<STANDARD-CLASS IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM 40D0347A5B> cannot be finalized because the following superclass is not defined: #<FORWARD-REFERENCED-CLASS IO.STREAMS:FUNDAMENTAL-BINARY-INPUT-STREAM 40D03479CB>. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
A trivial patch may fix this.
thanks, I've committed your patch :)
Another problem is that LispWorks' stream-read-sequence and stream-write-sequence generic function's lambda list is a little different: no "&optional".
After last patch, now I can got this compile error:
Error: Lambda list (STREAM SEQ &OPTIONAL START END) is not congruent with the lambda list (STREAM SEQUENCE SYSTEM::START SYSTEM::END) of #<STANDARD-GENERIC-FUNCTION STREAM-WRITE-SEQUENCE 41E03239C4>.
After use another trivial patch, I think this problem can be solved:
diff -rN old-iolib/io.streams/gray-stream-methods.lisp new-iolib/io.streams/gray-stream-methods.lisp 139c139 < &optional (start 0) end) ---
#-lispworks &optional #-lispworks (start 0) #+lispworks start end)
288c288 < &optional (start 0) end) ---
#-lispworks &optional #-lispworks (start 0) #+lispworks start end)
But this still cannot solve all problems. There are serious memory access bug in IOlib on 64bit platform, I'm trying to debug and fix it. (both 64bit SBCL and 64bit LispWorks cannot use net.socket)
In LispWorks like this:
CL-USER 4 > (net.smtp-client:send-email "mail.163.org" "binghe@163.org" "binghe@163.org" "test mail from lispworks" "Hi, binghe.")
Error: Signal B [code 0] at 41E093E83F {inside #<Function 1 subfunction of (TOP-LEVEL-FORM 19) 41E093E83C>} rax E093E80C ; rbx 41E093E83C ; rcx 2 ; rdx 41C0293B40 rsp 4040136DF8 ; rbp 4040136E00 ; rdi 6C07C000002AAA ; rsi 0 r8 40000530F9 ; r9 38 ; r10 8 ; r11 4040137101 r12 40502DB583 ; r13 40502DD1FB ; r14 4000049809 ; r15 414001772C 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 5 : 1 > :b Call to ERROR Call to NET.SOCKETS::SOCKADDR-STORAGE->SOCKADDR Call to NET.SOCKETS::MAKE-HOST-FROM-ADDRINFO Call to (METHOD NET.SOCKETS:LOOKUP-HOST (STRING)) Call to NET.SOCKETS:CONVERT-OR-LOOKUP-INET-ADDRESS Call to NET.SOCKETS:MAKE-SOCKET Call to NET.SMTP-CLIENT::MAKE-SMTP-SOCKET Call to NET.SMTP-CLIENT::SEND-SMTP Call to NET.SMTP-CLIENT:SEND-EMAIL Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK)
Have you any 64-bit test platform to identify this? (SBCL has the same problem)
Thanks.
Chun Tian (binghe)
Stelian Ionescu sionescu@common-lisp.net writes:
On Fri, Jun 08, 2007 at 02:20:24AM +0800, Chun Tian (binghe) wrote:
Hi, IOLib
The line 31 of iolib/io.streams/pkgdcl.lisp miss a "lispworks" feature. This caused io.streams package cannot import symbols from lispworks' stream package, and cause a error when I use net.smtp-client:
Error: The class #<STANDARD-CLASS IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM 40D0347A5B> cannot be finalized because the following superclass is not defined: #<FORWARD-REFERENCED-CLASS IO.STREAMS:FUNDAMENTAL-BINARY-INPUT-STREAM 40D03479CB>. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
A trivial patch may fix this.
thanks, I've committed your patch :)
-- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum videtur.") _______________________________________________ iolib-devel mailing list iolib-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel
Hi, dear iolib developer
I think you just test net.smtp-client's code on SBCL 32-bit but not on 64-bit, and LispWorks 64-bit (which I paid $2500 for it in April this year). Let me test #'net.smtp-client:send-email for you:
On SBCL 1.0.6 32-bit, Linux, everything goes well:
CL-USER(2): (net.smtp-client::send-email "mail.163.org" "binghe@163.org" "sa@163.org" "test mail 1" "test from SBCL") NIL
The mail.163.org is a sendmail server, and I can receive this mail, but it's strange that mail.163.org can be resolved to IP address, I cannot find where you use the net.dns-client to do this.
On SBCL 1.0.6 64-bit, Linux, can't resolv host name, must use IP address:
CL-USER(2): (net.smtp-client::send-email "mail.163.org" "binghe@163.org" "sa@163.org" "test mail 2" "test from SBCL") debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD "initial thread" {10025DF051}>: Unhandled memory fault at #x0.
I think this is reasonable, the #'make-smtp-socket function calls #'make-socket, and #'make-socket didn't call functions in net.dns-client to resolv host name, and I tried to direct use mail server's IP address, and success.
CL-USER(2): (net.smtp-client::send-email "192.168.80.2" "binghe@163.org" "sa@163.org" "test mail 3" "test from SBCL") NIL
On LispWorks 64-bit, Linux. (I only have 64-bit version, no 32-bit version), with two patches cannot work with any of above:
NET.SMTP-CLIENT 35 > (net.smtp-client::send-email "192.168.80.2" "binghe@163.org" "sa@163.org" "test mail 4" "test from lispworks") Error: #\2 is not of type INTEGER. 1 (abort) Return to level 0. 2 Return to top loop level 0. Type :b for backtrace, :c <option number> to proceed, or :? for other options
Strange. the read-from-smtp function:
(defun read-from-smtp (sock) (let* ((line (read-line sock)) (response-code (parse-integer line :start 0 :junk-allowed t))) (if (= (char-code (elt line 3)) (char-code #-)) (read-from-smtp sock) (values response-code line))))
It calls (read-line sock) to read the mail server's return code, LispWorks translate this into: (method stream:stream-read-line (stream:fundamental-stream)) which throw out the above error.
LispWorks think the sock is #<active IPv6 stream socket connected to ::ffff:192.168.80.2/25 41900A2C08>, of class 'socket-stream-internet-active. It's class precedence in LispWorks:
NET.SOCKETS:SOCKET-STREAM-INTERNET-ACTIVE NET.SOCKETS:ACTIVE-SOCKET NET.SCOKETS:STREAM-SOCKET NET.SOCKETS:INTERNET-SOCKET NET.SOCKETS:SOCKET IO.STREAMS:DUAL-CHANNEL-SINGLE-FD-MIXIN IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM IO.STREAMS:DUAL-CHANNEL-FD-MIXIN STREAM:FUNDAMENTAL-BINARY-INPUT-STREAM STREAM:FUNDAMENTAL-BINARY-OUTPUT-STREAM STREAM:FUNDAMENTAL-CHARACTER-INPUT-STREAM STREAM:FUNDAMENTAL-INPUT-STREAM STREAM:FUNDAMENTAL-CHARACTER-OUTPUT-STREAM STREAM:FUNDAMENTAL-OUTPUT-STREAM STREAM:FUNDAMENTAL-CHARACTER-STREAM STREAM:FUNDAMENTAL-BINARY-STREAM STREAM:FUNDAMENTAL-STREAM STREAM::STDOBJ-STREAM STREAM STANDARD-OBJECT T
Only STREAM:FUNDAMENTAL-STREAM has a method called stream-read-line, but seems that it cannot read correctly... I don't know if this is a LispWorks bug or IOlib bug, can you give some advice?
Thanks!
Chun Tian (binghe)
On Fri, Jun 08, 2007 at 03:35:21AM +0800, Chun Tian (binghe) wrote:
Another problem is that LispWorks' stream-read-sequence and stream-write-sequence generic function's lambda list is a little different: no "&optional".
After last patch, now I can got this compile error:
Error: Lambda list (STREAM SEQ &OPTIONAL START END) is not congruent with the lambda list (STREAM SEQUENCE SYSTEM::START SYSTEM::END) of #<STANDARD-GENERIC-FUNCTION STREAM-WRITE-SEQUENCE 41E03239C4>.
After use another trivial patch, I think this problem can be solved:
diff -rN old-iolib/io.streams/gray-stream-methods.lisp new-iolib/io.streams/gray-stream-methods.lisp 139c139
< &optional (start 0) end)
#-lispworks &optional #-lispworks (start 0) #+lispworks start end)288c288
< &optional (start 0) end)
#-lispworks &optional #-lispworks (start 0) #+lispworks start end)
I've fixed this now
But this still cannot solve all problems. There are serious memory access bug in IOlib on 64bit platform, I'm trying to debug and fix it. (both 64bit SBCL and 64bit LispWorks cannot use net.socket)
In LispWorks like this:
CL-USER 4 > (net.smtp-client:send-email "mail.163.org" "binghe@163.org" "binghe@163.org" "test mail from lispworks" "Hi, binghe.")
Error: Signal B [code 0] at 41E093E83F {inside #<Function 1 subfunction of (TOP-LEVEL-FORM 19) 41E093E83C>} rax E093E80C ; rbx 41E093E83C ; rcx 2 ; rdx 41C0293B40 rsp 4040136DF8 ; rbp 4040136E00 ; rdi 6C07C000002AAA ; rsi 0 r8 40000530F9 ; r9 38 ; r10 8 ; r11 4040137101 r12 40502DB583 ; r13 40502DD1FB ; r14 4000049809 ; r15 414001772C 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 5 : 1 > :b Call to ERROR Call to NET.SOCKETS::SOCKADDR-STORAGE->SOCKADDR Call to NET.SOCKETS::MAKE-HOST-FROM-ADDRINFO Call to (METHOD NET.SOCKETS:LOOKUP-HOST (STRING)) Call to NET.SOCKETS:CONVERT-OR-LOOKUP-INET-ADDRESS Call to NET.SOCKETS:MAKE-SOCKET Call to NET.SMTP-CLIENT::MAKE-SMTP-SOCKET Call to NET.SMTP-CLIENT::SEND-SMTP Call to NET.SMTP-CLIENT:SEND-EMAIL Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK)
Have you any 64-bit test platform to identify this? (SBCL has the same problem)
unfortunately I haven't
-
binghe.lisp＠gmail.com -
Stelian Ionescu