01:05:05 -!- rbarraud_ [~rbarraud@118-92-139-26.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 01:05:34 rbarraud_ [~rbarraud@118-92-139-26.dsl.dyn.ihug.co.nz] has joined #sbcl 01:23:53 DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has joined #sbcl 01:26:34 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 02:01:47 -!- nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 02:02:51 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 02:06:25 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 02:08:28 -!- rbarraud_ [~rbarraud@118-92-139-26.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 245 seconds] 02:08:44 rbarraud_ [~rbarraud@118-92-139-26.dsl.dyn.ihug.co.nz] has joined #sbcl 02:12:56 nyef: I think SBCL could usefully use LOOP internally. the COLLECT macro is clever, but... 02:13:41 oh, hum, no nyef 02:16:43 -!- specbot [~specbot@common-lisp.net] has quit [Ping timeout: 240 seconds] 03:46:02 -!- rbarraud_ [~rbarraud@118-92-139-26.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 04:36:15 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 04:43:28 rbarraud [~rbarraud@118-92-140-168.dsl.dyn.ihug.co.nz] has joined #sbcl 06:05:39 Blkt [~user@93-33-134-2.ip44.fastwebnet.it] has joined #sbcl 06:10:40 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:40:42 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 240 seconds] 06:50:57 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:50:57 -!- ChanServ has set mode +o nikodemus 06:52:37 good morning 06:58:39 -!- DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 07:04:07 morning 07:38:07 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 08:07:04 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:09:07 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 08:09:24 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:11:56 -!- Krystof [~csr21@78.146.236.83] has quit [Ping timeout: 240 seconds] 08:36:45 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 08:42:31 It seems that my problems with the finalization regression test were coming from some kind of conservative in-page aliasing. 08:42:53 If I cons lots of garbage before and after allocating the actual test object, it seems to be more or less reliably collected. 08:43:33 things are pinned at page-granularity, yes 08:44:36 so if you have a pointer on stack, everything on the same page as that object is retained 08:51:15 nikodemus: Why do you parse the result of array-element-type to determine size in you sb-vector-io? 08:51:41 Instead of using saetp information, like I did here and in my sse module: http://github.com/angavrilov/cl-gpu/blob/master/buffers/utils-array.lisp 09:08:21 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 09:33:30 Krystof [~csr21@158.223.161.73] has joined #sbcl 09:33:30 -!- ChanServ has set mode +o Krystof 09:53:52 angavrilov: don't remember, really 09:54:02 probably for no good reason 09:56:11 attila_lendvai1 [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 09:56:11 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Disconnected by services] 09:56:12 -!- attila_lendvai1 is now known as attila_lendvai 09:58:27 -!- rbarraud [~rbarraud@118-92-140-168.dsl.dyn.ihug.co.nz] has quit [Read error: Operation timed out] 09:59:37 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 10:11:02 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 11:01:39 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 11:03:41 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 11:05:45 -!- Blkt [~user@93-33-134-2.ip44.fastwebnet.it] has quit [Read error: Operation timed out] 11:05:57 What's a JNB instruction after a CALL instruction about? Is that part of some sbcl calling convention to look at the CF after a call? 11:10:53 multiple value handling 11:17:54 In this case the return value is ignored; SBCL might have to pop additional values from the stack nontheless? 11:22:18 that sounds right 11:22:34 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Read error: Connection reset by peer] 11:22:48 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 11:29:04 attila_lendvai1 [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 11:29:04 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Read error: Connection reset by peer] 11:41:21 -!- attila_lendvai1 [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Ping timeout: 240 seconds] 11:43:26 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:04:41 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 12:17:16 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 240 seconds] 12:18:38 -!- froydnj [~froydnj@gateway.codesourcery.com] has quit [Ping timeout: 264 seconds] 12:30:09 Krystof [~csr21@158.223.161.73] has joined #sbcl 12:30:09 -!- ChanServ has set mode +o Krystof 12:55:45 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 13:03:49 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 13:38:47 nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has joined #sbcl 13:38:58 G'morning all. 13:43:24 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 13:51:33 froydnj [~froydnj@gateway.codesourcery.com] has joined #sbcl 14:09:11 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 14:19:40 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 14:19:40 -!- ChanServ has set mode +o nikodemus 14:20:34 So, I have a TN, #, which is appearing where I would normally expect a CONSTANT-TN (which I'd expect to be # for some value of ~D). 14:21:02 This happened during XC, and I can't seem to replicate it from the REPL. 14:22:49 ... Looks like the LEAF-INFO of the CONSTANT might be set to something bogus already? 14:25:05 doesn't ring any bells here 14:27:12 Okay, thanks. 14:28:30 Aha! Just got it to reproduce outside of XC. That makes things less confusing. 14:28:40 A few days ago I asked the following question but never received any response: 14:29:40 When running sbcl with load start-swank.lisp load foo.lisp eval "(main)", I do get a ;; Swank started at port  message, but connecting to swank does not work, basically the swank thread is stuck in accept-connection 14:30:17 however, if I interrupt that sbcl process, and invoke the "skip processing cmdline args" restart, swank suddenly starts to work 14:30:34 so the question is what's in between the cmdline arg processing code and the normal toplevel? 14:32:22 Have a look, should be in SRC;CODE;TOPLEVEL. 14:32:41 i'm not sure i understand the question, but looking at TOPLEVEL-INIT in that file should answer your question 14:33:33 Whaa... The TN-KIND is :CONSTANT, but the TN-SC is #, and the TN-OFFSET is NIL? 14:34:11 that sounds plausible to me 14:34:21 especially if the constant is a static symbol 14:34:50 Hunh. Why static symbols? 14:34:55 ;; classic CMU CL comment: 14:34:55 ;; zzzzz jrd here. tn-offset is zero for constant 14:34:55 ;; tns. 14:35:50 nyef: symbols stored in static space at known offsets from NIL 14:36:17 Why do I have the feeling that I'm about to be annoyed? 14:36:29 look in generic/parms.lisp and target/parms.lisp 14:36:54 No, that'd just provide the list of such symbols, not the reason why they don't get the same treatment for CONSTANT-TNs. 14:37:00 and https://bugs.launchpad.net/sbcl/+bug/645140 14:37:20 oh, right. sec 14:37:59 Heh. I'm going to make that bug worse. 14:39:32 Ah, immediate-constant-sc? 14:40:03 Damn. 14:40:08 Immediate-constant-sc. 14:41:08 Hey, that at least gives me a direction to proceed. Thanks. 14:42:35 Of course, that now blows up in the MOV emitter. 14:54:25 Right, that got it working. Many thanks, nikodemus. 14:59:48 whee! you being the disassembler guy, do you think you might have time to look at that static-symbol & disassembly bug at some point? 15:01:18 Mmm... Those unannotated [#x20100888]s must be annoying. 15:02:18 You know that I'm in the process of making the disassembler situation -worse- on threaded targets, right? 15:02:31 15:02:51 i sense penance coming your way :) 15:02:57 Heh. 15:03:06 I'll paste a couple of samples once my current build is done. 15:04:31 i have in my head the idea that you (and maybe paul) are the people who best understand the disassembler currently, so if you don't have time for (re)improving the annotations, a sketch of how to do it would be great 15:04:54 I'll take a look at it. 15:05:34 i've been burned by SYMBOL-VALUE references killing my performance -- and i realized that because the disassembler told me what was going on 15:06:20 Really? You were taking a SYMBOL-VALUE when you thought it was a lexical, or something else? 15:08:36 *nyef* would almost like to see a symbol-global-storage array to go with the thread-local-storage arrays. 15:10:20 symbol-global-value? 15:10:36 Sortof. 15:11:01 I'm thinking that if we had such an array, we could easily emit fixups for hitting it. 15:13:29 Basically reduce the need to have the symbol object loaded for accessing the values, which would save a register, in theory. 15:13:55 Actually, a register and a couple of loads. 15:32:31 DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has joined #sbcl 15:34:25 minion: paste 115027? 15:34:25 Paste number 115027: "For nikodemus: Worse disassembly" by nyef in None. http://paste.lisp.org/display/115027 15:35:49 The odd [R12+8720] in the middle is a nice touch, I think. 15:37:13 eep.. :) 15:37:48 nyef: i was using a DEFVAR where i thought it was a constant 15:42:37 -!- DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 15:49:01 rmarynch [~roman@88.135.194.233] has joined #sbcl 16:56:56 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 17:29:07 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 240 seconds] 17:32:38 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 17:52:06 rmarynch: "git format-patch -1" is really the preferred patch format 17:52:45 it includes the commit message where you can explain the why and the how of the patch -- and most of the time the patch author is the best person to write that 17:53:18 no need to resubmit existing stuff -- just for future reference :) 17:54:40 nikodemus: okay, but I do not commit the patches, because I do not have my own bug fixes tree. How should I use that command (I mean with the diff)? 17:55:44 (I use SVN at work, so I did ask that question) 17:56:06 Just about everyone else commits to their local git repository. 17:56:49 Really, git has been a godsend to SBCL development workflow. 17:57:22 git checkout -b wip-foobug # creates branch wip-foobug and takes you there 17:57:32 # hack sbcl till happy 17:57:43 git commit -a # commit all the changes 17:57:55 git format-patch -1 # formats the last commit as a patch 17:58:23 git checkout master # back to master 17:58:34 nikodemus: thanks, I will consider this approach 17:58:34 git pull # pull upstream changes 17:58:52 git checkout wip-foobug # back to foobug 17:59:06 git checkout wip-foobug; git rebase master # Update patch to latest upstream changes. 17:59:12 git rebase master # update the foobug branch 17:59:44 # revise the patch 17:59:56 And when you're doing more involved work, involving multiple conceptual changes, the ability to rewrite history via git rebase --interactive is just completely amazing. 18:00:21 git commit -a --amend # commit current stuff, replacing the last commit on top 18:00:30 well, I definitely should go and read Git manual :) 18:00:45 Start with doc/GIT-FOR-SBCL-HACKERS. 18:01:08 http://progit.org/book/ # seems decent too 18:01:15 Yeah, that too. 18:01:30 fine, thanks for the references 18:01:37 And there was one blog post I liked about the "tangled working copy problem". Not sure I have it bookmarked anywhere useful, though. 18:04:11 yea, git rebase -i is my favorite command ever 18:04:28 Mmm. Had to use it, what, yesterday? 18:04:51 foom: How are you doing? 18:04:56 I'm working on a large branch right now, and the ability to push some changes to the front of the changelist, and to push those into trunk before the rest of the stuff I'm working on is amazing. 18:05:23 Heh. Did that a lot while working on ppc threading. 18:05:47 Kept all of the PPC-specific stuff at the recent end, and pushed all of the generic stuff further back. 18:06:08 Too bad I haven't finished the branch yet so I can get some git infrastructure and docs at ITA setup so other ppl can use it too. :) 18:08:09 before, when using SVN, I would've just had the whole mess in a checkout, with no separation of random fixes and the stuff I'm actually working on. 18:09:20 foom: sounds familiar to me - the SVN hell :) 18:09:34 it's kinda funny, nothing I like about git has anything to do with it being a "D" VCS 18:10:08 it's just a better svn client than svn is. 18:10:32 Heh. And it's great for preparing stuff to go into CVS as well. 18:10:51 *nyef* glances at his SBCL-export script. 18:12:46 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:13:21 foom: Did you get my email, btw? 18:14:02 nyef: yea; it's open in my browser but I haven't actually looked at it yet. 18:14:11 Okay, fair enough. 18:26:29 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 18:47:53 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:51:16 attila_lendvai [~attila_le@catv-89-133-171-82.catv.broadband.hu] has joined #sbcl 19:05:26 rmarynch [~roman@88.135.194.233] has joined #sbcl 19:15:45 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 19:22:56 Blkt [~user@93-33-134-28.ip44.fastwebnet.it] has joined #sbcl 19:24:02 good evening everyone 19:24:49 Hello Blkt. 19:27:01 Krystof [~csr21@78.146.236.83] has joined #sbcl 19:27:01 -!- ChanServ has set mode +o Krystof 19:27:38 -!- cmm- [~cmm@bzq-109-64-205-76.red.bezeqint.net] has quit [Ping timeout: 245 seconds] 19:28:35 cmm [~cmm@bzq-109-64-205-76.red.bezeqint.net] has joined #sbcl 19:30:37 Does anything grovel the binding stack other than SRC;COMPILER;TARGET;CELL.LISP, src/runtime/dynbind.c, and the debugger? 19:34:05 Hrm. Nothing obvious, at least... :-D 19:36:12 mm.. why is byte-consed-between-gcs an (unsigned-byte 32)? 19:36:44 Because that's the size of the address space? 19:37:00 And nobody actually noticed that it isn't anymore? 19:37:33 first time I hit that issue in forever, though. 19:37:44 you wanted to set b-c-b-gcs to more than 2GB? 19:37:50 yeah. 19:37:52 that's probably why nobody noticed. :P 19:37:58 I have 24 GB on my workstation 19:38:02 heh. can you fix the GC instead? 19:38:07 should be easy. :) 19:38:09 no time :p 19:38:30 So, I'm thinking of changing the binding stack on threaded x86-64, if not all threaded ports, to stash TLS-indexes instead of symbols. Thoughts? 19:38:31 I spawn computational threads that allocate a lot of garbage and die, releasing everything. 19:38:45 so it's really easy for me to trigger a GC at the right time. 19:38:55 pkhuong: Run them in without-gcing, and give them non-heap allocation regions? 19:39:26 bah, seems ok with 4GB 19:39:45 they seem to allocate around 1-1.5 GB per run. 19:40:34 nyef: any idea how to make your thing work if we wanted to do away with the hard limit on the number of specials? 19:41:03 Not on PPC, no. 19:41:48 Otherwise, sure: Stop all the threads, allocate new TLS blocks for them, update their thread base registers, and let 'er rip. 19:42:18 Your new hard limit on x86oids runs to about a billion specials, and on PPC you run out at... 8191? 19:42:37 Less the overhead for the thread struct, interrupt data storage, et cetera. 19:42:56 (Ooh! I could double that by biasing reg_THREAD.) 19:44:45 Actually, we possibly should bias the thread base anyway, moving the saved-interrupt stuff to outside the TLS area. 19:49:34 I guess we could recycle tls indices. 19:49:46 That too. 19:50:24 Heh. We could have a list of available TLS indices, and just pop the next one off the list in the allocator. 19:50:38 how would you know which ones to reuse, though? 19:51:00 Hrm. Good point. 19:51:31 you could just randomly evict an existing symbol's tls slot if no threads have it bound. 19:51:51 Not with tls-indexes allocated at load-time. 19:52:03 foom: I was going with GC. 19:52:25 well, if they're allocated at load-time, you can at least fail at load time saying it ran out of tls-indices. 19:52:28 instead of randomly later 19:52:37 Right, right. 19:52:45 And I'm fairly sure it does that now. 19:53:13 or, we could restrict the number of concurrent threads :) 19:53:27 foom: Should I post the repository URL for my tree here and now, or wait for a bit? 19:54:00 nyef: Yes, post it, for sure. It's not private. 19:54:08 Right. 19:54:37 http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/tls-allocation 20:00:49 Heh. If we switch to storing TLS-indexes on the binding stack instead of symbols, binding and unbinding looks like it might be cheaper on threaded than non-threaded targets. 20:01:38 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 20:04:03 ASau [~user@83.69.227.32] has joined #sbcl 20:08:13 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 20:16:22 -!- fualo is now known as vsbuffalo 20:42:01 rbarraud [~rbarraud@118-92-140-168.dsl.dyn.ihug.co.nz] has joined #sbcl 20:56:49 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Remote host closed the connection] 21:02:18 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 21:15:38 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 264 seconds] 21:17:57 -!- Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 21:18:03 Kaer [~b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 22:06:31 -!- lnostdal [~quassel@167.80-203-136.nextgentel.com] has quit [Remote host closed the connection] 22:07:28 lnostdal [~quassel@167.80-203-136.nextgentel.com] has joined #sbcl 22:15:22 -!- Blkt [~user@93-33-134-28.ip44.fastwebnet.it] has quit [Ping timeout: 252 seconds] 22:18:14 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 265 seconds]