00:02:59 got it working finally :D 00:03:53 unfortunately it does not quite match up with what is optimal. Well I can make it be optimal by tweaking the order of the arguments to +, but that just feels hacky 00:06:11 well, this actually matters depending on the order of the args to the function 00:24:19 hargettp [~hargettp@pool-71-174-133-100.bstnma.east.verizon.net] has joined #sbcl 00:49:57 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 240 seconds] 01:00:36 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 260 seconds] 01:04:50 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 02:04:17 stassats [~stassats@wikipedia/stassats] has joined #sbcl 02:05:06 -!- drl [~lat@110.139.230.255] has quit [Ping timeout: 240 seconds] 02:18:10 drl [~lat@110.139.230.255] has joined #sbcl 02:34:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 02:49:29 -!- hargettp [~hargettp@pool-71-174-133-100.bstnma.east.verizon.net] has quit [Quit: Leaving...] 03:06:21 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 03:06:36 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 03:13:30 -!- drl [~lat@110.139.230.255] has quit [Ping timeout: 276 seconds] 03:25:40 drl [~lat@110.139.230.255] has joined #sbcl 04:14:47 -!- drl [~lat@110.139.230.255] has quit [Ping timeout: 258 seconds] 04:27:27 drl [~lat@110.139.230.255] has joined #sbcl 04:36:40 -!- drl [~lat@110.139.230.255] has quit [Remote host closed the connection] 04:37:28 drl [~lat@110.139.230.255] has joined #sbcl 04:39:42 -!- drl [~lat@110.139.230.255] has quit [Client Quit] 04:43:47 -!- hakkum [~hakkum@c-67-181-176-186.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 06:17:18 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 06:17:18 -!- ChanServ has set mode +o nikodemus 06:19:20 flip214 [~marek@86.59.100.100] has joined #sbcl 06:19:20 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 06:19:20 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 06:19:30 morning 06:28:14 -!- lisper [18d1340b@gateway/web/freenode/ip.24.209.52.11] has quit [Ping timeout: 252 seconds] 06:53:15 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 06:57:35 feeling rich, nikodemus? :-) 06:57:52 feeling gobsmacked 06:58:05 at the current rate, you'll have $80000 in pledges when the auction is over :-) 06:58:18 (warning: extrapolation may not be entirely valid :) 06:58:23 hah 06:58:54 but if i can hit 6k i'm extremely happy -- not that i'm not happy at the current success! 06:59:18 i'm /really/ wondering how repeatable this is 06:59:48 could i do this again in, say 3 months? 07:01:12 that of course is the really interesting question 07:02:05 I would say that it's not impossible 07:13:44 ooh, win32 commits! shiny! 07:53:07 nikodemus: I could certainly tithe $50 monthly 08:14:13 What is the auction of? 08:16:09 it's a cooperative auction for nikodemus' time 08:17:08 referring to http://www.indiegogo.com/SBCL-Threading-Improvements-1 08:20:20 Cool. 09:24:36 -!- ASau [~user@95-28-79-252.broadband.corbina.ru] has quit [Quit: off.] 10:04:29 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 10:08:37 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 10:49:10 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:49:10 -!- ChanServ has set mode +o nikodemus 10:52:09 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 10:53:08 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 11:10:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:27:23 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 11:37:36 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Ping timeout: 260 seconds] 11:47:56 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 11:50:22 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 11:50:22 -!- ChanServ has set mode +o nikodemus 12:25:33 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 12:29:09 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 12:44:38 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 12:45:36 i think i like anton's least-specialized-type suggestion 12:46:30 gah, and there was me thinking it was ugly :-/ 12:46:33 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 12:47:25 i haven't looked at code, mind you 12:48:01 I think because I think of distinct array types as really disjoint types 12:48:35 not in any kind of hierarchy: I really do think that STRING is a special case, not sensible to generalise 12:48:50 it seems sensible for sensible-to-use-with-map union types 12:49:16 which include all sorts of subtypes of STRING: like (or (vector base-char) (vector character)) 12:49:29 but when would you actually use that? 12:49:43 why would you not use just STRING? 12:51:32 it's a leaky abstraction if STRING symbol is magical 12:52:04 as opposed to the actual union type 12:52:35 ah, you see, I take the view that the STRING symbol is defined to be magical, because the spec explicitly gives it its magical qualities 12:53:15 and that there's no suggestion that it's a good idea to extend that magic to other things 12:53:40 yeah. but making the symbol magical leads to it being a leaky abstraction. if the whole string-part of the type lattice is magical it's neater, imo 12:53:48 string section, even :) 12:55:05 and once you make that magical, it seems reasonable to ask "should this not be general"? and anton's suggestion is a workable generalization 12:55:36 I don't know. I think in terms of documentation complexity it's easier to say "STRING is magical" rather than talking about union types of arrays 12:55:56 particularly since most people still have a difficulty understanding the difference between (OR (ARRAY X) (ARRAY Y)) and (ARRAY (OR X Y)) 12:56:38 it's a workable generalization; I think that it's not a useful one 12:57:24 so axiom people should be forced to use 'cl:string? 12:57:42 well, that's why I asked how hard it would be 12:58:01 I also am willing to buy things that type-expand into 'cl:string should be allowed 12:58:32 and simple-string, and simple-base-string, and base-string? 12:59:45 the latter two aren't special 12:59:52 what about those that try to make their code both pretty and avoid paying for our multiple string types, and have (deftype string () '(vector character)) and shadow cl:string? 12:59:53 it's just string and simple-string I believe 13:00:08 likewise, that latter case already works 13:00:30 (vector character) is a perfectly well-defined vector subtype 13:01:24 oops, right. make that (or (vector character) (vector base-char)) -- because they don't want accidental (vector nil)s :) 13:02:49 is (ARRAY (OR X Y)) equivalent to (ARRAY ) ? 13:03:37 fe[nl]ix: yes 13:04:16 so those two types differ when that supertype has more subtypes than X and Y ? 13:04:25 no 13:04:53 think about (or (array bit) (array base-char)) compared to (array (or bit base-char)) 13:05:21 the first is (or bit-array base-char-array); the second is (array t) 13:05:55 oh, right 13:06:21 I should stop thinking of array types in algebraic terms 13:06:47 thanks 13:53:33 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 13:54:07 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 13:54:07 -!- ChanServ has set mode +o nikodemus 14:17:22 Isn't the workaround/correct way to do this very simple? 14:17:52 Rather than (deftype %string() 'string), (deftype %string () '(simple-array character 1)) ? 14:20:08 I think that they also want to (declare foo %string) and have FOO still be allowed to be a base-string 14:20:29 i.e. %string for creation means one thing, but %string for discrimination means something else 14:21:50 (I didn't expect Rich Hickey to show up on nikodemus' funders list!) 14:29:30 slyrus [~chatzilla@99-28-163-38.lightspeed.miamfl.sbcglobal.net] has joined #sbcl 14:29:37 homie [~levgue@xdsl-84-44-153-230.netcologne.de] has joined #sbcl 14:40:26 neither did i :) 15:14:14 does anyone object me putting an iframe-widget for my campaign on sbcl.org (making clear that it's an individual developer, etc) 15:40:19 sounds like a good idea to me. 15:43:26 no objection from me 15:43:44 I'm also planning to delete my entry for paid support in the manual, on the basis that no-one has ever asked and I don't have time anyway 15:44:32 finding the time to delete the entry is of course a bootstrapping problem :) 15:47:46 incidentally, I was going to point you in the direction of http://www.goblinscomic.com/tempts-fate/ for a feeling for what's achievable given a suitably adoring fanbase 16:28:58 CL-USER> (map '%string 'code-char '(#x40 #x41 #x42)) 16:29:51 this I acheve with a ~10-line patch to src/code/seq.lisp; it doesn't contain any of the generality of union array types, but it is simple 16:31:04 and it also works for coerce/concatenate/merge/make-sequence 16:31:28 bah, when I was a naive user and asked about this, I was pointed to the spec. These days, users only need to ask persistently, and the interpretation of the spec will be bent for them! 16:32:33 Even in the user's favour, for something non-SBCL lisps are strict about. 16:33:10 we're growing old. 16:34:06 lichtblau: actually I thought about making that argument (about outward portability) but since sbcl as far as I know is the only one with multiple string representations it's a bit of an academic argument now 16:34:16 not that I have anything against academic arguments 16:35:16 also, I'll go for this if it stops some random union array type support that I don't understand going in 16:35:31 hmm, wasn't the gazillion of LispWorks character types just as bad? 16:37:51 I forget :) 17:02:38 scymtym_ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 17:02:38 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 17:50:15 <|3b|> Failure: timer.impure.lisp / (TIMER THREADED-STRESS) 17:50:26 scymtym__ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 17:50:49 -!- scymtym_ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 17:52:09 |3b|: do it like me (and presumably everyone else): rerun the tests until they pass 17:52:23 some refactoring, and the LOC has gone down a bit. 17:53:25 <|3b|> lichtblau: 3 of 3 tries passed running just that file 17:54:35 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 17:54:41 yeah, the threading and timer tests often fail only when running in the "right" (wrong?) order. It's about threads left over from previous tests that didn't clean up after themselves, or about GC hitting at an inopportune moment. Stuff like that. 17:55:10 <|3b|> yeah, already filed 1 bug on that sort of thing last time i updated :p 17:55:59 For more fun, change the test runner to loop around each test a little, that gives nice extra failures. 17:56:05 -!- scymtym__ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 17:56:15 scymtym__ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 17:56:32 *|3b|* was just adding a loop around that test :) 17:57:13 -!- scymtym__ [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Client Quit] 17:57:47 <|3b|> 100 iterations -> ~40 failures 17:57:56 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 17:58:29 Is it waiting for its threads to finish? Otherwise increasing the repeat count worsens the "left over threads" issue. 17:58:52 I think we should (or "I will") commit a change so that tests never leak threads. It's the only sane thing to do. 17:58:52 <|3b|> it uses with-test, which i think waits 18:00:22 <|3b|> looks like more deadlock cycle stuff 18:01:45 DGASAU [~user@91.218.144.129] has joined #sbcl 18:03:56 |3b|: i haven't had much luck reproducing those 18:04:09 what kind of setup do you have? 18:04:31 <|3b|> Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz 18:04:49 because really, unjoined threads shouldn't be causing that kind of things 18:04:54 <|3b|> ubuntu 10.10 x8664 18:06:22 ok 18:06:24 would be nice to see stacktraces for lp#807475, too 18:07:26 *|3b|* failed to figure out how to acquire those :/ 18:07:46 |3b|: attach gdb, "thread apply all ba" is the first step 18:07:54 <|3b|> LDB was unresponsive, and hadn't figured out gdb stuff when i ran out of time to mess with it 18:08:25 an ever better step is to get a lisp stacktrace through gdb, too, using antifuchs's gdb init file 18:09:13 yeah, the terminal setup is a bit screwed with tests -- it looks like it's waiting for input, but the input really goes to the parent which isn't reading it 18:09:37 well, ldb is useless for that sort of thing anyway 18:10:14 <|3b|> nikodemus: might also be some background CPU load involved in making these things easier to trigger, this time i had a core spinning on some OpenCL stuff, and slow X due to same 18:10:54 <|3b|> might have been similar last time too, though i thought the test case in the bug report worked even on unloaded system 18:10:56 plausible 18:11:51 my current belief is that there's a race in deadlock detection 18:12:38 <|3b|> lichtblau: where can i find that gdb setup? 18:12:57 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:13:06 glad to see my gdbinit is still useful (-: 18:13:28 http://boinkor.net/lisp/sbcl/gdbinit is the one I put online way back when 18:15:32 <|3b|> ok, got an sbcl stopped in the 807475 deadlock, what next to get more info? 18:16:37 -!- cmm [~cmm@bzq-79-180-200-201.red.bezeqint.net] has quit [Quit: leaving] 18:17:24 gdb --pid $(pidof sbcl) 18:17:33 thread apply all ba 18:18:30 (I have a slightly newer version of antifuchs's initfile, but my thread debugging has all been on x86, and would need fixing for 64 bit) 18:22:54 <|3b|> ok, figured out how to convince gdb to actually attach... 18:24:27 <|3b|> not very informative : http://paste.lisp.org/+2NNN 18:25:39 <|3b|> actually, that might be the wrong sbcl, 18:25:45 *|3b|* tries again... 18:26:00 I was about to say: In a deadlock situation, there should be more than one thread. :-) 18:29:00 <|3b|> ok, annotated 18:30:22 ignotus [~ignotus@unaffiliated/ignotus] has joined #sbcl 18:33:10 hi, I use SBCL and I would like to read from a hash-table while another thread may write to it. I don't want to use mutexes because they slow down things considerably and I'm a sucker for premature optimization, so what is the worst thing that can happen in this case? 18:33:24 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:35:38 ah never mind, it was just my development version full-of-debug-infos with-mutex macro that was slow 18:35:52 otoh the question is still interesting:) 18:38:14 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 18:44:57 ignotus: multiple reader single writer... without deletion, i don't think it's too dangerous, right now. 18:45:23 pkhuong: thanks 18:47:30 |3b|: grab http://www.lichteblau.com/kludgily-hacked-for-current-sbcl.gdbinit and use "source /path/to/.gdbinit" to load it. 18:48:42 I haven't had to debug threads on x86-64 yet, so that file is a very rough 5min port to x86-64 that haven't actually used myself yet. 18:49:05 But you should be able to copy&paste a PC from the stacktrace and say "fun 0xdeadbeefdeadbeef". If that address is in dynamic space, it will try to print the lisp function name. 18:49:28 haha, wow, I had forgotten all about how to use this 18:50:20 <|3b|> ok, seems to work, #3 in thread 1 seems to be "GET-MUTEX" 18:50:29 the xlisp command should let you pass in a function or object ref and get at least some information 18:51:08 or maybe it should just use fun (: 18:51:35 yeah, my version of the script already tries to be a tiny bit more clever. 18:52:32 And if you see a futex call in the stacktrace, you can use lock_word_info to find the thread that holds it. lisp_thread_info and symval are also new, I think. 18:52:45 But I really need to translate it to Python to get rid of all the kludges. 18:52:46 <|3b|> nothing below that, same for thread 2 (get-mutex then garbage) 18:54:05 <|3b|> thread 3 is get-mutex, gethash3, equal-but-no-car-recursion, nothing, gethash3, more junk 18:55:30 That you're getting lock_word= is a bit suspicious. 18:56:17 <|3b|> 4 is similar, 5 is condition-wait followed by stream stuff 18:56:36 And since you're in a GC locking thing, you should see way more C function names in the stack trace that should be quite telling. 18:56:38 Good old x86 was a lot more debuggable than what you've pasted. 19:02:54 <|3b|> hmm, might actually be debuggable from lisp if i don't run it from run-tests.sh 19:03:36 <|3b|> (not that i remember how to deal with threads in the sbcl debugger) 19:04:02 *|3b|* tries in slime instead 19:05:23 -!- ignotus [~ignotus@unaffiliated/ignotus] has left #sbcl 19:10:56 <|3b|> more annotations, not sure how useful 19:11:14 -!- homie [~levgue@xdsl-84-44-153-230.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:13:39 <|3b|> hmm, one of the tries deadlocked on "thread result lock"+"World Lock" instead of "GC lock"+"World Lock" 19:28:22 hargettp [~phil@dhcp-161.mirrorimage.net] has joined #sbcl 19:30:17 -!- hargettp [~phil@dhcp-161.mirrorimage.net] has quit [Client Quit] 19:44:02 \\?\c:\lpt1 (Oh the possibilities! This is going to be fun.) 19:49:17 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:49:18 -!- ChanServ has set mode +o nikodemus 19:51:18 lichtblau: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath 19:52:23 yeah, that's what I've been reading 19:56:57 the interesting part is that \\?\ disables all string parsing 19:57:34 which means that the rest must necessarily be the truename 20:08:32 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:10:06 -!- Quadrescence [~Quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 20:12:11 nikodemus: FWIW, 3b pasted lots of stuff regarding the deadlock thing at http://paste.lisp.org/+2NNN 20:12:17 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 20:15:22 thanks 20:20:25 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 20:36:38 ASau [~user@95-28-79-252.broadband.corbina.ru] has joined #sbcl 20:58:26 <|3b|> can i get backtraces from other threads from ldb? 21:22:06 -!- Kryztof [~user@csrhodes.plus.com] has quit [Ping timeout: 260 seconds] 21:45:11 |3b|: I do that from gdb. 22:18:51 lisper [18d1340b@gateway/web/freenode/ip.24.209.52.11] has joined #sbcl 22:30:05 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl 22:36:58 <|3b|> does loading a .fasl hold the world lock? 22:39:09 *|3b|* should probably avoid trying to test deadlock stuff directly from C-c C-c if so :p 22:45:41 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 22:45:41 -!- ChanServ has set mode +o nikodemus 22:57:58 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 258 seconds] 23:00:56 <|3b|> http://paste.lisp.org/display/123978 another set of backtraces 23:09:37 <|3b|> inspector says the GC lock is free, d1 is waiting on world lock, and d3 holds world lock and waits on gc lock (d1 and d3 both still in debugger) 23:17:56 Quadrescence [~Quad@unaffiliated/quadrescence] has joined #sbcl 23:31:28 -!- hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has quit [Quit: Leaving...] 23:53:58 hargettp [~hargettp@pool-71-184-177-187.bstnma.east.verizon.net] has joined #sbcl