00:20:53 homie` [~levgue@xdsl-78-35-165-106.netcologne.de] has joined #sbcl 00:22:07 -!- homie [~levgue@xdsl-78-35-188-125.netcologne.de] has quit [Read error: Connection reset by peer] 00:49:26 -!- tcr1 [~tcr@user-0c9h4tj.cable.mindspring.com] has quit [Quit: Leaving.] 01:12:59 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 01:31:28 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Ping timeout: 248 seconds] 01:37:20 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 01:45:39 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 01:49:05 -!- drdo` [~user@85.207.54.77.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 02:35:54 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 03:57:19 attila_lendvai [~attila_le@87.247.34.213] has joined #sbcl 03:57:19 -!- attila_lendvai [~attila_le@87.247.34.213] has quit [Changing host] 03:57:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:10:38 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 05:09:04 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: bonk] 05:30:30 Quadrescence [~quad@168-103-81-174.hlrn.qwest.net] has joined #sbcl 05:30:37 -!- Quadrescence [~quad@168-103-81-174.hlrn.qwest.net] has quit [Changing host] 05:30:37 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:16:05 -!- chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 06:31:38 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:35:28 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 248 seconds] 06:48:50 Kryztof [~user@81.174.155.115] has joined #sbcl 06:48:51 -!- ChanServ has set mode +o Kryztof 07:07:48 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 07:08:31 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:08:31 -!- ChanServ has set mode +o nikodemus 07:32:34 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 07:33:04 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 07:34:52 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 260 seconds] 07:38:45 attila_lendvai1 [~attila_le@87.247.3.160] has joined #sbcl 07:38:45 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 07:38:48 -!- attila_lendvai1 is now known as attila_lendvai 07:38:48 -!- attila_lendvai [~attila_le@87.247.3.160] has quit [Changing host] 07:38:48 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:38:51 Phoodus [~foo@68.107.217.139] has joined #sbcl 07:39:42 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:39:42 -!- ChanServ has set mode +o nikodemus 08:03:36 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 08:04:43 flip214 [~marek@86.59.100.100] has joined #sbcl 08:04:43 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 08:04:43 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 09:16:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 10:00:50 -!- homie` [~levgue@xdsl-78-35-165-106.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:04:17 homie [~levgue@xdsl-78-35-165-106.netcologne.de] has joined #sbcl 11:26:44 Blkt [~user@82.84.182.166] has joined #sbcl 11:33:34 DGASAU [~user@91.218.144.129] has joined #sbcl 11:49:47 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 11:51:38 drdo [~user@85.207.54.77.rev.vodafone.pt] has joined #sbcl 12:11:49 attila_lendvai [~attila_le@87.247.51.177] has joined #sbcl 12:11:49 -!- attila_lendvai [~attila_le@87.247.51.177] has quit [Changing host] 12:11:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:14:14 homie` [~levgue@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 13:15:50 -!- homie [~levgue@xdsl-78-35-165-106.netcologne.de] has quit [Ping timeout: 244 seconds] 13:18:49 -!- homie` [~levgue@xdsl-87-79-195-126.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:22:09 wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 13:30:54 -!- drdo [~user@85.207.54.77.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 13:37:03 homie [~levgue@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 13:40:29 -!- wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has quit [Quit: Client Quit] 13:46:22 pkhuong: do we have a nice way of asking "does this object have a boxed immediate representation"? 14:04:10 immediate-constant-sc ;) 14:04:25 That's what the immediate sc means. 14:25:43 wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 14:29:26 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:29:35 G'morning all. 14:29:48 morning nyef 14:30:26 nikodemus: Any thoughts on threads.impure.lisp / (deadline-detection interrupts)? 14:36:55 nyef: nothing immediate, except that given that it uses sleep it may just be brittle (i don't /think/ that's the case, but...) 14:37:26 Mmm. I'm rebuilding for the configuration that failed so that I can try to repeat it. 14:37:32 nyef: i'll go poke at a ppc a bit later today and fix the sb-ext:dynamic-space-size while at it 14:38:29 -!- wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has quit [Quit: Client Quit] 14:38:58 I think I'll forward-port my stack-allocatable-fixed-objects stuff this week. Try and land that early next cycle. 14:39:44 Umm... What happens if we take a GC in the middle of that test? 14:40:01 Is that likely to cause any sort of problem? 14:40:05 -!- lichtblau [~user@port-92-195-21-77.dynamic.qsc.de] has quit [Ping timeout: 252 seconds] 14:40:42 It's the sort of thing that would cause an intermittent failure, and since SLEEP conses on PPC... 14:42:13 wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 14:45:58 Wow, that test is almost stupidly fragile. 14:46:42 And, yes, an unexpected GC should be more than adequate to throw it off. 14:51:42 -!- wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has quit [Quit: Client Quit] 14:56:46 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 14:57:05 drdo [~user@85.207.54.77.rev.vodafone.pt] has joined #sbcl 14:57:52 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has quit [Ping timeout: 248 seconds] 14:58:23 That test could be made stronger... by burying it in enough mutexes to completely obscure the point. 14:58:35 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 14:58:59 pon1980 [~pon@195.67.88.105] has joined #sbcl 15:01:43 i think it wants semaphores to orchestrate things 15:07:57 Something like that. 15:08:22 Mutexes would work if we can release them from a non-owning thread. 15:09:34 lichtblau [~user@port-92-195-21-77.dynamic.qsc.de] has joined #sbcl 15:09:35 Just create them locked and have them released whenever a thread has done what it needs to. 15:12:14 but using mutexes like that is /icky/. 15:12:21 it's what sems and gates are for 15:12:57 Sure. 15:13:10 But which is the primitive construct? 15:13:23 futex is :) 15:13:29 (Honestly, I'd really prefer to run such tests under a hypervisor.) 15:13:42 akovalenko: On a #!-sb-futex target? 15:14:07 nyef: abstractly neither 15:14:10 Maybe hypervisor is the wrong concept to apply. But some other process that can schedule each thread individually. 15:14:21 nikodemus: And in our implementation? 15:14:37 nyef: mutexes and condition variables currently 15:15:10 The problem being that we're actually testing the mutex behavior here. 15:15:21 nyef: mutex+condvar is what you're guaranteed to have in POSIX, and of those two, neither is "more fundamental" 15:18:00 btw, maybe there is some userspace cooperative pthread implementation, hackable enough to make something like such a hypervisor.. 15:18:28 It's definitely possible to write something like that with swapcontext or fibers :) 15:18:58 ptrace(). 15:21:12 akovalenko: hi! 15:22:18 I suppose you've seen my fiber-related question on sbcl-devel. I wasn't sure whether you'd rather explain here or on the list. 15:22:37 ... In any case, I'd be very glad if you could just explain the basic idea very briefly. 15:23:56 (And I'm rather firmly planning on actually doing Windows work starting january. I can't rule out that other projects get in the way, of course, but my previous merge attempt has been sitting there for 6 months now, so it'd be getting silly otherwise.) 15:25:28 nyef: i don't see a problem. semaphores don't get deadlock detection, and using them there to make threads wait until other threads are in position doesn't expose them to interrups 15:25:57 (And it's a good moment to be doing it, since hlavaty has almost finished porting our software to SBCL (your branch), so we've actually got a use case for it now.) 15:28:26 lichtblau: I've already answered via gmain (right now got the request from gmane authorizer and responded to it, so the message will be there in a few minutes, probably) 15:28:33 *gmane 15:30:19 lichtblau: really, the basic decision is whether we want to switch stacks for foreign callbacks. I found them much more easy to implement if we switch stacks. And if it's accepted, it becomes necessary to use fibers on Windows, 'cause if we switch stack in a custom way, OS will hate us. 15:33:16 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 15:42:34 Thank you for the email. 15:42:57 *lichtblau* re-reads it for the second (and probably not the last) time 15:43:11 OK, so fibers for stack overflow sound really cool. 15:44:16 and makecontext for stack overflow wouldn't hurt either :) this way, it wourld become really possible to debug overflows with no fingers crossed. 15:46:01 Indeed, I suppose I could have asked my question the way you've phrased it now: why "we want to switch stacks for foreign callbacks". 15:46:37 So far, for me the argument seems to center around available stack space, but perhaps I'm not seeing the full picture. In the other situations, we're just sharing the stack with native code after all. 15:47:36 Ha ha, the POSIX standard isn't really trying to be helpful: 15:47:39 | APPLICATION USAGE: The obsolescent functions getcontext(), makecontext(), and swapcontext() can be replaced using POSIX threads functions. 15:47:44 Surely they are jesting? 15:48:19 it could have been written when most pthreads were userspace :) 15:48:42 As /thread/ functions, they can. For other clever uses it's fairly unlikely. 15:48:43 so there wouldn't be too much difference 15:50:02 iirc, D language "alternative standard" library has portable fibers (though I didn't look inside them for implementation details). 15:50:12 *that is, the Tango library. 15:52:11 tyson1 [~Ian@bas1-toronto06-2925210187.dsl.bell.ca] has joined #sbcl 15:52:34 lichtblau: with a stack-switching design, there's no need to change a control stack start/end fields in struct thread; I avoid another synchronization issue when I have them "constant" 15:53:01 attila_lendvai [~attila_le@87.247.51.177] has joined #sbcl 15:53:01 -!- attila_lendvai [~attila_le@87.247.51.177] has quit [Changing host] 15:53:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:53:04 -!- pon1980 [~pon@195.67.88.105] has left #sbcl 15:55:41 And for descheduled fibers (that is, for currently unused lisp environments in a possible alternative design) there is still something that GC would have to conserve (unless we try hard to avoid it), so it's great when it can take struct thread and work on it. 15:56:43 -!- tyson1 [~Ian@bas1-toronto06-2925210187.dsl.bell.ca] has left #sbcl 15:56:53 Another issue is that a foreign thread can terminate at any moment, and we can't force it into our "post-mortem" cemetry. So its native stack may just become inaccessible in some wrong moment. 15:57:51 ..and our fiber's stack won't go away until *we* delete the fiber. 16:02:52 this is really strange 16:03:28 ahahahaha. silly me 16:10:04 milanj [~milanj_@178-223-158-248.dynamic.isp.telekom.rs] has joined #sbcl 16:27:40 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 16:41:26 huh. why are our gf calls so slow? 16:41:46 -!- whoops [u549@gateway/web/irccloud.com/x-xypfvgudpptoknuj] has quit [Excess Flood] 16:42:27 nikodemus: profile ;) 16:42:44 when i could just mutter here and guess? 16:43:43 CCL seems to optimize the single-unspecialized-method case pretty well -- almost as cheap as a regular function call 16:43:44 well, you could exploit the perf syscalls. 16:45:17 that way the kernel will take care of profiling IPs, and it can even backtrace correctly ;) 16:58:43 whoops [u549@gateway/web/irccloud.com/x-pysphzehxvtrcakj] has joined #sbcl 17:04:24 Okay, I've thus far been unable to repeat the failure of deadline-detection interrupts, so I'm going to chalk it up to a fragile test case, because it's far too timing-dependent for my liking. 17:14:33 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 258 seconds] 17:26:03 nikodemus: have you remembered to amortize the lazy discriminating function generation? 17:46:45 Kryztof: yes 17:58:33 then I don't know. PCL also optimizes at least a certain amount of default-method-only stuff 17:58:45 *nyef* sighs. 17:59:03 Five backends, four different arrangements for undefined_tramp. 17:59:58 I wonder if the &rest arg construction in the distriminating function 18:00:00 whoos 18:00:13 "discriminating function" might be a cause of a problem 18:01:33 What's next, "indiscriminate function"s? 18:09:50 -!- antgreen [~user@bas3-toronto06-1177890745.dsl.bell.ca] has quit [Remote host closed the connection] 18:25:50 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 18:31:23 blackwolf [~blackwolf@ool-45763eb0.dyn.optonline.net] has joined #sbcl 18:43:13 wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 18:50:14 Kryztof: i'm 90% sure that compute-secondary-dispatch-function1 should call make-emf-call with type 'fast-function, which helps a little 18:56:58 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:08:32 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:34:32 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:34:32 -!- ChanServ has set mode +o nikodemus 19:37:55 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Client Quit] 19:40:20 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 19:49:02 -!- whoops [u549@gateway/web/irccloud.com/x-pysphzehxvtrcakj] has quit [Ping timeout: 258 seconds] 19:59:14 -!- wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has quit [Quit: Client Quit] 20:07:36 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 20:14:35 sdemarre [~serge@91.176.87.217] has joined #sbcl 20:23:50 whoops [u549@gateway/web/irccloud.com/x-zloewqgcabnaxdxr] has joined #sbcl 20:37:53 wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has joined #sbcl 20:46:42 -!- wbooze [~wbooze@xdsl-87-79-195-126.netcologne.de] has quit [Remote host closed the connection] 21:14:21 tyson1 [~Ian@bas1-toronto06-1096637666.dsl.bell.ca] has joined #sbcl 21:21:52 -!- akovalenko [~akovalenk@95.73.49.241] has quit [Ping timeout: 248 seconds] 21:25:48 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 244 seconds] 21:26:37 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 21:32:58 antgreen [~user@bas3-toronto06-1177890745.dsl.bell.ca] has joined #sbcl 22:29:57 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 244 seconds] 23:00:29 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 23:15:53 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:46:45 -!- tyson1 [~Ian@bas1-toronto06-1096637666.dsl.bell.ca] has quit [Quit: Leaving.]