Show enters and exits. Hide enters and exits.
| 02:16:30 | evan | brixen: I can't understand the existing qsort code, so I recoded it to help me understand it. http://gist.github.com/396835 |
| 06:19:44 | brixen | evan: awesome, and your recoded version fails to have the bug that I showed earlier |
| 06:19:53 | evan | thats correct. |
| 06:19:53 | brixen | understandable and correct |
| 06:19:54 | brixen | win |
| 06:19:55 | brixen | :) |
| 06:20:10 | evan | passes the sort specs we have |
| 06:20:15 | brixen | excellent |
| 06:20:18 | evan | not sure how extensive they are |
| 06:20:21 | brixen | I'll add this case |
| 06:20:35 | brixen | apparently, tim sort is in jdk 7 |
| 06:20:42 | brixen | might be interesting to investigate |
| 06:20:46 | evan | ok |
| 06:20:49 | evan | post 1.0 perhaps |
| 06:20:51 | brixen | yep |
| 06:20:57 | evan | my qsort is ported from the qsort wikipedia page. |
| 06:21:00 | brixen | are you going to push this? |
| 06:21:06 | evan | if you'd like me to |
| 06:21:12 | brixen | I don't see why not |
| 06:21:16 | evan | i still wonder what the heck is going on in the existing qsort |
| 06:21:23 | brixen | let's see, do we have some benches |
| 06:21:29 | evan | perhaps |
| 06:21:32 | brixen | might be good to do a sanity check on perf |
| 06:22:58 | brixen | the existing sort is a three-way qsort |
| 06:23:13 | brixen | dunno if it was a lot more performant than a regular qsort |
| 06:24:33 | evan | well |
| 06:24:54 | evan | looking at the description of three-way qsort helps see what the current qsort is doing |
| 06:24:59 | evan | but i suspect it's also the source of the bug. |
| 06:25:15 | evan | since it attempts to treat values that are equal to the pivot specially |
| 06:25:33 | evan | which is one big property of the broken sorted array |
| 06:25:50 | evan | given the complexity involved |
| 06:25:57 | evan | the sorter algorithm might be faster |
| 06:26:19 | evan | even if it's does more comparisons |
| 06:26:22 | evan | in my qsort |
| 06:26:35 | evan | I ignore elements that are equal to the pivot, not moving them |
| 06:26:44 | evan | not sure if thats a bug or not, but that minimizes some operations |
| 06:26:45 | slava | hi evan |
| 06:26:48 | slava | qsort eh |
| 06:26:50 | slava | why not mergesort? |
| 06:27:01 | evan | i was trying to fix the existing one |
| 06:27:15 | evan | and i'm trying to do minimize the changes |
| 06:27:22 | evan | since we're in 1.0 lockdown. |
| 06:27:27 | brixen | I think the simple qsort is fine |
| 06:27:54 | brixen | yes, the equal key treatment in 3-way is very likely the cause of this bug |
| 06:28:03 | brixen | I'm reading the algo now |
| 06:28:03 | scoopr | not moving equal elements would mean it's "stable", right? |
| 06:28:20 | brixen | scoopr: not necessarily |
| 06:28:47 | evan | scoopr: no, because the pivot is always moved around |
| 06:29:17 | scoopr | oh right, pivot |
| 06:29:39 | evan | brixen: well, i'm going to actually head to bed here |
| 06:29:45 | evan | you wanna check it over |
| 06:29:54 | evan | and go ahead and commit it if you're happy with it/ |
| 06:29:54 | evan | ? |
| 06:30:28 | brixen | I'll wait till morning |
| 06:30:32 | brixen | I'm still looking at this |
| 06:30:33 | evan | k |
| 06:30:38 | evan | check it over |
| 06:30:39 | brixen | k |
| 06:30:41 | evan | and lets discuss in the morning. |
| 06:30:44 | brixen | sounds good |
| 06:30:51 | slava | do you have a roadmap for after 1.0? |
| 06:31:02 | brixen | slava: more like a freeway map :D |
| 06:31:09 | evan | slava: we're starting to put one together. |
| 06:33:07 | evan | ok, good night! |
| 06:35:15 | brixen | night! |
| 16:13:23 | evan | morning. |
| 16:13:56 | brixen | morning |
| 16:14:20 | brixen | so, the reimplemented sort is slightly slower on the benchmark/rubinius/standalone_array_sort.rb |
| 16:14:30 | brixen | but not enough to worry I think |
| 16:14:43 | brixen | I could reimplement the 3-way partition algo |
| 16:14:54 | brixen | or we could run with this for 1.0 |
| 16:16:19 | evan | hm. |
| 16:16:22 | evan | lets go with the simple one |
| 16:16:28 | evan | i'm worried about making too big of a change. |
| 16:16:46 | evan | even replacing the method whole sale is a little worrysome |
| 16:16:54 | evan | but I don't have a better way to deal with this bug. |
| 16:16:57 | brixen | indeed |
| 16:17:30 | evan | the code in those benchmarks is pretty pathalogical |
| 16:17:40 | evan | i'm betting that most real world usages of sort will be the same. |
| 16:17:50 | brixen | right |
| 16:18:23 | brixen | have you run the rails 3 tests with this? |
| 16:18:31 | evan | no, but I can. |
| 16:18:39 | brixen | ok |
| 16:36:31 | evan | hm, got a hang. |
| 16:37:45 | evan | in spin_lock |
| 16:38:19 | brixen | hm |
| 16:40:06 | evan | mmm |
| 16:40:07 | evan | ok |
| 16:40:10 | evan | it's in the kill specs |
| 16:40:14 | evan | that this is happening. |
| 16:45:35 | evan | ok, i think I see the spin_lock deadlock problem. |
| 16:45:56 | brixen | sweet |
| 16:49:04 | evan | :/ |
| 16:49:20 | evan | pthread_cond_signal is not safe to use from a signal handler. |
| 17:03:56 | evan | if anyone is curious, here is the case: http://gist.github.com/397548 |
| 17:05:51 | brixen | hmm |
| 17:08:28 | scoopr | eww, threads + signals + cross-platform vm that needs to make sense of it all.. have fun! =) |
| 17:41:11 | evan | well hrmph |
| 17:41:21 | evan | i think the best is to work around this by not using a Channel for sleeping |
| 17:42:32 | brixen | could we use a Tent or SleepingBag? :) |
| 17:43:07 | evan | heh |
| 22:31:31 | imajes | evan: hey, does/can/will rbx support ++ and -- operators? |
| 22:31:38 | imajes | it'd be nice to have that sugar to get around foo = foo +1 |
| 22:31:43 | evan | never. |
| 22:31:56 | evan | thats what += 1 is for. |
| 22:32:22 | imajes | sadness. |
| 22:32:28 | brixen | imajes: you should search the mailing list for the N discussions of adding += 1 |
| 22:32:41 | imajes | haha |
| 22:32:51 | brixen | yes, the sadness is that N would likely be a Bignum on most platforms |
| 22:32:51 | imajes | += 1 is nicer for sure. |
| 22:33:06 | brixen | er, adding ++ |
| 22:33:54 | brixen | and by mailing list, I mean MRI mailing lists like ruby-core |
| 22:33:55 | evan | imajes: no one will add it |
| 22:34:00 | evan | unless they're making their own language. |
| 22:34:04 | imajes | sure, |
| 22:34:05 | evan | ie, not-ruby. |
| 22:34:43 | imajes | right |
| 22:34:52 | imajes | but += is rbx? i don't think i remember getting mri tosupport it |
| 22:35:22 | slava | evan: when is rbx going to support postfix syntax |
| 22:35:25 | slava | and static types |
| 22:35:48 | evan | when I add inline COBOL |
| 22:36:32 | evan | COBOL do |
| 22:36:34 | evan | IDENTIFICATION DIVISION. |
| 22:36:36 | evan | PROGRAM-ID. HELLO-WORLD. |
| 22:36:38 | evan | PROCEDURE DIVISION. |
| 22:36:40 | evan | DISPLAY 'Hello, world'. |
| 22:36:42 | evan | STOP RUN. |
| 22:36:44 | evan | end |
| 23:16:03 | evan | brixen: trying to replace sleep with something that uses nanosleep is causing more trouble |
| 23:16:06 | evan | so i'm not going to do that. |
| 23:17:47 | brixen | ok |
| 23:18:16 | evan | there is a lot of thread interaction |
| 23:18:33 | evan | it's going to require some extensive testing to do differently, I think. |
| 23:18:37 | brixen | ok |
| 23:18:51 | evan | i'll try and come up with another workaround to avoid the spin_lock deadlock |
| 23:18:52 | brixen | threads and signals are just the cat's meow huh |
| 23:18:56 | evan | no |
| 23:18:57 | evan | they're not. |
| 23:19:07 | brixen | </sarcasm> :) |
| 23:19:12 | evan | :) |
| 23:36:39 | evan | funny, apple added qsort_b() |
| 23:36:48 | evan | which takes a block instead of a function pointer |
| 23:37:16 | evan | FUCKING A RAILS. |
| 23:37:29 | brixen | :/ |
| 23:37:46 | brixen | evan: logged into IM? |
| 23:37:51 | evan | yep. |
| 23:37:56 | brixen | hum |
| 23:38:13 | brixen | shows you as offline |
| 23:38:41 | evan | aim is fucked up I think. |