01:01:39 -!- rme [rme@5696D541.F74FD1E8.699BA7A6.IP] has quit [Quit: rme] 01:01:39 -!- rme [~rme@50.43.142.43] has quit [Quit: rme] 01:46:48 rme [~rme@50.43.142.43] has joined #ccl 02:04:00 consolers [tastelessl@59.92.52.183] has joined #ccl 02:31:31 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 02:32:44 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 03:22:55 bfulgham_ [~brent@cpe-76-173-170-144.socal.res.rr.com] has joined #ccl 04:23:48 arm business model seems to be transmeta 2.0 or transmeta done right 04:24:18 i dont understand the ccl connection, are there a lot of boston investors driving the press and social media? 04:25:08 who funded the arm work? 04:25:10 The connection is that CCL runs on numerous systems with ARM processors. 04:25:27 i bet you'll find some terrible secrets there 04:57:39 gah i couldnt even get started on using ccl today 04:58:18 did you see scrollback on my locks and tables comment rme? if i'm missing something, or being stupid pls do tell 04:59:41 32bit ccl has a 64 bit long-long type, 32bit lw doesnt seem to have it though internet suggests otherwise 05:04:50 I don't know why make-read-write-lock doesn't take a name in the same way that make-lock does. 05:06:35 Also, all ccl's locks are recursive locks---even the ones made with (make-lock). 05:07:17 i dont know why i keep thinking nonrecursive is useful 05:08:12 why is ccl:iterate or ext:iterate named as ITERATE? there is some scheme looping idiom there? 05:13:30 I doubt any CCL implementation code even uses ccl::iterate. I assume it's just left over from days of yore. 05:16:47 ";;; The ultimate iteration macro..." 05:17:33 gls' copy? 05:34:00 -!- consolers [tastelessl@59.92.52.183] has quit [] 06:27:38 -!- rme [rme@5696D541.F74FD1E8.699BA7A6.IP] has quit [Quit: rme] 06:27:38 -!- rme [~rme@50.43.142.43] has quit [Quit: rme] 06:36:10 Wow. That was sort of like a conversation, rather than the usual stream of non-sequitors. I must be in the wrong channel. 06:58:04 -!- bfulgham_ [~brent@cpe-76-173-170-144.socal.res.rr.com] has quit [Quit: bfulgham_] 07:01:31 nonrecursive locks are plenty useful 07:01:39 recursive locks invite sloppy code 07:03:43 I know what you mean. Hanging waiting for a lock that you own is much better than checking to see if you already own it, and the next step after "sloppy code" is "generally useful libraries". After that, street crime. 07:21:19 https://groups.google.com/forum/?hl=en&fromgroups#!msg/comp.programming.threads/tcrTKnfP8HI/me2K7_byNdgJ 07:21:27 the history of recursive mutexes 07:33:27 -!- krrrcks [~krrrcks@krrrcks.de] has left #ccl 08:01:16 I should know better, but here goes ... Suppose that you have a data structure with lots of attributes that need to be accessed/modified from multiple threads. So, you associate a lock with the data structure and make sure that all accessors hold the lock around the access. Everything's simple and tractable, and so far it doesn't matter whether the lock is recursive or not. Your requirements change: whenever field X of the data strucure is 08:01:16 modified, fields Y and Z may also need to change. If the lock is a recursive lock, you can just make the setter for X call the setters for Y and Z, and that continues to be relatively simple and tractable. If the lock isn't a recursive lock, you may have to separate the setters for Y and Z into separate versions or separate layers. Which approach is likely to be more modular/simple/reliable ? What about the availability of recursive loc 08:01:17 ks encourages error-prone code here ? Why are you listening to randoms on Usenet ? 08:03:18 that last question is nothing but inflammatory 08:03:33 Yes, it is. 08:05:28 If you're saying "recursive locks are bad because someone on Usenet says so", I should probably be more patient than I was, sorry. 08:06:46 i think that there is value in recursive locks insofar as they make changing your code a lot easier and sometimes easier to reason about, but i think more often they're an excuse for not really thinking about your locking strategy 08:09:17 and it wasn't a random on usenet, it was an explanation of why POSIX has recursive locks (it was a dare) from the implementer himself 08:09:26 anyway 08:09:32 there's no sense in arguing over the internet 08:09:39 if you're so sure they're wonderful and i'm so sure they're not 08:09:42 i can agree to disagree 08:13:16 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #ccl 08:16:37 segv- [~mb@dslb-088-075-159-058.pools.arcor-ip.net] has joined #ccl 08:19:34 -!- jasom [~aidenn@ip70-191-80-19.sb.sd.cox.net] has quit [*.net *.split] 08:19:42 jasom [~aidenn@ip70-191-80-19.sb.sd.cox.net] has joined #ccl 11:24:10 -!- segv- [~mb@dslb-088-075-159-058.pools.arcor-ip.net] has quit [Quit: segv-] 13:58:25 -!- sellout- [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 14:22:45 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Ping timeout: 244 seconds] 14:27:33 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:34:15 rme [~rme@50.43.142.43] has joined #ccl 14:40:17 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 15:05:13 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 15:12:15 sellout [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has joined #ccl 15:36:09 segv- [~mb@dslb-088-075-159-058.pools.arcor-ip.net] has joined #ccl 15:39:06 -!- rme [rme@5696D541.F74FD1E8.699BA7A6.IP] has quit [Ping timeout] 15:39:10 rme_ [~rme@50.43.152.56] has joined #ccl 15:40:33 -!- rme [~rme@50.43.142.43] has quit [Ping timeout: 255 seconds] 15:40:33 -!- rme_ is now known as rme 16:56:35 milanj [~milanj_@82.117.199.26] has joined #ccl 21:39:35 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: alms_] 21:54:55 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 21:57:49 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 22:20:02 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 22:20:22 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 23:53:50 rme_ [~rme@50.43.174.122] has joined #ccl 23:54:00 -!- rme [rme@B1D340B4.1B3AA978.699BA7A6.IP] has quit [Ping timeout] 23:55:22 -!- rme [~rme@50.43.152.56] has quit [Ping timeout: 250 seconds] 23:55:23 -!- rme_ is now known as rme