From matt.lamari at gmail.com Sat Aug 1 23:46:57 2009 From: matt.lamari at gmail.com (Matt Lamari) Date: Sat, 01 Aug 2009 18:46:57 -0500 Subject: [Bordeaux-threads-devel] Basically, I suck (LW patch) In-Reply-To: <367017C8-07AB-4DFD-BE7A-9F1D931E3852@technomadic.org> References: <367017C8-07AB-4DFD-BE7A-9F1D931E3852@technomadic.org> Message-ID: <4A74D3F1.8070104@gmail.com> I'm still around if anyone needs support on the functions I've added. I don't know where the test suite is, let me know if you need "unit-test-lw-conditions" modified to return instead of print errors. Greg Pfeil wrote: > Matt wrote this nice patch to add condition-variables for LispWorks, > and I never got it merged. I'm gone for the weekend, then switching > jobs next week, then gone in Pittsburgh, then to Europe. I'm afraid if > it's left to me, this will never get in. > > The only thing from my perspective that should change is that the > unit-test-lw-conditions function should be moved into the test suite > (as it should work just fine for any impl) so everyone gets the > benefit. Stelian has a much better > view of the state of BT these days than I do. > > Begin forwarded message: > >> *From: *"Matthew Lamari" > > >> *Date: *3 June 2008 11:55:42 EDT >> *To: *"Greg Pfeil" > >> *Subject: **Re: [Bordeaux-threads-devel] Lispworks additions to >> Bordeaux - where do I submit?* >> >> >> I'm a win32 guy, so I'm not sure what you'd want the file diffed with >> - please find the full file enclosed - I'm guessing the original >> doesn't change very often, and that you could diff it faster than >> explaining to me what to do. >> >> I added a simple unit-test and tried to heavily comment this, as it's >> not trivial like the other call-throughs, and should probably come >> under more scrutiny. >> >> (Unlike the non-implementation-supported literal polling) the >> Lispworks' "process-wait"-based polling seems lightweight enough to >> be usable in the same situations as true condition/notification, with >> negligible cpu hit while waiting (see my comments if interested). >> >> > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel > From fade at deepsky.com Sat Aug 8 18:45:29 2009 From: fade at deepsky.com (Brian O'Reilly) Date: Sat, 8 Aug 2009 14:45:29 -0400 Subject: [Bordeaux-threads-devel] darcs problem... Message-ID: <200908081445.29575.fade@deepsky.com> I originally posted this bug to clbuild-devel, reposting here at David Lichteblau's suggestion. Brian -------------- next part -------------- An embedded message was scrubbed... From: "Brian O'Reilly" Subject: clbuild install fails in bordeaux-threads Date: Sat, 8 Aug 2009 14:05:11 -0400 Size: 1679 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Brian O'Reilly" Subject: Re: [clbuild-devel] clbuild install fails in bordeaux-threads Date: Sat, 8 Aug 2009 14:36:20 -0400 Size: 969 URL: From sionescu at cddr.org Sat Aug 8 19:17:03 2009 From: sionescu at cddr.org (Stelian Ionescu) Date: Sat, 08 Aug 2009 21:17:03 +0200 Subject: [Bordeaux-threads-devel] darcs problem... In-Reply-To: <200908081445.29575.fade@deepsky.com> References: <200908081445.29575.fade@deepsky.com> Message-ID: <1249759023.3227.78.camel@blackhole.cddr.org> On Sat, 2009-08-08 at 14:45 -0400, Brian O'Reilly wrote: > I originally posted this bug to clbuild-devel, reposting here at David > Lichteblau's suggestion. Sorry for that. It's fixed now. -- 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 fade at deepsky.com Sat Aug 8 19:41:22 2009 From: fade at deepsky.com (Brian O'Reilly) Date: Sat, 8 Aug 2009 15:41:22 -0400 Subject: [Bordeaux-threads-devel] darcs problem... In-Reply-To: <1249759023.3227.78.camel@blackhole.cddr.org> References: <200908081445.29575.fade@deepsky.com> <1249759023.3227.78.camel@blackhole.cddr.org> Message-ID: <200908081541.23008.fade@deepsky.com> On August 8, 2009 03:17:03 pm Stelian Ionescu wrote: > On Sat, 2009-08-08 at 14:45 -0400, Brian O'Reilly wrote: > > I originally posted this bug to clbuild-devel, reposting here at David > > Lichteblau's suggestion. > > Sorry for that. It's fixed now. Thanks Stelian. That resolves the issue. Brian From sionescu at cddr.org Mon Aug 10 22:26:39 2009 From: sionescu at cddr.org (Stelian Ionescu) Date: Tue, 11 Aug 2009 00:26:39 +0200 Subject: [Bordeaux-threads-devel] Basically, I suck (LW patch) In-Reply-To: <4A74D3F1.8070104@gmail.com> References: <367017C8-07AB-4DFD-BE7A-9F1D931E3852@technomadic.org> <4A74D3F1.8070104@gmail.com> Message-ID: <1249943199.3699.14.camel@blackhole.cddr.org> On Sat, 2009-08-01 at 18:46 -0500, Matt Lamari wrote: > I'm still around if anyone needs support on the functions I've added. I've cleaned up the code a little(attached as patch against the darcs repository), however, before merging I need you to split condition-wait in at least 3-4 separate functions because it's way too big(two screenfuls here). When you're done, please send a unified diff done against the darcs repository. -- 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: lispworks.patch Type: text/x-patch Size: 9022 bytes Desc: not available URL: -------------- 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 martin at lispworks.com Tue Aug 11 13:50:02 2009 From: martin at lispworks.com (Martin Simmons) Date: Tue, 11 Aug 2009 14:50:02 +0100 Subject: [Bordeaux-threads-devel] Basically, I suck (LW patch) In-Reply-To: <1249943199.3699.14.camel@blackhole.cddr.org> (message from Stelian Ionescu on Tue, 11 Aug 2009 00:26:39 +0200) References: <367017C8-07AB-4DFD-BE7A-9F1D931E3852@technomadic.org> <4A74D3F1.8070104@gmail.com> <1249943199.3699.14.camel@blackhole.cddr.org> Message-ID: <200908111350.n7BDo2nx019250@higson.cam.lispworks.com> >>>>> On Tue, 11 Aug 2009 00:26:39 +0200, Stelian Ionescu said: > > On Sat, 2009-08-01 at 18:46 -0500, Matt Lamari wrote: > > I'm still around if anyone needs support on the functions I've added. > > I've cleaned up the code a little(attached as patch against the darcs > repository), however, before merging I need you to split condition-wait > in at least 3-4 separate functions because it's way too big(two > screenfuls here). When you're done, please send a unified diff done > against the darcs repository. I have some comments on the patch: It would be better to implement thread-alive-p by calling mp:process-alive-p. The relocking of the caller's lock in condition-wait should be inside the unwind-protect cleanup, otherwise you can throw without the lock held. Claiming a lock and doing hash table manipulation inside a mp:process-wait predicate ("Waiting for notification") is not good practice because the predicate is suppose to be a pure function. It should be safe to check the value of wakeup-allowed-to-proceed without the lock and manipulate the hash table after mp:process-wait has returned. Is the prog1 in condition-wait redundant? -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ From matt.lamari at gmail.com Wed Aug 12 22:23:21 2009 From: matt.lamari at gmail.com (Matt Lamari) Date: Wed, 12 Aug 2009 17:23:21 -0500 Subject: [Bordeaux-threads-devel] Basically, I suck (LW patch) In-Reply-To: <200908111350.n7BDo2nx019250@higson.cam.lispworks.com> References: <367017C8-07AB-4DFD-BE7A-9F1D931E3852@technomadic.org> <4A74D3F1.8070104@gmail.com> <1249943199.3699.14.camel@blackhole.cddr.org> <200908111350.n7BDo2nx019250@higson.cam.lispworks.com> Message-ID: <4A8340D9.7070509@gmail.com> Okay - I changed thread-alive-p in the attached file; (but I did not write the original). The hash-table modification has now been shifted out of process-wait. The lock is now returned on an unwind-protect around the entire function's body (in case anything else fails) -. The tlist-affecting functions have been factored out into other functions, and indenting was fixed. Condition-notify's primary failure clause has been cleaned up, and made more correct (it now checks for consumption of the notification as independent of receiving it). Martin - thanks for correcting this with respect to Lispworks, please let me know if anything else looks amiss. Everybody else - look, I'm a windows guy and am not too up on darcs or unix diff files - but my change is a big addition to a file that doesn't see a lot of use. Please diff and add from the attached file. Martin Simmons wrote: >>>>>> On Tue, 11 Aug 2009 00:26:39 +0200, Stelian Ionescu said: >>>>>> >> On Sat, 2009-08-01 at 18:46 -0500, Matt Lamari wrote: >> >>> I'm still around if anyone needs support on the functions I've added. >>> >> I've cleaned up the code a little(attached as patch against the darcs >> repository), however, before merging I need you to split condition-wait >> in at least 3-4 separate functions because it's way too big(two >> screenfuls here). When you're done, please send a unified diff done >> against the darcs repository. >> > > I have some comments on the patch: > > It would be better to implement thread-alive-p by calling mp:process-alive-p. > > The relocking of the caller's lock in condition-wait should be inside the > unwind-protect cleanup, otherwise you can throw without the lock held. > > Claiming a lock and doing hash table manipulation inside a mp:process-wait > predicate ("Waiting for notification") is not good practice because the > predicate is suppose to be a pure function. It should be safe to check the > value of wakeup-allowed-to-proceed without the lock and manipulate the hash > table after mp:process-wait has returned. > > Is the prog1 in condition-wait redundant? > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lispworks.lisp URL: From curtis_schlak at yahoo.com Sun Aug 16 06:52:07 2009 From: curtis_schlak at yahoo.com (Curtis Schlak) Date: Sat, 15 Aug 2009 23:52:07 -0700 (PDT) Subject: [Bordeaux-threads-devel] No Thread Support on Darwin SBCL Message-ID: <711072.38173.qm@web30504.mail.mud.yahoo.com> I've just started developing in LISP, again, after some years away from it. I wanted to try using Hunchentoot which requires the Bordeaux Threads project. After asdf-installing the project, I REPLd (require :bordeaux-threads) and received the following message: WARNING: Either there is no Bordeaux-threads support for your implementation, or your implementation does not support threads therefore some features may not work. Feel free to implement it, or bug one of the maintainers to do so if your lisp supports threads at all. I'm running Mac OS X 10.5, SBCL 1.0.30, and Bordeaux-Threads 0.6.0. Does anyone know why I don't have thread support though it appears to have a "green" status on the project page? Sincerely, Curtis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik at evahjelte.com Sun Aug 16 12:12:27 2009 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 16 Aug 2009 14:12:27 +0200 Subject: [Bordeaux-threads-devel] No Thread Support on Darwin SBCL In-Reply-To: <711072.38173.qm@web30504.mail.mud.yahoo.com> References: <711072.38173.qm@web30504.mail.mud.yahoo.com> Message-ID: <50e8e4f60908160512w56127347w3bbe140ca4923f38@mail.gmail.com> On Sun, Aug 16, 2009 at 8:52 AM, Curtis Schlak wrote: > I'm running Mac OS X 10.5, SBCL 1.0.30, and Bordeaux-Threads 0.6.0. Does > anyone know why I don't have thread support though it appears to have a > "green" status on the project page? Welcome back to Common-Lisp. I am speculating, but sbcl needs to be built with threads enabled in order for threads to work. I am not sure if sbcl threads are supported for OS-X? Are threads-support a requirement for the green color? You can always try openmcl, or sbcl in a virtualbox/vmware/parallels linux (my personal choice). Or maybe do without threads while developing. /Henrik From curtis_schlak at yahoo.com Sun Aug 16 13:03:54 2009 From: curtis_schlak at yahoo.com (Curtis Schlak) Date: Sun, 16 Aug 2009 06:03:54 -0700 (PDT) Subject: [Bordeaux-threads-devel] No Thread Support on Darwin SBCL In-Reply-To: <50e8e4f60908160512w56127347w3bbe140ca4923f38@mail.gmail.com> References: <711072.38173.qm@web30504.mail.mud.yahoo.com> <50e8e4f60908160512w56127347w3bbe140ca4923f38@mail.gmail.com> Message-ID: <318460.29753.qm@web30506.mail.mud.yahoo.com> >> I'm running Mac OS X 10.5, SBCL 1.0.30, and Bordeaux-Threads 0.6.0. Does >> anyone know why I don't have thread support though it appears to have a >> "green" status on the project page? >Welcome back to Common-Lisp. I am speculating, but sbcl needs to be >built with threads enabled in order for threads to work. I am not sure >if sbcl threads are supported for OS-X? Are threads-support a >requirement for the green color? >You can always try openmcl, or sbcl in a virtualbox/vmware/parallels >linux (my personal choice). Or maybe do without threads while >developing. >/Henrik Many thanks, Henrik. What a wonderful idea, one of which I should have thought! That's where I'm going, today. Curtis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fade at deepsky.com Sun Aug 16 18:24:51 2009 From: fade at deepsky.com (Brian O'Reilly) Date: Sun, 16 Aug 2009 14:24:51 -0400 Subject: [Bordeaux-threads-devel] No Thread Support on Darwin SBCL In-Reply-To: <318460.29753.qm@web30506.mail.mud.yahoo.com> References: <711072.38173.qm@web30504.mail.mud.yahoo.com> <50e8e4f60908160512w56127347w3bbe140ca4923f38@mail.gmail.com> <318460.29753.qm@web30506.mail.mud.yahoo.com> Message-ID: <200908161424.51901.fade@deepsky.com> On August 16, 2009 09:03:54 am Curtis Schlak wrote: > >> I'm running Mac OS X 10.5, SBCL 1.0.30, and Bordeaux-Threads 0.6.0. Does > >> > >> anyone know why I don't have thread support though it appears to have a > >> "green" status on the project page? > > > >Welcome back to Common-Lisp. I am speculating, but sbcl needs to be > >built with threads enabled in order for threads to work. I am not sure > >if sbcl threads are supported for OS-X? Are threads-support a > >requirement for the green color? > >You can always try openmcl, or sbcl in a virtualbox/vmware/parallels > >linux (my personal choice). Or maybe do without threads while > >developing. > > > >/Henrik > > Many thanks, Henrik. What a wonderful idea, one of which I should have > thought! That's where I'm going, today. If you're on a PowerPC Macintosh, then sbcl likely will not compile with threads enabled. When I'm working on darwin/ppc, I use Clozure with excellent results. Kind Regards, Brian