00:31:40 -!- sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 00:34:11 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 00:34:52 -!- sellout is now known as Guest69901 00:45:34 -!- Guest69901 [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds] 01:13:54 -!- orivej [~orivej@91.79.228.117] has quit [Ping timeout: 245 seconds] 01:39:29 -!- hargettp [~hargettp@pool-71-174-142-225.bstnma.east.verizon.net] has quit [Quit: Linkinus - http://linkinus.com] 02:36:57 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 02:42:15 -!- sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 02:42:43 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 02:52:25 -!- rme [rme@1A9DFE36.220E3728.699BA7A6.IP] has quit [Quit: rme] 02:52:26 -!- rme [~rme@50.43.134.71] has quit [Quit: rme] 03:27:13 -!- sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 03:31:14 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 03:47:45 -!- sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 04:07:40 -!- clop [~jared@moat3.centtech.com] has quit [Ping timeout: 260 seconds] 04:29:41 clop [~jared@moat3.centtech.com] has joined #ccl 05:20:18 -!- gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has quit [Read error: Connection reset by peer] 06:58:57 rme [~rme@50.43.155.6] has joined #ccl 07:01:07 -!- rme [~rme@50.43.155.6] has quit [Client Quit] 07:20:43 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Quit: Leaving...] 07:22:54 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 07:24:57 billstcalir [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 07:27:03 jdz [~jdz@193.206.22.97] has joined #ccl 07:27:23 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Ping timeout: 252 seconds] 07:34:00 -!- billstcalir [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has quit [Quit: Linkinus - http://linkinus.com] 07:34:35 billstclair [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 07:34:35 -!- billstclair [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has quit [Changing host] 07:34:35 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 08:02:01 tfb [~tfb@80.238.0.145] has joined #ccl 08:03:56 -!- tfb [~tfb@80.238.0.145] has quit [Client Quit] 08:07:26 tfb [~tfb@80.238.0.145] has joined #ccl 08:14:51 -!- tfb [~tfb@80.238.0.145] has quit [Quit: gone] 08:16:51 tfb [~tfb@80.238.0.145] has joined #ccl 08:18:01 -!- tfb [~tfb@80.238.0.145] has quit [Client Quit] 08:19:57 tfb [~tfb@80.238.0.145] has joined #ccl 10:32:30 yakov [~yakov@ip-83-149-3-73.nwgsm.ru] has joined #ccl 12:16:43 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Read error: Connection reset by peer] 12:17:24 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #ccl 12:37:39 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 13:19:41 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Quit: Linkinus - http://linkinus.com] 13:24:39 billstclair [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 13:24:51 -!- billstclair [~billstcla@p-69-195-55-65.dsl1.rtr.chat.fpma.frpt.net] has quit [Changing host] 13:24:51 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 14:02:27 -!- yakov [~yakov@ip-83-149-3-73.nwgsm.ru] has quit [Quit: Leaving] 14:44:12 -!- sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 15:50:05 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 252 seconds] 15:50:19 rme [~rme@50.43.155.6] has joined #ccl 16:29:09 -!- tfb [~tfb@80.238.0.145] has quit [Quit: sleeping] 16:39:05 jdz [~jdz@host35-70-dynamic.54-82-r.retail.telecomitalia.it] has joined #ccl 16:49:02 sellout [~Adium@c-98-245-161-7.hsd1.co.comcast.net] has joined #ccl 17:02:21 gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has joined #ccl 19:55:33 -!- bfulgham [~brent@wsip-72-215-191-226.sb.sd.cox.net] has quit [Ping timeout: 258 seconds] 19:56:09 bfulgham [~brent@wsip-72-215-191-226.sb.sd.cox.net] has joined #ccl 21:22:39 -!- jdz [~jdz@host35-70-dynamic.54-82-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 22:27:32 hello 22:27:47 gbyers: do you have a moment ? 22:27:55 Sure. 22:29:19 I'm trying to implement clock_gettime on OSX 22:29:37 and I stumbled upon host_get_clock_service() 22:30:39 but I can't find an explanation of what SYSTEM_CLOCK, REALTIME_CLOCK and CALENDAR_CLOCK are like 22:31:18 I suspect that that's all Mach stuff and would be shocked if it was useful for anything. 22:31:20 is REALTIME_CLOCK monotonic and continuous ? 22:31:57 I found it here: 22:31:58 http://books.google.com/books?id=K8vUkpOXhN4C&pg=PA523&lpg=PA523&dq=osx+clock_get_time&source=bl&ots=OKijSTRpZx&sig=OJTRn5gtI5nyjIyHW65qJb8dA84&hl=la&ei=pMdWTu2BNozE8QPdqojGDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDEQ6AEwAw#v=onepage&q&f=true 22:32:30 and one reference in contrib/huebner/advice-profiler/profiler.lisp too 22:34:04 elsewhere, they advise to use mach_timebase_info(): http://www.macresearch.org/tutorial_performance_and_time 22:34:55 I don't think that I've ever used any of that stuff. There is something that just returns nanoseconds since boot and it is monotonic (can deal with CPU frequency changes, etc.) If I've ever used the (slightly) higher-level stuff on top of that, I don't remember. 22:37:02 Actually, I'm probably misremembering that. Just a sec ... 22:40:25 What I was remembering as returning "nanoseconds since boot" is mach_absolute_time(). That returns "time units since boot", and mach_timebase_info() returns a ratio that can convert those abstract time units into something more concrete. 22:41:38 ok 22:42:17 also, if I understand correctly, a mach port is valid for the entirety of the process so I can cache it in a global variable ? 22:43:07 *process's duration 22:43:25 They get reference-counted (weirdly) and can become invalid before then. 22:44:25 oh dear 22:45:22 On an x8664 running 10.6.something, the ratio returned by mach_timebase_info() is 1/1; mach_absolute_time() does return nanoseconds since boot, but you're not supposed to count on that. I think that on the PPC the ratio was something other than 1/1. 22:45:24 is there no guarantee at all ? allocating and de-allocation two ports per call seems wasteful 22:48:01 Some things are documented as "returning a reference" to a port. Unless you do something explicit (or something else does), the reference remains valid. There are all kinds of weird "kernel creates a reference, user code is supposed to deallocate it" conventions. AFAIK, the documentation is correct, but you may have to suspend disbelief while reading it ("someone actually thought that this was a good idea ?"). 22:51:55 "The mach_host_self function returns send rights to the task's host self port" 22:52:01 how would you interpret that ? 22:53:27 That particular port "name" (an integer) is likely to remain valid for the lifetime of the task (where "task" is roughly "unix process"). 22:57:32 so when docs speak of "send rights", they're referring to reference-counting ? 22:59:42 In some bizarre, never-should-have-escaped-the-lab way, yes. Let me see if I can find something in the docs; just a sec. 23:01:25 http://www.gnu.org/software/hurd/gnumach-doc/Port-Rights.html might be helpful. You can have some kinds of rights multiple times. 23:06:13 so, a port is a kernel object, a send right is an endpoint connected to a port and may or may not be unique per task 23:07:43 depending on whether the function used to request a send right decides to increment a refcount to an already existing send right or allocate a new send right 23:07:53 this is wonderfully contorted 23:08:20 If you can avoid this stuff, that'd probably be good. I'm amazed that OSX works at all. 23:10:41 unless Apple decide to implement clock_gettime & friends, I'll have to make do 23:13:48 It seems that you can largely ignore this stuff for clock_gettime itself. A lot of Linux systems effectively treat CLOCK_REALTIME and CLOCK_MONOTONIC as the same and claim nanosecond resolution when it's actually nowhere near that. 23:17:19 -!- rme [~rme@50.43.155.6] has quit [Quit: rme] 23:17:29 but they're not the same 23:17:56 just tested here, and CLOCK_MONOTONIC is unaffected by frequency changes and clock adjustments 23:18:52 Tested on ? 23:19:13 linux 3.0 23:19:24 On? 23:19:38 core2 64bit 23:21:26 Ok. I think it's still true that a lot of Linux systems don't really differentiate between CLOCK_MONOTONIC and CLOCK_REALTIME, and I think that they're probably standards-compliant even if they don't. 23:23:45 rme [~rme@50.43.155.6] has joined #ccl 23:25:40 gbyers: in that case I'm fortunate that I can afford to care only about recent versions 23:32:48 btw, I found it: https://developer.apple.com/library/mac/#qa/qa1398/_index.html 23:33:01 mach_absolute_time() seems to be the official way 23:33:10 gbyers: thanks a lot :) 23:33:53 OK. Always remember: "Mach sucks, but no one understands how." 23:34:22 hahaha 23:39:32 On the other hand, Linux sucks differently each time a kernel is released, so you pick your poison.