From matt.lamari at gmail.com Thu Feb 4 04:38:10 2010 From: matt.lamari at gmail.com (Matt Lamari) Date: Wed, 03 Feb 2010 22:38:10 -0600 Subject: [Bordeaux-threads-devel] Bordeaux-threads 0.7->Lispworks support (4, 5 and 6) patch Message-ID: <4B6A4F32.1030804@gmail.com> Diff is from published 0.7 to a working copy. Lispworks pre-6.0 and 6.0 tested (I tested on 5.1 and 6.0) Added the rest of the API for lispworks. make-recursive-lock and make-lock are now differentiated in LW6 The real differences come in condition support. Pre-6.0 (4 and 5) Lispworks has condition variables emulated via lispworks' old polling lock. Lispworks 6+ condition code just calls through to the new 6.0 condition constructs. Both pass the unit-test, and both notify only a single thread. Please add this to the bordeaux-threads tip and publish. If the format or contents are an impediment please advise so I can correct. Thanks, Matt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bordeaux-threads.asd.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: impl-lispworks.lisp.diff URL: From martin at lispworks.com Fri Feb 5 23:15:18 2010 From: martin at lispworks.com (Martin Simmons) Date: Fri, 5 Feb 2010 23:15:18 GMT Subject: [Bordeaux-threads-devel] Bordeaux-threads 0.7->Lispworks support (4, 5 and 6) patch In-Reply-To: <4B6A4F32.1030804@gmail.com> (message from Matt Lamari on Wed, 03 Feb 2010 22:38:10 -0600) References: <4B6A4F32.1030804@gmail.com> Message-ID: <201002052315.o15NFIYD023737@higson.cam.lispworks.com> I think this is a great improvement on the default condition variable implementation. Please can someone with commit access apply this patch? -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ >>>>> On Wed, 03 Feb 2010 22:38:10 -0600, Matt Lamari said: > > Diff is from published 0.7 to a working copy. > > Lispworks pre-6.0 and 6.0 tested (I tested on 5.1 and 6.0) > > Added the rest of the API for lispworks. > > make-recursive-lock and make-lock are now differentiated in LW6 > > The real differences come in condition support. > > Pre-6.0 (4 and 5) Lispworks has condition variables emulated via > lispworks' old polling lock. > > Lispworks 6+ condition code just calls through to the new 6.0 condition > constructs. > > Both pass the unit-test, and both notify only a single thread. > > > Please add this to the bordeaux-threads tip and publish. > > If the format or contents are an impediment please advise so I can correct. > > > Thanks, > Matt > > > From sionescu at cddr.org Sat Feb 6 01:18:02 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 06 Feb 2010 02:18:02 +0100 Subject: [Bordeaux-threads-devel] Bordeaux-threads 0.7->Lispworks support (4, 5 and 6) patch In-Reply-To: <4B6A4F32.1030804@gmail.com> References: <4B6A4F32.1030804@gmail.com> Message-ID: <1265419082.14472.26.camel@blackhole.cddr.org> On Wed, 2010-02-03 at 22:38 -0600, Matt Lamari wrote: > Diff is from published 0.7 to a working copy. > > Lispworks pre-6.0 and 6.0 tested (I tested on 5.1 and 6.0) > > Added the rest of the API for lispworks. > > make-recursive-lock and make-lock are now differentiated in LW6 > > The real differences come in condition support. > > Pre-6.0 (4 and 5) Lispworks has condition variables emulated via > lispworks' old polling lock. > > Lispworks 6+ condition code just calls through to the new 6.0 condition > constructs. > > Both pass the unit-test, and both notify only a single thread. > > > Please add this to the bordeaux-threads tip and publish. > > If the format or contents are an impediment please advise so I can correct. Sorry, I had already applied your condition-variable implementation a few weeks ago but forgot to push the changes :) The recursive locks are also in. I've also added a function START-MULTIPROCESSING, implemented on Allegro, CMUCL and Lispworks. -- 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 Feb 6 01:19:42 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 06 Feb 2010 02:19:42 +0100 Subject: [Bordeaux-threads-devel] Bordeaux-threads 0.7->Lispworks support (4, 5 and 6) patch In-Reply-To: <201002052315.o15NFIYD023737@higson.cam.lispworks.com> References: <4B6A4F32.1030804@gmail.com> <201002052315.o15NFIYD023737@higson.cam.lispworks.com> Message-ID: <1265419182.14472.28.camel@blackhole.cddr.org> On Fri, 2010-02-05 at 23:15 +0000, Martin Simmons wrote: > I think this is a great improvement on the default condition variable > implementation. > > Please can someone with commit access apply this patch? I've committed that patch. By the way, is it ever necessary to call MP:INITIALIZE-MULTIPROCESSING explicitly ? -- 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 attila.lendvai at gmail.com Mon Feb 8 18:30:26 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 8 Feb 2010 19:30:26 +0100 Subject: [Bordeaux-threads-devel] bug around unimplemented functions Message-ID: i've told this to Stelian on IRC, just making sure it gets the record: (bt:acquire-recursive-lock nil) simply returns T on sbcl. a quick glance suggests that unimplemented functions are simply noop (instead of an error i guess). -- attila From attila.lendvai at gmail.com Mon Feb 8 19:14:57 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 8 Feb 2010 20:14:57 +0100 Subject: [Bordeaux-threads-devel] the way sb-thread:get-mutex is called Message-ID: ...and while we are at acquire-lock, the docstring of sb-thread:get-mutex says that without-interrupts is necessary to be around the call to sb-thread:get-mutex. -- attila From martin at lispworks.com Wed Feb 10 19:41:20 2010 From: martin at lispworks.com (Martin Simmons) Date: Wed, 10 Feb 2010 19:41:20 GMT Subject: [Bordeaux-threads-devel] Bordeaux-threads 0.7->Lispworks support (4, 5 and 6) patch In-Reply-To: <1265419182.14472.28.camel@blackhole.cddr.org> (message from Stelian Ionescu on Sat, 06 Feb 2010 02:19:42 +0100) References: <4B6A4F32.1030804@gmail.com> <201002052315.o15NFIYD023737@higson.cam.lispworks.com> <1265419182.14472.28.camel@blackhole.cddr.org> Message-ID: <201002101941.o1AJfK1O002459@higson.cam.lispworks.com> >>>>> On Sat, 06 Feb 2010 02:19:42 +0100, Stelian Ionescu said: > > On Fri, 2010-02-05 at 23:15 +0000, Martin Simmons wrote: > > I think this is a great improvement on the default condition variable > > implementation. > > > > Please can someone with commit access apply this patch? > > I've committed that patch. Thanks! > By the way, is it ever necessary to call MP:INITIALIZE-MULTIPROCESSING > explicitly ? Yes, if you have an image saved with multiprocessing switched off. That must be a non-GUI image saved with :ENVIRONMENT NIL (and not :MULTIPROCESSING T). -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ From james.anderson at setf.de Sun Feb 14 16:03:04 2010 From: james.anderson at setf.de (james anderson) Date: Sun, 14 Feb 2010 17:03:04 +0100 Subject: [Bordeaux-threads-devel] changes for mcl@5.2 (2) Message-ID: good afternoon; please find enclosed below a diff relative to patch 162 to improve support for mcl-5.2. apologies for missing the symbol problem in the 0.6 -> 0.7 change + define acquire-lock and release-lock * add dynamic-extent declarations for mcl and ccl * ccl::process is not external ? why repeat the deftype per implementation rather than use satisfies? --- diff -rN old-bordeaux-threads/src/bordeaux-threads.lisp new-bordeaux- threads/src/bordeaux-threads.lisp 110a111,113 > > > (deftype bt:thread () '(satisfies bt:threadp)) diff -rN old-bordeaux-threads/src/impl-clozure.lisp new-bordeaux- threads/src/impl-clozure.lisp 85a86 > (declare (dynamic-extent args)) diff -rN old-bordeaux-threads/src/impl-mcl.lisp new-bordeaux-threads/ src/impl-mcl.lisp 12c12 < 'ccl:process) --- > 'ccl::process) 32a33,43 > (defun acquire-lock (lock &optional (wait-p t)) > (if wait-p > (ccl:process-lock lock ccl:*current-process*) > ;; this is broken, but it's better than a no-op > (ccl:without-interrupts > (when (null (ccl::lock.value lock)) > (ccl:process-lock lock ccl:*current-process*))))) > > (defun release-lock (lock) > (ccl:process-unlock lock)) > 44a56 > (declare (dynamic-extent args)) From james.anderson at setf.de Sun Feb 14 15:45:55 2010 From: james.anderson at setf.de (james anderson) Date: Sun, 14 Feb 2010 16:45:55 +0100 Subject: [Bordeaux-threads-devel] changes for mcl@5.2 Message-ID: <97783365-7E83-4765-A967-E82C862D0630@setf.de> good afternoon; please find enclosed below a diff relative to patch 162 to improve support for mcl-5.2 + define acquire-lock and release-lock * add dynamic-extent declarations for mcl and ccl ? why repeat the deftype per implementation rather than use satisfies? --- diff -rN old-bordeaux-threads/src/bordeaux-threads.lisp new-bordeaux- threads/src/bordeaux-threads.lisp 110a111,113 > > > (deftype bt:thread () '(satisfies bt:threadp)) diff -rN old-bordeaux-threads/src/impl-clozure.lisp new-bordeaux- threads/src/impl-clozure.lisp 85a86 > (declare (dynamic-extent args)) diff -rN old-bordeaux-threads/src/impl-mcl.lisp new-bordeaux-threads/ src/impl-mcl.lisp 32a33,43 > (defun acquire-lock (lock &optional (wait-p t)) > (if wait-p > (ccl:process-lock lock ccl:*current-process*) > ;; this is broken, but it's better than a no-op > (ccl:without-interrupts > (when (null (ccl::lock.value lock)) > (ccl:process-lock lock ccl:*current-process*))))) > > (defun release-lock (lock) > (ccl:process-unlock lock)) > 44a56 > (declare (dynamic-extent args)) From sionescu at cddr.org Sun Feb 14 16:34:45 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sun, 14 Feb 2010 17:34:45 +0100 Subject: [Bordeaux-threads-devel] changes for mcl@5.2 In-Reply-To: <97783365-7E83-4765-A967-E82C862D0630@setf.de> References: <97783365-7E83-4765-A967-E82C862D0630@setf.de> Message-ID: <1266165285.7646.12.camel@blackhole.cddr.org> On Sun, 2010-02-14 at 16:45 +0100, james anderson wrote: > good afternoon; > > please find enclosed below a diff relative to patch 162 to improve > support for mcl-5.2 Please send a unified diff(obtained with darcs diff -u) > + define acquire-lock and release-lock > * add dynamic-extent declarations for mcl and ccl > ? why repeat the deftype per implementation rather than use satisfies? Because it should lead to slightly smaller code when used in a TYPECASE. -- 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 james.anderson at setf.de Sun Feb 14 17:01:57 2010 From: james.anderson at setf.de (james anderson) Date: Sun, 14 Feb 2010 18:01:57 +0100 Subject: [Bordeaux-threads-devel] changes for mcl@5.2 (3) Message-ID: A non-text attachment was scrubbed... Name: bt-20100214.diff Type: application/octet-stream Size: 2132 bytes Desc: not available URL: From sionescu at cddr.org Sun Feb 14 20:38:20 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Sun, 14 Feb 2010 21:38:20 +0100 Subject: [Bordeaux-threads-devel] changes for mcl@5.2 (3) In-Reply-To: References: Message-ID: <1266179900.10644.1.camel@blackhole.cddr.org> Thanks, I've committed the changes, except the DEFTYPE. -- 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 james.anderson at setf.de Mon Feb 15 12:44:15 2010 From: james.anderson at setf.de (james anderson) Date: Mon, 15 Feb 2010 13:44:15 +0100 Subject: [Bordeaux-threads-devel] license verification for inclusion in de.setf.amqp Message-ID: <937F34B0-FA73-45AF-A8BF-786115B252E7@setf.de> good morning; i have released a library, de.setf.amqp[1], which incorporates work of yours. the combined license is the gnu affero. please see the readme[2] for more information. this is to verify the contact information for your library's license. yours is the last respective contact. in some cases, there was none and i have substituted a mailing list as an immediate place-holder, even though, as subscription-only lists, it is not well suited to this purpose. please advise me, should an alternative contact be available. [1] : http://github.com/lisp/de.setf.amqp [2] : http://github.com/lisp/de.setf.amqp/blob/master/README.md