From binghe.lisp at gmail.com Mon Jan 4 10:58:35 2010 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Mon, 4 Jan 2010 18:58:35 +0800 Subject: [Bordeaux-threads-devel] MCL patch Message-ID: <6926390E-ABB0-4183-8AAB-9E517311BED1@gmail.com> Hi, Bordeaux team I found two typos in MCL support. Without them, your package cannot be compiled correctly in MCL (test with RMCL 5.2.1). Please check and merge it. Regards, Chun Tian (binghe) -------------- next part -------------- A non-text attachment was scrubbed... Name: bt-mcl.patch Type: application/octet-stream Size: 216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2603 bytes Desc: not available URL: From liron.greenstein at gmail.com Sat Jan 9 02:45:05 2010 From: liron.greenstein at gmail.com (Liron Greenstein) Date: Fri, 8 Jan 2010 21:45:05 -0500 Subject: [Bordeaux-threads-devel] asdf installation Message-ID: <34faea111001081845n5bb67cdbl1caf59b8fe02bae1@mail.gmail.com> Hey, This is pretty dumb but I'm trying to install hunchentoot via asdf, which depends on bordeaux-threads, and when this installer goes to download bordeaux-threads, it's looking for this .asc PGP signature file at http://common-lisp.net/project/bordeaux-threads/releases/bordeaux-threads.tar.gz.ascand failing (you can see why, there's a version number in that file now). I don't know enough about how asdf works to fix this, but could you symlink the file it looks for to the devhead one? Should be fine to do this since it's already blindly downloading bordeaux-threads.tgz anyway so it'll always be devhead. Thanks, Liron -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at softwarematters.org Sun Jan 10 00:58:01 2010 From: patrick at softwarematters.org (Patrick May) Date: Sat, 9 Jan 2010 19:58:01 -0500 Subject: [Bordeaux-threads-devel] asdf installation In-Reply-To: <34faea111001081845n5bb67cdbl1caf59b8fe02bae1@mail.gmail.com> References: <34faea111001081845n5bb67cdbl1caf59b8fe02bae1@mail.gmail.com> Message-ID: On Jan 8, 2010, at 9:45 PM, Liron Greenstein wrote: > Hey, > > This is pretty dumb but I'm trying to install hunchentoot via asdf, which depends on bordeaux-threads, and when this installer goes to download bordeaux-threads, it's looking for this .asc PGP signature file at http://common-lisp.net/project/bordeaux-threads/releases/bordeaux-threads.tar.gz.asc and failing (you can see why, there's a version number in that file now). I don't know enough about how asdf works to fix this, but could you symlink the file it looks for to the devhead one? Should be fine to do this since it's already blindly downloading bordeaux-threads.tgz anyway so it'll always be devhead. I had trouble getting all of the Hunchentoot dependencies correct until someone on the TBNL mail list recommended using the Subversion repository at http://bknr.net/svn/ediware. This has a working configuration in one fell swoop. Regards, Patrick ---- patrick at softwarematters.org Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sionescu at cddr.org Wed Jan 20 21:55:31 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Wed, 20 Jan 2010 22:55:31 +0100 Subject: [Bordeaux-threads-devel] MCL patch In-Reply-To: <6926390E-ABB0-4183-8AAB-9E517311BED1@gmail.com> References: <6926390E-ABB0-4183-8AAB-9E517311BED1@gmail.com> Message-ID: <1264024531.15832.39.camel@blackhole.cddr.org> On Mon, 2010-01-04 at 18:58 +0800, Chun Tian (binghe) wrote: > Hi, Bordeaux team > > I found two typos in MCL support. Without them, your package cannot be compiled correctly in MCL (test with RMCL 5.2.1). > > Please check and merge it. Thanks, patch merged. In general, try sending only unified patches (obtained with diff -u or darcs diff -u). -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From yarek.kowalik at gmail.com Sat Jan 23 02:00:07 2010 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Fri, 22 Jan 2010 18:00:07 -0800 Subject: [Bordeaux-threads-devel] Having trougle with SBCL 1.0.20 on x86 Message-ID: I get this error when compiling bordeaux-threads, has anyone seen this? Any workarounds? Thanks!! Yarek The value # is not of type SB-KERNEL:CLASSOID. [Condition of type TYPE-ERROR] Restarts: 0: [TRY-RECOMPILING] Try recompiling impl-sbcl 1: [RETRY] Retry performing # on #. 2: [ACCEPT] Continue, treating # on # as having been successful. 3: [RETRY] Retry SLIME REPL evaluation request. 4: [ABORT] Return to SLIME's top level. 5: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (SB-KERNEL:UNDEFINE-STRUCTURE #) 1: (SB-IMPL::%COMPILER-DEFTYPE TIMEOUT # NIL) 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV ..) 3: ((FLET SB-C::DEFAULT-PROCESSOR) ..) 4: (SB-C::PROCESS-TOPLEVEL-FORM ..) 5: (SB-C::PROCESS-TOPLEVEL-PROGN ..) 6: (SB-C::PROCESS-TOPLEVEL-FORM (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (SB-IMPL::%COMPILER-DEFTYPE 'TIMEOUT (LAMBDA # #))) (SB-C::ORIGINAL-SOURCE-START 0 16) NIL) 7: ((FLET SB-C::DEFAULT-PROCESSOR) (DEFTYPE TIMEOUT () 'SB-EXT:TIMEOUT)) 8: (SB-C::PROCESS-TOPLEVEL-FORM (DEFTYPE TIMEOUT () 'SB-EXT:TIMEOUT) (SB-C::ORIGINAL-SOURCE-START 0 16) NIL) 9: (SB-C::SUB-SUB-COMPILE-FILE #) 10: ((LAMBDA ())) 11: (SB-C::%WITH-COMPILATION-UNIT #)[:EXTERNAL] 12: (SB-C::SUB-COMPILE-FILE #) 13: (COMPILE-FILE #P"/home/yarek/.sbcl/site/bordeaux-threads_darcs/src/impl-sbcl.lisp")[:EXTERNAL] 14: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) # # # #) 15: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..) 16: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..) 17: ((LAMBDA ())) 18: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 19: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]508)) 20: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..) Locals: SB-DEBUG::ARG-0 = # SB-DEBUG::ARG-1 = #S(SB-THREAD:MUTEX ..) 21: (SB-C::%WITH-COMPILATION-UNIT #)[:EXTERNAL] 22: (ASDF:OPERATE ASDF:LOAD-OP :FASHION-ORIGAMI)[:EXTERNAL] 23: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS 'ASDF:LOAD-OP :FASHION-ORIGAMI) #) 24: (SWANK::EVAL-REGION "(asdf:oos 'asdf:load-op :fashion-origami)\n") 25: ((LAMBDA ())) 26: (SWANK::TRACK-PACKAGE #) 27: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #) 28: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) 29: (SWANK::REPL-EVAL "(asdf:oos 'asdf:load-op :fashion-origami)\n") 30: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load-op :fashion-origami)\n") #) 31: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load-op :fashion-origami)\n") "FASHION-ORIGAMI" 439) 32: (SWANK::PROCESS-REQUESTS NIL) 33: ((LAMBDA ())) 34: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) # #) 35: (SWANK::CALL-WITH-REDIRECTED-IO # #) 36: (SWANK::CALL-WITH-CONNECTION # #) 37: (SWANK::HANDLE-REQUESTS # NIL) 38: (SWANK::CALL-WITH-BINDINGS NIL #) 39: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 40: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 41: (SB-THREAD::CALL-WITH-MUTEX ..) 42: ((LAMBDA ())) 43: ("foreign function: call_into_lisp") 44: ("foreign function: funcall0") 45: ("foreign function: new_thread_trampoline") 46: ("foreign function: #xB7FB880E") -------------- next part -------------- An HTML attachment was scrubbed... URL: From yarek.kowalik at gmail.com Sat Jan 23 09:05:28 2010 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Sat, 23 Jan 2010 01:05:28 -0800 Subject: [Bordeaux-threads-devel] Having trougle with SBCL 1.0.20 on x86 In-Reply-To: References: Message-ID: Quick questions: what versions of SBCL (32 and 64 bit) are suported on the current head branch? Yarek On Fri, Jan 22, 2010 at 6:00 PM, Yarek Kowalik wrote: > I get this error when compiling bordeaux-threads, has anyone seen this? Any > workarounds? > > Thanks!! > > Yarek > > The value # > is not of type > SB-KERNEL:CLASSOID. > [Condition of type TYPE-ERROR] > > Restarts: > 0: [TRY-RECOMPILING] Try recompiling impl-sbcl > 1: [RETRY] Retry performing # on > #. > 2: [ACCEPT] Continue, treating # on > # as having been successful. > 3: [RETRY] Retry SLIME REPL evaluation request. > 4: [ABORT] Return to SLIME's top level. > 5: [TERMINATE-THREAD] Terminate this thread (# RUNNING {B0580D1}>) > > Backtrace: > 0: (SB-KERNEL:UNDEFINE-STRUCTURE # CONDITION>) > 1: (SB-IMPL::%COMPILER-DEFTYPE TIMEOUT # > NIL) > 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV ..) > 3: ((FLET SB-C::DEFAULT-PROCESSOR) ..) > 4: (SB-C::PROCESS-TOPLEVEL-FORM ..) > 5: (SB-C::PROCESS-TOPLEVEL-PROGN ..) > 6: (SB-C::PROCESS-TOPLEVEL-FORM (EVAL-WHEN (:COMPILE-TOPLEVEL > :LOAD-TOPLEVEL :EXECUTE) (SB-IMPL::%COMPILER-DEFTYPE 'TIMEOUT (LAMBDA # #))) > (SB-C::ORIGINAL-SOURCE-START 0 16) NIL) > 7: ((FLET SB-C::DEFAULT-PROCESSOR) (DEFTYPE TIMEOUT () 'SB-EXT:TIMEOUT)) > 8: (SB-C::PROCESS-TOPLEVEL-FORM (DEFTYPE TIMEOUT () 'SB-EXT:TIMEOUT) > (SB-C::ORIGINAL-SOURCE-START 0 16) NIL) > 9: (SB-C::SUB-SUB-COMPILE-FILE #) > 10: ((LAMBDA ())) > 11: (SB-C::%WITH-COMPILATION-UNIT # {BEA6FA5}>)[:EXTERNAL] > 12: (SB-C::SUB-COMPILE-FILE #) > 13: (COMPILE-FILE > #P"/home/yarek/.sbcl/site/bordeaux-threads_darcs/src/impl-sbcl.lisp")[:EXTERNAL] > 14: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP > ASDF:CL-SOURCE-FILE)) # # > # # {C72B119}>) > 15: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. > SB-PCL::.ARG1.)) ..) > 16: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP > ASDF:CL-SOURCE-FILE)) ..) > 17: ((LAMBDA ())) > 18: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) > 19: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]508)) > 20: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..) > Locals: > SB-DEBUG::ARG-0 = # SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {B68969AD}> > SB-DEBUG::ARG-1 = #S(SB-THREAD:MUTEX ..) > 21: (SB-C::%WITH-COMPILATION-UNIT # {BE9601D}>)[:EXTERNAL] > 22: (ASDF:OPERATE ASDF:LOAD-OP :FASHION-ORIGAMI)[:EXTERNAL] > 23: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS 'ASDF:LOAD-OP > :FASHION-ORIGAMI) #) > 24: (SWANK::EVAL-REGION "(asdf:oos 'asdf:load-op :fashion-origami)\n") > 25: ((LAMBDA ())) > 26: (SWANK::TRACK-PACKAGE #) > 27: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." > #) > 28: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #) > 29: (SWANK::REPL-EVAL "(asdf:oos 'asdf:load-op :fashion-origami)\n") > 30: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(asdf:oos > 'asdf:load-op :fashion-origami)\n") #) > 31: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(asdf:oos 'asdf:load-op > :fashion-origami)\n") "FASHION-ORIGAMI" 439) > 32: (SWANK::PROCESS-REQUESTS NIL) > 33: ((LAMBDA ())) > 34: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) # SWANK:SWANK-DEBUGGER-HOOK> #) > 35: (SWANK::CALL-WITH-REDIRECTED-IO # > #) > 36: (SWANK::CALL-WITH-CONNECTION # # (LAMBDA #) {B05A0BD}>) > 37: (SWANK::HANDLE-REQUESTS # NIL) > 38: (SWANK::CALL-WITH-BINDINGS NIL #) > 39: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) > 40: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) > 41: (SB-THREAD::CALL-WITH-MUTEX ..) > 42: ((LAMBDA ())) > 43: ("foreign function: call_into_lisp") > 44: ("foreign function: funcall0") > 45: ("foreign function: new_thread_trampoline") > 46: ("foreign function: #xB7FB880E") > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sionescu at cddr.org Sat Jan 23 16:17:32 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 23 Jan 2010 17:17:32 +0100 Subject: [Bordeaux-threads-devel] Having trougle with SBCL 1.0.20 on x86 In-Reply-To: References: Message-ID: <1264263452.6358.27.camel@blackhole.cddr.org> On Fri, 2010-01-22 at 18:00 -0800, Yarek Kowalik wrote: > I get this error when compiling bordeaux-threads, has anyone seen > this? Any workarounds? This looks like a compiler bug. What version of bordeaux-threads are you using ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sionescu at cddr.org Sat Jan 23 16:18:27 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 23 Jan 2010 17:18:27 +0100 Subject: [Bordeaux-threads-devel] Having trougle with SBCL 1.0.20 on x86 In-Reply-To: References: Message-ID: <1264263507.6358.28.camel@blackhole.cddr.org> On Sat, 2010-01-23 at 01:05 -0800, Yarek Kowalik wrote: > Quick questions: what versions of SBCL (32 and 64 bit) are suported on > the current head branch? Should work with any release since 1.0.11, which added SB-THREAD:THREAD-YIELD. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From yarek.kowalik at gmail.com Sat Jan 23 17:52:49 2010 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Sat, 23 Jan 2010 09:52:49 -0800 Subject: [Bordeaux-threads-devel] Having trougle with SBCL 1.0.20 on x86 In-Reply-To: <1264263452.6358.27.camel@blackhole.cddr.org> References: <1264263452.6358.27.camel@blackhole.cddr.org> Message-ID: <8A9A2DB3-37CC-44B4-9A37-E1632B404504@gmail.com> Checked out the latest from the Dev repository. Yarek Sent from my mobile On Jan 23, 2010, at 8:17 AM, Stelian Ionescu wrote: > On Fri, 2010-01-22 at 18:00 -0800, Yarek Kowalik wrote: >> I get this error when compiling bordeaux-threads, has anyone seen >> this? Any workarounds? > > This looks like a compiler bug. What version of bordeaux-threads are > you > using ? > > -- > Stelian Ionescu a.k.a. fe[nl]ix > Quidquid latine dictum sit, altum videtur. > http://common-lisp.net/project/iolib > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel