00:07:28 -!- borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Read error: Operation timed out] 00:09:01 -!- cmm [~cmm@bzq-79-182-211-206.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 00:10:27 cmm [~cmm@109.66.69.61] has joined #sbcl 00:25:31 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 01:07:04 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 02:12:50 Would someone be so kind to interpret these results for me? http://paste.lisp.org/display/125809 02:14:09 Or a little more specifically, help me identify the issues and what to do to approach solving them? 02:23:13 Quadrescence: is that on PPC? (nothing to be done on non-x86 for range-reduction, probably) 02:23:34 akovalenko: That is correct. Darwin/PPC 03:05:00 I don't know what to do about the range reduction errors. 03:05:26 in theory libm should DTRT. in practice it doesn't. But, in practice, isn't whatever libm does TRT? 04:33:13 attila_lendvai [~attila_le@81.211.133.38] has joined #sbcl 04:33:13 -!- attila_lendvai [~attila_le@81.211.133.38] has quit [Changing host] 04:33:13 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:06:37 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [Ping timeout: 240 seconds] 05:06:49 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 06:23:43 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 06:48:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:51:41 sdemarre [~serge@91.176.210.70] has joined #sbcl 08:35:12 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:36:24 good morning everyone 08:53:43 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 245 seconds] 09:04:39 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 09:54:42 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 11:00:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 256 seconds] 11:08:40 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 11:08:40 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 11:08:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:17:03 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 11:17:03 -!- ChanServ has set mode +o nikodemus 11:21:34 huh. successfully loaded a fasl from user-defined stream, but it required a bit too much of jumping thru hoops (I had to add some Gray methods on my subclass of SB-SIMPLE-STREAM:FILE-SIMPLE-STREAM, and to wrap it all into synonym-stream for making it fast-read-byte-compatible..) 11:30:24 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 11:30:26 It occured to me that we can turn some ordinary functions into generic ones during cold/warm -- specifically, it would be great to have generic SB-IMPL::REFILL-INPUT-BUFFER.. 11:38:46 akovalenko: is + sign allowed in filenames on windows? 11:39:17 nikodemus: it's allowed by WinAPI and some tools, but I'm not sure on CMD.EXE 11:39:42 but basically it should work if there's a .lisp file called foo+.lisp? 11:40:14 yep. (seems like cl+ssl has something like that, and I had no problem with it) 11:44:02 attila_lendvai [~attila_le@81.211.133.51] has joined #sbcl 11:44:02 -!- attila_lendvai [~attila_le@81.211.133.51] has quit [Changing host] 11:44:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:09:00 good, good :) 12:25:14 Kryztof: that's quite a nifty bug! 12:43:08 pchrist_ [~spirit@gentoo/developer/pchrist] has joined #sbcl 12:46:07 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 248 seconds] 12:54:55 I'm just glad it's not *actually* my fault 12:55:08 homie [~levgue@xdsl-87-79-192-72.netcologne.de] has joined #sbcl 13:20:37 my brain... 13:21:31 what are the minimal requirements that guarantee that (slot-value x y) uses standard-instance-access or f-s-i-a? 13:22:00 slots exits, slot is bound, slot is a standard slot? 13:22:38 no, that's no enough. slot-value-using-class can just dispatch on the metaclass 13:22:58 slots exits, slot is bound, slot is a standard slot, class is a standard class? 13:23:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 13:32:53 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 258 seconds] 13:47:05 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 13:47:05 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 13:47:05 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:55:34 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:55:42 G'morning all. 14:07:39 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 14:27:15 morning nyef 14:32:56 rpg [~rpg@mpls.sift.info] has joined #sbcl 14:53:22 -!- homie [~levgue@xdsl-87-79-192-72.netcologne.de] has quit [Remote host closed the connection] 15:08:43 -!- _8david [~user@port-92-195-81-17.dynamic.qsc.de] has quit [Ping timeout: 258 seconds] 15:09:15 homie [~levgue@xdsl-87-79-192-72.netcologne.de] has joined #sbcl 15:14:41 Ugh. 15:15:17 Two failures on darwin/x86-64 (threads.pure.lisp / ({CONDITION-WAIT,WAIT-ON-SEMAPHORE} TIMEOUT ONE-THREAD)). 15:15:35 And SYMBOL-VALUE-IN-THREAD.3 seems to be locking up on linux/ppc. 15:17:42 i had a crash with rt-test.lisp, after loading it and invoking with rt-clim:rt the pane appeared with some tests and i clicked and run some tests, but somewhere along the debugger appeared about a concurrent access to a hashtable again, tho i used nikodemus patch ..... 15:18:16 lichtblau2 [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 15:20:24 ok, am now testing again, the bug appears on some specific test.... 15:23:07 yay, a proper test case 15:23:42 yep, olistbyte test fails i think.... 15:23:56 i got allocation error i think on xlib 15:24:50 tho can't say for sure what the problem is, so maybe it's not xlib, maybe it's something else, maybe i should start the rt as a new process too..... 15:25:44 ok from top of clim-listener it fails, and it freezes, i'll try the sbcl repl 15:27:37 it fails and freezes even earlier..... 15:27:39 Yup, SYMBOL-VALUE-IN-THREAD.3 is locking up at a random point during the test. 15:28:04 Seems to pass on x86-64, though. 15:34:00 Skipped broken on darwin? What? 15:42:19 nikodemus [~nikodemus@87-93-20-23.bb.dnainternet.fi] has joined #sbcl 15:42:19 -!- ChanServ has set mode +o nikodemus 15:42:27 Hello nikodemus. 15:44:30 hello 15:45:50 hello, http://picpaste.com/pics/Bildschirmfoto7-bMbqAEAH.1321026318.png 15:46:22 Do you know if threads.pure.lisp / (condition-wait timeout one-thread) and (wait-on-semaphore timeout one-thread) are supposed to fail on darwin/x86-64? 15:46:23 nikodemus, your patch fixes mostly mcclim, but somehow it fails on the rt-test for mcclim 15:46:53 nyef: they pass for me 15:47:03 nyef: what's the symptom? 15:47:20 They're listed as having failed when I run the test suite. 15:47:34 Might be my current patch, might be xcode 4.1, might be lion... 15:48:23 can you rerun thread.impure.lisp a few times with --break-on-failure? 15:48:56 Hang on, going to build without my latest patch, and with the workaround for xcode 4.1. 15:49:11 homie: looks --at a glance-- like there might be need for a similar patch to clx as well 15:49:31 hmm ok 15:49:38 The other thing I've run into this morning is SYMBOL-VALUE-IN-THREAD.3 locking up on PPC linux. 15:49:53 Which might -also- be my current patches. 15:50:19 I really don't want to have to bisect that, since builds take a while on an 800MHz box. 15:51:08 just run once thru all tests, else i get randomly that picture error..... 15:51:17 the tests seem all fine tho 15:59:22 Okay, --break-on-failure. 15:59:34 The function SB-THREAD::WAIT-FOR is undefined. 16:00:32 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 16:02:54 PatrickMcLaren [~PatrickMc@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 16:06:44 Looks to be the same in both cases. 16:09:34 -!- PatrickMcLaren [~PatrickMc@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 16:09:52 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 16:10:39 ... why would SB-THREAD::WAIT-FOR be undefined on darwin, but not on linux? 16:13:25 Patch review time. I'd like a second or third set of eyes on this before I commit it: http://repo.or.cz/w/sbcl/nyef.git/commitdiff/6874ffd1d69fd41f495c1c4f46304f1cea5da512 16:13:58 (It's a clearly-necessary change, but while it seems to work I'm not absolutely certain that it's correct.) 16:18:04 i'm building 53-dirty 16:18:21 sh ./run-tests.sh stage now.... 16:20:10 Ah, no wonder I'm confused. I forgot to rebase. 16:23:17 got failure on bugs 309448 and on debug.impure.lisp backtrace-interrupted-condition-wait... 16:23:19 2 16:23:38 and 3 expected 16:24:35 nyef: should be sb-ext:wait-for 16:26:02 That's what I figured when I started looking for why the package structure would be different between darwin and linux, only to find that the linux version I was testing was from before all the new stuff landed. 16:27:11 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 16:27:18 Kryztof: aroundp 16:29:12 nikodemus` [~nikodemus@188-67-240-34.bb.dnainternet.fi] has joined #sbcl 16:32:15 -!- nikodemus [~nikodemus@87-93-20-23.bb.dnainternet.fi] has quit [Ping timeout: 276 seconds] 16:33:24 yes 16:33:31 I have a fix for Fare's bug 16:34:06 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 16:40:24 coolness. i was going to ask something about slot-value-using-class but i need to unconfuse myself first 16:40:36 (not related to Fare's bug) 16:41:43 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 16:42:10 ... Oh. No threading by default on darwin. -THAT's- why it chokes. 16:42:55 ... isn't it? 16:43:23 ... yeah, the one-thread tests still run without threads enabled. 16:49:02 many-thread tests should be disabled without threads, but one-thread tests should pass even without threads 16:49:13 oh 16:49:19 oh, but i know why it breaks 16:49:51 my bad, missing sb-ext in target-thread.lisp from #!-sb-thread side 16:53:25 fix pushed 16:53:33 -!- nikodemus` [~nikodemus@188-67-240-34.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 16:54:59 Quadrescence: what does hypot do with signed zeros? 16:55:24 it should always be positive; good. 16:56:51 We don't have any mechanism for detecting incompatible values of most-positive-fixnum, do we? 16:57:19 that is, code compiled with a most-positive-fixnum of 2^62 will happily load into an sbcl of the same version number with most-positive-fixnum = 2^60 16:57:35 or have I forgotten some defence? 17:09:05 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:13:32 Your tree will be dirty if you change it. 17:17:33 oh, no non-source customization method 17:17:36 ok then 17:25:03 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 17:26:53 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:28:29 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:29:06 Now, you can easily confuse 62 and 61 bit fixnums, but you still need a dirty tree in each case. 17:30:16 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:32:03 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 276 seconds] 17:34:30 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:35:10 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:36:17 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:36:20 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:39:03 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:39:13 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:41:03 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:41:12 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:42:21 patrick [~patrick@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 17:42:28 -!- patrick [~patrick@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Client Quit] 17:44:25 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 18:01:25 akovalen` [~anton@95.72.47.174] has joined #sbcl 18:02:55 -!- akovalenko [~anton@77.51.42.201] has quit [Ping timeout: 248 seconds] 18:07:35 -!- akovalen` is now known as akovalenko 18:10:21 prxq [~mommer@mnhm-5f75d5a7.pool.mediaWays.net] has joined #sbcl 18:43:47 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 18:46:50 flip214 [~marek@86.59.100.100] has joined #sbcl 18:46:50 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 18:46:50 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 18:47:26 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 18:49:01 flip214 [~marek@86.59.100.100] has joined #sbcl 18:49:01 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 18:49:01 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 18:51:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 19:08:11 Okay, SYMBOL-VALUE-IN-THREAD.3 still locks up in mainline. 20:00:41 mensch_ [~mensch@c-71-232-44-219.hsd1.ma.comcast.net] has joined #sbcl 20:19:13 nyef: how much work would it entail to use the string instructions to clear each page? 20:20:13 Possibly not much, but what do you gain? 20:20:53 smaller code size? Plus intel has been telling us to do it that way for ages; some day it might randomly make a huge difference. 20:21:12 Really? String instructions are "in" again? 20:22:33 yeah. 20:22:41 For copying/clearing, at least. 20:23:03 Hunh. 20:23:58 It's something like: regular word/SSE at a time loop, string instructions, and, for large chunks, funky versions with alignment, prefetch and all. 20:24:43 I think those regs are callee-saves on x86. 20:26:19 nyef: which regs, xmm? 20:26:25 cx 20:26:34 ESI, EDI. 20:26:53 ESI/EDI are caller-saved, iirc 20:27:30 ... Nope. Callee-saves. 20:27:52 ECX and EDX are caller-saves. 20:27:54 *akovalenko* had a terminological confusion.. 20:28:26 a,c,d -- caller, other stuff -- callee. 20:28:58 Right. 20:29:20 And b is for an offset table for PIC. 20:30:49 akovalenko: do you have an isolated commit for saving xmm regs in our fast_bzero? 20:31:46 pkhuong: I do. Though it may be ugly (I use movups, not movaps..) 20:32:08 wfm. 20:32:46 another option: save regs correctly in the assembly trampoline. 20:33:50 pkhuong: So, would you say that the basic change to scrub_control_stack is right, and the assembly language bits are at least not wrong, but there's an opportunity for further optimization? 20:33:51 It turned out that it's not isolated -- history is a mess. Confused with another commit for saving xmm in alloc_tramp on amd64.. 20:33:52 One day a compiler will emit code that uses SSE for our normal code, and we'll suffer. 20:34:13 nyef: It looks right to me, but I didn't read it closely. 20:34:29 Hmm. Okay. 20:35:46 Too much academic work and admin trivium to deal with. 20:37:04 I think the bits I'm most worried about are the CMP / Jcc pairs. 20:38:47 We're semi-wedded to GCC, no? How about __builtin_frame_address ? 20:42:05 Does that work on clang? What about the x86-64 red zone? 20:42:46 And how tightly wedded are we to GCC, anyway? 20:42:47 red zone doesn't matter for our purposes; it only means that there can be data below SP. 20:43:24 Yes, and we're about to try and blank all of the data below our frame, remember? 20:43:50 oh shit, right. 20:44:28 Yeah, I can imagine stuff going wrong if we do anything but roll our own in asm. 20:44:33 On the whole, we're far, far safer doing this in ASM. 20:45:14 in theory, we could read sp and add 256 or however many bytes. 20:45:47 Which would be an arch-dependent value. 20:46:07 abi, right. 20:46:47 Somewhere I just allocated a huge local array and zeroed it out (can't recall if it was declared volatile or cast to volatile).. 20:48:10 If a "scrubber" is not inline assembly any more, but an external thing in $arch-assem.S, red zone can be ignored. 20:48:26 akovalenko: that's what nyef does. 20:49:03 One of the problems was that it WASN'T inline assembly, it was straight-up C. 20:49:41 "last var in text == last var in frame" => fun 20:49:57 Yeah. Fun. Until you try to build in xcode 4.1. 20:51:48 -!- mensch_ [~mensch@c-71-232-44-219.hsd1.ma.comcast.net] has quit [Quit: leaving] 20:52:47 gcc -mno-red-zone ;; just in case you have to get rid of it in the future.. 20:54:09 Heh. 20:55:16 *akovalenko* saved much time on amd64 with __attribute__((sysv_abi)). Gcc is cool. 20:55:18 I think it'd be amusing to have an x86-64 port with split stacks, and a PPC version with a unified stack, but building on PPC is already a pain. 20:55:52 it'd be amusing to have precise GC on unified stack! 20:56:15 and even more amusing to implement it... 20:56:43 Yeah, have fun with that. d-: 20:58:17 with async signals going away, it becomes a non-crazy idea. 20:58:52 Well, certainly an easier idea. 20:59:26 another option: unboxed stack at a fixed offset from the real stack. 20:59:45 infrared zone... 21:11:26 with non-partitioned registers, does the compiler "know" (at some moment) for each vop, which registers hold lispobjs and which don't? (say, /before/ or /after/ that vop) 21:11:36 blackwolf [~blackwolf@ool-45763eb0.dyn.optonline.net] has joined #sbcl 21:12:01 nikodemus [~nikodemus@188-67-240-34.bb.dnainternet.fi] has joined #sbcl 21:12:01 -!- ChanServ has set mode +o nikodemus 21:12:41 my sbcl build is failing , timing out doing sb-concurrency tests. there's a quick patch for that (increase the timeout) but I can't find it on the web. anyone remember what the fix is? 21:14:12 blackwolf: what os? 21:14:29 *akovalenko* suspects missing :sb-futex 21:14:39 linux 21:15:02 anything in customize-target-features.lisp? 21:15:13 blackwolf: x86[-64]? up-to-date git head? 21:15:22 it's the "expected N actual M" failure 21:15:53 blackwolf: i'm asking due to recent threading changes 21:15:56 sb-thread in customize, 64-bit, 1.0.53 source (d/l today) 21:16:21 nikodemus: ah. I saw that you'd checked some changes in. 21:16:22 nikodemus: Speaking of, I'm bisecting the symbol-value-in-thread.3 thing. 21:16:28 1.0.53, huh. can't remember offhand that i'd heard of a failure like that before 21:17:07 read somewhere of a patch to a timeout value 21:17:24 but: touch contrib/sb-concurrency/test-passed # and install.sh will be happy and install it even if the tests failed 21:17:40 yeah, I think tobias sent a patch some time ago 21:17:55 something about AMD CPUs 21:18:01 nikodemus: that'll do. thanks. 21:19:30 Have it down to about three candidate commits. 21:19:44 akovalenko: yes, at least in theory. 21:25:14 http://paste.lisp.org/display/125822 # slot-value-using-class oddness, load as source 21:31:14 homie` [~levgue@xdsl-78-35-173-42.netcologne.de] has joined #sbcl 21:33:14 What's the point of invoke-with-saved-fp-and-pc, again? 21:33:15 -!- homie [~levgue@xdsl-87-79-192-72.netcologne.de] has quit [Ping timeout: 260 seconds] 21:34:03 nyef: backtrace. 21:34:10 -fno-omit-frame-pointer can't be applied to everything we call, like OS libraries.. 21:34:19 Makes sense, I guess. 21:34:45 That's what I thought it was, figured I'd make sure. 21:36:30 ... I distinctly remember there being some kind of backtrace / unwind API for unixoids, but the details escape me... 21:36:43 AARGH. THIS MAKES NO SENSE 21:36:48 dwarf stuff 21:37:01 Yeah, dwarf stuff. 21:37:05 gcc has at least a partial api in some library 21:37:09 Or, at least, the eh_frame stuff. 21:37:24 Could we integrate against VirtualUnwind on win64? 21:37:27 AARGH. THIS MAKES NO SENSE AT ALL 21:37:49 nyef: VirtualUnwind is hard. 21:38:24 Can you get reliable backtrace through alien frames on win64 without it? 21:39:08 nikodemus: Is this LOADed directly, or compiled first? 21:39:47 Wait, S-V-U-C? 21:39:53 nyef: without signals + with an additional frame pointer chain (that gets updated on foreign callouts/callbacks) you can get reliable backtrace wherever it's possible to get any backtrace :) 21:40:15 Wasn't there something about having to define the methods for MOPpery before creating an instance? 21:40:26 akovalenko: No, no... Backtrace for the foreign frames themselves? 21:42:55 loaded directly 21:42:55 (test-1) (test-2) (test-1) sequence in particular baffles me 21:42:57 (test-1) => 2, (test-2) => sqrt 2, (test-1) => sqrt 2 ; and i can't see how that changes 21:42:59 hmm. VirtualUnwind necessary here, but unwind tables for non-runtime/-code can wait a bit. 21:43:50 nyef: libunwind? 21:45:46 pkhuong: That might have been it. 21:47:06 nikodemus: Because defining non-standard-thing-b causes the slot-value accessors to be recomputed? 21:47:16 nyef: on windows, you /want/ to trace foreign frames only when the debugger is entered from foreign callback (otherwise there's either nothing to trace, or no one to trace it). Not that it happens too much.. 21:47:30 nikodemus: Well, not defining, allocating the first instance of. 21:48:03 nikodemus: those slot-value calls'll go through #'(sb-pcl::reader something something :global) 21:48:58 calling the thing which passes a non-standard-thing-b will be a cache miss and then recomputation 21:49:27 #'(sb-pcl::accessor reader x :global) 21:49:29 something like that 21:49:57 duh, cache miss 21:50:13 i see 21:50:29 Kryztof: do you think all those asserts should pass? 21:50:44 I'm not sure 21:51:02 I have a feeling you're meant to define the svuc method before you're allowed to allocate any of the non-standard instances 21:51:12 The documentation for the MOP probably says that they don't need to pass, because the code breaks some rule or other. 21:52:03 "Portable methods on specified generic functions specialized to portable metaobject classes must be defined before any instances of those classes (or any subclasses) are created, either directly or indirectly by a call to make-instance." 21:52:04 that rule 21:52:17 gotcha 21:53:02 what would be better: make them pass without making things slow, or make the defmethod signal an error because IT'S TOO LATE! 21:53:14 the former 21:53:20 or maybe the latter 21:53:24 or maybe both! 21:53:35 am I a user or an implementor? I'm so confused 21:53:35 yeah, a cerror 21:54:03 if it's a cerror it doesn't matter if the flushing out is a bit slow :) 21:54:04 If you can do the former, great. The latter warrants a Big Fat Warning, or at least a Style Warning. 21:54:44 clearly not a hack for tonight, though 21:55:31 Hopefully your hack for tomorrow night will be fixing symbol-value-in-thread.3. d-: 21:57:25 http://paste.lisp.org/display/125822#1 # does this make sense -- slot-value provisions, that is? a better phrasing, maybe? the meaning is "no slot-value-using-class tom-foolery, and the system has to know that" 22:00:23 At the very least, it seems to be missing a comma. 22:01:51 "specified, unless"? 22:03:14 "SLOT-VALUE, results" 22:03:29 Possibly also "In the case". 22:04:44 The use of SB-PCL:+SLOT-UNBOUND+ in the interface is also a little unsettling. 22:05:00 maybe just "unspecified if there is an applicable method on SLOT-VALUE-USING-CLASS" 22:05:59 That seems easier to parse, at least. Can you guarantee that stronger assertion, though? 22:05:59 yeah. i'm not entirely happy about that, but if someone wants to CAS something into an unbound slot, that makes sense -- and otherwise calling slot-unbound seems TRT 22:06:33 Can you CAS an unbound SYMBOL-VALUE? 22:06:53 not now, at least 22:07:11 but unbound slot seems less intrusive 22:07:14 Are you planning on making it possible? 22:07:27 not really, because i don't see a use case for it 22:07:35 but i can imagine several for slots 22:08:14 Leave it as an undocumented extension, or mark it as an egregious and unsupported hack, then? 22:08:59 re. stronger assertion. it should really be "no applicable methods on SLOT-VALUE-USING-CLASS, its SETF version, or SLOT-BOUNDP-USING-CLASS" i guess 22:11:00 it's a conundrum. either (cas (slot-value i n) +slot-unbound+ t) needs to signal an error before the value is cassed into place, which is needs to be documented; or it needs to signal an error after the CAS, which seems counterintuitive; or it needs to do what the user actually asked, which is a bit hairy 22:11:14 not hairy in terms of implemtation, but hairy in terms of API 22:12:21 Looks like d6f9676ae94419cb5544c45821a8d31adbc1fbe8 breaks SYMBOL-VALUE-IN-THREAD.3 on Linux/PPC. 22:12:47 hm 22:12:54 (It's that, or one of the following two commits.) 22:13:13 surely there are no threads on Linux/PPC? 22:13:34 Why wouldn't there be threads on Linux/PPC? 22:14:28 wow, i didn't know we had threads on PPC 22:14:43 Since 1.0.41.38, no less! 22:14:53 how does it break? 22:14:56 Well, or so. 22:15:09 The process locks up. 22:15:34 After some number of dots, it just stops, and doesn't appear to generate any CPU load. 22:15:47 gdb? 22:16:05 "bash: gdb: command not found". 22:16:16 futexes or userspace synch? 22:16:32 Well, it's a linux, so it -should- be futexes. 22:16:48 no apt or equivalent? :) 22:17:02 I could install gdb, I suppose... 22:17:09 How do I know if it's using futexes or not? 22:17:41 (member :sb-futex *features*) 22:17:42 :sb-futex 22:19:29 I'm not seeing it in l-t-f or c-t-f, so it's almost certainly not there. 22:20:32 sh run-sbcl.sh and repl? 22:21:05 Okay, I'll try a build with :sb-futex tomorrow, and if that fixes it I'll commit a change to make-config. 22:21:23 ... Did you forget a memory barrier somewhere? 22:21:32 nyef: any chance of SSH access to that box? 22:21:57 it'd like to see it in gdb, because it works fine without futexes for me on linux 22:22:02 x86-64, that is 22:22:17 always possible 22:23:03 There might be a chance, but I'd have to punch a hole through our company gateway for it, and I'm not about to tangle with that piece of junk tonight. 22:23:26 Seriously, you probably forgot a barrier somewhere. 22:24:33 i can believe that 22:24:58 i'll be back in hacking mode on monday -- weekend is otherwise busy 22:25:45 good night 22:25:45 Fair enough. All the magic is in target-thread.lisp? 22:25:53 yes 22:25:55 Thanks. Sleep well. 22:26:45 if there's a barrier missing, my bet would be in the %waitqueue-enqueue/wakeup/drop stuff 22:27:27 -!- nikodemus [~nikodemus@188-67-240-34.bb.dnainternet.fi] has quit [Quit: Leaving] 22:38:10 Clearly, we're going to have to get a few alphas to use for SBCL, and get threading to run on them. That'll highlight missing barriers all right... 23:11:20 -!- rpg [~rpg@mpls.sift.info] has quit [Ping timeout: 258 seconds] 23:25:15 -!- prxq [~mommer@mnhm-5f75d5a7.pool.mediaWays.net] has quit [Quit: Leaving] 23:44:00 For the record, adding :sb-futex does fix the lockup. 23:51:12 -!- sdemarre [~serge@91.176.210.70] has quit [Ping timeout: 248 seconds] 23:54:10 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving]