Show enters and exits. Hide enters and exits.
| 00:01:20 | boyscout | CI: 1824ab5 success. 3002 files, 11393 examples, 35413 expectations, 0 failures, 0 errors |
| 00:01:35 | brixen | sweet |
| 00:14:39 | brixen | ok, I'm going to test this on elle now |
| 00:14:46 | brixen | building ext is a little more verbose |
| 00:14:51 | brixen | but such is life with rake |
| 00:15:06 | brixen | it's good probably, let's you know what is going on |
| 00:15:52 | evan | k |
| 00:28:19 | brixen | well, good thing I checked |
| 00:28:22 | brixen | man POS! |
| 00:28:36 | brixen | why are platforms so fucking ridiculous |
| 00:28:56 | slava | brixen: does your ffi do structs on ppc? |
| 00:29:09 | slava | I just discovered the alignment rules for fields are super-weird |
| 00:30:12 | brixen | I thought you had a wiki page on struct alignment on ppc? |
| 00:30:24 | brixen | something about this rings a bell |
| 00:30:49 | slava | no I made a wiki page about passing structs by value |
| 00:30:57 | slava | this is about accessing the fields themselves |
| 00:31:19 | slava | struct { long long x; int y; } is 16 bytes but struct { int x; long long y; } is 12 |
| 00:32:00 | brixen | ahh, that's right |
| 00:32:13 | brixen | that's wacky |
| 00:32:54 | slava | so you have code to handle this? |
| 00:39:49 | brixen | slava: I don't know, I'd have to look |
| 00:39:56 | slava | never mind |
| 00:41:31 | brixen | sorry |
| 00:41:45 | brixen | trying to get stupid C to compile and link correctly |
| 00:41:50 | brixen | horrid language |
| 00:43:00 | slava | heh |
| 00:48:07 | evan | huh. |
| 00:48:14 | evan | i'm getting that strange env failure thing |
| 00:48:19 | evan | consistently too. |
| 00:48:34 | evan | it's very wierd. |
| 00:48:43 | brixen | does is persist through a rake clean? |
| 00:49:15 | brixen | I think I hit it once switching to c-ng, so I figured it was related to stale rbc's or something |
| 00:50:50 | evan | not sure why that would be |
| 00:50:57 | evan | it happened after I changed one file |
| 00:51:00 | evan | pretty randomly too |
| 00:51:02 | evan | i'm debugging it. |
| 00:51:41 | evan | it's like ENV itself freakes the fuck out. |
| 00:51:52 | evan | i'm poking. |
| 00:52:07 | evan | on the soft underbelly that is the UNIX environment variables |
| 00:53:25 | brixen | heh |
| 00:56:33 | evan | seems to be something with running them via rake |
| 00:56:33 | evan | bin/mspec ci -B full |
| 00:56:33 | evan | is fine. |
| 00:56:52 | evan | now, why it just started, thats a mystery. |
| 01:01:14 | brixen | weird |
| 01:04:09 | brixen | seriously g++?! seriously! |
| 01:04:29 | brixen | on linux I have to have the .o before the .a |
| 01:04:34 | brixen | something like this rings a bell |
| 01:04:47 | brixen | from maybe FIFTEEN years ago |
| 01:04:49 | brixen | man |
| 01:07:39 | evan | yeah |
| 01:07:42 | evan | lame-o |
| 01:07:43 | evan | i know. |
| 01:07:52 | brixen | I can't decide which is more lame |
| 01:07:57 | brixen | that it's not that way on os x |
| 01:08:02 | brixen | or it is that way on linux |
| 01:08:10 | brixen | asinine is what it is |
| 01:08:16 | slava | what's the problem exactly? |
| 01:08:38 | brixen | g++ has to get the .o files before the .a files on linux |
| 01:08:48 | brixen | or it just silently ignores that you asked it to link |
| 01:08:55 | brixen | SILENTLY |
| 01:09:25 | brixen | "oh, what's this .a doing here? <toss>" |
| 01:09:27 | slava | I think I've found another gcc bug |
| 01:09:29 | evan | yeah, the silently thing is the problem |
| 01:09:35 | brixen | it's like homer simpson or something |
| 01:56:47 | evan | oops! |
| 01:56:51 | evan | think I found the ENV problem |
| 01:56:55 | evan | testing now. |
| 01:57:14 | evan | seems that the JIT's inline FFI dispatcher didn't properly check that the return value of a :string type was NULL and return nil |
| 01:57:19 | evan | thats probably why it's so random |
| 01:57:31 | evan | because if the method that is calling getenv happens to heat up |
| 01:57:32 | evan | you see it |
| 01:57:35 | evan | otherwise you don't |
| 01:57:59 | slava | and stuff that calls getenv is rarely hot |
| 01:58:04 | slava | this is what scares me about JITs |
| 01:58:09 | evan | yep |
| 01:59:09 | brixen | interesting |
| 01:59:12 | evan | welcome to very late dispatched! |
| 01:59:16 | brixen | we could write a heater-upper |
| 01:59:34 | brixen | actually just force jit compile everything and run the specs |
| 01:59:36 | evan | might be useful to have a CI run that runs the specs over and over again |
| 01:59:54 | brixen | ah yeah, cus you wouldn't get the same inlining decisions |
| 01:59:59 | evan | right |
| 02:00:01 | brixen | just doing a forced upfront jit |
| 02:00:08 | evan | force jit doesn't actually test any runtime behavior |
| 02:00:13 | evan | but you need ICs to fill up |
| 02:00:19 | brixen | yeah |
| 02:02:10 | brixen | wouldn't be hard to run mspec repeatedly on a set of files |
| 02:02:19 | brixen | mspec --loop :files :) |
| 02:02:38 | brixen | mspec --repeat=10 :files |
| 02:02:49 | evan | heh |
| 02:02:53 | evan | sure |
| 02:02:55 | evan | add it |
| 02:02:58 | evan | we'll add a CI run |
| 02:03:07 | evan | add a rake target for it |
| 02:03:12 | evan | rake vm:horror |
| 02:04:11 | brixen | heh |
| 02:06:59 | ddub | rants on twitter |
| 02:07:21 | ddub | keynote literally crashed on the last line of my last slide |
| 02:07:49 | evan | :( |
| 02:08:30 | ddub | feels very disappointed @ apple right now |
| 02:11:21 | brixen | wow, no autosave in keynote? |
| 02:11:25 | brixen | that's crazy |
| 02:11:29 | brixen | what version? |
| 02:11:33 | ddub | still, after how many releases? |
| 02:11:33 | ddub | 09 |
| 02:11:47 | brixen | huh, I didn't know that |
| 02:11:49 | ddub | like I bitched on twitter, apple added autosave to cocoa in 10.4 |
| 02:11:59 | brixen | good thing I'm an obsessive cmd-s'er |
| 02:12:23 | ddub | the built-in autosave for cocoa kinda sucks in that it doesn't auto-save unless you have an actual _file_ |
| 02:12:31 | ddub | so you need to make sure you at least save a new file once :) |
| 02:13:21 | evan | oh yeah |
| 02:13:24 | evan | i always do that first |
| 02:13:32 | evan | save right after I open it |
| 02:13:35 | brixen | evan: oh, is the packed object stuff generic? should I try to add compiler support for it? |
| 02:14:01 | ddub | well iwork doesn't autosave even if you have a file |
| 02:14:23 | ddub | so i lost about 45 minutes of work, but worse - I have to work on this over the day off tomorrow now :P |
| 02:16:15 | evan | ddub: :( :( |
| 02:16:23 | evan | brixen: yeah, if you emit the calls to add_ivar |
| 02:16:28 | evan | then we can make it auto |
| 02:18:24 | brixen | k |
| 02:19:21 | ddub | evan: it is actually an intro to ruby for my team |
| 02:20:13 | evan | oh cool! |
| 02:20:30 | evan | so, i'm exposing a new way to use a FFI attached function |
| 02:20:42 | evan | i'm tweaking they're attachment slightly |
| 02:20:53 | evan | they're going to go into the Modules instance methods table as well |
| 02:20:55 | evan | marked private |
| 02:21:04 | evan | so they're just like module_function style methods |
| 02:21:08 | evan | ie, you can include the Module |
| 02:21:17 | evan | and access the FFI functions directly |
| 02:21:21 | evan | privatly |
| 02:21:38 | evan | we can use that to speed things up a little bit too |
| 02:21:55 | evan | because you don't have to go through some long constant lookup path to get to an FFI function everytime you want to use it |
| 02:22:37 | ddub | hmm |
| 02:22:56 | ddub | for security, one might want to make their imports private as well |
| 02:23:15 | evan | true |
| 02:23:49 | evan | well, what kind of security were you thinking? |
| 02:24:00 | boyscout | Cleanup Binding#eval spec - 95e35c4 - Evan Phoenix |
| 02:24:00 | boyscout | Update Binding tags - 3550f4b - Evan Phoenix |
| 02:24:00 | boyscout | Add RUBY_DESCRIPTION - 68cff4b - Evan Phoenix |
| 02:24:00 | boyscout | Add RUBY_COPYRIGHT - 2c9a41f - Evan Phoenix |
| 02:24:00 | boyscout | Update builtin constants tags - 84622fe - Evan Phoenix |
| 02:24:01 | boyscout | Fix JIT FFI inliner bug (NULL => nil) - 7e4600d - Evan Phoenix |
| 02:24:03 | boyscout | Get @method_table and @constants setup entirely in allocate - 9d24b92 - Evan Phoenix |
| 02:24:05 | boyscout | Update Class tags - 3de9a08 - Evan Phoenix |
| 02:24:07 | boyscout | Taint strings coming back over FFI - 967e4e0 - Evan Phoenix |
| 02:24:09 | boyscout | Expose FFI functions as private instance methods also - 84c5c7f - Evan Phoenix |
| 02:24:11 | boyscout | Chang how ENV gets to the FFI functions - f9fccb7 - Evan Phoenix |
| 02:25:07 | ddub | evan: probably doesn't matter so much for ruby. In CLR, you create types around pointers in order to enforce type safety, then expose methods to take those in rather than an API with raw pointers |
| 02:25:30 | evan | ah |
| 02:25:34 | evan | you can certainly still do that |
| 02:25:41 | ddub | they have a native_int type which is like an intptr_t, with the added constraint that only unsafe code is allowed to do any integer math on them |
| 02:25:43 | evan | thats typically how people use FFI |
| 02:26:47 | boyscout | CI: f9fccb7 success. 3002 files, 11397 examples, 35420 expectations, 0 failures, 0 errors |
| 02:27:04 | ddub | yeah, but more to put an object oriented flavour around non-object API calls, am i right? |
| 02:27:25 | ddub | type safety would be bonus points :) |
| 02:28:05 | ddub | man, I lost a dozen slides. Do I really have to explain regexp again? |
| 02:28:17 | ddub | decides to take a break for dinner |
| 02:28:25 | evan | good plan. |
| 02:34:18 | ddub | maybe I should have someone review my slides to make sure I'm not setting people up for failure ;-) |
| 02:34:52 | ddub | "Ruby is just like Java except you don't always have to use parenthesis when calling methods" |
| 02:35:01 | slava | haha |
| 02:35:15 | boyscout | Be more discriminating about arguments when checking AST transforms. - bf832d0 - Brian Ford |
| 02:35:15 | boyscout | A little cleanup for transforms specs. - 68de861 - Brian Ford |
| 02:35:15 | boyscout | Reworked compiling C extensions. - 9ed0630 - Brian Ford |
| 02:35:15 | boyscout | Removed old extension compiler. - ac10d93 - Brian Ford |
| 02:35:15 | boyscout | MV lib/bin/compile-ng.rb lib/bin/compile.rb - 9e38179 - Brian Ford |
| 02:35:15 | boyscout | Patched up capi spec helper. - fc96a0a - Brian Ford |
| 02:35:41 | ddub | brixen, you are making it very hard for me to maintain a compiler fork |
| 02:35:49 | brixen | ddub: sorry :( |
| 02:35:56 | ddub | *grin* no problem |
| 02:35:58 | brixen | you should consider not forking me :P |
| 02:36:25 | ddub | well that doesn't sound fun |
| 02:36:43 | brixen | I wouldn't say anything related to rake is particularly "sane" |
| 02:36:45 | ddub | maybe I should just finish some of it up and see if you want it? |
| 02:36:54 | ddub | does rake do file dependencies? |
| 02:36:55 | brixen | but building exts is now at least somewhat standardized |
| 02:37:01 | brixen | and comprehensible |
| 02:37:06 | ddub | or is it pure task based? |
| 02:37:15 | brixen | nope, it does files |
| 02:37:21 | brixen | pretty nicely too |
| 02:37:33 | brixen | rake's biggest problem is that it's like make |
| 02:37:36 | ddub | fun, then why isn't there a mkrf lib? |
| 02:37:43 | evan | there is! |
| 02:37:43 | brixen | and that's the wrong way to structure an app |
| 02:37:45 | evan | go look |
| 02:37:48 | ddub | oooh |
| 02:37:52 | evan | but sadly, it doesn't do what you think it does. |
| 02:37:57 | ddub | ok, after dinner |
| 02:37:59 | evan | it doesn't supplant the usage of mkmf |
| 02:38:12 | boyscout | Polish a few unfinished corners in Dir - 13a11aa - Evan Phoenix |
| 02:38:12 | boyscout | Update Dir tags - d989302 - Evan Phoenix |
| 02:38:21 | ddub | I still seem to read that internally as "make mf'er" |
| 02:38:23 | brixen | :( |
| 02:38:25 | evan | brixen: i'm into D! |
| 02:38:30 | brixen | sweet! |
| 02:38:36 | brixen | I wonder if boyscout is going to break |
| 02:38:42 | boyscout | CI: fc96a0a success. 3002 files, 11399 examples, 35422 expectations, 0 failures, 0 errors |
| 02:38:45 | brixen | nope! |
| 02:38:47 | brixen | yay! |
| 02:38:54 | slava | evan: are you doing a big rubyspec passing effort? |
| 02:39:03 | ddub | slava: was just going to ask that :) |
| 02:42:22 | evan | yeah, far too many specs are tagged |
| 02:42:49 | evan | and a huge percentage of them are trivial. |
| 02:44:04 | slava | good stuff |
| 02:45:17 | brixen | I love that the compiler and parser are now 100% userland |
| 02:45:31 | brixen | that's where they belong |
| 02:45:42 | brixen | made it easier to hammer out the ext compiling stuff |
| 02:45:47 | slava | parser too? cool |
| 02:45:48 | brixen | cus at least rbx could run |
| 02:45:56 | brixen | slava: the parser is a C ext |
| 02:46:04 | slava | userland in the sense that its not in the vm? |
| 02:46:09 | brixen | yeah |
| 02:46:16 | brixen | not linked/loaded directly in |
| 02:46:23 | slava | yeah |
| 02:46:24 | brixen | not loaded in our bootstrapping .rbc files |
| 02:46:32 | slava | so when you ruby guys come up with a sane syntax |
| 02:46:37 | slava | it will be easy to switch right |
| 02:46:38 | slava | I kid, I kid |
| 02:46:41 | brixen | I need to fix up #require |
| 02:46:47 | brixen | heh |
| 02:46:48 | slava | any plans to dust off that pure ruby parser you had once? |
| 02:46:51 | brixen | sane syntax?! |
| 02:47:00 | brixen | not any plans of mine |
| 02:47:09 | brixen | I plan on writing a peg parser :) |
| 02:47:24 | brixen | the ruby_parser needs all it's productions fixed |
| 02:47:27 | brixen | it emits sexps |
| 02:47:31 | brixen | I've banned them |
| 02:47:35 | slava | cool, using the lpeg algorithm? |
| 02:47:42 | brixen | yeah, I want to |
| 02:47:53 | slava | so that would be the first non-MRI derived ruby parser |
| 02:47:58 | slava | sounds like a challenge |
| 02:48:00 | brixen | it's already got a name: pegarus |
| 02:48:04 | brixen | actually not |
| 02:48:10 | slava | packrat then? |
| 02:48:16 | brixen | there's a guy who's got a pretty complete peg in scheme |
| 02:48:24 | brixen | based on his own peg framework |
| 02:48:42 | slava | time to add car and cdr keywords to ruby then |
| 02:48:51 | brixen | good idea! :) |
| 02:49:11 | slava | how do you guys generate identity hashcodes? incrementing counter, RNG, address? |
| 02:49:31 | evan | incrementing counter |
| 02:49:33 | brixen | object_id is a monotonic counter |
| 02:50:32 | boyscout | Goodbye vm/parser. - 43341b5 - Brian Ford |
| 02:50:37 | brixen | oops, dang |
| 02:50:44 | brixen | I was going to test that on elle first |
| 02:51:00 | evan | well here we go! |
| 02:51:03 | brixen | heh |
| 02:51:16 | brixen | it either works or it doesn't |
| 02:51:37 | brixen | which is not a 50/50 chance, contrary to rue's brand of probability |
| 02:52:54 | evan | heh |
| 02:55:52 | evan | raise ArgumentError, "Improper spaceship value", e |
| 02:55:53 | evan | hehehe |
| 02:55:54 | evan | love it. |
| 02:55:55 | boyscout | CI: Build 43341b5 failed. http://ci.rubini.us/rubinius/builds/43341b532420ebd8058d6a20474fd29c7dfbfee9 |
| 02:56:00 | brixen | dammit |
| 02:56:20 | brixen | hmm |
| 03:02:00 | brixen | wait, what? why are we using bstring if it's gpl'd? |
| 03:04:00 | brixen | I just compiled head on elle and I get no such error |
| 03:04:09 | brixen | evan: can you force a clean build, please |
| 03:04:13 | evan | surely |
| 03:14:21 | boyscout | CI: 43341b5 success. 3002 files, 11404 examples, 35428 expectations, 0 failures, 0 errors |
| 03:14:57 | evan | brixen: there ya go. |
| 03:15:16 | evan | and i recall the bstring/gpl issue |
| 03:15:21 | evan | we probably need to remove it. |
| 03:15:30 | evan | because of that. |
| 03:15:46 | brixen | evan: thanks |
| 03:30:36 | evan | MAN there are some silly fucking specs. |
| 03:30:50 | evan | SystemCallError.new(-2**24).errno.should == -2**24 |
| 04:00:48 | ddub | what, bstring is GPL? |
| 04:01:57 | ddub | I thought it was dual-licensed |
| 04:02:51 | brixen | ah, it is I think |
| 04:03:09 | brixen | the gpl.txt stands out more than license.txt :P |
| 04:03:33 | ddub | whew |
| 04:03:59 | ddub | now all you have to worry about is libmpa, libmquark, etc. |
| 04:04:09 | ddub | i.e. be nice to me |
| 04:05:58 | brixen | I'm not worried, I'm determined :) |
| 04:06:03 | brixen | ok, bbiab... |
| 04:06:14 | brixen | for your viewing pleasure http://i.usatoday.net/tech/graphics/iss_timeline/flash.htm |
| 04:06:36 | ddub | ooh |
| 04:06:41 | ddub | NASA's version of voltron! |
| 04:07:40 | ddub | they have voltron on hulu. I thought I would watch it, but it was too painful |
| 05:11:19 | brixen | hmm, we really need to implement frozen with self.extend FrozenWhatever |
| 05:11:52 | brixen | because switching the class in Array gives a.class => Array::Frozen |
| 05:12:02 | brixen | which makes self.class.new not work |
| 05:12:11 | brixen | and a.instance_of? Array => false |
| 05:12:33 | brixen | the cost of #extend is born by whoever is freezing |
| 05:12:51 | brixen | I think actually shifting the class will lead to many issues |
| 05:13:42 | ddub | so freezing would be done with metaclasses? |
| 05:14:03 | brixen | basically def freeze; self.extend Frozen; end |
| 05:14:19 | brixen | where Frozen is a module that redefines the mutator methods to raise |
| 05:14:36 | brixen | but the cost of #extend is big because it blows away caches |
| 05:14:42 | brixen | but too bad IMO |
| 05:15:24 | brixen | the approach of switching the class doesn't blow away caches, but causes problems based on the expected real class of an obj |
| 05:15:37 | brixen | that's a bigger problem I think |
| 05:16:25 | brixen | because we have to code stuff in Array with self.class.new to work with class MyClass < Array |
| 05:16:34 | ddub | I might not understand what extend does, if it blows away caches |
| 05:16:36 | brixen | some methods have to return an instance of the subclass |
| 05:16:40 | brianmario | any chance for a pre-built llvm-x86_64-apple-darwin10.2.0.tar.bz2 ? ;) |
| 05:17:01 | brixen | brianmario: sure, if you can build one, evan will make it available |
| 05:17:12 | brixen | brianmario: or are you hoping not to have to build it? |
| 05:17:45 | ddub | 10.2.0? is that the ver. of 10.6.2? |
| 05:17:50 | brianmario | I don't *really* mind either way, but compiling definitely takes longer than downloading a binary (I think the difference is I'm on 10.6.2 now) |
| 05:17:54 | brianmario | yeah |
| 05:17:55 | ddub | ahh |
| 05:18:06 | ddub | hmm, I'll build one if someone tells me the magical command line |
| 05:18:14 | brianmario | I'll happily build whatever you guys need |
| 05:18:16 | brianmario | or that |
| 05:22:57 | ddub | eww, yeah extend does something different than I expected |
| 05:23:46 | ddub | at least from the object interface p.o.v. |
| 05:33:12 | ddub | brixen: if extend makes another metaclass, won't it not invalidate the caches? |
| 05:33:37 | ddub | err, will it not then keep caches valid |
| 05:43:34 | brixen | brianmario: you can ./configure --enable-llvm=svn; rake build; rake package:llvm |
| 05:43:48 | brixen | that'll build you the .tar.bz2 |
| 05:44:09 | brianmario | running through the rake compile right now, I'll do the llvm build when it's done |
| 05:44:15 | brixen | cool |
| 05:47:44 | brixen | ddub: the IC is the actual module and selector at that send site |
| 05:48:14 | brixen | if you do obj.extend mod, and mod defines a new method with that selector, the IC is invalid |
| 06:23:46 | brianmario | brixen: built and packaged llvm, not sure if you have access to add this to the prebuilt dir on asset.rubini.us or not but - http://files.me.com/brianmario/oggrb4 |
| 06:24:04 | brianmario | wtf is up with the password on that... sec |
| 06:25:00 | brianmario | ok the pass is "rubinius" |
| 06:25:11 | brianmario | dunno why I even needed it, but... |
| 06:26:03 | brixen | brianmario: I don't have access, but I'll let evan know |
| 06:27:54 | brianmario | cool |
| 06:31:20 | brixen | thanks for building it |
| 06:33:20 | evan | brixen: ah damn (changing the class) |
| 06:33:33 | evan | i'll switch it to using extend later |
| 06:33:36 | evan | off to play ps3 |
| 06:35:34 | brixen | evan: oki |
| 06:35:38 | scoopr | evan, what's your psn id? :P |
| 06:45:04 | ddub | attempts a build with mri 1.9.1 |
| 06:45:15 | slava | evan: I tried doing the incrementing counter thing and got really bad hash collisions |
| 08:41:29 | boyscout | Detect if <=> is correct in Enumerable#sort - e1b1344 - Evan Phoenix |
| 08:41:29 | boyscout | Update Enumerable tags - a32481f - Evan Phoenix |
| 08:41:29 | boyscout | Fix ENV.clear spec - db0630d - Evan Phoenix |
| 08:41:29 | boyscout | Update ENV tags - f792b62 - Evan Phoenix |
| 08:41:29 | boyscout | Polish Exception up a little - 9c5b1f1 - Evan Phoenix |
| 08:41:29 | boyscout | Update Exception tags - 6e7cf79 - Evan Phoenix |
| 08:42:15 | slava | evan phoenix is a machine that turns specs and coffee into code |
| 08:42:21 | brixen | heh |
| 08:42:24 | evan | hehe |
| 08:42:28 | brixen | specs, coffee, and ps3 |
| 08:42:30 | evan | and now it turns code into sleep. |
| 08:42:47 | brixen | evan: did some GC params tweaking |
| 08:42:53 | brixen | I'll show ya in the morning |
| 08:43:03 | evan | ok |
| 08:43:06 | evan | i'm all the way through e! |
| 08:43:06 | brixen | got a full CI run from ~93 sec to ~83 sec |
| 08:43:13 | brixen | awesome! |
| 08:43:20 | slava | weren't you on 40 secs or so a while back? |
| 08:43:23 | slava | or did the amount of work increase? |
| 08:43:32 | brixen | slava: we're running a ton more specs |
| 08:43:36 | slava | ah |
| 08:43:40 | evan | thats also compiling i'm assuming |
| 08:43:44 | brixen | evan: yeah |
| 08:43:50 | evan | a precompiled run is about 54s here |
| 08:43:54 | brixen | yep |
| 08:44:05 | brixen | got the % GC to 22.9% |
| 08:44:18 | evan | sweet! |
| 08:44:23 | brixen | only thing is, I don't have a stat on the total mem load |
| 08:44:27 | evan | lets discuss GC stuff in the morning |
| 08:44:30 | evan | perhaps with a brief call |
| 08:44:33 | brixen | yep |
| 08:44:34 | brixen | ok |
| 08:44:39 | slava | brixen: what did you change? |
| 08:45:15 | evan | nite! |
| 08:45:15 | brixen | slava: basically, young lifetime=1, "malloc" trigger 20M, and immix trigger ever chunks_.size() % 4 == 0 |
| 08:45:18 | brixen | evan: nite! |
| 08:45:31 | slava | brixen: I got a nice win today by changing freelist strategy |
| 08:45:46 | brixen | slava: I saw your tweet, what did you change? |
| 08:45:47 | slava | brixen: so I have freelists for various small sizes |
| 08:45:53 | brixen | ahh neat |
| 08:45:59 | brixen | kinda like hole size? |
| 08:46:00 | slava | brixen: previously if a free list was empty, it would go up to the next largest one |
| 08:46:03 | slava | and so on |
| 08:46:05 | slava | yeah |
| 08:46:09 | brixen | cool |
| 08:46:21 | slava | now, if a free list of a given size is empty, it allocates 1kb and splits it up into chunks of that size |
| 08:46:32 | brixen | interesting |
| 08:46:48 | slava | so before, the case right after a compaction, where there's one big free block, was the worst for small object allocation |
| 08:47:01 | slava | it would check each small free list in turn, then go to the large free list, split that block, and add the second piece back |
| 08:47:19 | brixen | ah, do you have a histogram of obj sizes during a bench? |
| 08:47:25 | boyscout | CI: Build 6e7cf79 failed. http://ci.rubini.us/rubinius/builds/6e7cf7929fd05dc13666e3be948d01b4813ca953 |
| 08:47:30 | slava | its much better now -- suppose a request is made for 32 bytes, if that list has entries it pops one off, otherwise it allocates 1kb and chops it up |
| 08:47:32 | brixen | :/ |
| 08:47:53 | slava | brixen: a histogram of all objects allocated during a test suite run or something? |
| 08:48:09 | brixen | yeah, during a benchmark or app |
| 08:48:19 | brixen | their sizes |
| 08:48:28 | slava | unfortunately I don't |
| 08:48:39 | slava | I can get a histogrma of sizes of objects in the heap at a given point |
| 08:49:02 | slava | but I don't have allocation profiling of any kind; it would take a bit of work to instrument that in because the compiler generates allocation sequences inline for small objects |
| 08:49:12 | brixen | ahh |
| 08:49:36 | brixen | would be interesting to compare with rbx |
| 08:50:00 | brixen | I have a stat for builtin class instances that I could derive sizes from |
| 08:50:01 | slava | http://paste.factorcode.org/paste?id=1025 |
| 08:50:12 | slava | this is a snapshot from a running instance that I've done a bunch of random stuff in over the last few hours |
| 08:50:22 | slava | first column is size in bytes, second column is # of objects that have this size |
| 08:50:32 | brixen | oh cool |
| 08:51:07 | slava | 32 bytes seems very popular |
| 08:51:24 | brixen | yeah it does |
| 08:52:10 | brixen | interesting spikes in the long tail |
| 08:53:17 | brixen | rad, GC % during non-compiling full CI run 17.0% ! |
| 08:53:30 | brixen | compiling stresses the GC pretty good |
| 08:54:26 | brixen | but the difference is only ~5 % |
| 08:54:46 | brixen | while the total obj alloc'd is 33% running vs running + compiling |
| 08:55:11 | brixen | so 2/3 more obj created due to compiling |
| 08:56:09 | brixen | 30 nanoseconds min time to alloc in immix, 280n avg |
| 08:56:26 | brixen | 26n min, 45n avg in young |
| 08:57:55 | brixen | 16 millisecond avg young GC collect times |
| 08:58:50 | brixen | welp, to sleep, perchance to dream of being a sanitation engineer |
| 11:00:34 | weepy | is there a big release coming up this fri ? |
| 11:03:58 | dbussink | weepy: why do you ask? |
| 11:07:01 | weepy | i read somewhere on the logs |
| 11:07:27 | weepy | but perhaps i was mistaken - |
| 11:11:25 | dbussink | weepy: ah, well, i think there is a plan to do it on the short term afaik |
| 11:11:31 | dbussink | dunno if friday is a hard target though |
| 11:25:46 | weepy | yes probz not ! |
| 11:25:57 | weepy | do u know what the release is going to be / do / |
| 11:25:59 | weepy | ? |
| 11:27:46 | dbussink | well, a lot of stuff has been fixed and there is a whole new compiler now |
| 11:28:00 | dbussink | but i have to go now |
| 16:38:17 | brixen | morning folks |
| 16:42:05 | wayneeseguin | ohio! |
| 16:43:59 | brixen | wayneeseguin: hey, I'm working on install today! |
| 16:44:07 | brixen | I promise we'll get it right this time :) |
| 16:44:15 | wayneeseguin | brixen: that is hardcore awesome :D |
| 16:44:21 | brixen | heh |
| 16:44:43 | brixen | ddub is working on getting rbx to build with 1.9.1 too |
| 16:57:20 | Defiler | brixen: This is a great commit http://github.com/evanphx/rubinius/commit/9ed0630d33746188f77f8479bd7a28232b88b922 |
| 16:58:13 | brixen | Defiler: ah cool, glad ya like it :) |
| 16:58:29 | Defiler | I know exactly how much work that way. Heh |
| 17:04:17 | ddub | btw: I already have rbx building on 1.9.1 |
| 17:04:25 | ddub | just trying to make sure I don't break building on 1.8.7 :) |
| 17:04:50 | brixen | and 1.8.6 ;) |
| 17:05:21 | ddub | thats why I'll give you a diff before I commit |
| 17:05:33 | ddub | although it would be nice to spin up a local leopard VM |
| 17:05:44 | ddub | thats just such a cool idea anyway |
| 17:05:53 | Defiler | I've been meaning to try that VMWare feature, yeah |
| 17:06:46 | ddub | so far the two issues I have are the complete inadequacy of Config::CONFIG, and bigdecimal seems to be doing 32-bit things |
| 17:06:58 | ddub | don't know if that is a building-with-1.9 issue or a SL issue |
| 17:07:50 | brixen | ddub: I can try building with 1.9.[12] on L |
| 17:09:28 | ddub | still have the patch gist from yesterday? |
| 17:10:30 | brixen | ddub: I do, but I think those changes need to be tweaked |
| 17:10:35 | brixen | the ones to find the hdrdir |
| 17:10:43 | brixen | ddub: I'll check in a bit |
| 17:16:49 | ddub | man I really don't want to switch this off of the ruby version |
| 17:17:01 | ddub | but the locations of things are very different |
| 17:17:29 | brixen | yep |
| 17:17:38 | brixen | I think the version conditionals will be needed |
| 17:18:55 | ddub | is there a preferred check? |
| 17:19:21 | brixen | all the checks I've seen are pretty ad hoc |
| 17:19:32 | brixen | in mspec, I have an object for comparing versions |
| 17:22:15 | ddub | just did if RUBY_VERSION.start_with? "1.9" |
| 17:22:34 | brixen | can't use start_with? on 1.8.6 |
| 17:22:39 | ddub | gah. |
| 17:22:47 | ddub | 1.8.6 is a POS :P |
| 17:22:55 | brixen | oh well ;) |
| 17:23:05 | ddub | is there an equiv for 1.8? |
| 17:23:16 | brixen | regexp |
| 17:23:23 | ddub | omfg really? |
| 17:23:29 | brixen | huh? |
| 17:23:30 | ddub | why is 1.8.7 a minor release again? |
| 17:23:39 | brixen | um yeah, dunno |
| 17:24:22 | ddub | there are a lot of things I am surprised are missing under 1.8.6, like really basic things I would have expected to be in over the last 10 years |
| 17:24:54 | brixen | and there's stuff in 1.9 that I can't believe are in there in 100 years |
| 17:25:11 | brixen | ahem ->() { puts "you are soo ugly" } |
| 17:26:09 | Zoxc | faster blocks :) |
| 17:26:25 | brixen | faster? |
| 17:26:56 | Zoxc | unless it just maps to a lambda call :/ |
| 17:34:17 | ddub | yeah I dislike that syntax, seems unruby-like |
| 17:36:32 | ddub | brixen: that bigdecimal test seems to fail under system mri on SL as well |
| 17:36:59 | ddub | sorry, not under, 'when building with system mri' |
| 17:37:25 | ddub | expected (32 bit normal value) to equal (64 bit normal value) |
| 17:38:34 | brixen | k |
| 17:41:45 | ddub | would you like me to submit these changes, assuming the 1.9.1 build I'm verifying now succeeds? |
| 17:43:01 | brixen | well, I should check it |
| 17:43:22 | ddub | k |
| 17:43:56 | ddub | once I get this out of my tree, I can look at what is going on with bigdecimal (if you like) |
| 17:44:33 | brixen | sure |
| 17:44:40 | brixen | I can check in a minute |
| 17:44:49 | brixen | give me an updated gist if you got it |
| 17:45:02 | ddub | I'm running the ci now, so it will be a minute |
| 17:45:34 | brixen | ddub: I need it now, nowwwww! |
| 17:45:36 | brixen | j/k |
| 17:47:01 | ddub | fine, https://gist.github.com/232135/d355bb0ee584c6f6baabfa28216a4634e29584df |
| 17:49:27 | brixen | k, checking |
| 17:49:40 | brixen | anything special you did to build with 1.9? |
| 17:49:47 | brixen | like what was you cmd line? |
| 17:50:09 | brixen | I'll try it with 1.9.1p129 and 1.9.2 head |
| 17:52:45 | ddub | rvm 1.9.1; ./configure; rake |
| 17:53:37 | wayneeseguin | oh sweet, adding 1.9.1 build support brixen ? :D |
| 17:54:01 | ddub | wayneeseguin, https://gist.github.com/232135/d355bb0ee584c6f6baabfa28216a4634e29584df |
| 17:54:21 | dbussink | brixen: quick question, enumerable.rb has a custom sorter method, shouldn't that be private? or is public / private something that needs reviewing anyway? |
| 17:54:30 | ddub | brix is reviewing it before I commit, because my ability to commit frightens him slightly |
| 17:55:03 | brixen | ddub: not true! |
| 17:55:05 | brixen | heh |
| 17:55:19 | brixen | dbussink: sec, on a call |
| 17:55:41 | brixen | ddub: it worked for me on 1.8.6 |
| 17:55:46 | brixen | ddub: go ahead and push |
| 17:56:00 | brixen | I'll check 1.9 stuff, but we can continue tweaking that as needed |
| 17:57:37 | boyscout | add support for MRI 1.9.x bootstrapping - 5e6630d - David Waite |
| 17:58:18 | ddub | I wonder if I can use 1.9.2 head in rvm |
| 17:58:37 | dbussink | wayneeseguin: ^^ |
| 17:58:52 | wayneeseguin | ddub: sure, "rvm install 1.9.1-head" |
| 17:59:07 | wayneeseguin | ddub: 1.9.1-head === 1.9.2-head because they haven't branched 1.9.2 yet |
| 17:59:28 | boyscout | CI: Build 5e6630d failed. http://ci.rubini.us/rubinius/builds/5e6630d25206cbe467fde936a5464e16123ab193 |
| 18:00:05 | brixen | oh, that's left over from last night |
| 18:00:09 | brixen | evan: ^^^ |
| 18:02:33 | evan | zoinks! |
| 18:02:49 | brixen | dbussink: generally, yes, custom methods in core should be private |
| 18:02:52 | evan | thats weird |
| 18:03:06 | dbussink | brixen: ok, if i see them i'll change them |
| 18:03:10 | brixen | dbussink: we have Rubinius.privately { ... } to call them with receiver if necessary |
| 18:03:17 | brixen | you can grep for how that's used |
| 18:03:36 | dbussink | brixen: ah, well, this still works if i make it private since it's only used inside enumerable itself |
| 18:03:40 | ddub | wayneeseguin: aha, thats what I was looking for. I was trying 1.9.1 --rev head, but it was replacing my existing 1.9.1 install |
| 18:03:46 | evan | it's pretty easy, any method call inside the block to privately is done as a private method call |
| 18:03:47 | brixen | dbussink: ok, sure |
| 18:04:04 | wayneeseguin | ddub: ::grin:: yeah it's just "rvm install 1.9.1-head" |
| 18:04:17 | wayneeseguin | ddub: also always be sure you are on latest rvm, bugfixes happen fast |
| 18:04:25 | ddub | one of my coworkers is apparently working today, even though we have the day off. |
| 18:04:26 | wayneeseguin | except for dbussink :-p |
| 18:04:33 | ddub | so I disabled my work mail account :P |
| 18:04:56 | dbussink | brixen: privately is for calling from outside the class / module then right? |
| 18:05:18 | ddub | oh, is there a way to use rvm with tcsh? |
| 18:05:31 | evan | FAIL. |
| 18:05:40 | ddub | evan? |
| 18:05:41 | evan | -2 ** 30 is a Bignum on 32bit |
| 18:05:59 | evan | why would you assume that -2 ** 30 is a valid errno. |
| 18:06:04 | evan | stabs specs |
| 18:06:14 | brixen | dbussink: for calling a private method with a receiver |
| 18:06:22 | ddub | -2**30 is a fixnum on mri, is it not? |
| 18:06:22 | brixen | dbussink: see Hash.allocate |
| 18:07:00 | evan | huh, why is that a Bignum actually.. |
| 18:07:16 | evan | we should be only using one tag bit... |
| 18:07:38 | brixen | is that supposed to be -2**30 or (-2)**30 ? |
| 18:07:47 | ddub | -(2**30) |
| 18:07:52 | ddub | ** > unary - |
| 18:07:58 | brixen | I know |
| 18:08:02 | brixen | hence my question |
| 18:08:13 | brixen | because the classes are different |
| 18:08:13 | evan | it's parsed as -(2 ** 30) |
| 18:08:13 | ddub | also, -2**30 would be pointless |
| 18:08:14 | evan | it seems |
| 18:08:22 | evan | because (-2) ** 30 is 1073741824 |
| 18:08:24 | ddub | since 30 is even |
| 18:08:36 | brixen | -2**30 is a fixnum on mri 32bit, (-2)**30 is a bignum |
| 18:08:45 | evan | yeah |
| 18:08:47 | evan | thats weird. |
| 18:08:54 | evan | thats the boundary |
| 18:08:56 | evan | as I recall. |
| 18:08:59 | ddub | the largest fixnum on 32 bit is 2**30 -1 |
| 18:09:20 | dbussink | brixen: like 8 bit signed goes from -128 to 127 |
| 18:09:42 | brixen | yah, I know how bits work :P |
| 18:09:49 | brixen | I'm trying to clarify what the spec meant |
| 18:09:51 | ddub | they can either be on, or off |
| 18:09:56 | ddub | ;-) |
| 18:10:12 | evan | yeah -2 ** 30 is the negative boundary |
| 18:10:21 | evan | we must have a bug there actually |
| 18:10:27 | evan | because that should be a Fixnum for us too. |
| 18:10:45 | brixen | well, we do have a difference at that boundary |
| 18:10:50 | brixen | it should be explained in a comment |
| 18:11:05 | evan | hm, ok. |
| 18:11:18 | brixen | oop.hpp |
| 18:11:28 | brixen | we actually discussed this a bit |
| 18:11:40 | ddub | oops, bug in 1.9.1-head ;) |
| 18:11:46 | ddub | guess I'll try that again later |
| 18:11:46 | evan | ah |
| 18:11:47 | evan | i see. |
| 18:11:48 | evan | yes |
| 18:11:50 | evan | the comment makes sense. |
| 18:12:39 | brixen | heh, we should have named oop.hpp oops.hpp :) |
| 18:12:45 | brixen | imagine the questions |
| 18:12:49 | ddub | kinda a shame that fixnum doesn't have max and min constants |
| 18:12:49 | evan | it shuold be noted that passing -2**30 to SystemCallError results in a very strange message |
| 18:13:00 | ddub | would greatly simplify these sorts of things |
| 18:13:01 | evan | irb(main):023:0> SystemCallError.new("", -2**30) |
| 18:13:01 | evan | => #<SystemCallError: Unknown error 3221225472 - > |
| 18:13:09 | evan | really? 3221225472? really? |
| 18:13:15 | evan | i smell a casting error. |
| 18:13:25 | brixen | ddub: you mean like Fixnum::MAX in rbx :) |
| 18:13:33 | ddub | brixen: yeah, something like that :) |
| 18:14:16 | boyscout | Only consider Fixnum errnos in SystemCallError - 1829ef3 - Evan Phoenix |
| 18:15:00 | evan | I find it highly unlikely that -2**30 is a valid errno. |
| 18:16:07 | boyscout | CI: 1829ef3 success. 3002 files, 11411 examples, 35443 expectations, 0 failures, 0 errors |
| 18:19:56 | ddub | E_ERRNO_TOO_LARGE |
| 18:20:50 | brixen | yeah, I guess ETOOLRG could be misunderstood |
| 18:24:19 | ddub | I think I got a spam about that |
| 18:25:03 | dbussink | ddub: wasn't that ETOOSML? |
| 18:26:00 | brixen | haha |
| 18:27:13 | ddub | really odd re: bigdecimal |
| 18:29:37 | ddub | brixen: could this test be wrong? |
| 18:29:54 | ddub | I'm curious because when the word size is 64, I would expect the number to be more accurate, not less |
| 18:33:59 | brixen | ddub: it could be wrong, yes |
| 18:34:07 | brixen | it merely states what MRI does |
| 18:42:05 | dbussink | ddub: seeing a bigdecimal failure? (i'm having it too_ |
| 18:47:20 | ddub | dbussink: yeah, seems 64 bit only |
| 18:47:46 | luislavena | hey guys |
| 18:47:48 | luislavena | me again :) |
| 18:48:04 | luislavena | did someone made progress on the configure/build tasks? |
| 18:54:03 | brixen | hey luislavena |
| 18:54:15 | brixen | yeah, I reworked the C ext compiling |
| 18:54:33 | brixen | I looked at rake-compiler, but not sure I understood how to use it correctly |
| 18:54:42 | brixen | appears to work still with mkmf and extconf files |
| 18:54:59 | brixen | while I would like to see mkmf.rb disappear from the face of the universe |
| 18:55:21 | luislavena | brixen: if you need anything on rake-compiler front, shoot me an email |
| 18:55:35 | luislavena | brixen: was thinking on rbx complete building process, not just the C ext part. |
| 18:55:42 | brixen | ah sure |
| 18:55:56 | brixen | well, we are piece by piece improving it |
| 18:56:03 | brixen | no longer requires ParseTree |
| 18:56:18 | brixen | we have a custom dependency grapher |
| 18:56:23 | brixen | a configure script |
| 18:56:32 | brixen | and I'm working on improving the rakefiles |
| 18:57:09 | brixen | I'd really like to take a shot at cross-compiling rbx for windows using your setup in rake-compiler |
| 18:57:19 | brixen | but so far, that's just on my wish list |
| 18:58:17 | ddub | is there an eventual goal to be able to build rubinius without having another ruby implementation present? |
| 18:58:29 | ddub | (a Rakefile based build system conflicts with that obviously) |
| 18:59:24 | brixen | yes |
| 18:59:26 | luislavena | brixen: well, working in the cross port system stuff... |
| 18:59:27 | brixen | and no it doesn't |
| 18:59:33 | brixen | rbx will be able to bootstrap rbx |
| 18:59:50 | brixen | luislavena: ok, cool |
| 19:00:15 | brixen | luislavena: I'll look at what you've got and see where we need to fix stuff |
| 19:00:38 | brixen | luislavena: we've been steadily reducing the deps in rbx, so hopefully it will compile without too much trouble |
| 19:01:48 | luislavena | brixen: wanted to take a look again since we completed the RC1 milestone... and now getting 1.9.2dev build |
| 19:01:55 | brixen | ddub: the goal is to 1. build rbx with mri, 2. build rbx with rbx, 3. have binary distros, 4. goto 2 |
| 19:02:27 | brixen | luislavena: sure, were you looking at cross-compile or compile directly on windows? |
| 19:03:00 | luislavena | brixen: first compile directly, to know the issues first hand. then cross-compile will be more easier. |
| 19:03:08 | brixen | ok |
| 19:03:18 | brixen | the reverse would probably be easier for me :) |
| 19:03:32 | brixen | I haven't compiled anything on windows since about '02 |
| 19:03:53 | brixen | luislavena: just let us know if you have issues |
| 19:04:01 | brixen | er rather, what the issues are :) |
| 19:04:03 | luislavena | brixen: well, both can be done pretty easily, will keep you posted :) |
| 19:04:09 | brixen | excellent |
| 19:04:12 | brixen | thanks! |
| 20:22:16 | dbussink | brixen: rspec is actually starting to work too now :) |
| 20:22:25 | dbussink | brixen: i can run projects with rspec specs : |
| 20:22:26 | dbussink | :) |
| 20:22:34 | dbussink | run the specs that is |
| 20:39:51 | brixen | dbussink: that's awesome :) |
| 20:40:00 | brixen | dbussink: we're fixing the frozen issue too |
| 20:40:16 | dbussink | brixen: seems something is still up with pending things though, looking into it a bit |
| 20:40:23 | dbussink | brixen: ah cool |
| 20:40:34 | dbussink | brixen: guess there are no optparse specs then ;) |
| 20:40:54 | brixen | guess not |
| 20:41:27 | brixen | food, bbiab... |
| 20:44:52 | dbussink | brixen: i've abstracted a funny case for you :) |
| 20:48:25 | dbussink | brixen: http://github.com/evanphx/rubinius/issues/#issue/72 |
| 21:01:36 | evan | so, Go's interfaces are duck type interfaces. |
| 21:01:39 | evan | thats pretty cool. |
| 21:15:51 | scott | I really like what they do with the methods on structs |
| 21:17:24 | benschwarz | evan: Any thing in particular that you want to see for the MO? |
| 21:17:45 | benschwarz | I got a $100 donation last night |
| 21:17:53 | evan | woo! |
| 21:18:10 | evan | smoking a cigar |
| 21:18:20 | evan | maybe in a pool, with a drink |
| 21:18:32 | evan | those are seperate |
| 21:18:40 | evan | in a hat. |
| 21:20:30 | boyscout | Port fnmatch over from MRI 1.8.7 - 6a529fd - Evan Phoenix |
| 21:20:30 | boyscout | Update File tags - 12339de - Evan Phoenix |
| 21:27:07 | boyscout | CI: 12339de success. 3002 files, 11416 examples, 35482 expectations, 0 failures, 0 errors |
| 21:27:56 | brixen | evan: could you fix frozen? can't run gem under rbx because optparse fails |
| 21:28:03 | evan | oops |
| 21:28:04 | evan | ok |
| 21:33:31 | boyscout | Use extend rather than changing the class to freeze an Array - dd361f7 - Evan Phoenix |
| 21:33:47 | evan | ok |
| 21:33:57 | evan | gem runs now. |
| 21:34:08 | brixen | heh, nice |
| 21:35:22 | boyscout | CI: dd361f7 success. 3002 files, 11416 examples, 35482 expectations, 0 failures, 0 errors |
| 21:35:57 | brixen | evan: working on rake install |
| 21:36:22 | brixen | evan: I think the GC needs some abstraction around the config and triggers |
| 21:36:32 | evan | how so? |
| 21:36:52 | brixen | well, like the static values for immix parameters could be a config object, no? |
| 21:36:58 | brixen | twiddled by -X flags |
| 21:37:07 | brixen | -Xgc.chunk_size=N |
| 21:37:21 | evan | sure. |
| 21:37:24 | brixen | and in OM, a trigger object like immix uses |
| 21:37:39 | evan | ah, for when stuff happens. sure. |
| 21:37:45 | brixen | like om->trigger()->bytes_malloced() or something |
| 21:37:50 | evan | mmm |
| 21:37:55 | evan | don't go overboard on them though. |
| 21:37:57 | brixen | I was just unsure where to start adding this stuff |
| 21:38:04 | brixen | yeah, I didn't want to |
| 21:38:07 | evan | that works in immix largely because it's passed in as a template |
| 21:38:13 | brixen | k |
| 21:38:21 | evan | which means it gets flattened out to be a simple code sequence |
| 21:38:35 | brixen | makes sense |
| 21:38:47 | brixen | well, I figured I'd put the bug in your ear |
| 21:39:04 | brixen | it would be good to encapsulate it a bit better I think |
| 21:39:09 | evan | k |
| 21:39:13 | evan | i think you're right |
| 21:39:16 | evan | something in there would be good. |
| 21:39:19 | brixen | I end up looking in like 5 files going "where is this" |
| 21:39:19 | evan | let me think about it. |
| 21:39:22 | brixen | k |
| 22:07:20 | boyscout | Add generation lifetime autotuning - f080f9a - Evan Phoenix |
| 22:07:31 | evan | a quick test shows it working |
| 22:07:44 | evan | we'll need to try it out in different scenarios to see if the logic is what we want |
| 22:07:49 | evan | it's fairly "soft" now |
| 22:08:01 | evan | meaning that it adjusts the lifetime nicely |
| 22:09:30 | brixen | sweet! |
| 22:10:06 | evan | oh hm. |
| 22:10:10 | evan | i missed something in the logic. |
| 22:10:29 | evan | actually, no, it's fine. |
| 22:10:37 | boyscout | CI: f080f9a success. 3002 files, 11416 examples, 35482 expectations, 0 failures, 0 errors |
| 22:10:45 | evan | if, say, your filled over 95% 3 times in a row |
| 22:10:50 | evan | the lifetime is decremented |
| 22:11:02 | evan | if the next is also 95%, lifetime is decremented again |
| 22:11:15 | brixen | ahh, down to the base limit |
| 22:11:16 | evan | so basically it forces a warm up period of GC behavior |
| 22:11:20 | brixen | that makes sense |
| 22:11:42 | evan | the threshold starts at 0 |
| 22:11:46 | evan | overfull? threshold++ |
| 22:11:51 | evan | underfull? threshold-- |
| 22:12:08 | evan | norminal? Adjust threshold towards 0 by one |
| 22:12:46 | evan | threshold == 0? adjust lifetime towards original lifetime by 1 |
| 22:13:14 | evan | so it tries to "right the ship" |
| 22:13:30 | evan | which seems pretty good. |
| 22:14:00 | brixen | reads |
| 22:15:21 | brixen | interesting |
| 22:15:46 | brixen | so the tune_threshold acts like a counter-balance almost |
| 22:16:02 | brixen | a damper |
| 22:16:13 | brixen | keeps the occupancy from thrashing the tuner |
| 22:18:55 | evan | right |
| 22:19:25 | evan | any and return to normality adjusts the tune_threshold |
| 22:19:41 | brixen | neat |
| 22:20:00 | evan | when the threshold itself has normalized |
| 22:20:01 | brixen | you should really start picking titles for these academic papers you need to write |
| 22:20:06 | evan | then the lifetime is normalized |
| 22:20:10 | brixen | one on the jit, one on the gc... |
| 22:20:11 | evan | hah |
| 22:20:17 | brixen | I'll think of some more ;) |
| 22:21:44 | brixen | we probably need to fix super in a define_method block soon |
| 22:21:56 | brixen | I'm sure some rails apps will hit that |
| 22:22:09 | brixen | I'm surprised LazyArray didn't |
| 22:22:24 | brixen | LazyArray == grab bag of ewww |
| 22:22:36 | evan | yeah |
| 22:22:39 | evan | i was just thinking that. |
| 22:22:43 | evan | i'll just do it now. |
| 22:23:03 | brixen | I'm fixing def f(*) super end now |
| 22:23:06 | brixen | dbussink: hit that |
| 22:23:11 | evan | ah |
| 22:23:14 | evan | the * with no name |
| 22:23:18 | brixen | yeah |
| 22:23:20 | evan | yeah, we need to fix that |
| 22:23:22 | brixen | I missed that |
| 22:23:30 | evan | there are 2 things with that |
| 22:23:32 | evan | actually |
| 22:23:35 | evan | oh oh |
| 22:23:35 | evan | yeah |
| 22:23:37 | evan | you're doing the super case |
| 22:23:38 | evan | gotcha |
| 22:23:40 | brixen | yeah |
| 22:23:42 | evan | yeah, i used a hidden local |
| 22:23:44 | brixen | there were no specs |
| 22:23:48 | brixen | yeah, works fine |
| 22:23:51 | brixen | tiny patch |
| 22:24:07 | brixen | unless you want to do it a different way |
| 22:24:32 | evan | nope |
| 22:24:33 | evan | thats fine. |
| 22:24:43 | brixen | k |
| 22:24:43 | evan | what would be rad though |
| 22:24:52 | evan | although not necessary |
| 22:25:00 | evan | is only emit the hidden local if super is used |
| 22:25:03 | evan | so that |
| 22:25:06 | evan | def f(*); end |
| 22:25:12 | evan | doesn't use the hidden local |
| 22:25:17 | brixen | ok |
| 22:25:27 | evan | the reason for that is we don't have to allocate the Array then |
| 22:25:36 | brixen | gotcha |
| 22:25:47 | evan | thats a nice to have |
| 22:25:53 | evan | not necessary right now though. |
| 22:26:13 | brixen | yeah, I'd have to think a bit on it |
| 22:26:16 | brixen | I'll push this |
| 22:26:18 | evan | k |
| 22:27:07 | slava | yo |
| 22:27:26 | evan | hey slavs |
| 22:28:23 | brixen | slava: hey, do you keep download stats on factor binaries? |
| 22:29:45 | slava | brixen: no, but there's probably been 3 downloads in the last 2 years or something |
| 22:29:57 | brixen | heh |
| 22:30:00 | brixen | oh c'mon |
| 22:30:15 | brixen | I downloaded os x 32bit this morning |
| 22:30:19 | slava | I have logs on the dreamhost that hosts the downloads |
| 22:30:20 | slava | does it work? |
| 22:30:23 | brixen | yep |
| 22:30:26 | brixen | it's slick |
| 22:30:36 | brixen | you've done so much to the gui in a year |
| 22:31:17 | slava | I'll try to find a way to analyze the logs |
| 22:31:30 | brixen | slava: oh, but gc-stats. gets a stack underflow |
| 22:31:45 | brixen | if I invoke it right off in the listener |
| 22:31:51 | slava | brixen: the new gc stuff hasn't made its way through the build farm yet, because of crash bugs |
| 22:31:57 | brixen | ahh ok |
| 22:32:08 | slava | I'm going to be working on those today |
| 22:32:15 | brixen | cool |
| 22:32:45 | evan | slava: did ya see I just commited generational age autotuning? |
| 22:32:54 | slava | evan: no, what's that? |
| 22:33:11 | evan | using some stat data to see if the young GC is starting to thrash |
| 22:33:16 | evan | if so, it lowers the lifetime |
| 22:33:20 | evan | so it promotes earlier |
| 22:33:23 | slava | oh, cool |
| 22:33:26 | evan | to try and eliminate the thrash |
| 22:33:33 | slava | any perf boost? |
| 22:33:35 | evan | and if there isn't enough surviving |
| 22:33:39 | evan | it raises the lifetime |
| 22:33:50 | evan | not sure yet on the perf change |
| 22:33:57 | evan | just commited the initial attempt |
| 22:34:00 | evan | it's pretty simple. |
| 22:34:12 | evan | brixen was going to run some GC benchmarks for me :) |
| 22:34:13 | brixen | evan: I'll run the stats |
| 22:34:20 | brixen | heh |
| 22:34:26 | slava | let me know how it turns out |
| 22:34:35 | slava | generational policy is still black magic to me |
| 22:34:39 | brixen | gc benchmarks == running full CI compiling |
| 22:34:47 | brixen | slava: http://gist.github.com/231803 |
| 22:34:52 | evan | it's black magic to everyone. |
| 22:34:57 | brixen | that's some experimenting I was doing last night |
| 22:35:16 | brixen | slava: you can see quite a bit of improvement relative to total objects copied |
| 22:35:31 | brixen | and the behavior of immix |
| 22:36:55 | slava | brixen: how do you do nanosecond timing? |
| 22:37:13 | evan | slava: vm/util/timing.hpp |
| 22:37:22 | slava | I'll check it out, thanks |
| 22:37:35 | evan | oh, nm |
| 22:37:38 | evan | vm/instruments/timing.hpp |
| 22:37:52 | brixen | slava: yeah, check out all of vm/instruments/ |
| 22:37:57 | brixen | there's some fun stuff |
| 22:39:07 | evan | well, thats dumb. |
| 22:39:17 | evan | you can pass a Method object to define_method |
| 22:39:27 | brixen | heh |
| 22:39:32 | evan | but it actually treats it like an UnboundMethod |
| 22:39:37 | evan | i guess thats fine. |
| 22:39:41 | evan | just... kinda bleh. |
| 22:39:47 | brixen | yeah |
| 22:56:39 | brixen | hmm, well this is a mess |
| 22:56:52 | brixen | File.umask 2**30 is failing |
| 22:57:08 | brixen | but investigating a bit, the mess appears |
| 22:57:24 | brixen | see eg line 147 of kernel/common/file.rb |
| 22:57:31 | brixen | and the comment above it |
| 22:58:55 | evan | fun. |
| 22:59:03 | evan | sorry about that |
| 22:59:12 | evan | i updated all file tags and that one slipped in |
| 22:59:17 | brixen | that's ok |
| 22:59:18 | evan | feel free to retag it. |
| 22:59:20 | brixen | we need to fix it |
| 22:59:33 | evan | whats the failure? |
| 22:59:37 | brixen | so, basically, mri ignores values > 2**16 for mode_t |
| 22:59:44 | brixen | check out that line in the file |
| 22:59:47 | evan | right |
| 22:59:48 | evan | yep |
| 22:59:49 | evan | i see it |
| 22:59:54 | evan | so 2**30 becomes 0 |
| 22:59:57 | brixen | but we don't do that for umask |
| 23:00:16 | evan | ah |
| 23:00:17 | brixen | but we also shouldn't litter file.rb with these |
| 23:00:18 | evan | we should |
| 23:00:32 | evan | add a mode_clamp or something method |
| 23:00:32 | brixen | is there a better place to do this clamping? |
| 23:00:48 | brixen | should we do it on mode_t types in the FFI layer? |
| 23:01:05 | evan | well, it would have the same problem MRI does |
| 23:01:12 | evan | it would give you the random low bits |
| 23:01:56 | brixen | hm |
| 23:02:41 | brixen | ok, well a private #clamp_mode is a simple fix |
| 23:02:59 | brixen | well, maybe not private |
| 23:03:21 | evan | seems like this code should be coercing the argument anyway |
| 23:03:30 | evan | so we should have a single method that uses Type.coerce_to |
| 23:03:32 | evan | and then clamps it |
| 23:03:35 | evan | and returns the value |
| 23:03:38 | brixen | makes sense |
| 23:16:31 | brixen | well that was a total github fail |
| 23:16:38 | evan | eh? |
| 23:16:40 | brixen | lost my edit to a gist |
| 23:16:48 | evan | oop.s |
| 23:16:53 | brixen | but, since they are just git repos, I fixed it! |
| 23:16:54 | brixen | http://gist.github.com/231803 |
| 23:17:02 | brixen | update with stats from autotuning |
| 23:17:41 | brixen | github actually overwrote a file even though I added a new file and gave it a totally different name |
| 23:17:57 | brixen | anyway, manually worked |
| 23:18:32 | brixen | so, just with the autotuning, young gen performed better |
| 23:19:12 | brixen | 244M copied vs 394M |
| 23:19:31 | brixen | but maybe the damper is a little too dampening? |
| 23:20:28 | brixen | could add config vars for over/under times |
| 23:20:52 | evan | yep |
| 23:20:56 | evan | this is just a rough cut |
| 23:20:58 | evan | to let us play with it. |
| 23:21:02 | brixen | yeah |
| 23:21:05 | brixen | it works! |
| 23:22:15 | evan | success! |
| 23:22:17 | evan | so yeah |
| 23:22:28 | evan | feel free to go in there and play around with that logic |
| 23:22:35 | evan | move some of those things out to config vars |
| 23:22:36 | evan | etc. |
| 23:23:47 | brixen | k |
| 23:35:48 | jvoorhis | so i heard you guys plan to edit the FFI api a little bit |
| 23:36:35 | jvoorhis | what changes were you planning to make? i have some FFI libs and it would be cool if i could support more than just MRI |
| 23:37:01 | evan | already did it |
| 23:37:28 | jvoorhis | what did you remove? |
| 23:37:28 | evan | attached methods are available as public class methods and private instance methods |
| 23:37:42 | evan | so you can include a module and call the FFI attached methods |
| 23:37:45 | evan | i added something. |
| 23:37:58 | jvoorhis | cool, that's convenient |
| 23:38:23 | evan | there are parts of ruby-ffi i'm not happy with |
| 23:38:33 | jvoorhis | brixen mentioned some possible changes to Pointer |
| 23:38:38 | evan | like, i'm not happy with the requirement of using finalizers with AutoPointer |
| 23:38:40 | evan | thats bad news. |
| 23:39:24 | jvoorhis | i like AutoPointer in principle, but it's pretty unpredictable |
| 23:39:32 | evan | thats because of the finalizers. |
| 23:39:46 | evan | it's not a robust solution for managing external cleanup. |
| 23:40:12 | evan | AutoPointer originally just free'd the pointer |
| 23:40:46 | evan | but it got extended to do too much. |
| 23:40:54 | jvoorhis | i've been using it to call DisposeBlah()-style functions, but i'm not too happy with it |
| 23:41:11 | evan | even free'ing pointers is really the way to go |
| 23:41:48 | brixen | jvoorhis: I showed evan your llvm ffi bindings |
| 23:42:33 | jvoorhis | i really want a way to create a lib that frees the user from having to interact directly with ffi, including that sort of cleanup |
| 23:42:51 | evan | ok |
| 23:42:56 | evan | thats exactly the way FFI is meant to be used |
| 23:43:13 | evan | the idea was never that you pass out FFI::Structs and such. |
| 23:43:22 | jvoorhis | yeah, exactly |
| 23:43:30 | brixen | evan: oh! here's a 10.6.2 build of llvm that brianmario built |
| 23:43:31 | brixen | http://files.me.com/brianmario/oggrb4 |
| 23:43:37 | brixen | password is "rubinius" |
| 23:43:40 | evan | k |
| 23:43:43 | brianmario | oh |
| 23:43:44 | brianmario | sec |
| 23:43:44 | brianmario | l) |
| 23:43:46 | brianmario | ;) |
| 23:43:55 | brianmario | took it down cause i was gonna throw it up on my webserver |
| 23:44:03 | evan | jvoorhis: for cleanup, the best is to use a begin;ensure wrapper around the operations |
| 23:44:08 | evan | and force the user to go through that. |
| 23:44:25 | evan | for mass cleanup of resources |
| 23:44:35 | brianmario | http://sharpercoding.com/projects/rubinius/llvm-x86_64-apple-darwin10.2.0.tar.bz2 |
| 23:44:38 | evan | i'll probably add a Pool class |
| 23:44:41 | jvoorhis | evan: what about something you'll hold onto for a while? like an LLVM Context for example |
| 23:44:48 | brianmario | that password thing on my idisk was retarded |
| 23:44:59 | evan | jvoorhis: for something like that you probably don't ever need to clean it up. |
| 23:45:11 | evan | but if you do, you should require the user call a method when they're done with it. |
| 23:45:25 | evan | that does expose some cleanup logic, i know. |
| 23:45:33 | evan | which is why people use AutoPointer |
| 23:45:52 | jvoorhis | evan: so you would just define #dispose whenever it's needed? and maybe freeze it? |
| 23:46:11 | evan | freeze is nothing |
| 23:46:15 | evan | freeze means shit. |
| 23:46:28 | jvoorhis | ok :) |
| 23:46:44 | evan | i don't get why people think freeze is the answer to any question |
| 23:46:44 | evan | anyways. |
| 23:46:49 | evan | NOT talknig about freeze |
| 23:47:00 | evan | the context is an external resource |
| 23:47:14 | evan | so either you force them to call a #dispose method when they're done |
| 23:47:22 | evan | or you wrap usage in a begin;ensure |
| 23:47:23 | jvoorhis | it communicates something – it says "don't touch me!" :) but yeah, it won't enforce anything |
| 23:47:34 | evan | it doesn't communicate that though. |
| 23:47:39 | evan | in my mind. |
| 23:47:40 | evan | anyway. |
| 23:47:41 | jvoorhis | not very effectively |
| 23:48:02 | jvoorhis | evan: but those patterns sound right to me, now that i think about it |
| 23:48:12 | jvoorhis | one thing i really did like about the FFI api is #to_ptr |
| 23:48:24 | evan | thats not me |
| 23:48:28 | evan | this is the problem with the API |
| 23:48:38 | evan | wayne went off and added a shitton of stuff |
| 23:48:43 | evan | and never really synced it up with rubinius |
| 23:48:52 | evan | he did both the jruby and mri versions |
| 23:48:56 | jvoorhis | right |
| 23:49:03 | evan | but didn't really run anything by me |
| 23:49:07 | evan | so it's a mess. |
| 23:49:17 | evan | and there are hundreds of unimplemneted behaviors |
| 23:49:19 | jvoorhis | yeah, and underdocumented and somewhat opaque |
| 23:49:38 | evan | it's not wayne's fault |
| 23:49:43 | evan | i didn't have time to push back |
| 23:49:48 | evan | but it needs to be fixed soon. |
| 23:50:04 | jvoorhis | are you unhappy with #to_ptr? |
| 23:50:35 | evan | no, it's fine |
| 23:50:40 | evan | but i honestly don't even know what it is. |
| 23:50:45 | evan | this is the first i'm hearing of it |
| 23:50:46 | evan | which is a problem. |
| 23:50:49 | jvoorhis | yeah |
| 23:51:23 | jvoorhis | basically, you can substitute any object that implements #to_ptr for an FFI::Pointer in calls to attached methods |
| 23:51:50 | evan | right, it's a coerce. |
| 23:51:56 | jvoorhis | exactly |
| 23:51:57 | evan | i'm not a huge fan of that |
| 23:52:06 | evan | because now you have to check and call back into ruby code |
| 23:52:08 | evan | at any point. |
| 23:52:20 | evan | if you want to coerce |
| 23:52:25 | evan | you should be wrapping the attached method |
| 23:52:29 | evan | and doing the coerce there. |
| 23:52:42 | brixen | yeah, that's pushing too much under the covers of FFI |
| 23:52:49 | brixen | FFI is supposed to be *thin* |
| 23:52:55 | jvoorhis | right |
| 23:52:56 | evan | yes, razor thin. |
| 23:53:08 | evan | because it's supposed to be fast |
| 23:53:15 | evan | the more it's burdoned with coercions |
| 23:53:17 | evan | the slower it gets. |
| 23:53:45 | jvoorhis | the wrapper is still really convenient |
| 23:54:10 | evan | regardless |
| 23:54:16 | evan | i don't think it's FFI's business to do it. |
| 23:54:50 | evan | a big reason for me pushing back on that kind of thing is the simplicity of the FFI dispatch |
| 23:55:00 | evan | for most of the life of the FFI impl. in rbx |
| 23:55:06 | evan | there was no way for it to call back into ruby |
| 23:55:16 | evan | because it's implemented as a leaf primitive |
| 23:55:20 | evan | which can't call back into ruby code. |
| 23:55:30 | evan | a big restriction, but one that keeps everything fast and sane. |
| 23:55:53 | evan | thats the reason we don't support callbacks |
| 23:56:31 | jvoorhis | are there plans to? |
| 23:56:46 | evan | it's on the list |
| 23:57:03 | jvoorhis | and i didn't realize attach_function was the primitive – i assumed it would be a wrapper to a primitive |
| 23:57:04 | evan | but i'm hoping i don't have to dit |
| 23:57:09 | evan | i'm hoping that some interested in FFI helps. |
| 23:57:23 | evan | no |
| 23:57:25 | evan | attach_function isn't |
| 23:57:37 | evan | but when you call the attached function itself |
| 23:57:41 | evan | thats a primitive |
| 23:57:46 | evan | and it's at that point that #to_ptr is called |
| 23:57:47 | evan | i'm assuming |
| 23:57:53 | jvoorhis | sorry, i was conflating the two |
| 23:57:56 | evan | i don't know why you'd pass a pointer to attach_function |
| 23:58:05 | jvoorhis | no, you wouldn't |
| 23:58:11 | jvoorhis | i meant attach_function-generated methods |
| 23:59:03 | evan | right |
| 23:59:08 | evan | see, in RBX |
| 23:59:13 | evan | those are very, very fast. |
| 23:59:21 | evan | because they're extremely thin |
| 23:59:33 | evan | they perform the data conversions |
| 23:59:39 | evan | and call out |
| 23:59:45 | evan | and they can be inlined by the JIT |
| 23:59:53 | evan | which makes them as fast as calling a C function directly |