Show enters and exits. Hide enters and exits.
| 00:35:05 | headius | evan: you don't have ObjectSpace._id2ref, do you |
| 00:35:23 | evan | not atm, no. |
| 00:35:39 | evan | still need to add support for it |
| 00:35:48 | headius | how will you implement it? |
| 00:36:18 | headius | I'm considering allowing it to be disabled, so Object#object_id doesn't require us to synchronize and track weakrefs to objects |
| 00:36:27 | evan | well, since it uses object_id |
| 00:36:34 | evan | yeah, use a weakmap |
| 00:36:56 | headius | I think people use it without realizing what it does behind the scenes |
| 00:36:56 | evan | could really penalize people |
| 00:37:02 | evan | and use the GC to find the object :D |
| 00:37:16 | evan | course they do |
| 00:37:17 | headius | it's only used in a handful of places in stdlib and all the gems I have installed |
| 00:37:34 | evan | it's also nondeterministic |
| 00:37:41 | evan | something people don't seem to grasp |
| 00:37:49 | evan | so in that way |
| 00:37:51 | headius | right |
| 00:38:00 | evan | i guess a valid implementation of _id2ref jsut returns nil for everything |
| 00:38:42 | evan | since it's nondeterministic |
| 00:38:47 | headius | I don't think that would necessarily be valid, since it should return the object if it's alive |
| 00:39:01 | evan | not true |
| 00:39:01 | headius | I would have a flag or property to enable it and error if someone uses it without that flag |
| 00:39:07 | evan | it returns whatever object has that id |
| 00:39:10 | evan | and since MRI reuses ids |
| 00:39:12 | evan | it could be anything |
| 00:39:51 | headius | I really need to look at using jvm debugging stuff to implement some of these pieces |
| 00:39:56 | evan | maybe i'll implement it using a transative closure |
| 00:40:01 | evan | over all objects in the system |
| 00:40:03 | headius | then they'd be there and only have a cost with debug stuff enabled |
| 00:40:38 | evan | the latest GC work had me refactor the transitive closure code |
| 00:40:52 | headius | oh? |
| 00:40:56 | evan | so i can easily do a TC and do whatever I want |
| 00:41:15 | evan | hehe |
| 00:41:17 | evan | i'm going to do that |
| 00:41:20 | evan | maybe i'll do it now |
| 00:41:24 | headius | I don't follow |
| 00:41:39 | evan | when you call _id2ref(2) |
| 00:41:46 | evan | it walks every object in the system |
| 00:41:54 | evan | looking for an object that is tagged as having id 2 |
| 00:42:39 | evan | I store object_id in an ivar now |
| 00:43:19 | headius | it doesn't return anything you haven't called object_id on right now for us |
| 00:43:45 | evan | same for me |
| 00:43:50 | evan | it's lazy |
| 00:44:03 | evan | if you feed it random numbers |
| 00:44:06 | evan | it returns nil |
| 00:44:09 | evan | unlike MRI |
| 00:44:10 | evan | :/ |
| 00:45:34 | headius | yeah, so do we |
| 00:45:41 | headius | didn't know it raises a RangeError for that |
| 00:46:12 | evan | huh |
| 00:46:12 | evan | yep. |
| 00:47:37 | headius | heh, if the object associated with the ID has been collected, then it returns nil |
| 00:48:07 | headius | 1M calls to Object#object_id improves from 0.38s to 0.17s if I turn off the magic ID stuff |
| 00:48:30 | evan | whats the magic ID stuff? |
| 00:48:34 | evan | keeping the map? |
| 00:52:48 | headius | yes |
| 00:56:11 | evan | so does _id2ref not work then? |
| 00:59:06 | headius | if I disable the map stuff, yes |
| 00:59:25 | headius | er, correct...it would no longer work unless turned on |
| 01:01:51 | boyscout | Remove dead instructions - 2b39487 - Evan Phoenix (llvm-jit) |
| 01:01:51 | boyscout | Sensible MetaClass#inspect - 4e65917 - Evan Phoenix (llvm-jit) |
| 01:01:51 | boyscout | A whole bunch more instructions - 693a615 - Evan Phoenix (llvm-jit) |
| 01:12:08 | brixen | pretty cool http://www.wolframalpha.com/screencast/introducingwolframalpha.html |
| 01:23:26 | headius | brixen: yeah, that's sweet |
| 02:08:11 | crafterm | hi all! |
| 02:15:39 | evan | hey! |
| 02:15:42 | evan | just headed to get some dinner! |
| 02:15:42 | brixen | hey crafterm, how goes it down under? |
| 02:16:01 | crafterm | hi evan, brixen! |
| 02:16:11 | crafterm | all going well, arrived back in .au just a few days ago |
| 02:16:21 | crafterm | how are you guys going? missing all the fun in Vegas yet? |
| 02:16:46 | brixen | haha |
| 02:16:54 | brixen | you just had to mention that :P |
| 02:17:27 | brixen | going well |
| 02:22:24 | crafterm | was good fun, missing the trip already! :) |
| 02:22:53 | crafterm | good chat at the 'freakin frog' too brixen - enjoyed hearing about the new rubinius internals |
| 02:27:24 | brixen | cool |
| 02:27:42 | brixen | more "internals" coming soon :) |
| 02:48:28 | crafterm | cool mate :) |
| 02:48:52 | crafterm | we'll have to follow up on having another sprint mate! would be awesome to get some more details from you guys to give back into the source |
| 02:49:47 | brixen | sure |
| 02:49:55 | brixen | did you see we have a roadmap? |
| 02:50:01 | slava | url? |
| 02:50:20 | brixen | http://rubini.us/roadmap.html |
| 02:50:21 | crafterm | haven't seen the roadmap mate - where's that? |
| 02:50:37 | brixen | it's a bit in progress, but those are the broad strokes |
| 02:50:43 | crafterm | peruses the roadmap! |
| 02:50:44 | slava | oh i see |
| 02:51:29 | ddub | where we're going, we won't need roads |
| 02:52:35 | brixen | ^5s ddub |
| 02:52:36 | crafterm | :) |
| 02:52:46 | brixen | good point ddub |
| 02:57:52 | ddub | everything I ever needed to know I learned from Back to the Future |
| 08:44:42 | rue | ddub_: Will have become to learn? |
| 08:49:30 | scoopr | howsit going? |
| 09:51:55 | rue | Eh |
| 17:43:32 | enebo | WTF: http://jira.codehaus.org/browse/JRUBY-3646 |
| 17:43:54 | enebo | oh I see |
| 17:43:55 | enebo | heh |
| 17:44:00 | enebo | yuck |
| 17:46:54 | brixen | enebo: any chance of getting the code that uncovered that? |
| 17:47:20 | enebo | Like the real-life case versus the test case provided? |
| 17:47:25 | brixen | right |
| 17:47:43 | enebo | I can add a comment asking him if it is a library or his own private stuff |
| 17:47:50 | brixen | that would be cool |
| 17:48:06 | brixen | when writing rubyspec, sometimes it's hard to imagine such cases :) |
| 17:49:20 | enebo | yeah. and I think this one will not be so hard to fix, but we will need to change every occurance of this pattern |
| 17:49:33 | enebo | It also makes me wonder how many other core classes do this sort of thing |
| 17:49:41 | brixen | yeah |
| 17:49:51 | brixen | would be good to get this covered in rubyspec |
| 17:49:58 | enebo | yep |
| 17:51:27 | marcandre | some of these cases are covered by rubyspecs. |
| 17:51:51 | marcandre | In my last blog, I asked 12 such examples, for the array class. |
| 17:52:03 | marcandre | Some are downright nasty. |
| 17:52:15 | brixen | yeah |
| 17:52:37 | marcandre | (my_a+my_a).class != (my_a * 2).class |
| 17:54:08 | marcandre | Oh, here it's even more subtle though. The class is Ok but the initialize wasn't called. Anyways. |
| 18:13:39 | evan | wow |
| 18:13:45 | evan | that Array#uniq bug |
| 18:13:49 | evan | thats so stupid |
| 18:14:09 | evan | why in the world would you depend on the fact that uniq clones |
| 18:18:33 | brixen | alas, the world is made of mystery |
| 18:18:38 | evan | no seriously |
| 18:18:49 | evan | that seems like a mis-feature |
| 18:18:56 | evan | completely unintended |
| 18:19:00 | brixen | yep |
| 18:19:18 | brixen | but if there is a difference in behavior, it's likely some code depends on it |
| 18:19:28 | evan | accidental code |
| 18:19:44 | brixen | the difference between clone and dup seems mostly unneeded to me |
| 18:20:01 | brixen | yeah, accidental |
| 18:20:23 | brixen | because so much is ad hoc and obscure with no explicit spec |
| 18:21:51 | brixen | look at the specs for Hash#key? |
| 18:22:13 | brixen | compared to how Hash normally matches a key |
| 18:22:35 | brixen | btw, I've got cuckoo hash passing the specs |
| 18:22:42 | brixen | trying to get it running in rbx now |
| 18:24:30 | evan | yay |
| 18:25:02 | brixen | this mix of 1.8.6 and 1.8.7 just sucks |
| 18:25:05 | brixen | I hate ruby |
| 18:25:08 | brixen | :) |
| 18:25:11 | evan | what mix? |
| 18:25:18 | brixen | just having them both |
| 18:25:32 | evan | so 1.8.7's very existance |
| 18:25:36 | brixen | yeah |
| 18:25:59 | brixen | plug-n-play with a core data type is a pita |
| 18:26:18 | brixen | exacerbated by having these extra files now |
| 18:26:58 | evan | ah. |
| 18:27:02 | evan | so it's that thing. |
| 18:27:03 | evan | :? |
| 18:27:04 | evan | :/ |
| 18:27:37 | brixen | well, the 4 competing versions of ruby just makes everything more complicated |
| 18:27:46 | brixen | where is the benefit? |
| 18:27:50 | brixen | beats me |
| 18:28:19 | evan | yeah |
| 18:29:19 | brixen | let's just make it 7 and name them after the dwarves |
| 18:29:54 | evan | heheh |
| 18:30:18 | brixen | actually, there are about 7: 1.8.6, 1.8.7, 1.8.8, 1.9.0 1.9.1 1.9.2 |
| 18:30:40 | brixen | and if you think I'm kidding about the 1.9 series, think again |
| 18:30:56 | evan | doc, sneezy, grumpy, bashful, sleepy, and .... |
| 18:30:58 | brixen | people are posting bug comparing 1.9.0 behavior to 1.9.1 |
| 18:31:07 | brixen | and 1.9.2 is the "dev" version |
| 18:34:33 | scoopr | rbx is snow white, then? |
| 18:35:21 | brixen | ahh dur, I was using the multi-arg version of attr_accessor |
| 18:35:46 | brixen | so, just ran the Hash specs with the cuckoo version *replacing* the old Hash |
| 18:35:48 | brixen | sweet |
| 18:35:59 | brixen | scoopr: heh, exactly! :) |
| 18:55:39 | manveru | brixen: just skip 1.9.0... |
| 18:55:54 | brixen | manveru: oh, I do |
| 18:55:56 | manveru | i doubt anybody can run stable on it anyway |
| 18:56:10 | brixen | doesn't mean it isn't adding to the (unnecessary) confusion |
| 18:56:13 | manveru | and 1.9.2 isn't out yet |
| 18:56:25 | brixen | but it will be |
| 18:56:27 | brixen | :) |
| 18:56:40 | manveru | sure, there will be N versions :P |
| 18:57:03 | manveru | but you only have to target the ones mostly in use |
| 18:57:22 | manveru | nobody can cover all the crazy variations of the MRI guys |
| 19:42:41 | brixen | wb boyscout |
| 19:43:21 | evan | where did boyscout go... |
| 19:43:38 | evan | weird |
| 19:43:40 | evan | netsplit I guess |
| 19:44:00 | brixen | ahh yep |
| 19:44:03 | brixen | about 2 hrs ago |
| 20:41:27 | rue | Google assimilated it. |
| 21:56:34 | HaPK | Hey, people. Just cloned rubinius repository, built it, bin/mspec ci and it says "Tried to use non-reference value 0x1a as type Fixnum (19) (TypeError)". How can I fix this ? |
| 21:57:52 | brixen | hmm |
| 21:58:28 | brixen | what platform? |
| 21:59:16 | HaPK | OS X (Intel) |
| 21:59:30 | brixen | did you have rbx installed before? |
| 21:59:30 | HaPK | 10.5.7 |
| 21:59:32 | evan | HaPK: thats off a fresh clone? |
| 21:59:42 | HaPK | evan: yes |
| 22:00:14 | HaPK | brixen: no, as far as I remember |
| 22:00:25 | evan | hm |
| 22:00:32 | evan | you shouldn't get anything like this then... |
| 22:00:38 | evan | um.. |
| 22:00:55 | brixen | I haven't upgraded yet, but I could |
| 22:00:59 | HaPK | evan: can I somehow check if there are traces of old rbx in my system ? |
| 22:01:09 | brixen | you could try which rbx |
| 22:01:16 | evan | HaPK: look for any .rbc files |
| 22:01:17 | HaPK | which rbx shows nothing |
| 22:01:27 | HaPK | evan: where ? |
| 22:01:33 | evan | anywhere |
| 22:01:38 | evan | use spotlight |
| 22:03:13 | HaPK | evan: well, spotlight shows plenty of .rbc files, but they all are from Rubinius directory |
| 22:04:03 | evan | remove them all. |
| 22:04:08 | evan | then build again |
| 22:05:48 | HaPK | evan: I have found /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet.rbc |
| 22:06:13 | evan | weird. |
| 22:06:21 | evan | looks like someone packaged a .rbc file |
| 22:06:27 | evan | probaby on accident |
| 22:06:38 | HaPK | evan: probably |
| 22:06:52 | HaPK | evan: I have deleted all .rbc files and doing "rake build" now |
| 22:07:01 | evan | k |
| 22:07:34 | HaPK | evan: same thing |
| 22:07:50 | evan | hmr. |
| 22:08:06 | evan | whats gcc --version |
| 22:08:08 | evan | first line only |
| 22:08:24 | HaPK | evan: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488) |
| 22:08:39 | evan | hrm |
| 22:08:42 | evan | does |
| 22:08:43 | evan | bin/rbx -v |
| 22:08:44 | evan | work? |
| 22:08:56 | HaPK | evan: yes |
| 22:09:09 | HaPK | evan: it shows "rubinius 0.11.0-dev (ruby 1.8.6) (693a6155c 12/31/2009) [i686-apple-darwin9.7.0]" |
| 22:09:16 | evan | ok |
| 22:09:17 | evan | hm. |
| 22:09:54 | evan | HaPK: do you get a backtrace with the TypeError? |
| 22:10:00 | HaPK | evan: yes |
| 22:10:03 | evan | oh |
| 22:10:04 | evan | pastie it |
| 22:10:32 | HaPK | pastie: hit me |
| 22:10:43 | HaPK | hey, how does this work ? |
| 22:10:49 | evan | asking pastie? |
| 22:10:51 | evan | never works for me. |
| 22:11:19 | brixen | pastie: yo |
| 22:11:28 | pastie | http://pastie.org/478501 by HaPK. |
| 22:11:31 | brixen | it pm's you a link |
| 22:11:52 | HaPK | brixen, yeah, just figured it out |
| 22:11:57 | HaPK | thanks |
| 22:12:17 | evan | ..... |
| 22:12:22 | evan | why is the profiler running... |
| 22:12:44 | HaPK | evan: dunno |
| 22:12:50 | brixen | that's weird |
| 22:12:55 | evan | thats... bizarre |
| 22:13:04 | evan | HaPK: run 'env' and pastie the output |
| 22:13:15 | brixen | upgrading, brb... |
| 22:13:24 | evan | that looks like an error in the profiler |
| 22:13:26 | evan | is my guess |
| 22:13:28 | HaPK | pastie: one more time |
| 22:13:36 | evan | trying to treat a nil as a Fixnum |
| 22:14:06 | pastie | evan: http://pastie.org/478506 by HaPK. |
| 22:14:22 | dgtized | boyscout ran away again? |
| 22:14:37 | evan | um. |
| 22:14:39 | evan | did it? |
| 22:14:45 | evan | i'll restart him |
| 22:14:56 | evan | yeah, he crashed :/ |
| 22:22:57 | slava | hi evan |
| 22:23:12 | boyscout | CI: 2e866ab success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 22:23:35 | evan | slava: allo |
| 22:24:18 | HaPK | pastie: ping |
| 22:25:00 | rue | That is the error on 4.2 |
| 22:25:28 | pastie | http://pastie.org/478522 by HaPK. |
| 22:25:29 | rue | HaPK: You should be able to do a build:debug without problems if the issue is the same as I saw |
| 22:26:17 | evan | why the fuck is the profiler running |
| 22:26:19 | HaPK | evan: I have tried doing bin/mspec spec/ruby (after rake rubyspec:update) |
| 22:26:19 | evan | brixen? |
| 22:26:28 | rue | -O2 seemed to be the cause of the breakage, but I never investigated further |
| 22:26:36 | evan | rue: he's on gcc 4.0 |
| 22:27:42 | brixen | evan: no idea |
| 22:28:07 | brixen | HaPK: you have no local changes? |
| 22:28:20 | HaPK | brixen, no, just checked it out |
| 22:29:44 | HaPK | builds debug version |
| 22:30:29 | brixen | I just upgraded to 10.5.7 and doing a clean build |
| 22:31:09 | brixen | HaPK: try full/path/to/vm/vm ./mspec/bin/mspec-run -h |
| 22:31:39 | HaPK | brixen: will do once it finish building |
| 22:32:20 | brixen | HaPK: what do you have customized in your env? |
| 22:32:30 | rue | marcandre: Minor request for commit messages, can you stick in an "implemented"/"fixed"/"specced"/etc. whichever applies? I always get confused when I just see "1.8.7: IO#each" etc. :P |
| 22:36:01 | HaPK | brixen: I have pastied my env variables 10 minutes age. You can check them |
| 22:36:02 | brixen | HaPK: for example, what is your PATH? |
| 22:36:08 | brixen | link? |
| 22:36:15 | brixen | I was upgrading to look at your issue |
| 22:36:37 | HaPK | brixen: http://pastie.org/478506 |
| 22:39:00 | rue | Same error on 4.2 in 10.5.7 |
| 22:39:15 | rue | Double-checking build:debug and 4.0 |
| 22:39:42 | brixen | I have no issues on 10.5.7 with 4.0 |
| 22:39:45 | HaPK | rue: just built:debug and see the same error |
| 22:39:57 | rue | Think my next project will be reuptake of the const correctness tract |
| 22:40:25 | brixen | HaPK: the same issue running which command? |
| 22:40:41 | HaPK | brixen: bin/mspec ci |
| 22:40:49 | brixen | did you try the other command? |
| 22:41:37 | HaPK | brixen: I'm running "/full/path/to/vm/vm ./mspec/bin/mspec-ci" |
| 22:41:55 | HaPK | brixen: I see dots appearing and have seen one "F" so far |
| 22:42:12 | rue | Hum, we do not honour CC for g++ |
| 22:42:33 | rue | But |
| 22:43:06 | brixen | HaPK: what do you get from 'ls -l ./bin/rbx' ? |
| 22:43:10 | rue | Erm, but `CC=gcc-4.0 rake build` completes fine, mspec runs |
| 22:44:03 | HaPK | brixen: ./bin/rbx -> ../vm/vm |
| 22:44:28 | HaPK | brixen: the rest is usual "ls -l" output |
| 22:45:45 | brixen | HaPK: ok, did the other command complete? did you get profiler output? |
| 22:46:36 | HaPK | brixen: tests are still running. I got profiler output for failing test (just before "F" instead of dot appeared) |
| 22:46:59 | brixen | that is so crazy |
| 22:47:59 | rue | Something is just a bit sloppy (or it could even be an actual compiler bug), and the optimizer fucks up |
| 22:49:05 | rue | `rake build:debug` with gcc-4.2 also succeeds and runs specs here |
| 22:49:38 | brixen | HaPK: how are your ruby skills? |
| 22:49:47 | marcandre | rue: will do :-) I've be putting (new) for new specs and new methods, but yeah, I'll put in a bit more context. Gotta run now... |
| 22:50:03 | rue | marcandre: Good deal |
| 22:50:06 | HaPK | brixen: well, I've been writing ruby for 4 years so far |
| 22:50:15 | brixen | HaPK: heh, excellent |
| 22:50:21 | rue | Do not have time to actually look at the changeset oftentimes |
| 22:50:35 | HaPK | brixen: why? |
| 22:50:36 | brixen | HaPK: you could try tracking down how the ProfilerAction gets enabled |
| 22:50:52 | brixen | HaPK: look at spec/custom/utils/script.rb |
| 22:51:17 | brixen | see if config[:profiler] is set and try tracking backwards |
| 22:51:29 | rue | HaPK: When you run just `rake build`, do you get past the extension build? Or maybe you pastied that above somewhere? |
| 22:51:34 | HaPK | brixen: ok, will do. |
| 22:51:43 | brixen | bin/mspec should be exec'ing mspec/bin/mspec using rbx |
| 22:52:07 | HaPK | rue: the last line of "rake build:debug" was "Created bigdecimal.bundle" |
| 22:52:10 | weepy | hey - i had a question about cukoo hash |
| 22:52:24 | brixen | weepy: shoot |
| 22:52:33 | rue | HaPK: What about without :debug? Lemme paste what I saw there |
| 22:53:06 | weepy | as far as i understood - it is all super whizzy etc as long as it's somewhat sparsely populated. |
| 22:53:09 | HaPK | rue: as far as I remember, it was just like with :debug |
| 22:53:12 | brixen | HaPK: the mspec/bin/mspec script just gathers options and runs the worker script |
| 22:53:48 | weepy | - so question is - how do u know that's the case ? |
| 22:53:52 | rue | HaPK: http://gist.github.com/111951 |
| 22:54:09 | HaPK | ok, tests have finished. One test failed: ARGF.read reads the contents of one file and stdin FAILED |
| 22:54:23 | evan | that one fails all the time |
| 22:54:29 | evan | if your tests output anything |
| 22:54:35 | evan | like, in this case, the profiler. |
| 22:54:52 | rue | HaPK: That is `rake build`, i.e. gcc-4.2. `CC=gcc-4.0 rake build` works, `CC=gcc-4.0 rake build:debug` works and `rake build:debug` works here; i.e. on my end it seems to be 4.2's -O2 |
| 22:55:03 | evan | rue: he's not on gcc 4.2 |
| 22:55:05 | HaPK | pastie: I have something |
| 22:55:18 | pastie | http://pastie.org/478551 by HaPK. |
| 22:55:28 | brixen | weepy: www.itu.dk/people/pagh/papers/cuckoo-jour.pdf |
| 22:55:34 | HaPK | evan: see the test fails because of syntax error |
| 22:55:46 | brixen | weepy: that's what I'm looking at, and evan's prototype code |
| 22:55:51 | evan | wtf. |
| 22:55:57 | rue | evan: Yes, I saw |
| 22:57:28 | weepy | brixen: ta - but perhaps i didn't explain what i meant |
| 22:57:44 | brixen | weepy: fwiw, I'm working on something to give Hash characteristics (sets, gets, iterations, etc) and some benches |
| 22:58:40 | weepy | if you have N slots, cukoo is super fast etc as long as the number of entries is << than the number of slots |
| 22:58:48 | weepy | i.e. to avoid too many collisions |
| 22:59:01 | rue | Op, should probably try it with CXX set too. |
| 22:59:22 | rue | The structure knows its capacity and its occupancy? |
| 22:59:33 | weepy | what's the size of the number of slots ? |
| 23:01:00 | brixen | I don't understand that question |
| 23:01:28 | weepy | in the ruby Hash implementation => how many buckets are there ? |
| 23:01:42 | brixen | the current one? |
| 23:01:51 | weepy | yes and ur new one |
| 23:02:29 | brixen | 16 in the current one in a single table |
| 23:02:41 | brixen | in the cuckoo, there are currently 2 tables with min 8 slots |
| 23:02:56 | weepy | 16 ! |
| 23:03:09 | weepy | 2 ** 16 ? |
| 23:03:09 | brixen | no, just 16 |
| 23:03:21 | brixen | 16! would be a very big number |
| 23:03:32 | weepy | lol |
| 23:03:46 | weepy | that was just a plain surprise ! |
| 23:03:50 | brixen | um 16 as in 2**4 |
| 23:03:58 | brixen | that's the min size |
| 23:04:07 | brixen | btw, the code is publicly available :P |
| 23:04:16 | brixen | for the current one |
| 23:04:18 | weepy | o is it |
| 23:04:33 | weepy | ill have a gander :) |
| 23:04:46 | brixen | I can pastie you the cuckoo code if you want |
| 23:04:55 | weepy | ok koolio |
| 23:04:57 | brixen | it passes the specs but I'm not sure it will be faster yet |
| 23:05:06 | brixen | and it hasn't been optimized at all |
| 23:05:33 | weepy | u figured that it was important for Hash to be faster |
| 23:05:48 | weepy | I guess it really is used a great deal |
| 23:06:07 | brixen | well, we saw a lot of hash methods in the profile for running rails -h and rails bootup |
| 23:06:10 | brixen | http://gist.github.com/111957 |
| 23:06:21 | brixen | that file should be loaded after rbx boots |
| 23:07:23 | brixen | refresh the gist |
| 23:07:35 | weepy | ok done |
| 23:07:36 | brixen | if you put the bottom code in new_hash.rb you can do... |
| 23:08:00 | weepy | yes rails uses hash a great deal - esp for very small hashes |
| 23:08:02 | brixen | bin/mspec ci -r cuckoo -r new_hash core/hash |
| 23:08:27 | brixen | the current min size of 16 is based on previous profiling of hash sizes running specs |
| 23:08:51 | brixen | I'm working on a HashSpy that will tell me characteristics running specs, rdoc, and rails |
| 23:09:28 | weepy | HashSpy lol |
| 23:09:49 | weepy | sounds l ike a Narc :P |
| 23:10:12 | brixen | kinda :) |
| 23:10:17 | brixen | but more a spy |
| 23:10:24 | brixen | gathering sekrets |
| 23:11:25 | brixen | HaPK: any luck? need me to explain any mspec stuff? |
| 23:13:09 | HaPK | brixen: I was tracing the code from bin/mspec and found out that there are config[:profiles] and :xprofiles, and then noticed that you was referncing spec/custom/utils/script.rb, not mspec/.. |
| 23:13:17 | HaPK | brixen: why so ? |
| 23:14:22 | brixen | spec/custom/utils/script.rb is required by spec/default.mspec |
| 23:14:35 | brixen | which is loaded by mspec scripts for config options |
| 23:14:41 | HaPK | brixen: also, when I run "bin/mspec --help" I see options like "-P" or "-Pss" that are not part of mspec/lib/mspec/utils/option.rb |
| 23:14:56 | HaPK | brixen: oh, ok |
| 23:15:04 | brixen | yeah, something is really broken |
| 23:15:14 | brixen | not sure at what point it gets broken though |
| 23:15:28 | brixen | I'll pastie what bin/mspec run -h should be |
| 23:16:56 | brixen | HaPK: http://gist.github.com/111960 |
| 23:17:35 | brixen | maybe those will help you see an anomaly |
| 23:18:08 | HaPK | brixen: but I get the very different result |
| 23:18:11 | HaPK | pastie: help me |
| 23:18:24 | HaPK | ahh |
| 23:18:28 | HaPK | pastie: come on |
| 23:19:00 | pastie | http://pastie.org/478576 by HaPK. |
| 23:19:24 | HaPK | huh |
| 23:19:35 | HaPK | in fact it's rubinius' options |
| 23:19:55 | brixen | yeah, and it seems like loader is running the profiler |
| 23:20:11 | brixen | which would explain why you got the output *during* the spec runs |
| 23:20:22 | evan | wow thats bizarre. |
| 23:20:24 | brixen | the ProfilerAction will not output until the end of the main rnu |
| 23:20:27 | brixen | *run |
| 23:21:05 | brixen | HaPK: so, it could be exec in the bin/mspec file |
| 23:21:34 | brixen | HaPK: what do you get from ./vm/vm mspec/bin/mspec-run -h ? |
| 23:22:41 | HaPK | brixen: an exception: "Unknown errno : execvp() failed! (SystemCallError)" |
| 23:22:59 | brixen | HaPK: I'm wondering if something in ports is causing rbx to link wrong |
| 23:23:10 | brixen | HaPK: I'm assuming you do have ports installed |
| 23:23:24 | HaPK | brixen: yes, I have |
| 23:24:06 | HaPK | pastie: yo |
| 23:24:10 | brixen | this is what I have installed http://gist.github.com/111964 |
| 23:24:15 | dgtized | brixen: our hash keys are 32bits or 64bits? |
| 23:24:17 | pastie | http://pastie.org/478584 by HaPK. |
| 23:24:25 | dgtized | or rather architecture dependent right? |
| 23:24:34 | HaPK | brixen: here is what I have |
| 23:24:50 | brixen | HaPK: heh your ports list is bigger than mine AP |
| 23:24:54 | brixen | :P |
| 23:25:35 | HaPK | brixen: yeah, somewhat |
| 23:25:39 | brixen | HaPK: it's just a guess, but I think it could be something when rbx is linked.. |
| 23:25:48 | brixen | not sure how to trouble shoot that |
| 23:27:22 | brixen | HaPK: oh! it's probably darcs ... |
| 23:27:28 | brixen | kids |
| 23:27:30 | HaPK | huh ?!? |
| 23:27:34 | HaPK | =)) |
| 23:27:34 | brixen | heh |
| 23:27:46 | HaPK | brixen: I got used to darcs |
| 23:28:00 | HaPK | brixen: it's easy to use than git |
| 23:28:04 | HaPK | imo |
| 23:28:11 | evan | darcs is teh vacation time DVCS i hear |
| 23:28:20 | evan | ie, it so slow you get extra vacation! |
| 23:28:32 | brixen | well, after it melted a couple computers trying to get the Io repo a few years ago, I swore off it |
| 23:29:00 | HaPK | evan: well, haven't seen a performance comparision of git vs darcs2 |
| 23:29:08 | brixen | evan: any ideas on troubleshooting a possible link-time issue? |
| 23:29:21 | evan | whats the issue? |
| 23:29:27 | brixen | dunno |
| 23:29:42 | brixen | 15:22 HaPK >> brixen: an exception: "Unknown errno : execvp() failed! (SystemCallError)" |
| 23:30:00 | brixen | and for some reason, bin/mspec is not giving the expected behavior |
| 23:30:01 | evan | link time? |
| 23:30:11 | brixen | there's not many moving parts in that file |
| 23:30:22 | evan | what file |
| 23:30:27 | evan | i haven't been following |
| 23:30:28 | brixen | bin/mspec |
| 23:30:56 | brixen | looking at HaPK PATH, I see the opt dirs, which had me ask which ports are installed |
| 23:31:08 | brixen | this is his ports list http://pastie.org/478584 |
| 23:31:33 | HaPK | btw, I do not understand who is responsible for running mspec: in mspec/bin/mspec I see "#!/usr/bin/env ruby" and this is most definitely my MRI 1.8.6 |
| 23:31:53 | brixen | well, bin/mspec uses exec |
| 23:32:06 | evan | so exec is failing under rubinius or MRI? |
| 23:32:12 | brixen | which will run under MRI |
| 23:32:21 | HaPK | brixen, oh, ok |
| 23:32:29 | brixen | and in mspec/bin/mspec, MRI will exec rbx |
| 23:32:43 | brixen | when it runs mspec/bin/mspec-run or -ci etc |
| 23:33:19 | brixen | evan: http://pastie.org/478576 |
| 23:33:37 | HaPK | brixen: how come ? I see mspec/bin/mspec having the same MRI shebang and just requiring some modules and calling methods |
| 23:33:37 | evan | ok, yeah mega weird. |
| 23:33:50 | HaPK | brixen: when does rbx gets introduced ? |
| 23:35:12 | brixen | HaPK: mspec/lib/mspec/commands/mspec.rb |
| 23:35:38 | brixen | mspec is a script that gathers info and exec's a particular implementation to run the specs |
| 23:35:45 | brixen | could be rbx, mri, jruby, etc |
| 23:35:52 | brixen | based on the -t option |
| 23:36:07 | brixen | or the configuration file like spec/default.mspec |
| 23:36:08 | dgtized | brixen: on the subject of the cookoo hashing, do we know how that compares to Bagwell's HAMT's which are basically a hash table combined with a trie? |
| 23:36:33 | brixen | dgtized: I don't off hand |
| 23:36:41 | brixen | if there's a paper on it, I'll read it |
| 23:36:48 | slava | cuckoo hashing will be faster because its branchless |
| 23:36:51 | slava | traversing a trie is more work |
| 23:37:51 | dgtized | slava: except that you save on rehashing with the trie, so it depends on usage |
| 23:38:05 | dgtized | HAMT paper- http://lampwww.epfl.ch/papers/idealhashtrees.pdf |
| 23:38:19 | brixen | cool, thanks |
| 23:39:31 | dgtized | slava: basically it just starts out using say 4 MSB as the hash, when you get a collision you make a new trie node, and then use the next 4 bits to hash into the subtree |
| 23:39:58 | dgtized | when you hit a certain density you can rehash the top level hash with all it's children efficiently because they are all in the right place already |
| 23:40:22 | dgtized | ie you don't need to rehash the subtrees |
| 23:43:10 | dgtized | that said, you are correct it's definitely more branching then the flat table in cuckoo hash |
| 23:43:59 | HaPK | brixen: that's odd: I have added output of options that are passed to rbx when running mspec... They are "bin/rbx -v /full/path/to/mspec/bin/mspec-run -h" |
| 23:44:20 | brixen | that's the correct options |
| 23:44:33 | brixen | well... |
| 23:44:41 | HaPK | brixen: when I run it manually, I get normal help output, when run via mspec/bin/mspec run -h -- I see profiler output and rubinius' options |
| 23:44:53 | brixen | hm |
| 23:45:23 | brixen | what was the exact cmd in the first case? |
| 23:48:26 | HaPK | brixen: ruby -v mspec/bin/mspec run -h |
| 23:48:57 | brixen | HaPK: what do you get from: bin/rbx -v /full/path/to/mspec/bin/mspec-run -h + |
| 23:48:59 | brixen | ? |
| 23:49:37 | brixen | I am fearing it's nothing to do with rbx at all |
| 23:49:43 | HaPK | brixen: huh... the correct help output |
| 23:49:47 | brixen | yeah |
| 23:49:51 | brixen | it's your mri |
| 23:49:55 | brixen | I think |
| 23:50:04 | brixen | try to use the vanilla os x mri |
| 23:51:33 | HaPK | brixen: but I have vanilla mri from ports: "ruby @1.8.6-p114_0+darwin_9+thread_hooks (active)" |
| 23:51:54 | brixen | well, I think that is somehow the issue |
| 23:51:57 | brixen | not sure why |
| 23:55:51 | HaPK | trying to upgrade ruby to 1.8.7-p160 |
| 23:58:41 | evan | rad |
| 23:58:51 | evan | got the JIT doing a type specialization for Tuple#at |
| 23:59:06 | evan | that reduces a Array#each benchmark from 6.2s to 4.5s |
| 23:59:17 | dgtized | nice |
| 23:59:19 | evan | thats interpreter versus JIT |
| 23:59:23 | brixen | awesome |
| 23:59:56 | evan | doing the type specialization based on primitives is really nice and easy |