00:13:28 -!- mc40 [~mc@host86-148-141-128.range86-148.btcentralplus.com] has quit [Quit: mc40] 00:37:03 LiamH [~none@96.231.225.69] has joined #sbcl 01:35:24 -!- Bike [~Glossina@67-5-220-77.ptld.qwest.net] has quit [Read error: Connection reset by peer] 01:38:59 Bike [~Glossina@67-5-220-77.ptld.qwest.net] has joined #sbcl 02:25:52 echo-area [~user@182.92.247.2] has joined #sbcl 02:56:00 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 03:20:51 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 03:26:55 scymtym_ [~user@89.31.118.161] has joined #sbcl 03:36:20 -!- echo-area [~user@182.92.247.2] has quit [Ping timeout: 272 seconds] 03:38:53 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 03:50:03 -!- LiamH [~none@96.231.225.69] has quit [Quit: Leaving.] 03:52:47 echo-area [~user@182.92.247.2] has joined #sbcl 03:52:47 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 03:53:13 echo-area [~user@182.92.247.2] has joined #sbcl 03:55:47 teggi [~teggi@113.172.40.203] has joined #sbcl 04:26:56 yacks [~py@180.151.36.168] has joined #sbcl 04:36:29 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 04:52:15 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 04:56:49 sdemarre [~serge@45.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 05:13:06 prxq [~mommer@mnhm-5f75c3c4.pool.mediaWays.net] has joined #sbcl 05:22:47 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 05:29:28 -!- sdemarre [~serge@45.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 258 seconds] 06:03:05 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 256 seconds] 06:05:39 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:07:55 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Read error: No route to host] 06:10:28 -!- Bike [~Glossina@67-5-220-77.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 06:12:39 Bike [~Glossina@71-34-72-185.ptld.qwest.net] has joined #sbcl 06:18:20 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 06:24:19 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 06:28:01 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 256 seconds] 06:37:15 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 260 seconds] 06:39:33 mc40 [~mc@host86-148-141-128.range86-148.btcentralplus.com] has joined #sbcl 07:14:13 Munksgaard [~philip@192.38.109.188] has joined #sbcl 07:17:13 -!- ASau`` is now known as ASau 07:24:19 flip214 [~marek@86.59.100.100] has joined #sbcl 07:24:19 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 07:24:19 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 07:36:41 -!- Bike [~Glossina@71-34-72-185.ptld.qwest.net] has quit [Ping timeout: 268 seconds] 07:41:28 -!- p_l|omoikane [~pl@81-18-213-39.static.chello.pl] has quit [Read error: Connection reset by peer] 07:41:36 p_l|omoikane [~pl@81-18-213-39.static.chello.pl] has joined #sbcl 07:51:42 -!- Munksgaard [~philip@192.38.109.188] has quit [Ping timeout: 264 seconds] 07:55:55 -!- nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has quit [Remote host closed the connection] 07:56:15 nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has joined #sbcl 08:01:36 akovalen` [~user@95.73.53.4] has joined #sbcl 08:04:03 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:05:24 -!- akovalenko [~user@195.18.46.21] has quit [Ping timeout: 256 seconds] 08:07:06 -!- akovalen` [~user@95.73.53.4] has quit [Ping timeout: 256 seconds] 08:16:56 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 08:43:55 leoc [~leoc.git@p4FF7AFB9.dip0.t-ipconnect.de] has joined #sbcl 09:43:02 -!- mc40 [~mc@host86-148-141-128.range86-148.btcentralplus.com] has quit [Quit: mc40] 10:04:04 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 268 seconds] 10:24:37 xani [~user@178.183.152.96.dsl.dynamic.t-mobile.pl] has joined #sbcl 10:44:45 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 10:50:02 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 245 seconds] 10:51:59 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 11:18:15 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 11:28:25 hlavaty` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 11:30:04 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 246 seconds] 11:32:16 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 256 seconds] 11:47:21 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: this computer sucks] 11:47:59 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 12:04:50 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 255 seconds] 12:06:20 Munksgaard [~philip@fw.math.ku.dk] has joined #sbcl 12:16:47 huh, mixing the arguments to rassoc eats all memory 12:17:06 (rassoc '(("A" "B")) "A") => say hi to OOM 12:17:45 any type mismatch, (rassoc "A" 1) 12:18:02 lol 12:18:12 apparently, during backtrace printing 12:21:11 1.0.42.10 work sok 12:24:30 "what the hell" is all i can say 12:25:49 (if (fixnump count) ...) in clean-xep looks suspect 12:27:17 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:28:22 i have it called as (SB-DEBUG::CLEAN-XEP (SB-C::TL-XEP RASSOC) (70368647522892 1 "A") (:EXTERNAL)) 12:28:47 so, it thinks it has 70368647522892 arguments 12:28:53 that's a lot of arguments 12:28:59 almost as many as I have with my children 12:32:27 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:35:47 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 12:36:24 a reduced test case: http://paste.lisp.org/display/137060 12:39:52 i should be really using rassoc correctly than fixing this bug 12:43:11 when i do (cons 1), it's (SB-C::TL-XEP CONS) (1 1 70368647523080) 12:45:59 that's OK. 12:46:23 I think the problem is the listp check in the prologue overwrite RCX 12:46:26 i just meant to point the similarity of the numbers, looks like a stack address 12:48:08 LEA RCX, [RSP+RDX*4-24] is what your reduced test case does 12:48:30 yeah, just saw that 12:54:31 I don't see any nice fix. 12:55:15 so, it's coming from the more-arg-context VOP 12:55:46 but rcx can be allocated to any other vop in other cases 12:56:57 so it needs to somehow ensure that rcx is not overwritten in XEP before any errors? 12:57:03 something like that. 12:57:06 segv- [~mb@95-91-241-75-dynip.superkabel.de] has joined #sbcl 12:57:38 so we can pin the TN and make it live throughout the XEP, or at least the prologue. 12:58:12 that's not going to help once we're out of the XEP, but I don't know if we do anything clever in that situation 12:58:48 rcx is looked by the debugger only in case of an error in xep, as far as i can see 13:02:25 and it wants to do that so that (cons 1 2 3) is shown as (CONS 1 2 #), not just (CONS 1 2) 13:05:41 alright, back to actual work 13:09:08 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 13:09:13 drmeister [~drmeister@166.137.85.68] has joined #sbcl 13:11:45 -!- drmeister [~drmeister@166.137.85.68] has quit [Remote host closed the connection] 13:12:42 yup. We could clamp the arg cout. 13:12:46 *count 13:13:12 or detect when the error is an arg count mismatch and only use the reported count then 13:17:56 I'm about ready to give up on the whole "refactor MAP-ALLOCATED-OBJECTS slowly" thing and just commit my big-bang rewrite. 13:22:12 -!- Munksgaard [~philip@fw.math.ku.dk] has quit [Ping timeout: 252 seconds] 13:22:40 Umm... I'm in the lisp debugger, on x86-64. How can I tell if I'm running on the altstack or not? 13:28:07 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 13:28:24 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 13:29:48 drmeister [~drmeister@166.137.85.68] has joined #sbcl 13:34:43 -!- xani [~user@178.183.152.96.dsl.dynamic.t-mobile.pl] has quit [Remote host closed the connection] 13:37:16 Hrm. Okay, I'm in-bounds for the control stack, which means that my problem isn't a disconnect between the control stack and the altstack... 13:42:12 wbooze [~wbooze@xdsl-78-35-135-42.netcologne.de] has joined #sbcl 13:48:03 -!- scymtym_ [~user@89.31.118.161] has quit [Remote host closed the connection] 13:50:35 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Read error: Connection reset by peer] 13:51:06 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 13:52:02 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 13:52:14 scymtym_ [~user@89.31.118.161] has joined #sbcl 14:01:57 -!- drmeister [~drmeister@166.137.85.68] has quit [Remote host closed the connection] 14:13:21 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 14:14:12 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 14:14:32 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 14:23:39 -!- scymtym_ [~user@89.31.118.161] has quit [Remote host closed the connection] 14:24:10 scymtym_ [~user@89.31.118.161] has joined #sbcl 14:34:23 Bike [~Glossina@71-34-72-185.ptld.qwest.net] has joined #sbcl 14:34:45 -!- scymtym_ [~user@89.31.118.161] has quit [Ping timeout: 248 seconds] 15:11:58 davazp [~user@92.251.211.108.threembb.ie] has joined #sbcl 15:24:18 Krystof, produced a good chuckle 15:25:45 ... backtrace through alien code is sufficiently unreliable as to be actively misleading, so why do we go to the trouble of attaching the wrong function name to some of the stack frames? 15:26:53 (I ask because a frame for low_level_handle_now_handler is showing up as for block_deferrable_signals, which just Doesn't Help.) 15:29:52 Well, IIRC, it works only for exported symbols. Which is at least very useful for me. 15:30:12 Yeah, but it doesn't work for static functions. 15:31:13 Well, all you need to do is rewrite the debugger to use dwarf debug info. And have sbcl emit that too, for good measure. :) 15:31:42 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Remote host closed the connection] 15:32:45 I'm already considering adding it to my list. 15:33:08 Especially since it'd allow us to stop using -fno-omit-frame-pointer. 15:38:00 -!- wbooze [~wbooze@xdsl-78-35-135-42.netcologne.de] has quit [Quit: none] 15:40:57 only that ;) 15:41:51 on linux, I force frame pointers even in C; otherwise perf is nearly useless. 15:41:56 If the stack frame pointer chain is "broken" somehow, but there are interrupt contexts that would be after the break in the chain, would it make sense to pick up the backtrace from the next interrupt context, possibly with an inserted frame that says "broken frame link"? 15:42:43 It's quite sad that perf doesn't know how to read debug info yet. 15:43:23 foom: it's a feature. 15:47:02 sure it is 15:50:44 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:56:03 wbooze [~wbooze@xdsl-78-35-135-42.netcologne.de] has joined #sbcl 15:56:17 ;) point is, there are devs that are vocally opposed to parsing DWARF in the kernel 15:57:01 I've never gotten a useful callgraph out of perf even with frame pointers included 15:57:10 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 16:00:26 the default report is certainly non-standard. 16:02:33 -!- davazp [~user@92.251.211.108.threembb.ie] has quit [Read error: No route to host] 16:04:13 pkhuong: well, can't really blame them for being opposed to that. 16:04:42 davazp [~user@92.251.211.108.threembb.ie] has joined #sbcl 16:07:51 pkhuong: yea, and that's stupid and makes it a useless product. 16:07:58 I mean, if they REALLY don't want to parse dwarf in the kernel that's fine; they can make their own format that they read in the kernel and have a userspace helper parse the dwarf into it too. 16:18:46 Okay, so, fortress inhabitants aside, if we're doing a backtrace and we come to the "end", but there are still interrupt contexts that could be valid, does it make sense to pick up from the next interrupt context? 16:19:46 probably. 16:20:07 Would it ever not make sense? 16:21:27 I can't think of any reason why it wouldn't. 16:22:02 Good enough, I guess. And it'd fix the threaded x86-64 freebsd backtrace problem. 16:24:00 sdemarre [~serge@91.180.118.78] has joined #sbcl 16:49:18 -!- leoc [~leoc.git@p4FF7AFB9.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 17:22:53 nyef: is it possible that we'd have overlapping backtraces? 17:23:08 i.e. we continue decoding a backtrace through an interrupt context? 17:23:39 Could it be more robust to always stop backtracking when we hit an interrupt context's frame and resume from that context? 17:23:55 Not likely, as I'd only be hunting for an interrupt context when the normal backtrace dead-ends, and I'd be looking for a context that has a frame pointer in the "dead space" between the last known frame and the end of the stack. 17:24:18 And how do we know when we "hit an interrupt context's frame"? 17:24:19 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 17:24:42 look at the value for SP in the next interrupt context on the stack? 17:25:13 I believe that we already have find-escaped-frame or whatever it's called anyway. 17:25:53 so, how do i pin RCX inside XEP? 17:26:31 or anywhere, for that matter 17:27:04 "pin" in what sense? 17:27:25 disallow any vops to overwrite it 17:28:06 You mean like a wired TN with a carefully delineated lifetime? 17:28:18 no idea what that means 17:29:23 rcx is overwritten in the xep of rassoc, and it does type checking in the xep, causing the debugger to think that rassoc was called with 70368647522892 arguments if the type check fails 17:29:36 nyef: yeah, something like that 17:29:54 but I don't think that's such a good idea because the arg parsing code decrements that counter a lot. 17:30:27 in a part of xep? 17:30:32 yes. 17:30:38 around, say, (%more-arg-context ,n-supplied ,max) 17:30:48 ... Sometimes I wonder if we might be better off just gutting and rebuilding the compiler, debugger, and garbage collector. 17:31:09 nyef: i think that all the time, but usually because i don't grasp either 17:31:25 nyef: same. 17:31:33 I mean, I have a half-decent handle on all three, but... eesh. 17:32:00 but then i think about all new bugs it will bring to the table 17:32:10 I ran into something over the weekend where I got "NIL is not of type FUNCTIONAL" from the cross-compiler, but I haven't been able to come up with a less involved test case yet. 17:32:30 stassats: do we have code to look at the current error trap in the debugger? 17:32:43 I really think we should only look at the runtime arg count on arg count error. 17:34:17 yeah, that sounds like a better idea 17:36:22 and make the VOP for arg-count-error move its argument to rcx... 17:36:58 Why RCX, just have it as one of the error parameters and use the existing internal-error parameter parsing magic? 17:37:19 The debugger can parse TN-OFFSET values for a reason, after all. (-: 17:37:25 nyef: indeed, I just realised that would be much smarter. 17:39:23 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 17:39:54 wouldn't that increase the code? 17:40:10 what wouldn? 17:40:13 -n 17:40:39 encoding RCX into the error 17:40:59 it's already encoded 17:41:29 but i'm still not sure how to make the frame printer disregard arg count if it's not invalid-arg-count-error 17:42:05 Ahh, this is a backtrace problem, not an error-handling problem? 17:42:11 yes 17:42:15 Hrm. 17:42:35 Can we please just gut the compiler and debugger and rewrite them? 17:42:53 it tries to do (loop repeat 70368647522892 for arg = (if real-args (pop real-args) (make-unprintable-object "unknown")) collect arg) 17:42:55 stassats: always return (rest args) instead of inserting # 17:42:57 you can imagine the result 17:43:38 pkhuong: no, how do i know what is the current error? 17:44:10 maybe we can show real args somehow? 17:44:17 instead of doing # 17:44:53 drmeister [~drmeister@166.137.85.68] has joined #sbcl 17:45:40 What'd be really nice is HAVING the real args more often. 17:45:46 stassats: it only enqueues # when there aren't enough real args for the count 17:46:11 yes, what if we ensure that it has all the args? 17:46:36 All 70368647522892 args? 17:46:46 actually passed args 17:47:12 so that (cons 1 2 3) is 0: (CONS 1 2 3) [tl,external], not 0: (CONS 1 2 #) [tl,external] 17:47:17 ... wait, isn't that a fixnum, not a widetag? 17:47:56 70368647522892 is the result of LEA RCX, [RSP+RBX*4-24] 17:48:19 Ah, yeah, I know WHY it gets truncated there, and of a couple of race conditions where catching an interrupt will corrupt an arglist, but yeah... 17:50:15 the arguments are there on the stack, so the debugger should be able to get them 17:50:33 They're not reliably on the stack at that point, though. 17:51:16 can we make sure that xep doesn't overwrite them before checking arg-count? 17:51:29 The first thing done in a stack frame with a fixed set of expected arguments is to set the stack pointer to the greatest of the number of expected arguments or the required fixed stack allocation for the function. 17:52:02 Possibly. Have a look at XEP-ALLOCATE-FRAME. 17:52:52 you still have to be able to tell what error was triggered. 17:53:23 right, but i just think that having all the args is a good thing, besides solving the problem 17:54:51 we can get backtrace from XEP only if there's an error in that XEP? 17:55:25 or rather, we can get a XEP frame in the backtrace only if the error has occurred inside it 17:55:58 -!- teggi [~teggi@113.172.40.203] has quit [Remote host closed the connection] 17:56:12 Or a stray interrupt, possibly via TRACE... 17:56:41 (Well, TRACE :ENCAPSULATE NIL.) 17:56:55 what are trace tables? 17:57:59 Vestigial, if I recall correctly. 17:58:16 but what do they do? 17:58:30 They don't. They're always empty. 17:58:46 CMUCL uses them, and has better debugging and disassembler support because of it. 17:58:49 then what's the point? 17:59:09 And they were also used to support "gengc", whatever that does. 17:59:16 are they left for the chance that someone will resuscitate them? 17:59:42 Or because ripping them out completely was too much effort at the time and nobody did it since. 17:59:59 I have a possible use for them that I keep meaning to get around to. 18:00:01 yeah, removing that slot is a lot of work all over the place.\ 18:00:35 At the very least, they could be used to hide the inline-constant whatever from the disassembler on x86-64. 18:01:16 and x86 (: 18:01:42 wait no, I never got around to trying that. 18:02:18 I was more thinking that they'd be a great place to hide stack frame information for table-based unwind... or register and stack maps for precise scavenging. 18:02:54 Although the support code is actually broken, if you try to populate a trace table with anything, something breaks somewhere. I forget the details, though. 18:03:31 aren't trace table built and used during compilation, but never stored in components> 18:03:34 ? 18:03:47 Maybe, I don't know. 18:04:15 At some point I'd like to sit down and figure out what all debug information is available at compile time and runtime. 18:06:04 But that's well down on my project list at this point, given things like the ROOM disaster, how far behind the times the SPARC and MIPS backends are, persistent reports of broken backtrace on FreeBSD, not to mention actual paying work... 18:06:42 *stassats* has less work on may, more for sbcl! 18:07:37 if only this bloody laptop didn't heat too much when building sbcl 18:08:44 Oh, plus two test suite failures on PPC, one of which is due to something implemented for x86oids but not other platforms, and another is implemented in terms of specialized arrays but is testing for a DX bug, so fails if it can't stack-allocate the array, which it can't on PPC because PPC has precise stack scavenging. 18:09:26 And then there's a couple ideas that I've had with respect to new GC stuff... 18:09:37 Too many projects, not enough time. 18:09:52 you mean, not enough funding 18:11:26 *stassats* likes his change to the sb-introspect to find vops by names, not by :translate 18:11:32 quite useful for M-. 18:11:50 s/not/not just/ 18:12:01 No, time. Leaving my current employment would be a bad idea at this point. 18:12:31 even for a high-paying sbcl-development gig? 18:12:48 -!- yacks [~py@180.151.36.168] has quit [Quit: Leaving] 18:13:13 Oh yeah, sb-introspect. "Let's use internal symbols from SB-VM to grovel through the GC page tables". What a STELLAR idea. /-: 18:13:22 Even then. 18:13:55 that must be one cozy employment 18:14:15 Stock options and job security. 18:14:45 fair enough 18:15:17 Of course, if the company folds, that's another matter. But until and unless... 18:15:58 yacks [~py@180.151.36.168] has joined #sbcl 18:16:42 sb-introspect:find-definition-sources-by-name still lacks ir2-convert support 18:33:09 Oh, and another item on my project list is my SBCL arm port, and yet another is my CLIM implementation (nowhere near usable, yet)... 18:34:13 my project list is "make sbcl less buggy, more fast, more featureful" 18:34:29 and "more documented" somewhere in there too 18:36:23 And find the pony that has to be in there somewhere? 18:42:10 making introspect find ir2-convert was easy 18:43:25 also fixing the bug of listing LTN-ANNOTATE twice 18:45:05 might as well add stack-allocate-result 18:48:20 -!- drmeister [~drmeister@166.137.85.68] has quit [Remote host closed the connection] 18:57:34 looks like 2 gsoc slots for sbcl, yay 18:57:49 that's not much 19:00:57 It's better than nothing. 19:01:11 Infinitely better than nothing, in fact. 19:01:18 (percentage-wise) 19:01:24 i assumed 2 was the minimum they would allocate 19:03:02 2 was the presumed maximum for first-year organizations 19:03:25 1 was a real possibility. There is also a waiting list for slot transfers, in case organizations have been given more than they can support 19:03:56 tsuru` [~charlie@adsl-74-179-17-55.bna.bellsouth.net] has joined #sbcl 19:04:07 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 19:04:27 also, and without prejudice to the ongoing evaluation, to my eye there are at most three proposals which are sufficiently plausible to spend a fair amount of mentoring time on 19:04:27 Okay, so this is actually a good result for us at this time? 19:04:31 I think this is good 19:05:27 nyef: I think I'm about to buy a couple of arm systems. If I can work up the enthusiasm, maybe I might spend some time over the summer on the arm port, if you're willing to share? 19:06:22 Sure. And I've just got a working Raspberry Pi environment as of last... Thursday? I'm thinking about spending a little time on it myself. 19:07:11 While I have your attention, however, I'm thinking of committing http://repo.or.cz/w/sbcl/nyef.git/commitdiff/7c28a133ed9d81d4bf8807849b52d2235178e80a modulo the bit that breaks sb-introspect, without breaking it up any further. Does it look reasonable to you? 19:07:21 another question. Is the MPS OpenDlyan exception acceptable to sbcl culture? 19:07:34 (And, yes, it's since been tested on PPC.) 19:08:05 Would we be leaving MPS as a build-time option rather than the default? 19:08:16 is MPS really that good? 19:08:26 (or is our gc just that bad) 19:09:02 who knows? 19:09:41 i mean, e.g., conservatives can't be fixed by just swapping a gc 19:09:58 conservativness, damn flyspell 19:10:01 It would be a significant change in how GC is implemented, definitely 19:10:06 gencgc is only conservative on half of the platforms that it runs on. 19:10:13 it has many useful features that gengc lacks 19:10:38 What features, and are they things that we might consider just implementing for ourselves? 19:10:43 stassats: if you know the data is to be pinned, you can declare it as such. 19:11:20 nyef: based on the commit message, that looks great :) and frankly I can't believe that the code can be any worse than the existing code, even without knowing your track record 19:11:22 so go ahead 19:11:36 Krystof: Okay, thanks. 19:12:15 nyef: complete abstraction layer over multithreaded virtual memory support for several platforms that seems a bit more mature than SBCL's code, at least in terms of organization. Also, extensible protocols for designing custom memory pools that implement specific behaviour tuned to various uses 19:12:39 *stassats* sees "buzzword buzzword buzzword buzzword" 19:12:43 sorry 19:12:50 though due to certain changes, I think I'll ask that my proposal isn't taken :/ 19:13:14 stassats: nah, I understand. It definitely seems buzzwordy 19:13:27 not crapping out when a major gc is triggered after heap is half-full would be a nice feature to have 19:13:36 *nyef* sees "cleaner memory and signal context interface" and "special allocation region policies". 19:13:59 jsnell_: Would a mark-sweep collector for older generations work for that? 19:14:02 of course a lot of GCs would share that property, but few tend to be explicitly designed to be plugged in to other systems 19:14:09 jsnell_: there's support for dynamic growing, although documentation warns of fragmentation losses 19:15:19 nyef: yeah, and that's certainly been talked about over the years 19:16:14 I don't consider dynamic growing of the heap to be a fix to the problem 19:16:23 I've also been thinking about the read-barrier trick from Azul. That could be fun, too. 19:16:27 jsnell_: ah, thought of a different issue 19:16:40 nyef: isn't their trick rather... low level? 19:16:47 ... so? 19:17:55 nyef: many kinds of allocation pools with different collection algorithms, telemetry 19:17:57 nyef: as in "cpu vendor specific and superuser-requiring" 19:18:47 p_l|omoikane: Okay, that could be more of an issue. Still, it could be interesting. 19:19:01 nyef: definitely interesting 19:19:17 fe[nl]ix: What sort of telemetry? 19:21:25 -!- Snamich [~Snamich@netblock-68-183-229-245.dslextreme.com] has quit [Quit: Snamich] 19:22:06 drmeister [~drmeister@75.151.187.201] has joined #sbcl 19:23:41 nyef: http://www.ravenbrook.com/project/mps/master/manual/html/topic/telemetry.html 19:24:08 nyef: IIRC enough to get visualization of memory layout, among other things, though I don't remember details now - also, it's exported externally among other things, which is something I sometimes really, really wish I had in SBCL (though I guess I should rather look into implementing Linux Tracing + DTrace agents) 19:24:28 Hrm. 19:24:37 Yay, more stuff to read. Thanks. 19:24:40 haha 19:25:09 nyef: I found out yesterday that I need to refresh myself on deep tracing of Linux kernel/OS resources :> 19:25:40 p_l|omoikane: yes, what a shame 19:26:06 stassats: more like "bring me my brown pants" moment 19:37:20 ... The list of supported platforms for MPS is... rather anemic compared to SBCL. 19:38:37 nyef: where's it listed? 19:39:40 oh, found it. 19:39:54 x86 and x86-64, on lots of OSes. 19:40:27 We run on more OSes on those CPUs, and more CPUs as well. 19:40:53 does it look hard to port? 19:40:53 *stassats* looks at https://bugs.launchpad.net/sbcl/+bug/1099500 19:41:22 looks like the function calls advance the frame pointer, but debug-vars are not offset accordingly 19:41:23 stassats: Good luck! 19:41:24 so, um, I actually asked not about all these nice technical discussions of MPS, but about the licence exception 19:41:39 I'd assume it would be pretty easy to port to other OSes, and somewhat difficult to port to other CPUs. 19:42:23 the OS-specific stuff i glanced at looked odd, like how on some windows it casts a jmpbuf to an array 19:43:57 Krystof: I'm finding the Open Dylan exception to be difficult to interpret in terms of allowed and disallowed actions, and that leads me to be disinclined to approve of it. 19:44:11 and the variable is in the same location on the stack, not sure what to do here 19:46:02 Krystof: The exception looks fine to me. 19:46:36 stassats: If you get a compiler trace of the function, are the VOPs ANCESTOR-CELL-REF and ANCESTOR-CELL-SET used at all? If you treat the bogus values as addresses in memory, do they point to the "correct" value? 19:47:15 well, i if i offset the fp by 128, i get the correct value for the top frame 19:48:54 ANCESTOR-FRAME-REF and ANCESTOR-FRAME-SET are used 19:49:24 i see no ancestor-cell-ref, i assume these was meant by you 19:49:58 ";;; Accessing a slot from an earlier stack frame is definite hackery." 19:50:10 Yeah, sorry, it's been a while since I wrote those VOPs. (-: 19:50:37 so, are debug-vars badly encoded? 19:50:55 -!- drmeister [~drmeister@75.151.187.201] has quit [Remote host closed the connection] 19:51:13 The debugger doesn't know about this scheme for eliding value-cells. 19:51:35 Krystof: The exception looks fine to me as well, as long as we're certain that non-MPS builds are completely unencumbered 19:51:43 So not only are the debug-vars wrongly encoded, the right encoding isn't even defined. 19:55:31 so, it somehow needs to know the parent frame 19:56:04 which can be arbitrarily down the stack 19:56:18 There's a pointer available within the current frame. 19:58:54 ok, so it needs to encode it somehow and i need to learn how debug-vars are encoded 19:59:43 Either that, or there will turn out to be some easy way to distinguish between the two cases given the information already available, and you just have to hack the debugger to do the right thing. 20:01:50 "FIXME: old CMU CL representation follows:" 20:01:53 great... 20:03:05 Did I mention tearing apart the compiler and debugger yet today? 20:03:32 what will be left? 20:04:05 *stassats* needs to learn all the SBCL's mistakes first, before repeating them 20:06:13 Mmm. And there are some spectacularly dreadful bits of code in SBCL. 20:07:13 what's the difference between primary location and save location? 20:07:48 is save location used when a variable is set? 20:08:58 Save location is used for register spills, isn't it? 20:09:06 i have no idea! 20:09:52 nyef: yes. 20:10:02 spills or just caller-save. 20:10:12 Mmm. And I've never really dealt with debug-info, and am coming at this from the perspective of a compiler backend hacker. 20:11:32 -!- Bike [~Glossina@71-34-72-185.ptld.qwest.net] has quit [Quit: restarting] 20:13:18 ok, that's enough of looking at SBCL for tonight 20:13:30 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: dead] 20:16:23 How do you reproduce this, btw? Just pasting the LET form into a REPL gets me something involving SIMPLE-EVAL-IN-LEXENV as the topmost frame. 20:16:35 Bike [~Glossina@71-34-72-185.ptld.qwest.net] has joined #sbcl 20:16:54 try adding debug 2 20:17:07 i always use it, so i may forget to include it 20:17:40 (declaim (optimize (debug 2))) ? 20:17:47 Bike_ [~Glossina@71-34-72-185.ptld.qwest.net] has joined #sbcl 20:18:04 Hrm. Better, but no local variable list. 20:18:31 Setting debug 3 doesn't help either. 20:18:56 well, try compiling it then 20:19:07 I can get variables by using the L command. 20:19:16 and that's on x86-64, as usual 20:20:00 (let ((a 1)) (declare (optimize debug)) (labels ((f1 () (princ a) (incf a) (break)) (f2 () (f1))) (f2))) does the job 20:20:51 ... Still have to use L to get the local variables. 20:21:01 don't you always? 20:21:13 i don't really use the command line debugger 20:21:20 Ah, okay. 20:21:31 -!- Bike [~Glossina@71-34-72-185.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 20:21:43 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 20:22:10 Ahh... It's an untagged aligned pointer being interpreted as a fixnum. 20:23:22 Hrm. Frame pointer. Damnit. 20:30:44 -!- Bike_ is now known as Bike 20:38:10 Wow. If you have a value-cell legitimately stored in a variable, the debugger will only show you the contents of the value-cell. 20:40:05 -!- sdemarre [~serge@91.180.118.78] has quit [Ping timeout: 248 seconds] 20:44:08 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 21:08:10 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 21:16:19 <|3b|> would adding MPS help make GC times more predictable? 21:17:57 *|3b|* sees it claims to support 'multiple concurrent incremental GCs', which sounds promising 21:18:15 nyef: MPS seems to support also PPC, and I have seen mentions of support for Alpha, and I suspect SPARC is there too 21:18:53 maybe they have two definitions of support. 21:18:59 p_l|omoikane: MPS took some platforms out of its supported list some time ago. 21:19:15 |3b|: probably refers to how each allocation pool has its own specialized GC algorithm, so you can have specific stuff for different kinds of data, but there's one pause 21:19:16 "Has some code for which might work", and "We actually care about this and actively support it" 21:19:57 foom: the second is probably "actively release open-source code for it 21:20:00 *|3b|* will soon have use for predictably small GC pauses, would be nice to not have to run completely non-consing 21:20:39 <|3b|> (where 'small' is in the few-ms or less range) 21:22:19 |3b|: Do you have periods where you can release all of your allocated data or can release most of it and know which data you need to keep and where all the pointers to it are? 21:22:56 <|3b|> nyef: not really, or at least not often enough that i wouldn't need to run without consing in between anyway 21:23:37 Hrm. 21:24:18 So a tightly-controlled nursery generation and explicit eviction into the larger heap isn't a viable option for you... 21:24:41 *|3b|* is getting a VR display with head tracking (oculus rift for those familiar with it), and consistent and low latency is important for that sort of thing (to the point that 16ms to update the display is an issue) 21:25:56 <|3b|> for now i'll probably just try to avoid consing, but if i could sacrifice a few ms/frame to just not have to worry about it, that would be nice :) 21:33:27 Okay, time I got moving. 21:33:30 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:33:42 Watcher7 [~w@silly.tabby.cat] has joined #sbcl 22:15:10 mc40 [~mc@host86-148-141-128.range86-148.btcentralplus.com] has joined #sbcl 22:19:11 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 22:23:01 -!- Bike [~Glossina@71-34-72-185.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 22:33:14 Bike [~Glossina@71-34-72-185.ptld.qwest.net] has joined #sbcl 22:33:46 -!- mc40 [~mc@host86-148-141-128.range86-148.btcentralplus.com] has quit [Quit: mc40] 22:42:11 -!- segv- [~mb@95-91-241-75-dynip.superkabel.de] has quit [Remote host closed the connection] 22:42:40 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 22:42:54 -!- davazp [~user@92.251.211.108.threembb.ie] has quit [Remote host closed the connection] 22:46:28 Snamich [~Snamich@netblock-68-183-229-245.dslextreme.com] has joined #sbcl 23:21:59 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Ping timeout: 258 seconds] 23:49:44 ASau` [~user@p5797F5ED.dip0.t-ipconnect.de] has joined #sbcl 23:53:31 -!- ASau [~user@p5797F512.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 23:57:48 -!- Bike [~Glossina@71-34-72-185.ptld.qwest.net] has quit [Quit: fuck you, xterm]