I was testing out a port for quicklisp on MKCL, today. The file is attached as revised from the original at http://beta.quicklisp.org/quicklisp.lisp
It was a straightforward patch, focusing mostly on sockets support. Basically I just copied the quicklisp implementation package definition for SBCL, with some minor revisions. I was testing it out, then, when I encountered the following error.
I'm not sure if the error may be a matter of the patched quicklisp - going by the debugger output, I'd like to assume it may be a matter of socket streams.
It looks like quicklisp implements its own HTTP client. Maybe there could be a workaround possible, somewhere in that client code?
I wasn't certain about sending the patch to the quicklisp developers, given this 'feature'. Looking at the debugger output, it looks like the error was in mkcl_safe_fclose failing on a socket-output-stream due to a bad FD. Here's the debugger output and backtrace.
-- Sean
during (quicklisp-quickstart:install)
; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/asdf.lisp%22%3E ; 159.59KB ================================================== 163,424 bytes in 0.77 seconds (206.56KB/sec) ; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/quicklisp.tar%22%3E ; 210.00KB ================================================== 215,040 bytes in 1.03 seconds (203.16KB/sec) ; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/setup.lisp%22%3E ; 4.88KB ================================================== 4,995 bytes in 0.00 seconds (5546.73KB/sec)
Debugger called in: #<thread "Initial" (3737) 00000000010b7d80>.
Filesystem error with pathname: #<output stream "SOCKET-OUTPUT-STREAM">. mkcl_safe_fclose() failed. OS Explanation: (errno == 9) Bad file descriptor.
[...restarts...]
Broken at IHS[73]> C::COMPILER-DEBUGGER. In: #<thread "Initial" (3560) 000000000164fd80>. File: "/home/user/workspaces/workspace_gpcl/3rdparty/mkcl-1.0.1/src/cmp/cmputil.lsp" (Position #4195) QL-UTIL>> :b
Backtrace: IHS[117]> COMPILER-DEBUGGER IHS[116]> lambda, closure generated from compile-file IHS[114]> handle-internal-error IHS[113]> signal IHS[111]> wrapped-method-function IHS[110]> standard-compute-effective-method IHS[109]> compute-effective-method IHS[108]> compute-effective-method, closure generated from nil IHS[107]> compute-make-instance-function IHS[106]> make-instance_nil_class IHS[105]> lambda, closure generated from wrapped-method-function IHS[104]> make-condition IHS[101]> allocate-instance_nil_class IHS[100]> lambda, closure generated from wrapped-method-function IHS[99]> class-prototype_nil_class IHS[98]> lambda, closure generated from wrapped-method-function IHS[97]> compute-make-instance-function IHS[96]> make-instance_nil_class IHS[95]> lambda, closure generated from wrapped-method-function IHS[94]> make-condition IHS[91]> make-c1form* IHS[90]> c1c-inline IHS[89]> c1call-symbol IHS[88]> c1expr IHS[87]> c1stack-push-values IHS[86]> c1call-symbol IHS[85]> c1expr IHS[84]> t1/c1expr IHS[83]> c1progn IHS[82]> c1decl-body IHS[81]> c1let IHS[80]> c1call-symbol IHS[79]> c1expr IHS[78]> c1with-stack IHS[77]> c1call-symbol IHS[76]> c1expr IHS[75]> c1multiple-value-prog1 IHS[74]> c1call-symbol IHS[73]> c1expr IHS[72]> c1unwind-protect IHS[71]> c1call-symbol IHS[70]> c1expr IHS[69]> t1/c1expr IHS[68]> c1progn IHS[67]> c1decl-body IHS[66]> c1let IHS[65]> c1call-symbol IHS[64]> c1expr IHS[63]> c1call-symbol IHS[62]> c1expr IHS[61]> t1/c1expr IHS[60]> c1progn IHS[59]> c1block IHS[58]> c1call-symbol IHS[57]> c1expr IHS[56]> t1/c1expr IHS[55]> c1progn IHS[54]> c1decl-body IHS[53]> c1locally IHS[52]> c1call-symbol IHS[51]> c1expr IHS[50]> c1lambda-expr IHS[49]> c1compile-function IHS[48]> c1function IHS[47]> c1call-symbol IHS[46]> c1expr IHS[45]> c1fset IHS[44]> c1call-symbol IHS[43]> c1expr IHS[42]> t1ordinary IHS[41]> t1expr* IHS[40]> t1/c1expr IHS[39]> c1progn IHS[38]> c1eval-when IHS[37]> t1expr* IHS[36]> t1/c1expr IHS[35]> c1progn IHS[34]> t1expr* IHS[33]> t1expr* IHS[32]> t1expr IHS[31]> lambda, closure generated from compile-file IHS[30]> do-compilation-unit IHS[29]> compile-file IHS[28]> compile-file* IHS[27]> perform_nil_compile-op_cl-source-file IHS[26]> lambda, closure generated from wrapped-method-function IHS[25]> lambda, closure generated from standard-main-effective-method IHS[24]> perform-with-restarts_nil_t_t IHS[23]> lambda, closure generated from wrapped-method-function IHS[22]> perform-with-restarts_nil_compile-op_cl-source-file, closure generated from nil IHS[21]> lambda, closure generated from wrapped-method-function IHS[20]> lambda, closure generated from combine-method-functions IHS[19]> lambda, closure generated from operate_nil_t_t IHS[18]> do-compilation-unit IHS[17]> do-compilation-unit IHS[16]> operate_nil_t_t IHS[15]> lambda, closure generated from wrapped-method-function IHS[14]> lambda, closure generated from standard-main-effective-method IHS[13]> oos IHS[12]> bytecode [Evaluation of: (let ((*compile-print* nil) (*compile-verbose* nil) (*load-verbose* nil) (*load-print* nil)) (asdf:oos 'asdf:load-op "quicklisp" :verbose nil))] IHS[11]> initial-install IHS[10]> lambda IHS[9]> lambda, closure generated from wrapped-method-function IHS[8]> call-with-quiet-compilation IHS[7]> install IHS[6]> bytecode [Evaluation of: (quicklisp-quickstart:install)] IHS[5]> lambda, closure generated from interactive-loop
Hello Sean,
On Tue, Jul 17, 2012 at 9:23 PM, Sean Champ spchamp@me.com wrote:
I was testing out a port for quicklisp on MKCL, today. The file is attached as revised from the original at http://beta.quicklisp.org/quicklisp.lisp
I have long promised to do an "official" port of quicklisp for MKCL but it is still near the top of my work stack, just below "pushing MKCL 1.1.0 out the door" that I am currently hard at work on...
It was a straightforward patch, focusing mostly on sockets support. Basically I just copied the quicklisp implementation package definition for SBCL, with some minor revisions. I was testing it out, then, when I encountered the following error.
I'm not sure if the error may be a matter of the patched quicklisp - going by the debugger output, I'd like to assume it may be a matter of socket streams.
It looks like quicklisp implements its own HTTP client. Maybe there could be a workaround possible, somewhere in that client code?
I wasn't certain about sending the patch to the quicklisp developers, given this 'feature'. Looking at the debugger output, it looks like the error was in mkcl_safe_fclose failing on a socket-output-stream due to a bad FD. Here's the debugger output and backtrace.
This looks interesting to look at. Please, give me 24 to 48 hours to properly investigate it. I don't think you should escalate this to the quicklisp people yet, it really looks like a MKCL private matter. BTW, was there a reason for trying this with MKCL 1.0.1 rather than MKCL 1.1.0 RC1? That would in fact be my first test since there was some move on the socket side between the two.
Thanks,
Jean-Claude
On Tue, Jul 17, 2012 at 9:23 PM, Sean Champ spchamp@me.com wrote:
I was testing out a port for quicklisp on MKCL, today. The file is attached as revised from the original at http://beta.quicklisp.org/quicklisp.lisp
Here is my update on the "Quicklisp on MKCL" situation.
The file you attached to your original message worked more or less as is on MKCL 1.1.0 RC2 but that piece provides only a minimal bootstrap loader ("quicklisp-quickstart" it seems to be called) that limits itself to fetching the real full client code of Quicklisp in source form. That second larger version of the Quicklisp client code contains quite a number of platform specific portions (definterface and :implementation pairs) that needed MKCL versions somewhat in the style of what you did for the bootstrap loader but a bit more extensive.
That second level port done, I have been able to get quicklisp up and running and received a reasonably good looking reply to a (ql:system-apropos "vecto") query.
That is as far as I pushed it at this moment.
So I guess that I should now send the MKCL ported client code to the quicklisp maintainer (Zach Beane) for him to validate and eventually merge with the official quicklisp code base. But that may take some time to happen so I could in the meantime send you a tar file of the modified full client code if you need it. Do you?
Cheers,
Jean-Claude Beaudoin