00:11:45 -!- echo-area [~user@123.120.241.1] has quit [Read error: Connection reset by peer] 00:21:30 slyrus [~chatzilla@107.201.5.172] has joined #sbcl 00:41:13 -!- davazp [~user@92.251.156.228.threembb.ie] has quit [Remote host closed the connection] 00:41:32 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 01:11:18 -!- kwmiebach [~kwmiebach@xdsl-195-14-207-26.netcologne.de] has quit [Quit: Leaving] 01:11:38 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 01:59:55 -!- slyrus [~chatzilla@107.201.5.172] has quit [Read error: Connection reset by peer] 02:01:52 slyrus [~chatzilla@107.201.4.222] has joined #sbcl 02:12:56 ASau` [~user@p54AFF297.dip0.t-ipconnect.de] has joined #sbcl 02:16:09 -!- ASau [~user@p54AFF3EB.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 02:19:28 -!- ASau` is now known as ASau 02:26:51 echo-area [~user@182.92.247.2] has joined #sbcl 03:00:23 Fare: only the global binding is preserved. 03:01:34 pkhuong, is there a way to change the global binding below the current shadowing? 03:01:42 (that explains the bug I was seeing, indeed) 03:01:53 Thanks for the answer. 03:02:32 Bug fix: see ASDF 3.1.0.8. Oops. Proof that no one was relying on that interface this way, at least. 03:03:56 and now I understand what was happening: when I build normally, there's no issue, so I was never seeing a problem. But there, I build a small program that was using restore-image, and from there, with its special bindings, dumping a new image... that was couldn't set the actual global parameters. 03:04:26 Now that's what I call a subtle bug. 03:04:35 Works the first time around, not the second time. 03:11:33 -!- LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has left #sbcl 03:23:27 Fare: symbol-global-value. 03:23:45 not sure what happens on unthreaded builds. 03:25:23 pkhuong: good to know 03:25:27 thanks 03:28:22 btw, for historical purposes — were you the one who suggested loading files in interpreted, non-optimized mode, to speed up a large build? 03:29:18 it can indeed decrease latency ~4x as compared to waiting for the (c)fasl to compile and loading it. 03:29:41 I don't think so. I would guess jsnell. 03:29:45 ok 03:30:02 I didn't know whom to credit for the idea. 03:30:14 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Read error: Connection reset by peer] 03:32:08 I hope to see you in August in Montreal! 03:33:19 So do I, but I'll have to make the trip from NYC (: 03:34:15 oh wow do you live in NYC these days? 03:34:27 I hope to meet you at the next LispNYC, then 03:36:53 I'll be moving to work at AppNexus this January. 03:38:29 What underlying programming language will you be using? 03:39:11 -!- christoph_debian [~christoph@ppp-88-217-42-195.dynamic.mnet-online.de] has quit [Ping timeout: 272 seconds] 03:39:22 my experiments with python here are both satisfying and frustrating. 03:40:05 samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 03:40:20 C, for the most part. Probably some R and some random scripting, because that's how I try to think. 03:41:32 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 03:41:48 I've been moving my "random scripting" from zsh to cl, with some success so far. 03:43:42 in some ways, it's uglier than zsh because of the impedance mismatch. In another way, you get something richer and more robust in the end, because you have a real programming language with data structures and conditions, not just (arrays of) text strings and signals. 03:52:56 christoph_debian [~christoph@ppp-88-217-35-39.dynamic.mnet-online.de] has joined #sbcl 03:58:12 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 04:42:09 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 05:00:14 -!- Fare [fare@nat/google/x-einavjlqwyusmqtp] has quit [Ping timeout: 240 seconds] 05:21:49 -!- oleo [~oleo@xdsl-87-78-76-122.netcologne.de] has quit [Ping timeout: 252 seconds] 05:22:50 oleo [~oleo@xdsl-78-35-163-247.netcologne.de] has joined #sbcl 05:53:53 -!- oleo [~oleo@xdsl-78-35-163-247.netcologne.de] has quit [Remote host closed the connection] 06:03:43 prxq [~mommer@x2f68c59.dyn.telefonica.de] has joined #sbcl 06:13:45 -!- joshe [~joshe@2001:470:e862::1:1] has quit [Ping timeout: 245 seconds] 07:00:27 Munksgaard [~philip@80-71-132-106.u.parknet.dk] has joined #sbcl 07:20:04 sdemarre [~serge@109.134.146.216] has joined #sbcl 07:42:15 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 07:42:48 pegu [~user@c7F7CBF51.dhcp.as2116.net] has joined #sbcl 07:50:51 attila_lendvai [~attila_le@5.251.140.27] has joined #sbcl 07:50:51 -!- attila_lendvai [~attila_le@5.251.140.27] has quit [Changing host] 07:50:51 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:00:11 |3b|` [bbb@2600:3c00::f03c:91ff:fedf:5b65] has joined #sbcl 08:00:12 -!- |3b| [bbb@2600:3c00::f03c:91ff:fedf:5b65] has quit [Remote host closed the connection] 08:01:19 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 08:01:30 -!- |3b|` is now known as |3b| 08:15:15 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 08:15:48 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:24:03 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 252 seconds] 08:32:37 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 08:37:14 -!- Munksgaard [~philip@80-71-132-106.u.parknet.dk] has quit [Ping timeout: 244 seconds] 08:54:38 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 261 seconds] 08:55:14 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 08:56:00 -!- reb [user@nat/google/x-johbjhdskpummlam] has quit [Remote host closed the connection] 08:56:00 reb [user@nat/google/session] has joined #sbcl 08:56:00 -!- reb [user@nat/google/session] has quit [Changing host] 08:56:00 reb [user@nat/google/x-slkbxlnmbtmbwwup] has joined #sbcl 08:59:37 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 252 seconds] 09:10:18 Munksgaard [~philip@shop3.diku.dk] has joined #sbcl 09:19:34 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 09:34:07 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 272 seconds] 09:51:13 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 272 seconds] 09:58:11 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 10:02:08 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 10:02:26 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 10:02:30 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 245 seconds] 10:06:15 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 10:08:50 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:32:38 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 10:35:35 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 11:20:30 -!- sdemarre [~serge@109.134.146.216] has quit [Ping timeout: 252 seconds] 11:34:59 _8hzp [~user@87-93-84-94.bb.dnainternet.fi] has joined #sbcl 11:38:59 -!- _8hzp` [~user@178-55-158-129.bb.dnainternet.fi] has quit [Ping timeout: 272 seconds] 11:45:32 echo-area [~user@123.120.254.61] has joined #sbcl 11:48:08 gko_ [gko@114-32-172-194.HINET-IP.hinet.net] has joined #sbcl 11:57:23 sdemarre [~serge@109.134.146.216] has joined #sbcl 12:10:24 segv- [~mb@95-91-240-228-dynip.superkabel.de] has joined #sbcl 12:13:51 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:44:44 _8hzp` [~user@87-95-84-107.bb.dnainternet.fi] has joined #sbcl 12:48:28 -!- _8hzp [~user@87-93-84-94.bb.dnainternet.fi] has quit [Ping timeout: 264 seconds] 13:00:25 -!- sdemarre [~serge@109.134.146.216] has quit [Ping timeout: 245 seconds] 13:02:27 -!- Munksgaard [~philip@shop3.diku.dk] has quit [Ping timeout: 260 seconds] 13:06:16 teggi [~teggi@123.20.102.167] has joined #sbcl 13:25:37 LiamH [~none@129-2-129-146.wireless.umd.edu] has joined #sbcl 13:30:03 yacks [~py@103.6.159.103] has joined #sbcl 13:47:29 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 13:52:33 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 13:53:40 argh, structure accessors now again share the same docstring 13:53:53 probably after i fixed the difference between setf docstring #'x and 'x 13:54:19 changing accessors into its own function instead of closures, like i planned for optimization purposes, will solve that 13:57:23 or maybe just accessors without docstring receive the same one 13:58:13 davazp [~user@92.251.223.120.threembb.ie] has joined #sbcl 13:58:27 looks like it 14:26:49 oleo [~oleo@xdsl-78-35-167-164.netcologne.de] has joined #sbcl 14:27:39 -!- LiamH [~none@129-2-129-146.wireless.umd.edu] has quit [Quit: Leaving.] 14:31:42 -!- segv- [~mb@95-91-240-228-dynip.superkabel.de] has quit [Remote host closed the connection] 14:34:09 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: session lost into perpetual corruption] 14:34:35 segv- [~mb@95-91-240-228-dynip.superkabel.de] has joined #sbcl 14:58:41 sdemarre [~serge@109.134.146.216] has joined #sbcl 14:59:30 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:51:24 Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has joined #sbcl 15:52:23 for (mapc #'function sequence), can a frame be allocated only once for FUNCTION, instead of on each iteration? 15:53:28 or the return sequence will not allow for that 15:53:39 uh? what do you mean? 15:54:05 oh, I see. With a lot of hacking, perhaps. 15:54:25 hoisting frame pointer adjustment out of the loop, but the return sequence wouldn't allow for that 15:57:58 I think it might be doable if a single return value is used. 16:29:43 -!- gko_ [gko@114-32-172-194.HINET-IP.hinet.net] has quit [Ping timeout: 245 seconds] 16:30:10 gko_ [~gko@192.161.167.73] has joined #sbcl 16:35:24 what's the advantage of having maintaining RBP? 16:36:19 DX alloc. 16:36:24 backtraces 16:36:49 right, i just remembered that DX can be variable 16:38:12 there's a reason linux and perf build with frame pointers even on x86-64. It's just so much easier to work with. 16:39:52 i'm just looking how to improve iterating over a vector while calling a function 16:40:48 I assume http://lwn.net/Articles/379949/ is probably still an accurate assessment of the situation? 16:43:17 i used perf with some success on sbcl 16:43:46 but the annotated disassembled output was largely incomprehensible 16:47:52 stassats: yeah, we'd have to use the low level interface directly instead of the command line tools. 16:48:13 hmm, looks like perf supports dwarf in some form now. 16:48:19 Although not the version I have. 16:48:30 "perf record -g dwarf" 16:48:46 i used it only for the runtime 16:48:51 obviously 16:50:22 Oh. I actually like the disassembly output. The main problem is that most instruction-level stats aren't that useful due to the way hardware performance counters work. 16:50:31 ...which just dumps out 8k of stack (configurable) every hit and lets userspace do the dwarf interpretation. 16:51:48 pkhuong: i think my main problem was with inlined functions 16:52:04 stassats: it works with debugging information. 16:52:21 foom: well... I wouldn't want a dwarf interpreter in my kernel (then again, I wouldn't want a disassembler either...) 16:52:40 How about a JIT compiler? 16:52:43 (or 2?) 16:53:45 heh. same. I find the network filter stuff scary as well. 16:53:50 on that note, how does sbcl know to which function a frame belongs? the location stored on the stack only points into the middle of a function 16:54:10 stassats: walk the allocation region. 16:54:30 hit a code component, walk its function list. 16:54:46 so it's not that fast 16:55:10 does sb-sprof have to do that too? 16:55:18 *stassats* can just check 16:58:23 stassats: if you do that a lot, you can cache in a sorted map. 16:58:36 -!- teggi [~teggi@123.20.102.167] has quit [Remote host closed the connection] 16:59:35 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Ping timeout: 252 seconds] 17:06:17 looks like it just records the PC and computes things later, but reports are quite slow for large profilings 17:08:28 Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has joined #sbcl 17:08:53 -!- gko_ [~gko@192.161.167.73] has quit [Ping timeout: 248 seconds] 17:16:29 -!- segv- [~mb@95-91-240-228-dynip.superkabel.de] has quit [Ping timeout: 244 seconds] 17:16:43 segv- [~mb@95-91-240-228-dynip.superkabel.de] has joined #sbcl 17:21:02 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 17:26:18 would it be helpful to have (declaim ftype (function ...) ...) declarations before all of the calls to as-yet undefined functions so we don't end up with so many spurious style-warnings in the build? 17:31:11 how to make code with SETFs better? we don't have SSA, but CSP should be equivalent, shouldn't it? 17:33:09 e.g. (let (x) (setf x 10)) => no MOV x, NIL, (let (x) (setf x 10) x), there is such a move 17:33:37 Fare [fare@nat/google/x-lygwbuvutjsxucvy] has joined #sbcl 17:34:15 probably part of the same problem that every named variable is assigned a single register/memory location and single representation. 17:34:36 stassats: real CPS is equivalent. we don't do that. 17:34:51 we only represent control flow with CPS, but not data flow. 17:35:00 i can see why X is kept, because it has a reader, but the value is unreachable to that reader 17:35:25 slyrus: I would like that. I tried to get it right for PCL, and gave up after 40-some declaims. 17:36:24 pkhuong: well, we probably don't need to do this exhaustively, but it would be nice if we could get rid of some low-hanging fruit, unless there's reasonable objections (style, maintainability, etc...). Seemed like a good idea to me though! 17:37:21 stassats: it'd be possible to do that during IR1... a more type directed way would be to compute the type of REFs to variables, and elide bindings/set that are incompatible with that type. 17:37:54 that would already take care of stuff like OPTIMIZATIONS #8 17:39:09 i came from LOOP too, (loop for x across array) has (let ((limit 0)) (setf limit (length array)) ...) 17:39:52 i tried having (limit (length array)), but it's a let, not let*, and array is higher up 17:40:15 -!- sdemarre [~serge@109.134.146.216] has quit [Ping timeout: 244 seconds] 17:43:37 LOOP is very much *not* the style SBCL is made for. 17:44:58 Something like entering the loop body as a function call might suffice, without turning everything into tail calls. But I don't see our LOOP implementation changing soon. 17:52:07 is it even possible to forward declaim types like one can do with (declaim ftype ...)? 17:53:27 -!- Fare [fare@nat/google/x-lygwbuvutjsxucvy] has quit [Ping timeout: 246 seconds] 17:54:12 doubtful. 18:23:04 -!- davazp [~user@92.251.223.120.threembb.ie] has quit [Remote host closed the connection] 18:40:07 Fare [fare@nat/google/x-ookxutbfkcaoppyc] has joined #sbcl 18:46:15 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 245 seconds] 18:48:37 -!- slyrus [~chatzilla@107.201.4.222] has quit [Ping timeout: 265 seconds] 18:52:14 -!- Fare [fare@nat/google/x-ookxutbfkcaoppyc] has quit [Ping timeout: 240 seconds] 18:59:56 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:14:49 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 19:21:31 Fare [fare@nat/google/x-amrdsviszakmqmje] has joined #sbcl 19:50:20 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 20:05:35 sdemarre [~serge@109.134.146.216] has joined #sbcl 20:12:14 -!- prxq [~mommer@x2f68c59.dyn.telefonica.de] has quit [Quit: Leaving] 20:12:45 Bike [~Glossina@wl-nat105.it.wsu.edu] has joined #sbcl 20:21:03 -!- oleo [~oleo@xdsl-78-35-167-164.netcologne.de] has quit [Read error: Operation timed out] 20:29:02 -!- Fare [fare@nat/google/x-amrdsviszakmqmje] has quit [Ping timeout: 240 seconds] 20:36:18 oleo [~oleo@xdsl-78-35-187-83.netcologne.de] has joined #sbcl 20:38:59 Fare [fare@nat/google/x-cagusfrsudozbdpq] has joined #sbcl 20:47:46 scymtym [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 21:00:14 -!- Fare [fare@nat/google/x-cagusfrsudozbdpq] has quit [Ping timeout: 240 seconds] 21:01:03 Fare [fare@nat/google/x-jvslwxnmkkwicqpw] has joined #sbcl 21:14:38 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds] 21:32:03 -!- Bike [~Glossina@wl-nat105.it.wsu.edu] has quit [Ping timeout: 272 seconds] 21:37:48 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 21:45:38 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 21:46:15 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 245 seconds] 21:47:52 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 21:53:13 Bike [~Glossina@wl-nat101.it.wsu.edu] has joined #sbcl 22:00:33 -!- sdemarre [~serge@109.134.146.216] has quit [Ping timeout: 272 seconds] 22:01:02 -!- Bike [~Glossina@wl-nat101.it.wsu.edu] has quit [Quit: Reconnecting] 22:01:15 Bike [~Glossina@wl-nat101.it.wsu.edu] has joined #sbcl 22:02:12 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 244 seconds] 22:02:55 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 22:35:08 -!- scymtym [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 245 seconds] 22:41:58 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:42:06 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 23:54:22 Shall I wait until next month to commit https://github.com/pkhuong/sbcl/tree/regalloc-cleanup-staging-rewrite-history? (: 23:55:33 also, do you think the iterative code should be a feature? It's not that much code, but it's so modular that it's a single LOC.