00:11:01 What's the "World Lock" mutex in sbcl? 00:12:17 -!- tsuru [~charlie@adsl-98-87-48-58.bna.bellsouth.net] has quit [Remote host closed the connection] 00:13:55 And I guess what causes it to be held? 00:16:19 sshirokov: many things that affect the internal fact databases. 00:16:32 mostly compilation and the (re)definition of types. 00:20:23 Hm 00:20:25 Thanks 01:41:46 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 02:10:03 ah, make -j 20. 06:17:41 sdemarre [~serge@91.176.40.215] has joined #sbcl 07:06:01 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 07:25:29 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 07:27:39 good morning everyone 07:36:55 hallo 07:55:28 hi 08:48:30 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: testing...] 08:48:57 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:49:51 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 08:58:59 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 09:49:58 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 09:52:28 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 10:15:01 akovalen` [~anton@95.73.55.37] has joined #sbcl 10:16:47 -!- akovalenko [~anton@95.73.125.191] has quit [Ping timeout: 248 seconds] 12:00:10 tsuru [~charlie@adsl-98-87-25-188.bna.bellsouth.net] has joined #sbcl 14:14:47 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:56:30 homie [~levgue@xdsl-84-44-176-66.netcologne.de] has joined #sbcl 14:57:18 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 15:11:46 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 15:12:03 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 15:16:45 rpg [~rpg@206.117.31.188] has joined #sbcl 15:25:56 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 15:51:12 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 15:58:34 -!- akovalen` is now known as akovalenko 16:16:34 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: going home] 16:20:38 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 16:27:10 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 16:27:13 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:41:51 antgreen [user@nat/redhat/x-isqqkqocewrkunqc] has joined #sbcl 17:45:36 akovalen` [~anton@95.73.55.37] has joined #sbcl 17:47:36 -!- akovalenko [~anton@95.73.55.37] has quit [Ping timeout: 252 seconds] 18:12:00 sbryant- [~freenode@ghanima.slavasaur.com] has joined #sbcl 18:21:33 any sbcl devs around? seeing strange behavior when using save-lisp-and-die after loading a system with quicklisp. https://gist.github.com/3249100d4ac9785b6ede 18:21:54 a co-worker I think asked in #lisp about this a week or so ago? 18:22:12 sbryant-: threads on OS X are suboptimal. 18:22:43 What do you mean? 18:23:06 they cause things to fail in mysterious ways, including the above. 18:23:33 can you point me to any more specifics? 18:23:57 more specific what? 18:23:58 We fixed the issue by waiting a few moments (at the repl) then saving the lisp image 18:24:11 The mysterious ways they fail :-\ 18:24:40 gc failures like the above. 18:25:08 Hey, that reminds me. I was just looking at some of the OSX documentation, and noticed a comment about an interaction between posix threading functions and cocoa, where you need to create an NSThread in order to kick cocoa into a "multithreaded mode" before trying to use cocoa APIs from a posix thread. 18:25:25 Is there anything I can do to give more information, or access to a machine to help with the issue? 18:25:29 Has anyone looked into anything like this in conjunction with library loading? 18:25:55 nyef: mm, no. That would be nicer than loading from the initial thread. 18:26:23 pkhuong: Indeed. Or how about setting things up so we can use non-posix threading APIs to create threads in the first place? 18:26:28 sbryant-: I don't know that anyone's going to look into that GC failure any time soon. nyef expressed some interest a long time ago. 18:26:56 sbryant-: nikodemus's plan to go with spinlocks would also fix the issue. 18:27:02 sbryant-: nikodemus' threading work should cover that. though I get the feeling that won't be hitting master for a few releases yet 18:27:06 I think one of my trees has a patch to improve the diagnostic message. 18:27:15 heh. any word from him yet? he's been pretty quiet awhile. 18:27:35 ah, so should I just give a gratuitous sleep in order to let the gc calm down? 18:27:51 if it works... 18:27:54 And I have an MBP running Lion these days, so I might be able to replicate the failure... 18:27:58 pkhuong: seemed to. 18:28:01 sbryant-: it would be nicer if you could fix threads on os x (-: 18:28:15 thread's aren't too broken on OS X 18:28:44 sbryant-: you just gave an instance of brokenness. 18:29:46 pkhuong: other things don't seem to have problems with threads on OS X? Unless sbcl is hitting some weird bug 18:30:23 sbryant-: *sbcl*'s threads are broken on OS X. 18:30:57 OS X's pthread implementation smells, but that's something else. 18:31:34 alrighty, thanks for the information 18:31:36 lunch time! 18:36:47 -!- rpg [~rpg@206.117.31.188] has quit [Ping timeout: 276 seconds] 18:39:54 prxq [~mommer@mnhm-5f75db02.pool.mediaWays.net] has joined #sbcl 18:45:17 rpg [~rpg@206.117.31.188] has joined #sbcl 18:47:19 isn't nikodemus fixing threads on OS X? 18:48:05 I guess I will get to ask how that's going at the weekend 18:49:13 Hey, how do I commit changes now that we're on git? Is it just a git push my-local-branch:master or is there more to it? 18:49:22 nope, that's it. 18:49:28 Okay. 18:49:42 (and pull/rebase first if needed) 18:49:50 Right, fast-forward only. 18:49:53 pull --rebase is my new friend 18:50:14 and you don't even need to remember to edit version.lisp-expr 18:50:20 we've made it too easy! 18:50:49 those kids better get off our collective lawn (: 18:51:25 Well, I stopped needing to remember to edit version.lisp-expr a while back. I had a shell script for doing the git->cvs export for a branch that automatically did the update. 18:51:50 And did the commit-message munging to add the version number in the appropriate place. 18:51:52 *Krystof* stuck it out with manual editing to the last 18:52:16 it was so much fun, though, to see the snafus of successive waves of sbcl developers 18:52:24 I bet. 18:52:32 I think my favourite was when jsnell managed to get the whole of NEWS in as the commit message 18:52:39 Ouch. 18:52:58 Krystof: there's also a NEWS tag somewhere (: 18:53:03 Anyone object to wider-fixnums going in? 18:53:51 nyef: 64 bit only? 18:53:58 I'm all for it. 18:54:00 Yeah, 64-bit only. 18:54:08 which reminds me, I have 2 bugfixes in the queue 18:54:14 It's not like we have very many 64-bit architectures to deal with... 18:54:54 pkhuong: Is one of them size_lose() and scav_lose() ? 18:55:08 nope. 18:55:20 why do we size things up during coresave anyway? 18:55:36 To find lutexes. 18:55:53 It is specifically a lutex thing. 18:57:31 Hrm. Even the "fixed" versions of size_lose and scav_lose suck on 64-bit, they just suck less than they used to. 19:00:54 -!- jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has left #sbcl 19:10:55 -!- rpg [~rpg@206.117.31.188] has quit [Quit: rpg] 19:24:19 -!- homie [~levgue@xdsl-84-44-176-66.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:52:06 jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has joined #sbcl 19:59:52 ... what could we do with twice as many widetags on 64-bit? 20:00:17 what could we do with half again as many widetags on 64-bit? 20:01:19 I'd like more tags 20:02:08 for static arrays 20:02:18 We have six lovely lowtags that I'm about to use up. Some of them could be used to expand the widetag space instead. 20:02:39 But they're only available on 64-bit. 20:03:07 I'm all for ditching 32bit support 20:03:21 I'm not, one of my systems is a G4. 20:07:08 -!- antgreen [user@nat/redhat/x-isqqkqocewrkunqc] has quit [Ping timeout: 276 seconds] 20:10:37 fe[nl]ix: we don't need tags for those. 20:16:09 I'd like(as in Allegro), 2 new array types: 20:16:41 1) contiguous header+data allocated by the lisp in the C heap, 2) header in lisp heap + data in C heap and freed upon GC 20:18:33 pkhuong: do all current array accessors assume contiguous header and data ? 20:18:59 fe[nl]ix: simple arrays, yes. 20:19:07 fe[nl]ix: You can have 1 if you don't mind it not being subject to GC. 20:19:23 fe[nl]ix: You can have 2 with 1 and a finalizer. 20:21:27 nyef: people here helped me implement 1 some time ago: https://github.com/sionescu/static-vectors/blob/master/src/impl-sbcl.lisp 20:21:44 but how is 2 possible ? 20:21:54 Displaced array. 20:22:45 nyef: we could support native quaternion and octonion arithmetic with more widetags 20:22:48 rpg [~rpg@206.117.31.188] has joined #sbcl 20:23:06 Krystof: We could support them with structs instead. 20:23:39 Any objections to me pushing wider-fixnums right now, and disappearing for the evening in about 15 minutes? 20:24:46 nyef: it builds and tests? 20:25:05 we can of course support them with structs, but the type/tag checking becomes a mess 20:25:20 not that I think that non-standard numbers have a large constituency, so don't mind me 20:25:35 pkhuong: It did a couple weeks ago, and I'm fairly sure I haven't broken it since. 20:25:39 nyef: what wouldn't work, because the array was allocated by the C library, I can't write a header into it 20:27:49 fe[nl]ix: Doesn't your current static-vector implementation already include a header as a simple-vector type? 20:29:06 fe[nl]ix: So, create one of them, then use MAKE-ARRAY to create a displaced array on top of that, and add a finalizer to your displaced array to free the underlying simple-vector. 20:29:26 nyef: yes, but that would be case 1, where I allocate the array on the lisp side and want to use it with a C library 20:30:11 Ah. Okay, slightly different scenario. 20:30:13 Hrm... 20:30:16 but case 2 would be for when a C library allocates the array and I'd like to use it in the lisp as a "native" one, and being able to print and inspect it 20:31:35 I'll have to think about that. 20:32:22 a special kind of displaced array 20:32:32 Easiest solution might actually be to hack up the displaced vector stuff to include a "raw" pointer, and then hack up the GC stuff to ignore the raw pointer if the boxed pointer is unbound or something. 20:33:15 Okay, I'm not committing wider-fixnums tonight, I'll do one last build-and-test first. 20:33:24 but am I correct in assuming I need a new tag for that kind of array ? 20:33:35 Not necessarily. 20:34:02 fe[nl]ix: nope. 20:36:10 Might be able to do it with "just" some GC damage. 20:36:41 nyef: like my mark/sweep for SAP patch? (: 20:37:14 mark/sweep for SAPs? 20:37:15 What? 20:39:18 yeah. there was a list of address ranges. The GC looked for SAPs or lisp pointers either to the head of each range (or in the middle with the right flag)... and there was an optional further marking pass to update lisp pointers in the foreign area. 20:40:14 Umm... why? 20:40:32 Or do I not want to know? 20:40:41 I needed humongous arrays for a while... the mark/sweep part was just for fun. 20:41:57 Fair enough. 20:42:03 Okay, time I disappeared for the evening. 20:42:07 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 20:46:41 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 20:48:09 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 21:00:24 -!- sdemarre [~serge@91.176.40.215] has quit [Ping timeout: 240 seconds] 21:09:16 -!- prxq [~mommer@mnhm-5f75db02.pool.mediaWays.net] has quit [Quit: Leaving] 22:25:56 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 22:33:28 attila_lendvai [~attila_le@apn-94-44-58-44.vodafone.hu] has joined #sbcl 22:33:54 -!- attila_lendvai is now known as Guest30437 22:35:39 -!- Guest30437 [~attila_le@apn-94-44-58-44.vodafone.hu] has quit [Client Quit] 23:01:07 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 23:46:26 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving]