00:00:07 -!- ASau [~user@p5083D448.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 00:04:45 wbooze [~oleo@xdsl-78-35-185-226.netcologne.de] has joined #sbcl 00:05:33 -!- oleo is now known as Guest57559 00:06:35 -!- Guest57559 [~oleo@xdsl-78-35-189-114.netcologne.de] has quit [Ping timeout: 260 seconds] 00:07:07 -!- wbooze is now known as oleo 00:38:43 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 00:50:58 -!- LiamH [~none@96.231.217.60] has quit [Quit: Leaving.] 01:31:38 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 02:00:29 -!- davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] 02:49:09 -!- prxq_ [~mommer@x2f67763.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 03:03:00 prxq_ [~mommer@x2f69530.dyn.telefonica.de] has joined #sbcl 03:38:29 -!- christoph_debian [~christoph@ppp-88-217-46-199.dynamic.mnet-online.de] has quit [Ping timeout: 240 seconds] 03:52:46 christoph_debian [~christoph@ppp-88-217-39-101.dynamic.mnet-online.de] has joined #sbcl 04:08:20 jhao [~user@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 04:19:12 -!- ASau` is now known as ASau 04:35:02 scymtym__ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 04:40:48 bege_ [~bege@S0106001d7e5132b0.ed.shawcable.net] has joined #sbcl 04:42:29 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:51:13 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 05:08:36 -!- bege [~bege@S0106001d7e5132b0.ed.shawcable.net] has quit [Write error: Connection timed out] 05:09:21 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Write error: Broken pipe] 05:09:37 -!- luis [~luis@kerno.org] has quit [Ping timeout: 327 seconds] 05:09:44 luis` [~luis@kerno.org] has joined #sbcl 05:15:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 264 seconds] 05:29:32 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:59:09 -!- nyef [~nyef@pool-108-7-220-91.bstnma.fios.verizon.net] has quit [Quit: G'night all.] 06:27:24 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 06:28:25 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:28:30 -!- slyrus [~chatzilla@12.33.10.180] has quit [Ping timeout: 252 seconds] 06:38:00 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:20:09 -!- drmeister is now known as meister_ 07:20:15 -!- meister_ is now known as drmeister 07:24:03 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 07:35:25 -!- jhao [~user@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Ping timeout: 265 seconds] 07:40:19 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 07:48:15 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 252 seconds] 07:51:30 slyrus [~chatzilla@12.33.10.180] has joined #sbcl 08:58:07 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 09:41:45 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:30:45 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 10:36:48 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:47:07 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 10:51:15 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds] 10:55:46 -!- fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has quit [Quit: Leaving] 10:58:33 fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has joined #sbcl 10:59:41 pnpuff [~nnaylloh@unaffiliated/pnpuff] has joined #sbcl 11:08:31 -!- pnpuff [~nnaylloh@unaffiliated/pnpuff] has quit [Remote host closed the connection] 11:11:39 logand` [~user@f052052081.adsl.alicedsl.de] has joined #sbcl 11:15:17 -!- logand [~user@g225155136.adsl.alicedsl.de] has quit [Ping timeout: 248 seconds] 11:19:59 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 11:25:49 pnpuff [~harmonic@unaffiliated/pnpuff] has joined #sbcl 11:50:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 11:51:00 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:53:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 11:54:02 attila_lendvai [~attila_le@5.76.185.228] has joined #sbcl 11:54:02 -!- attila_lendvai [~attila_le@5.76.185.228] has quit [Changing host] 11:54:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:14:06 -!- pnpuff [~harmonic@unaffiliated/pnpuff] has quit [Remote host closed the connection] 12:23:48 -!- oleo [~oleo@xdsl-78-35-185-226.netcologne.de] has quit [Ping timeout: 252 seconds] 12:24:33 oleo [~oleo@xdsl-78-35-154-29.netcologne.de] has joined #sbcl 12:28:28 davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has joined #sbcl 12:34:08 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 12:35:47 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 12:40:53 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 12:58:21 -!- logand` [~user@f052052081.adsl.alicedsl.de] has quit [Remote host closed the connection] 12:58:51 logand` [~user@f052052081.adsl.alicedsl.de] has joined #sbcl 13:25:54 nyef [~nyef@pool-108-7-220-91.bstnma.fios.verizon.net] has joined #sbcl 13:26:21 -!- slyrus [~chatzilla@12.33.10.180] has quit [Read error: Connection reset by peer] 13:28:09 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 252 seconds] 13:29:23 pranavrc [~pranavrc@122.164.126.148] has joined #sbcl 13:29:24 -!- pranavrc [~pranavrc@122.164.126.148] has quit [Changing host] 13:29:24 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 13:31:23 slyrus [~chatzilla@12.33.10.180] has joined #sbcl 13:41:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 13:47:14 -!- slyrus [~chatzilla@12.33.10.180] has quit [Read error: Connection reset by peer] 13:51:38 slyrus [~chatzilla@12.33.10.180] has joined #sbcl 13:56:10 leuler [~user@p548F9409.dip0.t-ipconnect.de] has joined #sbcl 13:59:59 LiamH [~none@96.231.217.60] has joined #sbcl 14:25:06 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 14:27:06 jhao [~user@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 14:29:25 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 15:04:57 -!- milosn [~milosn@94.12.79.143] has quit [Ping timeout: 252 seconds] 15:06:04 milosn [~milosn@94.12.79.143] has joined #sbcl 15:11:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:19:42 -!- prxq_ is now known as prxq 16:13:46 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 16:16:09 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 16:27:01 fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has joined #sbcl 16:27:14 good evening nyef 16:30:12 -!- slyrus [~chatzilla@12.33.10.180] has quit [Ping timeout: 252 seconds] 16:31:37 I may have accidentally started work on an ILC paper. 16:34:24 There's a small class of codewalkers that can be made to compose (e.g., ANF transformation, but not CPS). We'll see if I can make IR1 translation support them nicely. 16:37:45 minion: memo for stassats: btw, if you ever write a git->rss gateway, sorting entries by commit date rather than author date, that would be useful. 16:37:45 Remembered. I'll tell stassats when he/she/it next speaks. 16:44:12 Hello fiveop, all. 16:46:15 pkhuong: glad to hear it; sad that I can't make ILC 16:47:22 and ELS doesn't seem plausible for me, sadly. 16:48:20 I'll probably email you for advice and guidance (: 16:52:12 nyef: I'm still wading through the code for calls. I have some specific and some broader questions, whose answer might help me a long quite a bit. 16:53:09 Okay, go ahead then. 16:53:49 -!- davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] 16:54:19 Let's start with specifics. 16:55:09 VOP CALL-LOCAL for ARM uses function DEFAULT-UNKNOWN-VALUES, right after the return-pc label. 16:55:40 DEFAULT-UNKNOWN-VALUES seems to nil every value location. Wouldn't you want to use the returned values? 16:56:36 Which part of default-unknown-values are you looking at here? 16:56:40 Another question, whose answer might help with my confusion in this case, is: What's the difference between call-local and multiple-call-local. 16:57:39 multiple-call-local receives an unbounded set of values as multiple-value lvar. call-local receives a specific set of values as a set of single-value lvars. 16:58:20 Forget the first question. 1 is not 0 und there is a R0. 16:58:21 You can see the logic used to dispatch to the correct VOP in ir2tran somewhere. 16:58:51 I will say that the ARM default-unknown-values is a lot nicer than that on any other platform. (-: 16:59:13 now I'm interested (: 16:59:40 pkhuong: Having predicated code means that we don't need the elsewhere segment. 17:00:32 I'll refrain from thinking about predictability and density in the common case. 17:00:40 Oh, and like on x86oids, we use status flags to signal a single or multiple valued return. 17:02:44 interesting: Unexpected success: threads.pure.lisp / (SEMAPHORE-NOTIFICATION WAIT-ON-SEMAPHORE LP-1038034) 17:03:28 (darwin/x86-64) 17:04:02 Is this one way to have a caller not know the number of returned variables: (lambda (c) (if c (values 1 2) (values 1 2 3))) ? 17:04:32 Not in a local call. 17:04:57 How would, even in a local call, the caller know the number of returned values? 17:04:58 Try something with multiple-value-prog1 or values-list, or multiple-value-call... 17:05:25 In a local call, the compiler can propagate the information that it's /expecting/ some number of values back up the line. 17:05:37 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 17:05:47 what if a local function also has an xep? 17:06:02 Then the xep calls the truly local function. 17:06:19 Too bad we don't do the same for representation :\ 17:06:34 That's sortof what an XEP is, a special wrapper that calls a local function, and then the local function typically gets let-converted. 17:06:55 (defun a (b) (flet ((c (d) (if d (values 1 2) (values 1 2 3)))) (c b))) 17:07:03 I've been digging into the scheduler part of the assembler recently, and it's a bit scary at how weak it is. 17:07:07 now how would the compiler know whether to expect 2 or 3 arguments? 17:07:32 That's going to get let-converted anyway, isn't it? 17:07:33 I think the scheduler's main/only use is to handle branch delay slots. 17:07:40 What does let convert mean? 17:08:10 attila_lendvai [~attila_le@5.76.185.228] has joined #sbcl 17:08:10 -!- attila_lendvai [~attila_le@5.76.185.228] has quit [Changing host] 17:08:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:08:14 The function gets inlined as a LET form, and further simplified from there. 17:08:40 because it's only called once? 17:08:47 Pretty much, yeah. 17:09:18 Another question: is XEP-ALLOCATE-FRAME essentialy the beginning of a code object? 17:09:43 Only started running into local functions once I was trying to get unwind-protect going, because the cleanup fun is called both from the NLE and from the main flow. 17:09:45 It looks like it, because it begins with the simple-fun-header. 17:10:07 It's not necessarily the start of the code object, as a local-fun could in theory wind up there. 17:10:54 But it is a main entry point into the code object. 17:10:56 My goal is to understand how top level forms are converted into code objects in memory, I guess. 17:11:01 Which is what the compiler does, right? 17:11:12 In memory or in a fasl file. 17:11:46 It looked to me, like things are always compiled first to fasl and then loaded back. 17:11:59 I was looking at compiler/main then 17:12:45 Do local calls always happen within code that is stored in a single code object? 17:13:04 Yes, local calls are always within a single component. 17:13:54 So component has somewhat of an isomorphism relationship with code object? 17:16:02 There's a bit where components can be stuck together to form larger components, but in the end a code object is built based on a single (possibly aggregate) component. 17:16:59 I think the aggregation happens when inlining? My memory is hazy here. 17:17:48 The unkown and known terms in the context of returning values have to do with their locations and the knowledge of the copmiler, correct? 17:18:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 17:18:44 Sortof. It has to do with the compiler deciding to treat them as an aggregate multiple-value object or as separate values. 17:19:21 As far as compiling to a fasl or to memory is concerned, have a look through compiler/main for references to *compile-object*. 17:20:05 Yes, that's mentioned in the comments of COMPILE. 17:20:46 I was trying to follow the path of a simple (defun test (a) (+ a a)) through the compiler. 17:21:03 The problem was following (sb-int:named-lambda ...) 17:21:31 processing that somewhere must be the actual compilation process, because everything else didn't work with the form. 17:21:50 (or rather the body of the function) 17:23:30 You probably end up somewhere in ir1-convert-lambdalike? 17:25:06 At which point you're at the toplevel entry to a codewalker that produces implicit-continuation-representation form from the function source. 17:25:44 nyef: yes 17:26:13 SBCL uses CR? 17:26:42 ICR, known as IR1. 17:27:01 It's similar to CPS, but without explicit continuations most of the time. 17:29:34 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 17:30:03 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 17:31:25 Basically, the IR1-{translate,convert} stuff turns Lisp source code into structures defined in compiler/node. 17:33:05 Last question for today: what is the code register for? 17:35:01 The main two things that the CODE register is for is easy access to the boxed constants vector, and to provide an anchor point so that the GC knows where and how to adjust the program counter (and link register, if we're in the middle of a function call/return scenario) when a GC is triggered. 17:36:51 If and when we get around to trying to add threading support, the CODE register is one which I might attempt to dispense with, though it would complicate both access to boxed constant data and the garbage collector. 17:37:02 attila_lendvai [~attila_le@5.76.185.228] has joined #sbcl 17:37:02 -!- attila_lendvai [~attila_le@5.76.185.228] has quit [Changing host] 17:37:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:37:23 So what does it hold? 17:37:58 My guess would be a pointer to the code object the currently running code resides in. 17:37:59 A boxed reference to the code object. 17:38:03 ok 17:38:04 Yes. 17:38:56 You'll see it recomputed using a dreadfully clever instruction sequence in compiler/arm/insts, towards the end. 17:39:14 I looked at that 17:39:52 thank you 17:40:21 The current goal is to understand enough to implement fun_end_breakpoint stuff in runtime/arm-assem.S 17:40:24 I'm not there yet :) 17:41:21 Ahh. You really don't need to have that working until we're in a position to run the debugger. 17:41:56 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 17:42:47 But debug-int is not compiling. I wanted to skip it, but then "enc-basic" was missing some "WARM symbols" at the linking stage, so I thought, let's not skip anything 17:43:23 I'd've just slapped the symbols in place with a FIXME comment to fill in later. 17:43:59 the problem with the error message is, that it doesn't tell you which 17:44:03 it probably even can't 17:44:38 Mmm. And I fixed up the last unimplemented case of it a while ago. 17:44:45 see warm-symbol in compiler/generic/genesis 17:45:57 Commit 485053aa46c262f9c357cf5cf48d8f6c3f6e8223 has the damage. 17:47:09 I think you misunderstood me. 17:47:29 you are still talking about fun_end_breakpoint_...? 17:47:32 Yeah. 17:48:24 Now I get what you meant by 19:43 < nyef> I'd've just slapped the symbols in place with a FIXME comment to fill in later. 17:48:25 Hrm. The (error "no warm symbol") thing? 17:48:48 Just slap it in the assem file? 17:48:56 Yeah. 17:49:26 Looks like there has to be some body there, but it's just 32-bit zero words, and it'll at least build enough that the debugger will compile. 17:49:32 (Or, at least, not choke on it.) 17:49:39 I'm not even sure it'll fix the no warm symbol problem. But it looks like it is missing something that should be compiled as part of another file and then is missing at 'linktime' 17:50:04 Mmm. I'm looking for an angle on "no warm symbol" now. 17:50:31 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 17:51:38 My problem is, I'm not on my machine where config/host/NFS to Raspberry is setup. (My wife is using it). So all I can do is read code, this evening :) 17:54:39 So, cold-fdefinition and fop-fset are the possible ways to get an uninterned cold symbol. 17:55:55 Err... fop-fdefinition, not cold-fdefinition, sorry. 18:00:37 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:09:02 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 18:18:02 What does NL in the NL2 and NL3 register names stand for? 18:18:22 "Non-Lisp" 18:18:42 So, for unboxed data. 18:21:13 thanks 18:21:34 I'm reading the beauty that is DEFINE-FULL-CALL :) 18:22:24 fiveop: what are you doing? 18:22:55 "Beauty" isn't the word that comes to my mind when I look at DEFINE-FULL-CALL. 18:23:15 Re: issues popping up with the new register allocator: I got a fix to disassemble 4990 into XCHG RAX, R8 on x86-64. I am polishing it up now. 18:23:55 ams: trying to understand the different calling conventions used by the compiler 18:24:02 leuler: aweomse, thank you. 18:24:13 ah, i just saw that you said something about rpi 18:24:47 That'd be because we're working on an ARM port of SBCL. 18:24:55 nyef is porting sbcl to arm and I'm trying to help, because I want to use it on my rpi 18:25:20 ah, better yet .. since i'm working on it as well .. but for beaglebone black 18:25:36 ... you are? 18:25:40 yes 18:25:50 Where'd you start from, and how far have you gotten? 18:26:24 nyef: before i saw your tree, i had my own attempt on an arm port, though yours is more complete 18:27:05 pkhuong: I just hope Stas didn't put too much work into it already. 18:27:12 Mmm. What's the FPU and float ABI on the beaglebone? VFP somethingorother and hard-float? 18:27:37 (I have a beaglebone, but haven't set it up yet, since my rpi works well enough for the moment.) 18:29:09 nyef: vfp, and hfloat .. 18:29:25 i've been having some issues with my bbb and arch gnu/linux 18:31:07 sdemarre [~serge@91.180.79.21] has joined #sbcl 18:32:18 Well, even after we get this thing to produce a working cold-core, there's going to be a pile of work to do. 18:32:35 nod 18:33:53 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 18:34:41 nyef: in define-full-call/do-next-filler, when is (consp next) ever do? 18:34:43 -do+true 18:38:03 I don't know that it ever is. 18:39:24 so what is unnecessary? 18:39:41 I don't know if it is or not. 18:40:50 This is one of those pieces of code that has a lot of history behind it and is fiendishly complicated, so figuring out why it is the way it is becomes a difficult-to-impossible task. 18:42:24 pkhuong: Adding this to the XCHG instruction definition already suffices: (:printer two-bytes ((op '(#x49 #x90))) '(:name :tab 'rax ", " 'r8)), but I wanted something more thorough, so the change is a bit larger ;-) 18:43:10 I am totally sucking at keeping up with arm port stuff 18:43:21 but when we get to booting cold-init.core, I expect to be able to contribute rather more 18:43:37 at least from remembering the order in which things normally go wrong :-) 18:43:43 Heh. 18:43:53 Maybe this month? 18:44:35 The ability to mis-compile floating-point stuff is one of the last big pieces before we should be able to start running !cold-init. 18:45:15 first use of floating point is very early in cold-init :-) 18:45:40 we find out very quickly if we can't load float constants or do comparisons 18:45:47 (hash tables, needed for packages) 18:46:06 slyrus [~chatzilla@12.33.10.180] has joined #sbcl 18:46:11 Right now we can't even compile floating point. 18:47:06 I have the ARM ARM open to the chapter that contains the VFP instruction definitions so that I can try to add them to the assembler, and then I got whacked by both work and the SPARC build issues. 18:47:52 yeah, sorry 18:48:19 Not entirely your fault. (-: 18:48:25 an arm boot would be nice from a personal perspective, but sorting out the register allocator from a project perspective is probably more important 18:48:33 Exactly. 18:48:42 also, I should write my lisp-flavoured papers for the year this month if I want to be going to conferences 18:49:15 Krystof: write about porting sbcl to arm .. and show an working port =) 18:49:22 I don't think we DTRT when binding specials with (declaim (type *foo* (function (...) ...))) 18:49:45 And the digging I've done into the register allocator stuff taught me how the scheduler works for the assembler, so it's not all bad. 18:50:14 nyef: are you cross compiling or using ccl? 18:50:29 "Cannot bind *COMPILER-ERROR-BAILOUT* to #, not of type (FUNCTION (&OPTIONAL CONDITION) NIL)." seems suboptimal. 18:50:59 ams: I'm cross-compiling from an x86-64/linux box. 18:52:11 interesting .. i'm doing my devel directly on the board 18:52:39 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:54:42 Um... Can we have function names that are lists with more than two symbols? 18:55:57 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 18:57:40 yes 18:57:56 I was afraid of that. Would they show up in enc-basic? 18:58:04 I wouldn't have expected so 18:58:26 Which very carefully isn't a no. 18:58:51 The other possibility is non-symbol components in a function name... 18:59:53 oh but wait there are more exotic function names than when I made them up 18:59:53 leuler: if your disassembly skills are fresh, can you help with XCHG RAX, R8 being decoded as NOP? 18:59:54 stassats, memo from pkhuong: btw, if you ever write a git->rss gateway, sorting entries by commit date rather than author date, that would be useful. 19:02:01 gah totally ungreppable 19:02:12 where are (defmacro foo) or (macrolet foo) function names used? 19:02:33 (defmacro foo) is for macro functions 19:02:35 iirc 19:02:56 So... (defmacro (setf foo)) might be plausible, if horrifying? 19:04:36 (DEFMACRO FOO) is the name of the named-lambda of a macro function, which is later renamed to (MACRO-FUNCTION FOO) 19:05:18 stassats: Please see today's log, around half an hour ago. I have it working; just need to polish the comments. 19:05:54 great, that's some ahead of time thinking 19:09:55 (nth-value 2 (function-lambda-expression (funcall (defun x () (flet (((setf x) ())) #'(setf x)))))) => (FLET (SETF X) :IN X) 19:10:29 Hrm. And if that ends up in an FDEFINITION or an FSET... 19:11:28 Krystof: Re arm vs. register allocator: I would have thought that the arm port is the most important thing currently to keep SBCL going forward as the platform becomes ever more widely used. What do you mean with "sorting out the register allocator"? 19:12:54 leuler: The recent PACK changes have tickled latent VOP lifetime issues in several places, and we haven't tracked them all down yet. 19:14:58 -!- slyrus [~chatzilla@12.33.10.180] has quit [Read error: Connection reset by peer] 19:15:28 Ah yes. If that means silent miscompilation it's definitely high priority. 19:16:06 In some cases it means complete build failure. 19:17:19 Already helped stassats fix an issue with PPC lifetimes, and I'm fairly sure that it affects other platforms, but SPARC is worse off than PPC was. 19:18:18 ... Are we even going to be able to test Alpha or MIPS? 19:19:16 MIPS via gcc, I think. 19:19:22 Alpha... nobody cares. 19:22:16 gcc compiler farm doesn't seem any MIPS machines up 19:23:12 I can dig out my small MIPS setup next weekend to run a build, but it takes basically half a day for a single build on that thing. 19:23:49 i tried qemu mips emulation, but it kept crashing 19:24:24 not to mention being slow as hell 19:27:39 -!- leuler [~user@p548F9409.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 19:28:50 Krystof: something like . 19:30:28 leuler [~user@p548FAD9A.dip0.t-ipconnect.de] has joined #sbcl 19:31:05 nyef: Who is responsible for cleaning up the CS in a tail call? (define-full-call with :tail argument does seem to revert the NFP but does nothing with the CSP or CFP) 19:33:15 so %walk-sexp gets a partially parsed sexp that's either a leaf, a function call, or a standard special form; SEXP-BOX are only in value position. The hook is disabled for the expansion, until ir1-convert hits a sexp-box, and those re-enable the rewriter. 19:33:17 So, control-stack frames are caller-allocated and caller-freed. 19:33:37 izirku [~izirku@pool-173-71-18-32.dllstx.fios.verizon.net] has joined #sbcl 19:33:40 ... Except in multi-value return situations, in which more complicated things happen. 19:33:59 but isn't define-full-call in the caller? 19:34:12 Yes, it is. 19:34:39 so I would expect it to free the control-stack frame in the tail case 19:34:55 And on ARM, we pass the OCFP and LRA on the stack, so the tail-call case only needs to deal with cleaning up the number stack allocation, because the function being called will set the stack frame size once it's dealt with its parameters. 19:35:40 (And will allocate its own number-stack frame if it needs one.) 19:35:59 So, control-stack is caller-allocated while number-stack is callee-allocated. 19:36:28 fiveop: for tail calls, the current frame overwrites itself, and its own (non-tail) caller will eventually clean the rest up. That's why it's a tail call. 19:38:28 we just 'forget' about the csp build up by us, where us is the tail calling code 19:39:17 ? 19:39:47 The CSP only needs to be positioned to cover all of the arguments so that they don't get overwritten by stray interrupts or by the GC, and the inbound frame resets it based on the arguments that it has and the position of the CFP, which is unchanged. 19:41:39 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 19:43:44 awssome .. got vlm running on arm all the way to fep.. now to fix about 1000 bugs to get a world loaded. 19:45:40 Heh. Might be interesting for you to try and get, say, one of the explorer emulators going as well. 19:46:33 hehe 19:47:49 if anything, i might spend sometime rewriting the alpha code into (proper) C code.. already got a slew of fixes that make vlm run really spiffy 19:55:21 nyef: is csp in general just used for the GC to know when to stop? 19:56:07 No, it's also the allocation pointer for new stack frames, unknown-values LVARs and dynamic-extent objects. 19:57:18 It occurs to me that we're probably going to have to do some juggling in the runtime to get everything to come out correctly with respect to stacks in signal handling. 19:57:29 -!- sdemarre [~serge@91.180.79.21] has quit [Ping timeout: 240 seconds] 19:58:38 mc40 [~mcheema@146.255.107.122] has joined #sbcl 19:58:55 -!- mc40 [~mcheema@146.255.107.122] has left #sbcl 20:14:39 -!- izirku [~izirku@pool-173-71-18-32.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 20:17:49 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 20:24:36 "The value #1=#1# is not of type (OR SB-KERNEL:LEXENV NULL)." interesting 20:38:56 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 20:43:33 gn8 20:43:34 -!- fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has quit [Quit: leaving] 20:53:44 this should be good enough for stepping and cover as pure contribs. 21:35:53 -!- ams [ams@gnu/inetutils/ams] has quit [Excess Flood] 21:46:15 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 260 seconds] 21:52:29 -!- bege_ is now known as bege 23:24:36 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: experience finished because execution expired] 23:27:23 -!- leuler [~user@p548FAD9A.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:55:07 davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has joined #sbcl 23:56:33 -!- LiamH [~none@96.231.217.60] has quit [Quit: Leaving.] 23:56:58 ASau` [~user@p54AFF440.dip0.t-ipconnect.de] has joined #sbcl