00:29:57 -!- sineer [~cluster@184.163.30.58] has quit [Quit: sineer]
00:50:44 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl
01:44:21 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Quit: Leaving...]
01:47:52 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Ping timeout: 265 seconds]
01:49:21 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl
02:28:04 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl
02:51:44 -!- homie [~levgue@xdsl-78-35-145-12.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
02:55:33 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Quit: Leaving.]
02:56:09 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl
02:56:09 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Client Quit]
02:56:27 homie [~levgue@xdsl-78-35-145-12.netcologne.de] has joined #sbcl
03:46:52 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Quit: Leaving...]
03:49:25 -!- nyef [~nyef@pool-70-109-148-200.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.]
04:09:52 rapacity [~prwg@unaffiliated/rapacity] has joined #sbcl
04:11:08 <rapacity> hello, I'm having problems compiling clx 0.7.4 on sbcl 1.0.45
04:11:38 <rapacity> I keep getting a "SB-INT:BUG in thread #<THREAD "initial thread" RUNNING"
04:12:47 -!- tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Quit: Leaving.]
05:15:11 -!- homie [~levgue@xdsl-78-35-145-12.netcologne.de] has quit [Ping timeout: 246 seconds]
05:17:42 homie [~levgue@xdsl-78-35-173-136.netcologne.de] has joined #sbcl
06:01:31 -!- specbot [~specbot@common-lisp.net] has quit [Remote host closed the connection]
06:01:32 -!- minion [~minion@common-lisp.net] has quit [Remote host closed the connection]
06:01:32 -!- lisppaste2 [~lisppaste@common-lisp.net] has quit [Remote host closed the connection]
06:11:21 lisppaste2 [~lisppaste@common-lisp.net] has joined #sbcl
06:11:38 minion [~minion@common-lisp.net] has joined #sbcl
06:11:43 specbot [~specbot@common-lisp.net] has joined #sbcl
06:30:27 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl
06:32:03 mega1` [~user@catv4E5CABA2.pool.t-online.hu] has joined #sbcl
06:48:26 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
06:48:26 -!- ChanServ has set mode +o nikodemus
06:52:47 -!- rapacity [~prwg@unaffiliated/rapacity] has left #sbcl
07:48:48 <Krystof> %%nip-values is relatively modern code.  Alexey wrote it in response to some of the early pfdietz random tester crashes
07:48:54 <Krystof> or a similar vintage
07:56:52 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
08:31:38 -!- mega1` [~user@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds]
08:31:38 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds]
09:21:29 Blkt [~user@net-93-151-229-166.cust.dsl.teletu.it] has joined #sbcl
10:12:49 stassats [~stassats@wikipedia/stassats] has joined #sbcl
10:18:12 <Blkt> good day everyone
10:22:26 -!- pattern [~pattern@unaffiliated/pattern] has quit [Ping timeout: 240 seconds]
10:26:19 tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl
11:19:55 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
11:19:55 -!- ChanServ has set mode +o nikodemus
11:21:35 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl
11:22:24 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has left #sbcl
12:01:46 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl
12:11:16 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
12:11:49 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
12:11:49 -!- ChanServ has set mode +o nikodemus
13:30:10 tcr2 [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl
13:31:29 -!- tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Read error: Connection reset by peer]
13:39:50 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Quit: Leaving...]
13:41:49 attila_lendvai [~attila_le@dsl51B614DA.pool.t-online.hu] has joined #sbcl
13:47:12 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
14:48:41 -!- homie [~levgue@xdsl-78-35-173-136.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
14:51:43 -!- Blkt [~user@net-93-151-229-166.cust.dsl.teletu.it] has quit [Quit: Error: do not makunboud t please!]
14:52:07 homie [~levgue@xdsl-78-35-173-136.netcologne.de] has joined #sbcl
15:14:06 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl
15:32:49 nyef [~nyef@pool-70-109-148-200.cncdnh.east.myfairpoint.net] has joined #sbcl
15:33:04 <nyef> G'morning all.
16:11:06 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Quit: Leaving...]
16:55:25 -!- attila_lendvai [~attila_le@dsl51B614DA.pool.t-online.hu] has quit [Ping timeout: 260 seconds]
16:55:27 attila_lendvai1 [~attila_le@dsl51B61463.pool.t-online.hu] has joined #sbcl
16:55:27 -!- attila_lendvai1 is now known as attila_lendvai
17:04:05 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Remote host closed the connection]
17:20:18 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl
17:28:18 christoph [~user@oteiza.siccegge.de] has joined #sbcl
17:46:13 -!- homie [~levgue@xdsl-78-35-173-136.netcologne.de] has quit [Read error: Connection reset by peer]
17:47:18 homie [~levgue@xdsl-78-35-182-7.netcologne.de] has joined #sbcl
17:49:01 -!- homie [~levgue@xdsl-78-35-182-7.netcologne.de] has quit [Client Quit]
17:51:49 homie [~levgue@xdsl-78-35-182-7.netcologne.de] has joined #sbcl
17:54:06 -!- slyrus [~chatzilla@adsl-75-36-217-249.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 276 seconds]
17:54:59 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl
17:55:21 -!- lisppaste2 [~lisppaste@common-lisp.net] has quit [Ping timeout: 240 seconds]
17:55:45 -!- minion [~minion@common-lisp.net] has quit [Ping timeout: 240 seconds]
17:56:10 -!- specbot [~specbot@common-lisp.net] has quit [Ping timeout: 240 seconds]
18:00:07 mega1` [~user@catv4E5CABA2.pool.t-online.hu] has joined #sbcl
18:35:59 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Quit: Leaving...]
18:53:08 -!- attila_lendvai [~attila_le@dsl51B61463.pool.t-online.hu] has left #sbcl
19:11:17 attila_lendvai [~attila_le@dsl51B61463.pool.t-online.hu] has joined #sbcl
19:12:48 hargettp [~hargettp@mobile-166-137-138-045.mycingular.net] has joined #sbcl
19:12:56 -!- hargettp [~hargettp@mobile-166-137-138-045.mycingular.net] has left #sbcl
19:18:23 -!- attila_lendvai [~attila_le@dsl51B61463.pool.t-online.hu] has left #sbcl
19:38:21 <mega1> do you see value in the llvm backend?
19:38:41 <mega1> I'm thinking about summeroflisp projects.
19:38:48 <stassats> wasn't foom working on something like this?
19:42:21 <mega1> yes, he was
19:43:35 <nyef> I don't see that an llvm backend would buy us much, TBH.
19:45:57 <mega1> what would?
19:46:05 <fe[nl]ix> nyef: you'd remove a big chunk of code from python and delegate code generation to somebody else who has the resources to continuously improve it
19:46:48 <stassats> mega1: an ARM port!
19:47:17 <mega1> wouldn't having an llvm backend give use ARM?
19:47:21 <mega1> *us
19:47:59 <nyef> Perhaps, but we'd gain a dependency, and the front-end of the compiler is where a number of optimization opportunities lie, and that would remain even after moving to llvm.
19:49:55 <mega1> it would be much easier to port to ARM though, wouldn't it?
19:50:50 <nyef> Possibly. I don't know that we'd ever know for sure.
19:52:59 <mega1> I haven't done a port. But I guess those who did should have an idea how much effort goes into the part that would be covered by llvm.
19:56:00 <mega1> anyway, llvm was just an idea. Anything else?
19:56:19 <mega1> how's the peephole patch?
19:56:28 <mega1> was it finished?
19:56:48 <nyef> How about cleaning up GC safepoints so they're usable on non-windows systems?
19:59:46 <mega1> GC and interrupt safepoints or only GC?
20:00:08 <nyef> interrupt safepoints.
20:00:42 <mega1> that's a lot of work I think
20:00:49 <nyef> Probably is, yes.
20:00:56 <mega1> even more :-)
20:01:55 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
20:01:55 -!- ChanServ has set mode +o nikodemus
20:02:24 <mega1> allegro has safepoints and it's tricky to get it right
20:02:40 <mega1> especially with foreign calls.
20:02:46 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Client Quit]
20:04:12 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
20:04:12 -!- ChanServ has set mode +o nikodemus
20:05:25 <mega1> the main advantage of the current scheme is that you don't deadlock the whole image if you get blocked in a system call
20:05:33 <mega1> (or anywhere else in foreign land)
20:05:49 <mega1> And getting blocked in a system call is easy.
20:06:01 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Client Quit]
20:06:22 <nyef> I actually don't mind if foreign code is interruptable, it's lisp code that I worry about.
20:06:23 <mega1> I should shut up, maybe nikodemus will then choose to stay.
20:07:35 <mega1> Yes, that's a more promising path.
20:15:21 <mega1> If foreign code is not safe then I don't think it's too much work.
20:15:45 <mega1> Perhaps it would even be suitable for summer of code.
20:16:25 <mega1> it would help the darwin port most probably
20:16:52 <mega1> so llvm, ARM, safepoints so far
20:17:29 <mega1> Ligth(er) weight threads
20:18:02 <mega1> growing stacks, condensed tls, etc
20:20:57 <nyef> ... I have those tls-index fixups to commit at some point.
20:21:26 <mega1> what was that about?
20:21:50 <nyef> Doing the tls-index lookup at load time instead of runtime.
20:22:41 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
20:22:41 -!- ChanServ has set mode +o nikodemus
20:22:54 *mega1* holds back breath
20:23:16 <nyef> Wasn't as big a win as I had hoped, as the symbol itself still needed loading during reads, but it made binding a touch quicker.
20:23:34 <mega1> that would be cool
20:23:51 <pkhuong> nyef: the reduction in code size was nice, though.
20:24:00 <nyef> http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/tls-allocation-3
20:24:05 <mega1> it wouldn't have a problem with tls recycling, were it implemented, right?
20:24:14 <nyef> Umm... It might, actually.
20:24:21 <mega1> how so?
20:24:22 <pkhuong> no.
20:24:30 <pkhuong> you still have a ref to the symbol.
20:24:36 <nyef> You do?
20:24:40 <nyef> ... No, you don't.
20:24:52 <pkhuong> you need one to look up the global value
20:25:02 <nyef> Sure, if you're doing lookups, but not for binding.
20:25:12 <pkhuong> mm. right.
20:25:29 <pkhuong> just add a ref in the constant pool.
20:25:31 <nyef> Might be amusing to have a separate vector for symbol-values, also indexed by TLS slot.
20:25:59 <mega1> khm
20:26:04 <mega1> not too amusing
20:26:28 <mega1> the per thread tls doesn't need locking
20:26:42 <pkhuong> neither does the global one
20:26:57 <mega1> it does if the vector needs to grow
20:27:16 <mega1> which it will
20:27:18 <pkhuong> that's a "solved" problem.
20:27:21 <mega1> ?
20:27:23 <mega1> really?
20:27:29 <mega1> I'm all ears
20:27:46 <pkhuong> in the sense that non-blocking atomic vector copying is well explored.
20:28:12 <mega1> I'll have some reading to do then.
20:28:28 <mega1> what about cache locality?
20:28:45 <mega1> the per-thread tls looks better
20:29:01 <mega1> depending on the sparsity of accesses
20:29:08 <mega1> may not be a factor.
20:29:17 <pkhuong> IIUC, nyef was referring to a TLS-slot-indexed vector for global values.
20:29:36 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
20:29:51 <pkhuong> and I don't expect that to be worse than the current slot in each symbol.
20:30:23 <mega1> vector for global values??
20:30:33 <mega1> isn't there only one per symbol?
20:31:08 <mega1> ah, I see
20:32:30 <mega1> but there is no reason to expect that it's better either hence the "amusing" part
20:33:54 <mega1> what about an exact gc for x86 or x86-64?
20:35:08 <pkhuong> precise for stack, sure. I'm not sure I agree for registers.
20:35:50 <mega1> tell me why
20:36:13 <mega1> too much work to separate regs dynamically?
20:36:41 <pkhuong> I don't trust us to annotate VOPs right.
20:37:25 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has left #sbcl
20:37:32 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl
20:40:03 <mega1> let me back off a step. Is cheneygc not precise for the regs?
20:40:20 <pkhuong> it is. There's a static split.
20:41:05 <pkhuong> oh yeah, also, I think nyef uncovered some issues with threads and precise GC
20:41:29 <mega1> so, the annotating the vops is only for the dynamic separation?
20:41:37 <pkhuong> right.
20:41:54 <mega1> can't we get away with a static split on x86-64?
20:42:34 <pkhuong> I can easily cook up cases where that'll hurt.
20:43:09 <mega1> sure, but how much
20:46:24 <nyef> ... Didn't I also stomp the issues with threads and precise GC?
20:47:04 <pkhuong> you would know (:
20:47:32 <pkhuong> safepoint and precise GC would be simpler, and we can try and deal with scaling issues when we have 64 core boxen ;)
20:48:02 <nyef> Anyway, the vector for symbol global values would mean we could use the TLS index against the global vector, which would mean no longer having to load the symbol identity for references.
20:48:25 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds]
20:52:30 <mega1> that sounds nice. So what were the issues with threads and preciseness?
21:00:45 <nyef> mega1: Most of 1.0.41.x, for x<29 is related.
21:02:30 <mega1> I saw those commit, but didn't realize they have to do with preciseness.
21:04:15 <mega1> bbl
21:04:52 <nyef> Some of them have to do with registers being treated as interior pointers to some specific base register.
21:05:06 <nyef> A couple of them are to do with context and stack scavenging.
21:11:42 <nyef> mega1: The big one was 1.0.41.13, which wasn't so much a thread fix as an asynchronous interrupt fix.
21:31:54 -!- tcr2 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Quit: Leaving.]
22:17:46 slyrus [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl
22:35:03 lisppaste2 [~lisppaste@common-lisp.net] has joined #sbcl
22:35:28 minion [~minion@common-lisp.net] has joined #sbcl
22:35:49 specbot [~specbot@common-lisp.net] has joined #sbcl
23:18:02 -!- mega1` [~user@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds]
23:18:02 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds]
23:24:04 -!- minion [~minion@common-lisp.net] has quit [Ping timeout: 240 seconds]
23:38:04 -!- slyrus [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Ping timeout: 240 seconds]