00:07:03 les [les@unaffiliated/les] has joined #sbcl 00:15:11 nyef: have we confirmed that it's an OS X and not a lutex issue? 00:15:28 So far as I know, we have not confirmed that. 00:15:48 But how many platforms actually use lutexes? 00:16:42 I think FBSD is solid now, but I don't remember how locking works there (post 5.4) 00:16:42 (Answer: Three. OSX on x86, OSX on x86-64, and some version of slowlaris.) 00:17:05 at some point, we could build with lutexes on futex platforms. 00:19:37 What do you think about redirecting first genesis to spit the headers out into somewhere under output/, hacking make-config to spit out "trampoline" headers under output/include/target/ that include the appropriate target file (so target/lispregs.h would include x86-64-lispregs.h or whatever), and adding a -I to CFLAGS? 00:19:56 oh, I don't have taste for that sort of issue. 00:20:07 Heh. Fair enough. 00:20:19 really, I consistently have bad taste for that. 00:20:35 re posix and mach, I'm pretty sure that we want to pump events in a dedicated thread. 00:20:42 I'm not sure I should trust my taste for it either. 00:20:57 What sort of events? 00:21:14 the one we try to handle with signal handlers. 00:21:39 Hrm. You mean use mach exceptions consistently, rather than deal with the posix emulation? 00:21:43 yup. 00:22:00 anything would be better than leaking memory for each signal handled. 00:22:04 I know we did something similar on win32, but that was because the posix emulation was clearly incomplete... 00:23:59 Do I remember rightly that the main problem with signal handling on OSX is actually a problem with the heuristics used for backtrace in both the debugger and LDB? 00:24:09 no, that's been "fixed" 00:24:26 we allocate contexts with mmap and never release them. 00:24:48 That's not "fixed". That's not even the sense of "fixed" meaning "neutered". 00:28:06 Surely we run out of address space doing that? 00:28:15 rarely enough. 00:28:52 Ah, right. We're more likely to run out of swap. 00:29:10 Or does the swapfile get expanded dynamically to cover the load? 00:29:59 We'll likely never find out: a swapping OS X is unusable. 00:30:35 ... that actually explains a few things. 00:31:17 I'll have to mention that one at work. 00:31:57 swapping probably uses nearly all of the big kernel locks (: 00:32:24 Two of the main complaints have been the network going down (more often than not for one person at a time), and the massive suck of an MBP left running too long without a reboot. 00:33:38 And I find that the network usually sorts itself out within a few minutes, and most of my problems with a long-running MBP are solved by quitting and re-launching XCode. 00:35:32 mixed win/mac environment? 00:36:07 Darwin's handling of DHCP timeouts is strange, iiuc. 00:37:30 That... might explain a couple things about how our network has behaved since I replaced the wifi point. 00:37:49 And no, it's currently a mixed linux/mac environment. 00:37:58 And that only because I have a couple of linux boxes around. 00:56:50 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 244 seconds] 01:10:52 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 01:34:33 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 244 seconds] 02:32:38 -!- nyef [~nyef@pool-70-109-155-234.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 05:05:11 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 06:03:01 homie` [~levgue@xdsl-78-35-185-189.netcologne.de] has joined #sbcl 06:05:05 -!- homie [~levgue@xdsl-78-35-131-206.netcologne.de] has quit [Ping timeout: 260 seconds] 06:41:42 zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has joined #sbcl 06:42:41 I have a "INFO: Control stack guard page unprotected" ... "Control stack exhausted" how can I get more info? 07:08:01 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 252 seconds] 07:37:45 sdemarre [~serge@91.176.11.83] has joined #sbcl 08:45:17 -!- Neronus [christian@heraklit.ayous.org] has quit [Read error: Operation timed out] 08:45:49 -!- eMBee [~eMBee@foresight/developer/pike/programmer] has quit [Ping timeout: 240 seconds] 08:46:53 -!- jsnell [~jsnell@ash.snellman.net] has quit [Ping timeout: 276 seconds] 10:09:41 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 10:09:41 -!- ChanServ has set mode +o jsnell 10:10:55 -!- homie` [~levgue@xdsl-78-35-185-189.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:13:35 homie [~levgue@xdsl-78-35-185-189.netcologne.de] has joined #sbcl 10:21:48 akovalen` [~anton@95.73.216.150] has joined #sbcl 10:22:18 -!- akovalenko [~anton@95.72.173.163] has quit [Read error: Operation timed out] 10:22:26 -!- akovalen` is now known as akovalenko 11:51:03 -!- zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has quit [Quit: Page closed] 12:13:50 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 13:08:12 nyef [~nyef@pool-70-109-155-234.cncdnh.east.myfairpoint.net] has joined #sbcl 13:08:33 G'morning all. 13:19:41 Checked yesterday, and it seems that my SSE stuff works fine with the new fixnums; they even actually lead to better array indexing code generation sometimes :) 13:21:39 That's good, given that they also lead to /worse/ array indexing code generation sometimes. 13:23:16 Well, at least when indexing floats (which is probably the most obvious use for SSE), it now can directly use both tagged and untagged index as input. 13:23:56 As opposed to...? 13:24:39 And don't forget that changing the fixnum width back is a simple build-time change, so you shouldn't rely on the fixnum width remaining as it is. 13:25:17 as opposed to always doing shift right by 3 to untag, then generating [reg*4+blah], because you can't do shift right in the addressing spec 13:25:32 Ahh. 13:25:47 and I used the proper constants from the start, which is obviously the reason why it works correctly :) 13:26:12 So now you can occasionally just use reg*2+blah or reg+blah, depending on n-fixnum-tag-bits. 13:29:11 I have a generic bit of code that takes an arbitrary index*scale + offset indexing spec (which can previously be adjusted by folding in transforms), and tries to select the best sequence of 1-2 instructions. 13:29:29 When scale is divisible by fixnum shift, the index is automatically allowed to be tagged. 13:30:52 I seem to recall slathering bits of the array code in the backend with read-time tests to determine if a given VOP requires a temporary for unboxing an index. 13:33:29 I just request a temporary register, and then don't use it if the constants turn out to be fully EA-compatible when the VOP is evaluated. I figured that x86_64 should have enough spare registers. 13:34:07 You know what I'd like to do at some point? Make an x86-64 port with a partitioned register set. 13:57:06 That generic piece of code is the make-scaled-ea function here: https://github.com/angavrilov/cl-simd/blob/master/sbcl-core.lisp; it is then used in some VOP-producing macros near the end 14:08:20 I've originally added all this complexity precisely to allow working around that shift weirdness by folding in a "(* index 2)"... 14:47:49 ... we don't have a SAP-REF-LISPOBJ type function, do we? 14:48:46 ? 14:49:05 Not seeing one, and I think it'd be useful. 14:49:13 nyef: we don't, but (make-lisp-obj (sap-ref-word)) generates something sensible, iirc 14:49:22 Sure, but that has a race condition. 14:50:25 A proper SAP-REF-LISPOBJ or SAP-REF-BOXED would move directly into a boxed register. 14:51:01 I'm thinking about %symbol-value-in-thread here. 14:52:22 We can even (load-time-value (make-lisp-obj unbound-marker-widetag nil) t) to get the tag values where we need them, as boxed values, and compare with EQ. 14:58:44 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Quit: Leaving] 15:08:40 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 15:14:51 Blkt [~user@dynamic-adsl-62-10-9-201.clienti.tiscali.it] has joined #sbcl 15:49:50 nyef: if you're going to rewrite symbol-value-in-thread, it would be nice to ensure that an object is not stack-allocated 15:50:44 As opposed to now, where it won't make a non-stack-allocated object? 15:56:05 nyef: there are some validity checks in sb-kernel:make-lisp-obj (as opposed to sb-kernel:%make-lisp-obj), but it doesn't reject other-thread stack-allocated object, iirc (and it's probably better to reject them, even if they happen to be valid up to a completion of symbol-value-in-thread) 15:57:04 Pointer objects go through valid_lisp_pointer_p() in the C runtime on GENCGC, and are bound-checked against the heap spaces on CHENEYGC. And valid_lisp_pointer_p() bound-checks against the heap spaces. 15:59:11 The entire idea is horribly unsafe anyway. 16:03:57 ... Did I say it won't make a non-stack-allocated object? It won't make a non-heap-allocated object. 16:44:47 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 16:48:56 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 18:13:19 Hrm. Looks like SBCL on OSX really does need some TLC. 18:52:38 homie` [~levgue@xdsl-78-35-138-106.netcologne.de] has joined #sbcl 18:54:00 -!- homie [~levgue@xdsl-78-35-185-189.netcologne.de] has quit [Ping timeout: 240 seconds] 19:28:23 Do we actually give a damn about PPC Darwin these days? 19:42:31 -!- nyef [~nyef@pool-70-109-155-234.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 19:49:14 -!- homie` [~levgue@xdsl-78-35-138-106.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:53:40 homie [~levgue@xdsl-78-35-138-106.netcologne.de] has joined #sbcl 20:01:57 -!- homie [~levgue@xdsl-78-35-138-106.netcologne.de] has quit [Read error: Connection reset by peer] 20:11:44 homie [~levgue@xdsl-78-35-138-106.netcologne.de] has joined #sbcl 20:50:24 -!- sdemarre [~serge@91.176.11.83] has quit [Ping timeout: 240 seconds] 22:31:02 -!- Blkt [~user@dynamic-adsl-62-10-9-201.clienti.tiscali.it] has quit [Quit: cya] 23:23:26 nyef [~nyef@ip-64-134-155-138.public.wayport.net] has joined #sbcl