Da
Show enters and exits. Hide enters and exits.
| 00:11:54 | brixen | 1.9 still just randomly breaks shit :( |
| 00:12:28 | brixen | or is it broken or change? inquiring minds want to know |
| 00:12:47 | brixen | these pack specs passed last week |
| 00:12:57 | brixen | ugh, PITA to track this shit down |
| 00:13:07 | brixen | is annoyed |
| 00:31:11 | evan | dbussink: poke |
| 00:31:14 | evan | he's probably asleep. |
| 00:32:11 | brixen | probably |
| 00:32:18 | brixen | or drunk |
| 00:32:25 | brixen | or drunk and asleep |
| 00:33:44 | evan | heh |
| 00:33:58 | evan | for me, it's highly likely they're occuring at the same time. |
| 00:34:06 | brixen | heh |
| 01:05:49 | goyox86 | guys is there a convencio about what rbx kernel exception messages messages should look like |
| 01:05:58 | goyox86 | ?? |
| 01:06:02 | evan | how do ya mean? |
| 01:06:15 | prophile | ascii art pictures of furry animals |
| 01:07:18 | goyox86 | evan: I've just working in some Fiber failing specs and for example Fiber.new should raise a ArgumentError if it is called without a block |
| 01:08:03 | goyox86 | I'm raising the Exception and the spec pass but should i show the same message as in MRI: "tried to create Proc object without a block" |
| 01:08:56 | evan | if the message makes sense, sure |
| 01:09:02 | evan | but you don't have to use the exact same message. |
| 01:09:06 | brixen | goyox86_: 2 things: 1. if the MRI exception makes sense, copy it, 2. we don't spec the exception msg itself |
| 01:09:07 | evan | we decided that long ago. |
| 01:09:40 | brixen | goyox86_: be as precise, descriptive, and concise as you can in the error msgs |
| 01:09:59 | brixen | FFFFF ucking encodings |
| 01:10:01 | brixen | grrr |
| 01:10:43 | brixen | I swear these specs were passing |
| 01:11:32 | goyox86 | brixen: encodings, grrrr, i remember a Rails app with MRI 1.9.1, i was going nutz! |
| 01:11:48 | goyox86 | evan: what |
| 01:12:02 | evan | pardon? |
| 01:12:30 | goyox86 | evan; waht happened with the gems, dependencies bug in 1.9.2, they used your patch? |
| 01:12:53 | evan | yeah |
| 01:12:57 | evan | they applied my patch to 1.9.3 |
| 01:13:06 | evan | it's going to be backported to 1.9.2 tomorrow |
| 01:13:21 | evan | it makes "require 'rubygems'" undo the prelude weirdness |
| 01:13:31 | evan | so that there is a workaround for the 1.9 weird logic. |
| 01:14:33 | goyox86 | evan: I can't believe a bug as important like this wasn't flagged as priority :s, wycats did well making the alarm :] |
| 01:14:47 | evan | yeah |
| 01:14:51 | evan | i'm not happy with the situation |
| 01:14:54 | evan | or really with my fix |
| 01:14:57 | evan | but it's better than nothing. |
| 01:15:31 | goyox86 | evan: it's a fix, after all :] |
| 01:16:02 | brixen | I think the only way to ensure these specs work with encodings on 1.9 is to make a matcher that does a byte-by-byte compare |
| 01:16:08 | brixen | independent of any ruby method like #== |
| 01:16:28 | brixen | I don't know what they changed, but this shit is a bitch :( |
| 01:16:57 | evan | brixen: you can't set the encoding to ASCII? |
| 01:17:02 | evan | or BINARY i gues sit is. |
| 01:17:03 | evan | it is. |
| 01:17:15 | brixen | well, here's the problem |
| 01:17:33 | brixen | #pack apparently encodes based on the encoding set in the file with a magic comment |
| 01:17:45 | brixen | and then that has to match what the expected string is |
| 01:18:13 | brixen | but if we set encoding to ascii-binary, what does that say about correctness of #pack when it's set to utf-8 |
| 01:18:24 | evan | ug. |
| 01:18:25 | brixen | or ISO-8859-1 |
| 01:18:25 | evan | nothing. |
| 01:18:28 | brixen | or etc |
| 01:18:33 | brixen | so. frustrating. |
| 01:18:41 | evan | can we ignore that for now? |
| 01:18:56 | brixen | well, these specs were passing when I wrote them |
| 01:19:10 | goyox86 | evan:fibers are currently implemented in C++ isn't? |
| 01:19:11 | brixen | and I added some today and tested with preview3 and boom, failures |
| 01:19:20 | brixen | so I'm like WTF dudes and dudettes |
| 01:19:23 | evan | goyox86_: yes. |
| 01:19:51 | evan | brixen: zoinks. |
| 01:20:46 | brixen | did they break that ascii-binary compares with any other encoding or something? |
| 01:20:54 | evan | possible |
| 01:20:59 | brixen | how is anyone to know these things |
| 01:21:25 | brixen | because the file encoding was ISO-8859-1 and all the expected strings were force_encoded to binary |
| 01:21:31 | brixen | that's the way yugui set it up |
| 01:22:26 | brixen | and her comment in the pack_spec.rb file is: |
| 01:22:34 | brixen | # Script encoding of this file should be neither ASCII-8BIT, US-ASCII nor UTF-8. |
| 01:22:37 | brixen | # This makes it easier to verify that Strings are converted into correct encodings. |
| 01:22:43 | evan | you should ask wycats |
| 01:22:45 | evan | he's an expert. |
| 01:24:37 | goyox86 | wycats has become an encoding expert, his posts helped me a lot to understand WTF was happening with a Rails app i was working on |
| 01:26:03 | evan | goyox86_: you know Rubinius::Fiber is missing stuff, right? |
| 01:26:59 | goyox86 | evan: I know :], but i was just trying to make some kernel specs pass :] |
| 01:27:16 | evan | ah ok |
| 01:27:18 | evan | no problem |
| 01:27:26 | evan | just making sure we're all on the same page. |
| 01:28:08 | goyox86 | evan: no pro bro, i know 1.9 features are planned for the future :-) |
| 01:39:12 | brixen | ok, whew, this was a problem with the with_feature guard not activating |
| 01:39:23 | brixen | #pack sets the encoding it ascii-8bit as one would hope |
| 01:39:33 | brixen | s/it/to/ |
| 01:40:31 | evan | man, just discovered a mega fail. |
| 01:40:40 | brixen | ? |
| 01:40:44 | evan | i totally hooked up finalizer support for data objects wrong |
| 01:40:50 | evan | and by wrong, i mean not at all. |
| 01:40:55 | brixen | oops |
| 01:40:56 | evan | i wrote Data::finalize |
| 01:41:04 | evan | but never called needs_finalization with it. |
| 01:41:16 | evan | I stupidly allowed the finalizer to call to be null |
| 01:41:25 | evan | and so it went uncaught until now. |
| 01:42:39 | evan | I must have gotten distracted |
| 01:43:16 | brixen | hm |
| 01:43:37 | brixen | I think I'll make our .mspec config MRI friendlier |
| 01:43:44 | evan | i'm a little worried that finalizers aren't running much too |
| 01:43:49 | evan | need to find that out now. |
| 01:47:18 | evan | fudge. |
| 01:48:06 | brixen | :( |
| 01:49:24 | evan | 100000.times { BigDecimal.new("100.03") } |
| 01:49:34 | evan | things. get. very. slow |
| 01:51:01 | evan | ug. |
| 01:51:04 | brixen | after you fixed the Data finalizer issue? |
| 01:51:06 | evan | they never die. |
| 01:51:17 | evan | no, finalizers just brought this to my attention. |
| 01:51:18 | brixen | or something is keeping them alive |
| 01:51:23 | evan | yep. |
| 01:51:26 | brixen | hmm |
| 01:51:31 | evan | i know too |
| 01:51:38 | evan | because a Data's inside can be written to directly |
| 01:51:54 | evan | i was calling remember_object when it was created |
| 01:52:04 | evan | and remember_object inside Data::Info::mark |
| 01:52:06 | evan | in other words. |
| 01:52:14 | evan | we've never been collecting any Data objects. |
| 01:52:15 | evan | ever. |
| 01:52:20 | brixen | ouch |
| 01:52:37 | evan | that might explain why datamapper gets so slow. |
| 01:53:57 | brixen | ok, food, bbiab |
| 01:54:02 | evan | later. |
| 03:16:59 | Plymouth | when's a windows release coming for rubinius? |
| 04:38:35 | cremes | Plymouth: the project needs windows developers to pitch in; no window release until it gets some windows lovin' |
| 05:12:36 | boyscout | Added start of Ragel-based Array#pack, String#unpack. - b706b66 - Brian Ford |
| 05:12:36 | boyscout | Added benchmarks for String#unpack('C'). - bfef694 - Brian Ford |
| 05:12:36 | boyscout | Added specs for String#unpack Cc directives. - a7af57b - Brian Ford |
| 05:12:36 | boyscout | Fixed be_computed_by matcher to display inspected value. - f2e0ea2 - Brian Ford |
| 05:12:36 | boyscout | Added Array#pack specs for embedded space/NULL. - ee6fde2 - Brian Ford |
| 05:24:56 | boyscout | CI: rubinius: ee6fde2 successful: 3458 files, 13692 examples, 41271 expectations, 0 failures, 0 errors |
| 05:29:32 | dbussink | evan: you rang? |
| 05:34:55 | dbussink | brixen: you deliberately didn't add the ragel source files? |
| 05:55:53 | brixen | dbussink: the ragel files are deliberately in rapa |
| 05:56:02 | brixen | because this is not just a rbx project |
| 05:56:15 | brixen | dbussink: I gave you the link :P |
| 05:57:16 | scoopr | rapa? |
| 06:02:17 | brixen | ragel pack |
| 06:02:25 | brixen | or RAgel PAck |
| 06:04:53 | scoopr | rapa (fi) ~= mud (en) :P |
| 06:05:14 | brixen | heh, nice :) |
| 06:06:27 | brixen | although, in Ruby we write that =~ :D |
| 06:07:10 | scoopr | I always get that wrong :P |
| 06:07:31 | brixen | me too, but the ruby parser never fails to correct me :) |
| 06:30:02 | dbussink | brixen: ok, well, more wondering about how people can easiest contribute then by providing new formats :) |
| 06:38:16 | brixen | dbussink: it's a git repo, have you read the readme? :P |
| 06:38:32 | brixen | dbussink: and people can contribute also by fixing the horrid pack/unpack specs |
| 06:38:33 | dbussink | brixen: hehe, just want to know where to point people to :) |
| 06:38:37 | brixen | so I don't have to do it all |
| 06:39:26 | brixen | also, I need to work on this a bit without too much interference |
| 06:51:05 | dbussink | brixen: can imagine yeah, this is plain gruntwork |
| 06:51:07 | dbussink | not plain maybe, but gruntwork still |
| 06:51:29 | brixen | well, more like figuring out what works |
| 06:51:36 | brixen | then it will be easier to add stuff |
| 06:51:42 | brixen | I think the groundwork is pretty good |
| 06:51:50 | brixen | I'm doing the integer formats next |
| 06:52:03 | evan | hah. more gc bugs. |
| 06:52:15 | brixen | :( |
| 06:52:17 | evan | finalizers were, in the case of mature objects that needed finalization |
| 06:52:25 | evan | keeping the object alive always |
| 06:52:29 | evan | and thus never finalizing |
| 06:52:30 | evan | oops! |
| 06:52:46 | brixen | evan: you know what, this is great news :) |
| 06:52:53 | evan | which, in the case of Data objects, was all of them. |
| 06:52:54 | brixen | rbx memory profile should be much better now |
| 06:53:11 | brixen | I'll take a bug fix over a hard optimization any day |
| 06:53:16 | evan | totally. |
| 06:53:28 | evan | there are still some bugs that need some thought. |
| 06:53:35 | evan | I think. |
| 06:53:39 | brixen | heh |
| 06:53:50 | brixen | are you wondering what you don't know that you don't know? |
| 06:53:54 | evan | so, consider this. |
| 06:54:05 | evan | no, i know what i don't know. |
| 06:54:10 | evan | so, you have a Data |
| 06:54:20 | evan | and thusly an RData* to use for Data_Make_Struct |
| 06:54:40 | dbussink | evan: you rang? or was it for this issue? |
| 06:54:41 | evan | I used a trick to have the RData part be embedded in Data |
| 06:54:47 | evan | by making them always mature and pinned |
| 06:54:53 | evan | dbussink: I got it. :) |
| 06:55:05 | dbussink | evan: found this through the valgrind stufF? |
| 06:55:07 | evan | so, that RData* has the void* for the struct that the user wanted |
| 06:55:16 | evan | dbussink: via a long path, yes. |
| 06:55:31 | evan | dbussink: oh oh, did you compile valgrind by hand for OS X? or use ports? I thought you said ports. |
| 06:55:44 | dbussink | evan: macports yeah |
| 06:55:48 | dbussink | valgrind-devel |
| 06:56:04 | evan | anyway, so Data->RData->void*->....->VALUE |
| 06:56:25 | evan | that VALUE is some object that will be picked up by a custom mark function |
| 06:56:32 | evan | now the issue: |
| 06:57:05 | evan | if Data is mature and the VALUE is young, VALUE won't be seen properly by the young GC |
| 06:57:17 | evan | there is no write barrier for when the user sets VALUE |
| 06:57:23 | brixen | hrm, indeed |
| 06:57:34 | evan | because thats in foreign code. |
| 06:58:10 | evan | anyway, i'll work on this tomorrow morning |
| 06:58:24 | evan | but i'm thinking about having Data have some special case code, capi handle wise |
| 06:58:44 | brixen | yeah, seems like it must |
| 06:59:00 | evan | where by the young gc will consider Data handles always (calling the mark) |
| 06:59:20 | evan | but the mature gc will treat the handles as "normal", ie, letting them expire via reachability |
| 07:00:06 | brixen | hmm |
| 07:01:04 | evan | anyway |
| 07:01:07 | evan | i'm going to head to bed. |
| 07:01:13 | brixen | ok, night! |
| 07:01:16 | evan | nite! |
| 07:01:17 | brixen | is processing |
| 11:36:31 | dbussink | tarcieri: ping? |
| 15:00:44 | tarcieri | dbussink: heh was long since asleep then |
| 15:00:51 | dbussink | tarcieri: i guessed so |
| 15:01:02 | dbussink | tarcieri: wanted to bug you with some reia install issues :) |
| 15:01:17 | dbussink | or at least not being able to just do 'rake' |
| 15:01:28 | tarcieri | you should just be able to do rake |
| 15:01:51 | dbussink | tarcieri: this is what i get: https://gist.github.com/d28f18e6ed68fe3732dd |
| 15:02:01 | dbussink | i had to change the toplevel rakefile to accept 5.8 as a version too |
| 15:02:09 | dbussink | because it assumes 3 part version numbers |
| 15:02:40 | tarcieri | yeah |
| 15:02:44 | tarcieri | I see |
| 15:02:56 | tarcieri | there's an error in the source code, but the old preprocessor didn't care |
| 15:02:57 | tarcieri | lol |
| 15:03:25 | tarcieri | apparently they've retroactively added one which does |
| 15:04:00 | dbussink | i'm just a good bug magnet :) |
| 15:04:06 | tarcieri | there ya go |
| 15:04:19 | dbussink | tarcieri: cool :) |
| 15:04:26 | dbussink | tarcieri: you want a patch for that version number thingy? |
| 15:04:32 | tarcieri | sure! |
| 15:04:43 | dbussink | it's totally trivial, but hey, who cares :P |
| 15:05:48 | tarcieri | match(/\d\.\d(\.\d)?$/) |
| 15:05:49 | tarcieri | heh |
| 15:05:53 | dbussink | tarcieri: https://gist.github.com/b11f2ccf7bac2c17a53f |
| 15:06:01 | tarcieri | yeah |
| 15:06:02 | tarcieri | heh |
| 15:09:51 | dbussink | tarcieri: already using it for any serious business? |
| 15:10:08 | tarcieri | no |
| 15:10:09 | tarcieri | heh |
| 15:10:15 | dbussink | ah, too bad :P |
| 15:10:23 | dbussink | but i'm going to head home :) |
| 15:10:27 | tarcieri | http://github.com/tarcieri/lolcat |
| 15:10:34 | tarcieri | that's about all I use it for right now |
| 15:10:35 | tarcieri | heh |
| 15:54:11 | evan | morning |
| 15:54:39 | brianmario | wassup dude |
| 15:58:52 | brixen | morning |
| 16:11:43 | brixen | evan: so, you would keep a list of Data objects that the young GC would traverse? |
| 16:11:51 | brixen | on every collection |
| 16:11:57 | evan | no |
| 16:12:13 | evan | i'd see it via the traversal of the handles |
| 16:12:22 | brixen | ah ok |
| 16:12:35 | evan | one change I think i'm going to make |
| 16:12:40 | brixen | those handy handles |
| 16:12:42 | evan | I have Data as a mature object so I can pin it |
| 16:12:48 | evan | I'm going to ditch that |
| 16:13:04 | evan | because in the case of massive Data creation (10000.times { BigDecimal.new }) |
| 16:13:10 | brixen | do we use the fact that it's pinned? |
| 16:13:14 | evan | the effects are delayed until a mature collection |
| 16:13:15 | evan | yeah |
| 16:13:16 | evan | we do. |
| 16:13:31 | evan | because I pass out an address to the inside of it as the RData* |
| 16:13:35 | evan | i'm going to ditch that. |
| 16:13:38 | brixen | ah yes |
| 16:13:49 | evan | so that Data can be young, with a handle, and die quickly |
| 16:13:54 | evan | without burdoning the mature GC |
| 16:14:14 | brixen | cool |
| 16:14:36 | evan | there is some hilarious intellectual wanking on the fonc list. |
| 16:15:08 | brixen | oh, I set a filter on that and missed the new posts |
| 16:15:10 | brixen | reads |
| 16:17:01 | evan | i've just scanned it |
| 16:17:07 | evan | but it's such wanking. |
| 16:17:33 | brixen | you mean the "goals" thread? |
| 16:19:47 | evan | yeah |
| 18:37:43 | dbussink | afternoon |
| 18:38:03 | dbussink | evan: how bad is that performance on creating those bigdecimals? |
| 18:38:15 | evan | it's not great. |
| 18:38:20 | evan | but i've fixed the bug |
| 18:38:31 | evan | perf still isn't super for capi handles compared to MRI |
| 18:38:33 | evan | but we knew that. |
| 18:46:28 | dbussink | evan: guess that isn't easy to improve right? |
| 18:46:41 | evan | well, i've got a few ideas. |
| 18:46:46 | dbussink | evan: or maybe provide some mechanisms that people can use to improve their extensions? |
| 18:46:52 | evan | i don't know if we need to though |
| 18:47:10 | evan | my benchmark is very synthetic |
| 18:47:13 | dbussink | would be great if that isn't needed of course :) |
| 18:47:14 | evan | it might be an issue in real code. |
| 18:50:07 | dbussink | should write up some benchmarks that run stuff through the do driver |
| 18:50:09 | dbussink | drivers |
| 18:50:13 | dbussink | for different databases |
| 18:50:21 | evan | yeah |
| 19:35:56 | dbussink | looks some basic DO stuff is jit friendly ;) |
| 19:42:00 | dbussink | evan: i've made some rough benchmark numbers which mainly exercise the capi stuff |
| 19:53:45 | evan | k |
| 19:56:03 | dbussink | evan: these are some numbers: https://gist.github.com/ed8ecec55aa752444040 |
| 19:56:07 | dbussink | rbx and mri |
| 19:56:25 | dbussink | the weird thing there is that mysql is relatively a lot faster on rbx compared to postgres |
| 19:56:34 | dbussink | while the c code parts are very much alike |
| 20:05:26 | evan | i've got the capi/finalizer fix sorted |
| 20:05:34 | evan | dbussink: could you post the code for the benchmarks? |
| 20:09:28 | dbussink | evan: https://gist.github.com/923f464f71c50b2de25a |
| 20:09:40 | dbussink | you need the do_mysql, do_sqlite3 and do_postgres gems for that |
| 20:09:54 | dbussink | you can also just run the sqlite3 ones to start with |
| 20:10:14 | evan | k |
| 20:11:42 | slava | evan: heh, there's a photo of you on wikipedia |
| 20:11:54 | slava | http://en.wikipedia.org/wiki/File:Paul_Wall.jpg |
| 20:12:23 | rue | dbussink: Parallelises better? |
| 20:12:39 | dbussink | rue: how do you mean? |
| 20:12:41 | evan | slava: haha |
| 20:13:27 | sbryant | evan's got the grill bling. |
| 20:20:37 | evan | slava: i wonder if grillz iritate the inside of your gums |
| 20:20:44 | evan | they probably would mine. |
| 20:21:40 | slava | evan: I've never worn one |
| 20:22:08 | evan | i wasn't suggesting you had, but if you had, i'd demand pictures. |
| 20:22:27 | imajes | i think you should get some grillz evan |
| 20:22:32 | imajes | it really is the next step up |
| 20:22:44 | goyox86 | slava: That dude has more money in his mouth than i've earned in my entire life lol |
| 20:23:05 | evan | goyox86: it's probably cubic zirconium |
| 20:25:41 | goyox86 | evan: i've never herad that term, heh |
| 20:26:49 | goyox86 | evan: according wikipedia the right term is "Cubic zirconia", lol btw nice pic |
| 20:27:40 | goyox86 | evan: I think this is "Unobtanium" |
| 20:27:47 | goyox86 | :p |
| 20:32:50 | ReinH | hmm, found a potential rbx 1.0.1 bug: l=lambda{|x,y| x+y}; [[1,2],[3,4]].map(&l) gives me a Rubinius::ObjectBoundsExceededError |
| 20:33:02 | ReinH | justin-george: also, oh hi |
| 20:33:15 | ReinH | on rbx-1.0.1-20100603 |
| 20:35:18 | dbussink | ReinH: does it also happen with current master? |
| 20:35:26 | ReinH | good point |
| 20:35:45 | ReinH | doh |
| 20:35:47 | ReinH | let's see |
| 20:36:07 | ReinH | hmm, can I install rubinius from master using rvm? |
| 20:36:19 | ReinH | I'm sure I can... RTFMing |
| 20:37:49 | ReinH | rvm install rbx-head, nice |
| 20:38:20 | justin-george | hey Rein, how's it going? |
| 20:39:04 | ReinH | justin-george: well :) |
| 20:39:05 | ReinH | you? |
| 20:40:16 | justin-george | it's hot! Damn hot, real hot. Doing some rearchitecting of the entire New Relic ruby agent. |
| 20:40:33 | justin-george | that's why I'm a programmer, the romance and excitement of it all. |
| 20:41:05 | ReinH | no kidding |
| 20:41:11 | ReinH | romantic, exciting and hot |
| 20:45:48 | brixen | ReinH: I get [3, 7] from that on rbx head |
| 20:45:51 | brixen | same as mri |
| 20:45:57 | ReinH | cool |
| 20:46:07 | ReinH | compiling... |
| 20:46:08 | brixen | ReinH: but do try there :) |
| 20:46:27 | ReinH | will do |
| 21:16:47 | boyscout | Remove defunct subclass array - 279ec3b - Evan Phoenix |
| 21:16:47 | boyscout | Memory cleanup and C-API finalization fixes - 3854f9d - Evan Phoenix |
| 21:31:13 | evan | dbussink: poke |
| 21:32:30 | brixen | http://wiki.github.com/graydon/rust/language-faq |
| 21:38:46 | evan | wtf is with benchmark |
| 21:38:49 | evan | look at these results: |
| 21:39:03 | evan | http://gist.github.com/468685 |
| 21:39:37 | evan | thats 26s wall clock |
| 21:39:42 | evan | but the total is 8s. |
| 21:39:46 | evan | ?! |
| 21:41:19 | brixen | multiple threads? |
| 21:41:31 | evan | that would be the inverse |
| 21:41:57 | brixen | evan: could you tell me what you get from [0xabab_1212_dede_3434].pack("L") |
| 21:41:59 | evan | small wall clock |
| 21:42:01 | evan | big user time |
| 21:42:11 | evan | |Blaze||: perhaps. |
| 21:42:11 | brixen | evan: and also l, V |
| 21:42:18 | evan | this is a massive write benchmark |
| 21:42:30 | evan | from what I can tell |
| 21:42:46 | evan | brixen: "44\336\336" |
| 21:42:50 | brixen | ty |
| 21:42:56 | evan | np |
| 21:44:16 | evan | ug ug ug |
| 21:44:34 | evan | this means that any ruby use of benchmark that ends up hanging out in the kernel will show up low |
| 21:44:45 | evan | but we don't use utime to get the real user time |
| 21:44:49 | evan | so we'll always report the wall clock |
| 21:44:54 | evan | and be hugely inflated. |
| 21:45:04 | evan | because benchmark reports, imho, the wrong column. |
| 21:45:18 | boyscout | CI: Commit 3854f9d failed. http://github.com/evanphx/rubinius/commit/3854f9dfc7a68afd6e40778ef9e24e2421953f18 |
| 21:45:23 | evan | oh hello. |
| 21:45:46 | evan | wtf. |
| 21:45:52 | evan | why did a wait spec start failing... |
| 21:54:59 | brixen | I would have opted for a spec failure |
| 21:55:03 | brixen | got a kernel panic instead |
| 22:06:21 | evan | :| |
| 22:57:42 | evan | finally adding some code I should have added long ago |
| 22:58:00 | evan | namely, method deoptimization when it triggers too many uncommon branches |
| 22:58:33 | brixen | ah cool |
| 22:59:22 | brixen | sometimes you have to rethink your decisions, even if you are a JIT |
| 22:59:45 | evan | making decisions as late as possible means you have to deal with making the wrong ones. |
| 23:00:09 | evan | but it also means you CAN deal with making wrong decisions. |
| 23:00:15 | brixen | indeed |
| 23:01:06 | evan | i have no idea what the right number of uncommon hits is |
| 23:01:08 | evan | i'm doing some testing |
| 23:01:11 | evan | i had it at 500 |
| 23:01:12 | evan | i'm trying 5 now. |
| 23:01:16 | brixen | hmm |
| 23:01:31 | brixen | do you know where you were getting a lot of uncommon's piling up? |
| 23:01:49 | evan | I can see the method in question |
| 23:01:53 | evan | and the ip, sp, etc. |
| 23:02:09 | brixen | for what code? a particular bench? |
| 23:02:10 | evan | and I can feed more info into it |
| 23:02:23 | evan | it's the dataobjects bench dbussink had |
| 23:02:27 | brixen | ahh |
| 23:03:07 | evan | I need to be feeding a reason into the uncommon_interpreter |
| 23:03:13 | evan | so it can be even smarter. |
| 23:04:36 | evan | i'm guessing that the number doesn't matter a lot |
| 23:04:39 | evan | what matters is doing it |
| 23:04:42 | evan | i'm testing that now. |
| 23:05:24 | brixen | seems like it should have a certain threshold |
| 23:05:34 | brixen | wouldn't want to deopt on a few misses |
| 23:05:41 | brixen | I'm assuming |
| 23:06:19 | brixen | I wonder if you could tune the number based on the seen types profile |
| 23:06:34 | evan | probably could |
| 23:06:47 | evan | I could feed in a strength counter to uncommon |
| 23:07:06 | evan | so I could see "oh, a guard with a low chance failed, thats ok" |
| 23:07:17 | evan | or "ah crap! a foolproof guard failed!" |
| 23:07:34 | evan | i've got all that info. |
| 23:07:41 | brixen | is the IC dump available through the agent? |
| 23:07:49 | evan | not atm |
| 23:07:51 | evan | but i could make it so. |
| 23:07:54 | brixen | that would be sweet |
| 23:08:01 | evan | need to figure out how to query it |
| 23:08:07 | evan | since the agent isn't really made for a massive data dump |
| 23:08:14 | brixen | ah true |
| 23:08:38 | brixen | a query based on a method would be kinda cool |
| 23:09:02 | brixen | like, I wonder what the types flowing through SomeClass#some_method are |
| 23:10:03 | evan | could probably do something like that. |