Show enters and exits. Hide enters and exits.
| 00:28:52 | boyscout | Expose the SystemExit to at_exit handlers. Fixes #395. - d6ce012 - Evan Phoenix |
| 00:28:52 | boyscout | Add String#secure_compare @x-api - d236fdc - Evan Phoenix |
| 00:41:10 | boyscout | CI: rubinius: d236fdc successful: 3500 files, 14306 examples, 42065 expectations, 0 failures, 0 errors |
| 00:47:29 | boyscout | Don't use self in a block that might be instance_evald. Fixes #399. - b3d1019 - Evan Phoenix |
| 00:52:10 | boyscout | Fix R::CompiledMethod#add_metadata to allow multiple keys - 349f609 - Tim Carey-Smith |
| 00:52:21 | boyscout | Fix the docs for enabling the profiler graph output - d8297e3 - Tim Carey-Smith |
| 00:55:19 | evan | tim's now on the board. |
| 00:55:28 | brixen | woot |
| 00:55:53 | boyscout | CI: rubinius: b3d1019 successful: 3500 files, 14306 examples, 42065 expectations, 0 failures, 0 errors |
| 01:08:35 | goyox86 | brixen: http://github.com/evanphx/rubinius/issues/issue/407 |
| 01:08:44 | evan | brixen: finally fixing the block arguments issue. |
| 01:09:16 | evan | goyox86: you're missing a spec |
| 01:09:27 | evan | if this is an unknown behavior |
| 01:10:39 | goyox86 | evan: i don't undertand i just fixed a existing failing spec |
| 01:10:47 | evan | ok |
| 01:10:51 | evan | thats what i was asking |
| 01:10:54 | evan | so you're fixing a tagged spec? |
| 01:11:03 | goyox86 | evan: yup |
| 01:11:09 | evan | k |
| 01:16:55 | brixen | goyox86: super |
| 01:17:04 | brixen | evan: you mean #398? |
| 01:17:16 | evan | yep. |
| 01:17:19 | brixen | sweet |
| 01:17:24 | evan | i dove into 1.8 to figure out what was up |
| 01:17:30 | evan | the check is basically |
| 01:17:49 | evan | if(not_a_lambda && args->len == 1) { args = args->ptr[0]; } |
| 01:17:58 | evan | we needed the not_a_lambda check. |
| 01:18:04 | brixen | ahh I see |
| 06:08:17 | jakedouglas | can someone help me with where the capi specs are |
| 06:12:58 | jakedouglas | nevermind |
| 07:09:49 | boyscout | File#truncate now raises an IOError if file is not opened for writing - 4dc5616 - Jose Narvaez |
| 07:09:49 | boyscout | Remove tag for now passing spec - 452da90 - Dirkjan Bussink |
| 07:18:11 | boyscout | CI: rubinius: 452da90 successful: 3500 files, 14307 examples, 42066 expectations, 0 failures, 0 errors |
| 07:23:00 | brixen | uh oh |
| 08:25:28 | dbussink | brixen: uh oh? |
| 08:34:13 | khaase | oh uh |
| 08:34:21 | khaase | also, jruby is faster |
| 08:34:33 | khaase | and ruby doesn't scale |
| 08:34:57 | khaase | you guys better start looking into Scala |
| 08:37:20 | dbussink | we need more erlang |
| 08:37:34 | dbussink | and store everything into cassandra |
| 08:37:35 | dbussink | or redis |
| 09:07:31 | rue | I hear NotevenNoSQL is the next best thing |
| 09:13:20 | khaase | only if it's faster than mongodb |
| 09:34:10 | dbussink | NoWaySQL it's faster |
| 14:16:36 | dbussink | cremes: you can't build rubinius while another version is active with rvm |
| 14:16:59 | dbussink | you can see it mixes up some stuff with your system ruby and the rvm one |
| 14:18:00 | dbussink | even if it compiles completely, if rvm is active a rbx version will pick up the GEM_PATH etc. so you'll get into problems anyway |
| 14:18:09 | dbussink | cremes: so i suggest using the default ruby during build time |
| 14:20:05 | cremes | dbussink: really? i thought rvm used ruby 1.87 to compile & install rbx |
| 14:20:34 | cremes | the rvm boys are on the case; hopefully they'll be able to get this all figured out and patched into rvm |
| 14:27:12 | dbussink | cremes: well, you can see in the gist it picks up another ruby version |
| 14:27:28 | dbussink | with which it compile the melbourne gem there |
| 14:27:36 | dbussink | and therefore it breaks with the 1.9 version |
| 14:27:50 | dbussink | cremes: but even if the building is fixed, you will get into runtime issues |
| 14:28:00 | dbussink | which are not fixable by definition actually... |
| 14:28:08 | dbussink | because rbx should honor GEM_PATH etc. |
| 14:29:39 | Sutto | dbussink: so during the build / install process for rbx it uses GEM_PATH / GEM_HOME? (that makes sense, just means I'll have to introduce a work around) |
| 14:30:06 | brixen | dbussink: this was the uh oh http://gist.github.com/475473 |
| 14:30:19 | dbussink | Sutto: well, it tries to build an extension for the ruby version that it's compiled with |
| 14:30:23 | brixen | dbussink: since it happened at the very end, I'm worried it was a finalizer |
| 14:30:39 | dbussink | Sutto: and from the gist cremes it shows it picked up the system ruby and not the active rvm version |
| 14:30:53 | dbussink | brixen: reproduceable then? |
| 14:31:18 | brixen | I dunno, my internets went out right after I wrote that |
| 14:31:24 | brixen | and I went to bed :P |
| 14:32:48 | Sutto | dbussink: oh? based off http://gist.github.com/474446 it was running configure + rake install inside the environment for ruby-1.8.7-p249 |
| 14:33:14 | Sutto | which would possibly explain it (in this case looking through it seems it's building fine etc but the actual rake install isn't overwriting the rbx file) |
| 14:33:21 | dbussink | Sutto: i think two things are being mixed up here |
| 14:33:36 | dbussink | i was talking about http://github.com/evanphx/rubinius/issues#issue/408 |
| 14:33:49 | dbussink | which is building rbx outside rvm, but with the active ruby being an rvm activated version |
| 14:34:18 | Sutto | ah, I hadn't seen that |
| 14:35:10 | Sutto | cremes: in that one, you need to do: rvm use system before building (that clears all the env vars etc) |
| 14:41:28 | cremes | got it |
| 14:42:05 | cremes | i'm the one who got the 2 issues confused |
| 14:42:28 | cremes | i thought dbussink was referring to the rvm rbx-head issue and not the git issue i opened earlier today |
| 14:42:36 | cremes | i'll close that one |
| 14:42:41 | dbussink | ok, cool :) |
| 14:42:55 | dbussink | btw, i've also seen that rbx install rbx-head doesn't rebuild properly |
| 14:43:02 | dbussink | the version isn't updated |
| 14:44:42 | Sutto | dbussink: yeh, that's the one I was having issues with - it seems it's setting it up correctly but not actually installing it |
| 15:34:36 | brixen | dbussink: http://gist.github.com/475580 |
| 15:34:59 | brixen | dbussink: I may have an opt too, but I'm going for simple and correct first |
| 15:35:39 | dbussink | brixen: pretty impressive :) |
| 15:35:52 | brixen | well, it's just C++, it better be as fast :P |
| 15:36:04 | dbussink | brixen: friend of mine has some stuff that does packing, i can check what he uses |
| 15:36:09 | dbussink | writing png files |
| 15:36:35 | brixen | mri actually mutates the value for endianness before catting to a string |
| 15:36:52 | brixen | I push back each byte on a C++ str and create the ruby string at the end |
| 15:37:09 | brixen | which makes it extremely obvious and simple what is happening |
| 15:37:25 | brixen | but I'll look at that method once everything is working |
| 15:38:38 | evan | hi guys |
| 15:38:59 | brixen | morning evan |
| 15:39:04 | brixen | hbd to abby! |
| 15:39:08 | evan | brixen: pack is looking awesome! |
| 15:39:13 | evan | brixen: :D |
| 15:39:20 | evan | she just headed out |
| 15:39:24 | evan | she'll see your tweet. |
| 15:39:24 | brixen | it's coming along |
| 15:39:28 | brixen | heh, cool |
| 15:39:44 | brixen | evan: so, got this on one spec run http://gist.github.com/475473 |
| 15:39:48 | brixen | can't repro it |
| 15:40:02 | brixen | but the fact it happened at the very end made me suspect finalizers |
| 15:40:25 | evan | possible, yes. |
| 15:40:39 | evan | i'll keep an eye out. |
| 15:40:42 | brixen | k |
| 15:40:50 | evan | i've fixed the return inside EM bug |
| 15:41:04 | evan | though, EM raises an exception about an error now |
| 15:41:08 | evan | so i'm tracking that down. |
| 15:41:12 | jakedouglas | yo |
| 15:41:28 | brixen | sup jakedouglas |
| 15:42:12 | jakedouglas | heh i decided i would finally write that spec so i checked out rubinius last night. im a little confused about the spec though |
| 15:43:54 | jakedouglas | i was looking at last night before bed. let me look at it again and see if i can come up with an intelligible question. |
| 15:44:25 | dbussink | brixen: hmm, friend of mine creates dynamic pack patterns like xNXNX... etc |
| 15:44:36 | dbussink | brixen: for extracting stuff from a png file |
| 15:44:48 | dbussink | i have no idea how well that would work with your changes :P |
| 15:45:01 | dbussink | jakedouglas: which spec? |
| 15:45:08 | jakedouglas | rb_rescue spec |
| 15:45:11 | evan | dbussink: it will work fine |
| 15:45:28 | evan | dbussink: but feel free to get a crazy pattern from your friend and we'll bench it. |
| 15:45:33 | jakedouglas | i remember the problem now. im just trying to see the best way to solve |
| 15:46:14 | jakedouglas | ok so |
| 15:47:01 | brixen | dbussink: it won't yet, because I haven't done xX so the prim will fail |
| 15:47:09 | brixen | dbussink: but I was planning on doing xX today :) |
| 15:47:10 | evan | i'm going to go jump in the shower |
| 15:47:11 | evan | bbiab. |
| 15:47:27 | dbussink | brixen: ah ok, cool :) |
| 15:47:32 | jakedouglas | the rb_rescue spec doesn't cover that the caught exception should be passed to the raise func in addition to the user supplied arg. |
| 15:47:35 | dbussink | he has some benchmarks too, so i can run those then |
| 15:47:46 | brixen | dbussink: sounds good |
| 15:49:32 | jakedouglas | does sometime have time to look at it with me and find a good solution? |
| 15:51:04 | jakedouglas | well. maybe i can do it. |
| 15:51:10 | jakedouglas | i believe in myself |
| 15:51:21 | brixen | jakedouglas: that's the spirit! |
| 15:51:26 | brixen | I believe in you too |
| 15:51:52 | jakedouglas | gee, thanks :) |
| 15:52:28 | brixen | we're always here for moral support! |
| 15:53:29 | cremes | brixen: your pack benches are looking incredible |
| 15:54:02 | brixen | aww shucks guys, it's just some C++ :) |
| 15:54:28 | brixen | cremes: I just pushed that code to rapa |
| 15:55:05 | brixen | cremes: I'm going to work on some string ones today, and @xX |
| 15:55:16 | cremes | i see that... i am still working on E |
| 15:55:38 | cremes | i'll use your latest push to fill in some of my knowledge gaps on some ragel issues |
| 15:55:55 | brixen | cremes: so, here's what I try to do: at the action level, keep things super simple, at the bottom, keep things super simple, the complexity is parameterized in the middle |
| 15:56:23 | brixen | rationale: I want to say, "what does 'Q' do" and have a simple answer at the action |
| 15:56:35 | brixen | and I want the lowest level stuff to be clear and maintainable |
| 15:56:52 | brixen | looking at MRI pack code gets me rather cross-eyed pretty quickly |
| 15:57:00 | cremes | right... me too |
| 15:57:28 | cremes | it's that complex middle that i was having uber-trouble with but now you've shown me the way :) |
| 15:57:53 | brixen | also, I adjusted the ragel output from G2 to G1 because pack.cpp was 5kloc and taking 30sec to compile |
| 15:58:03 | brixen | G1 appears to be as fast so far |
| 15:58:13 | brixen | but we can tweak these things once it's all in |
| 15:58:20 | cremes | yeah, the machine types are something to check when it's all done |
| 16:00:04 | cremes | brixen: for E, i think i'll probably need a CONVERT_TO_DOUBLE macro in the style you've shown |
| 16:00:06 | cremes | we'll see |
| 16:01:14 | brixen | cremes: sure, play with it and see what works |
| 16:01:25 | cremes | roger |
| 16:01:53 | brixen | my whole reason for this approach is that the code is quite declarative |
| 16:02:00 | brixen | rather than a nest of conditionals |
| 16:02:12 | brixen | so use what makes it clear |
| 16:02:50 | brixen | evan: :/ http://gist.github.com/475614 |
| 16:03:32 | brixen | evan: that's an ubuntu 9.10 64bit vbox |
| 16:07:22 | cremes | brixen: how do i get my local rbx to pick up the new pack.cpp and unpack.cpp files after i generate them in the vm directory? |
| 16:07:29 | cremes | do i run rake again in my rbx dir? |
| 16:07:33 | brixen | yeah |
| 16:07:37 | cremes | k |
| 16:07:37 | brixen | rake build or rake |
| 16:11:40 | brixen | evan: and on elle http://gist.github.com/475623 |
| 16:13:15 | boyscout | Added configure check for endianness. - 79a2076 - Brian Ford |
| 16:13:15 | boyscout | Added configure check for sizeof(long). - f29f8fd - Brian Ford |
| 16:13:15 | boyscout | Added Bignum::verify_size. - 9a720a5 - Brian Ford |
| 16:13:15 | boyscout | Array#pack directives SsIiLlNnQqVv. - b7d7f9b - Brian Ford |
| 16:13:15 | boyscout | Added benchmark for pack with SILNQV. - 9686951 - Brian Ford |
| 16:16:05 | cremes | anyone else having trouble cloning rubyspec? http://gist.github.com/475633 |
| 16:16:54 | brixen | hmm |
| 16:17:56 | brixen | cremes: I just cloned it fine |
| 16:18:14 | brixen | cremes: I used git://github.com |
| 16:24:07 | cremes | using git://github worked |
| 16:24:37 | brixen | cool |
| 16:25:33 | boyscout | CI: rubinius: 9686951 successful: 3500 files, 14307 examples, 42066 expectations, 0 failures, 0 errors |
| 16:56:24 | evan | brixen: question |
| 16:56:34 | evan | lambda { }.should_not raise_error(Blah) |
| 16:56:49 | evan | doesn't fail if the block happens to raise a different exception |
| 16:56:54 | evan | and it swallows that exception silently |
| 16:56:58 | evan | shouldn't it reraise it? |
| 16:57:21 | evan | so that mspec can see an exception bubbled out and the exception has an error |
| 16:57:34 | evan | spent 10 minutes wondering why my code wasn't failing |
| 16:57:40 | evan | it was because i had an NoMethodError |
| 16:57:46 | evan | but raise_error ate it. |
| 17:03:46 | brixen | hm, yeah it should let it bubble out |
| 17:04:50 | brixen | actually, I thought it did |
| 17:05:04 | evan | doesn't appear to |
| 17:05:07 | evan | i'll check the code. |
| 17:05:10 | brixen | evan: marcandre just patched this |
| 17:05:13 | brixen | le'me look |
| 17:05:22 | brixen | evan: are you on head? |
| 17:05:28 | evan | should be |
| 17:05:32 | brixen | hm |
| 17:05:34 | evan | so yeah |
| 17:05:38 | evan | it doesn't reraise it |
| 17:05:50 | evan | matches? in raise_error.rb swallows all Exceptions |
| 17:06:02 | evan | and just returns false if the thing being raised wasn't the matching exception |
| 17:06:12 | evan | it should probably reraise |
| 17:08:18 | brixen | hm, rspec appears to swallow it too |
| 17:08:23 | brixen | that's probably why I did |
| 17:08:48 | evan | it's easy to get false positives |
| 17:08:53 | evan | is my issue |
| 17:09:07 | brixen | well, why is it using should_not raise_error() ? |
| 17:09:17 | evan | it's like answering "nope, the phone didn't ring, but the earth was destroyed. thats fine, right?" |
| 17:09:23 | brixen | heh, yep |
| 17:09:33 | brixen | can I see the spec? |
| 17:09:39 | evan | i'm about to commit it. |
| 17:10:40 | brixen | if you use raise_error() with no class, you get the exception that was raised |
| 17:10:47 | brixen | I think the behavior is correct |
| 17:11:22 | brixen | should_not raise_error(ThePhoneRangError) should be silent about TheEarthWasDestroyedError |
| 17:11:24 | evan | perhaps it's because I used it with should_not? |
| 17:11:28 | brixen | no |
| 17:11:35 | evan | really? why silent about that? |
| 17:11:41 | brixen | did you give raise_error() an exception class? |
| 17:11:47 | evan | yeah |
| 17:11:50 | brixen | why? |
| 17:11:50 | evan | LocalJumpError |
| 17:12:05 | evan | because it seemed right to be specific |
| 17:12:14 | brixen | so, that's saying no LocalJumpErrors here, but anything else is ok |
| 17:12:29 | evan | ok |
| 17:12:31 | evan | thats fine |
| 17:12:31 | brixen | should_not raise_error() will fail if any error is raised |
| 17:12:38 | evan | I end up writing the spec |
| 17:12:45 | evan | then putting the lambda {}.should_not around it |
| 17:12:55 | brixen | yeah, that happens a lot |
| 17:12:57 | evan | so that I can see i'm writing the spec properly |
| 17:13:11 | evan | since i screwed up to begin with |
| 17:13:21 | evan | but the .should_not raise_error didn't let me see that. |
| 17:13:25 | brixen | I prefer the ScratchPad annotated flow on these |
| 17:13:45 | evan | rather than checking for LocalJumpError? |
| 17:13:49 | evan | yeah, thats probably a better way. |
| 17:14:09 | marcandre | brixen: hi! I remember only changing the error message, not the logic behind the matcher. Or did I? |
| 17:14:21 | brixen | marcandre: nope, you're fine |
| 17:14:28 | brixen | marcandre: it was just jogging my memory |
| 17:14:37 | brixen | cus I just sync'd mspec in rubinius |
| 17:14:43 | marcandre | k. |
| 17:14:51 | evan | i wasn't saying it was wrong |
| 17:14:56 | evan | just curious about the semantics |
| 17:14:58 | evan | and the thinking. |
| 17:15:51 | brixen | it is subtle |
| 17:16:19 | brixen | honestly, I think I'd have a fit if someone wrote a spec that allowed execeptions *except* for a certain one |
| 17:16:26 | brixen | I don't see the use case |
| 17:16:34 | brixen | maybe someone can enlighten me :) |
| 17:16:42 | evan | well, thats part of the issue |
| 17:16:58 | evan | these specs will pass if any other exception is raised |
| 17:17:09 | evan | which seems like a false positive |
| 17:17:15 | marcandre | evan: FWIW, I'm surprised too that it swallows other exceptions, not sure that's the way it should be. I'd be curious to run the full specs without swallowing and see if any spec is badly written. |
| 17:17:20 | brixen | well, raise_error() does not allow that |
| 17:17:35 | brixen | but again, this is an rspec semantic |
| 17:17:40 | evan | right |
| 17:17:43 | brixen | and I would bet money someone uses that |
| 17:17:47 | evan | I can see arguments both ways |
| 17:17:49 | brixen | I hope I never work with their code |
| 17:18:37 | brixen | marcandre: just grep for should_not raise_error([^)]+) |
| 17:19:38 | dbussink | thunderstorm time! |
| 17:19:46 | cremes | brixen: ready to cry uncle on pack 'E' |
| 17:20:09 | evan | brixen: i'm changing my spec to use the ScratchPad method |
| 17:20:15 | cremes | after chasing this rabbit down the hole, it looks like it needs some ruby primitive support |
| 17:20:18 | evan | ScratchPad.record erases whatever is there, yes? |
| 17:20:34 | cremes | something like a :to_float (for 'e') and :to_double (for 'E') |
| 17:21:14 | cremes | and then all of the Float.to_packed stuff will need to get ripped out (only used by pack) |
| 17:21:36 | brixen | evan: yes |
| 17:21:37 | cremes | i'm afraid its a bit beyond me :( |
| 17:22:01 | cremes | sorry to heap more work on your plate... i was hoping to take some off |
| 17:22:05 | boyscout | Handle block arguments to a lambda specially. Fixes #398. - b359b73 - Evan Phoenix |
| 17:22:05 | boyscout | Handle #inspect calling #to_s in the right cases. Fixes #405 - 440d929 - Evan Phoenix |
| 17:22:05 | boyscout | Deal with Fixnum and Symbol speciallize in #methods. Fixes #403 - a51a739 - Evan Phoenix |
| 17:22:05 | boyscout | Add spec for long-return-from-saved-block case - 98ebf2a - Evan Phoenix |
| 17:22:05 | boyscout | Test the proper scope when determining if long return is possible - 5fefabc - Evan Phoenix |
| 17:22:05 | brixen | cremes: well, do you have good specs? |
| 17:22:22 | brixen | cremes: le'me take a look at it |
| 17:22:33 | cremes | i have the hole in the donut |
| 17:22:38 | brixen | cremes: sometimes it takes a bit to gel, hence why I work on a chunk at a time |
| 17:22:44 | brixen | cremes: haha |
| 17:23:16 | evan | cremes: so, your cremes account on github has commit privs |
| 17:23:24 | evan | do you want chuckremes to have privs as well? |
| 17:23:28 | cremes | no need for you to look at it now if you have other things cooking; i can get lunch and jump back to my dayjob |
| 17:23:29 | evan | i only see you using cremes |
| 17:23:58 | cremes | evan: yes, please... i accidentally created 2 github accounts... i really only use the chuckremes one |
| 17:24:06 | evan | k |
| 17:24:34 | evan | ok, i removed cremes |
| 17:24:37 | evan | and added chuckremes |
| 17:24:42 | cremes | coolio |
| 17:25:03 | brixen | cremes: I'm working on some specs atm, I'll take a stab at fixing the 'E' specs then look at it |
| 17:25:18 | cremes | brixen: okay, time for lunch |
| 17:25:22 | brixen | k |
| 17:25:33 | evan | if we're doing pack in a primitive |
| 17:25:35 | brixen | evan: did you see my gists? |
| 17:25:37 | evan | there is no need for more Float stuff |
| 17:25:44 | brixen | evan: yeah |
| 17:25:51 | evan | the primitive can cast the double to a float and cast that to a C* |
| 17:25:58 | brixen | yep |
| 17:25:58 | evan | since i think the format is IEEE? |
| 17:26:09 | evan | which gist? |
| 17:26:32 | cremes | i was looking to mimic the pack::int stuff which calls :pack_to_int |
| 17:26:43 | brixen | http://gist.github.com/475614 |
| 17:26:49 | cremes | by doing a pack::float to call :pack_to_float and the same for double |
| 17:27:08 | evan | brixen: ug. |
| 17:27:09 | evan | *shrug* |
| 17:27:10 | cremes | perhaps i was going in the wrong direction. |
| 17:27:13 | brixen | cremes: you mean to coerce, yeah |
| 17:27:18 | cremes | exactly |
| 17:27:24 | brixen | yeah, we'll need that |
| 17:27:30 | brixen | but what you get back is a Float |
| 17:27:35 | brixen | which just has a double in it |
| 17:27:41 | brixen | that's what you pack |
| 17:28:05 | evan | brixen: the .rl files are only in rapa, right? |
| 17:28:10 | brixen | #pack_to_float isn't a primitive, it's just rubyland call to the coerce logic |
| 17:28:14 | brixen | evan: yeah |
| 17:28:27 | cremes | okay, but pack_to_float doesn't exist yet |
| 17:28:47 | brixen | cremes: right |
| 17:28:54 | brixen | evan: this is what I get in os x http://gist.github.com/475712 |
| 17:29:04 | evan | are you only calling pack::integer when the thing isn't already an Integer? |
| 17:29:13 | brixen | yes |
| 17:29:14 | evan | ie, are you using kind_of<Integer> first? |
| 17:29:24 | evan | ok |
| 17:29:27 | cremes | that's why i'm saying its beyond my capability right now... it seems to touch on a lot of other internal rbx stuff with which i have no familiarity |
| 17:29:41 | evan | cremes: not really. |
| 17:29:57 | cremes | no? |
| 17:29:58 | evan | pack_to_float is just a ruby method you writing that calls FloatValue and checks the thing is a Float |
| 17:30:05 | evan | it's not rubinius internals at all. |
| 17:30:36 | cremes | hmmmm, all right |
| 17:30:37 | evan | brixen: are you getting this malloc stuff everytime? |
| 17:31:14 | brixen | evan: I'm running again now |
| 17:31:19 | evan | k |
| 17:31:22 | brixen | seem to, yes |
| 17:31:48 | brixen | but not always the same number of errors |
| 17:31:55 | brixen | I'll try in gdb |
| 17:32:40 | boyscout | CI: rubinius: 6a04993 successful: 3500 files, 14308 examples, 42068 expectations, 0 failures, 0 errors |
| 17:33:35 | evan | yah |
| 17:33:36 | evan | please do. |
| 17:37:41 | brixen | evan: http://github.com/brixen/rapa/blob/master/actions/rubinius/pack_code.rl#L48-59 |
| 17:37:51 | evan | yep |
| 17:37:53 | evan | i was going through there |
| 17:37:53 | brixen | evan: you want to check I'm not doing anything bad GC-wise |
| 17:38:02 | evan | you've got quite the macro soup! |
| 17:39:01 | evan | seems fine |
| 17:39:20 | evan | so long as you don't access a Bignum on both sides of a call to coerce |
| 17:39:22 | evan | it doesn't appear you do. |
| 17:39:33 | brixen | hmm, bad connection |
| 17:40:11 | brixen | yeah, the coerce call is the only place calling back into Ruby |
| 17:40:34 | evan | and it appears that self is the only thing on both sides of that |
| 17:40:37 | brixen | and teh new ref is assigned and used |
| 17:40:38 | evan | which is protected with OnStack<> |
| 17:40:44 | brixen | yeah |
| 17:40:58 | brixen | at least, that's the way I planned it :) |
| 17:41:23 | evan | :) |
| 17:41:39 | jakedouglas | how do i diagnose the spec run spontaneously terminating |
| 17:41:56 | brixen | jakedouglas: run under gdb |
| 17:42:34 | brixen | something like gdb --args vm/vm mspec/bin/mspec-ci <path/to/specs> |
| 17:42:42 | jakedouglas | ok |
| 17:43:33 | jakedouglas | Program received signal SIGTRAP, Trace/breakpoint trap. |
| 17:43:33 | jakedouglas | 0x00007fff5fc01028 in __dyld__dyld_start () |
| 17:44:38 | evan | :/ |
| 17:44:42 | evan | continue past that. |
| 17:44:58 | brixen | evan: http://gist.github.com/475734 |
| 17:44:59 | evan | bin/mspec --gdb is the better way |
| 17:45:00 | evan | btw. |
| 17:45:10 | brixen | I'm in run_all_finalizers, what should I poke? |
| 17:45:24 | evan | well |
| 17:45:30 | jakedouglas | i just get assloads of failures when i continue |
| 17:45:59 | jakedouglas | (or when i run bin/mspec --gdb) |
| 17:46:00 | evan | brixen: you should probably build objectmemory.cpp and builtin/data.cpp in DEV=1 mode |
| 17:46:08 | evan | because we can't see what finalizer is actually calling free. |
| 17:46:17 | evan | this might be related to the -1 change. |
| 17:46:19 | brixen | k |
| 17:46:22 | evan | is my guess. |
| 17:46:25 | brixen | hm |
| 17:46:50 | evan | jakedouglas: umm.. |
| 17:46:53 | evan | i'm not sure. |
| 17:46:59 | jakedouglas | i did find my problem, though, by only running the 1 spec i needed |
| 17:47:07 | jakedouglas | unclear why it was exploding trying to run all of them |
| 17:47:09 | evan | thats what we meante |
| 17:47:14 | evan | meant |
| 17:47:16 | evan | i dunno. |
| 17:47:21 | jakedouglas | oh. heh. i just tried running them all for fun first |
| 17:47:26 | evan | no no |
| 17:47:31 | evan | just the one. |
| 17:47:34 | jakedouglas | got it :) |
| 17:47:44 | evan | otherwise you'll get all the Process specs and such |
| 17:47:51 | evan | which are a real pain to run under gdb |
| 17:48:03 | evan | which might have been the source of your "assload" of failures. |
| 17:48:11 | jakedouglas | k |
| 17:49:58 | brixen | I think I need to fix bin/mspec --gdb |
| 17:50:13 | brixen | it does not do the same thing as gdb --args ... |
| 17:50:32 | brixen | and all the argf specs fail while running |
| 17:51:57 | evan | i only use it strictively |
| 17:52:00 | evan | restrictively |
| 17:52:00 | evan | rather. |
| 17:55:12 | brixen | that's reasonable |
| 17:55:21 | brixen | in this case, I want it all to run |
| 17:55:41 | brixen | evan: so, what am I looking for in the finalizer code? |
| 17:57:04 | evan | let it run and crash again |
| 17:57:06 | evan | get a new bt |
| 17:58:22 | brixen | bt is essentially the same |
| 17:59:19 | brixen | hm, trying to use rp causes more exceptions |
| 18:00:27 | evan | it shouldn't be |
| 18:00:39 | evan | did you recompile with DEV=1 for tohse files? |
| 18:01:12 | evan | maybe try all with DEV=1 |
| 18:01:22 | evan | we need to know which finalizer is being called |
| 18:01:31 | evan | from line 642 of objectmemory.cpp |
| 18:01:41 | brixen | yeah, DEV=1 for those files |
| 18:01:57 | jakedouglas | could someone review this please http://gist.github.com/475761 |
| 18:02:27 | brixen | rp fi.object uses a std::string and causes another malloc error |
| 18:03:29 | evan | you want to |
| 18:03:31 | evan | p fi.finalizer. |
| 18:05:03 | brixen | rubinius::Pointer::finalize |
| 18:05:48 | evan | ok |
| 18:05:59 | evan | i think i've seen this |
| 18:06:02 | evan | for now |
| 18:06:11 | evan | go ahead and comment out running finalizers on shutdown |
| 18:06:14 | evan | thats new code anyway |
| 18:07:50 | evan | for some reason, we're free'ing some FFI Pointers twice. |
| 18:13:28 | brixen | evan: did you want me to commit that? |
| 18:13:33 | evan | sure |
| 18:13:36 | brixen | ok |
| 18:13:36 | evan | no harm for now. |
| 18:13:43 | evan | finalizers on shutdown is a nicity only. |
| 18:23:25 | boyscout | Disallow platform size modifier for pack NnQqVv. - e8174a5 - Brian Ford |
| 18:23:25 | boyscout | Temporarily disable running finalizers at exit. - 61502e1 - Brian Ford |
| 18:31:58 | boyscout | CI: rubinius: 61502e1 successful: 3500 files, 14320 examples, 42080 expectations, 0 failures, 0 errors |
| 18:34:25 | jakedouglas | what should I do with my patch? can i just commit it or should i post it to the issue tracker? i understand you might not have time to review it right now |
| 18:34:44 | brixen | hm |
| 18:34:48 | brixen | looks |
| 18:34:57 | brixen | jakedouglas: sorry, got distracted |
| 18:35:01 | jakedouglas | np |
| 18:35:16 | jakedouglas | also, are the capi specs part of rubyspec? does it need to be committed to rubyspec or can i just commit it to the rbx repo? |
| 18:37:05 | brixen | they are part of rubyspec, yes, but I sync them over |
| 18:37:09 | brixen | so you can just commit to rbx |
| 18:37:44 | jakedouglas | ok. someone yanked my commit bit on rubyspec sometime after you added it a long time ago. i dont care thoiugh, ill just commit to rbx |
| 18:38:04 | evan | jakedouglas: we pruned the bits at some point, yeah. |
| 18:38:13 | evan | spring cleaning. |
| 18:38:20 | jakedouglas | word |
| 18:38:28 | brixen | jakedouglas: I prune the rubyspec commit bits so I can stay on top of what is being committed |
| 18:38:43 | brixen | jakedouglas: I'll gladly add you back |
| 18:38:50 | jakedouglas | dont bother for now |
| 18:38:54 | brixen | k |
| 18:39:39 | jakedouglas | does the patch look ok? |
| 18:39:52 | brixen | jakedouglas: in the kernel_specs_call_proc_... why not just pass the two args directly? |
| 18:40:04 | brixen | rather than in an array, then pull them out, etc |
| 18:40:44 | brixen | ie (VALUE proc, VALUE arg, VALUE raised_exc) |
| 18:41:23 | jakedouglas | well |
| 18:41:28 | jakedouglas | then i would need more procs |
| 18:41:51 | jakedouglas | one that took 1 arg, one that took 2 args and returned arg1, and another that took 2 args and returned arg2 |
| 18:42:15 | brixen | hm |
| 18:42:15 | jakedouglas | oh |
| 18:42:17 | jakedouglas | i see what you mean |
| 18:42:31 | jakedouglas | sorry i misunderstood |
| 18:42:38 | brixen | that's ok, so did I :) |
| 18:42:48 | brixen | sees lots of head scratching |
| 18:42:52 | jakedouglas | you're talking about the arguments to kernel_spec_call_proc_with_raised_exc |
| 18:42:55 | brixen | yeah |
| 18:43:10 | jakedouglas | because thats what gets called by rb_rescue when it 'rescues' |
| 18:43:16 | jakedouglas | so it can only take 1 user supplied argument |
| 18:43:20 | brixen | ok |
| 18:43:34 | brixen | it is all rather convoluted, thanks MRI! |
| 18:43:43 | jakedouglas | indeed |
| 18:44:26 | brixen | ok, I see |
| 18:44:28 | jarib | some Process specs failing for me on linux http://gist.github.com/475838 |
| 18:44:46 | brixen | jarib: please try rake distclean |
| 18:44:50 | jarib | k |
| 18:44:58 | brixen | jakedouglas: looks ok to me |
| 18:45:08 | jakedouglas | ok |
| 18:45:52 | jakedouglas | the issue was just that the spec wasn't checking for the rescued exception getting passed to the raise func as the second arg |
| 18:46:12 | jakedouglas | also the other specs were a little off as far as what was being tested imo |
| 18:46:17 | jakedouglas | so i 'improved' them |
| 18:47:46 | brixen | cool |
| 18:48:04 | jakedouglas | ill commit it. thanks for checking. |
| 18:48:41 | brixen | ok, thanks for fixing it! |
| 18:48:56 | jakedouglas | heh. my spec conscience is now clear. |
| 18:51:07 | boyscout | Improve capi specs for rb_rescue - 9191de6 - Jake Douglas |
| 18:51:14 | jakedouglas | you guys going to jvm langs? |
| 18:51:32 | evan | nope |
| 18:51:45 | brixen | jakedouglas: i'll be at oscon/emerging langs |
| 18:52:15 | jakedouglas | cool. i wont make it down to oscon :( |
| 18:52:22 | brixen | bummer |
| 18:53:06 | jakedouglas | any low-hanging fruit in the rubinius world? |
| 18:53:36 | brixen | hmm, yes |
| 18:53:44 | brixen | now, if we only knew what it was :) |
| 18:53:47 | jakedouglas | :) |
| 18:53:51 | brixen | run your code |
| 18:53:54 | brixen | profile your code |
| 18:53:57 | brixen | benchmark your code |
| 18:54:04 | brixen | cuddle with your code :) |
| 18:55:05 | brixen | since we don't get out much, other people's code is the best data for us |
| 18:55:31 | jakedouglas | true |
| 18:55:54 | evan | brixen: i've hit upon a flaw with my debugging strategy. |
| 18:56:10 | brixen | oh? |
| 18:56:24 | evan | you can't set breakpoints in methods that are currently running and get those breakpoints |
| 18:56:35 | evan | you can get them in the method is run again after you set it |
| 18:56:49 | evan | but because the method is already running, and not using the debugging interpreter, it doesn't see the breakpoints. |
| 18:56:52 | brixen | ahh hm |
| 18:56:56 | brixen | yeah |
| 18:57:19 | evan | i've got an idea to solve it, but it requires putting some code in the fast path |
| 18:57:39 | evan | can't think of a way to do it otherwise |
| 18:57:53 | evan | basically, after a send returns, we'd have to do |
| 18:57:59 | evan | if(vmm->debugging) { ... } |
| 18:58:07 | evan | it would be just a flag, so it should be ok. |
| 18:58:24 | evan | then i'll have a debugging interpreter like the uncommon interpreter |
| 18:58:35 | evan | that can start where another interpreter left off |
| 18:58:37 | evan | so |
| 18:59:06 | evan | if(vmm->debugging) { return VMMethod::continue_debugging(state, call_frame, ...); } |
| 18:59:06 | jakedouglas | tries to load the big rails app with rbx |
| 18:59:33 | brixen | makes sense |
| 18:59:41 | boyscout | CI: rubinius: 9191de6 successful: 3500 files, 14322 examples, 42084 expectations, 0 failures, 0 errors |
| 18:59:51 | brixen | jakedouglas: make sure the fire extinguishers are nearby :) |
| 19:00:02 | jakedouglas | indeed |
| 19:00:14 | jakedouglas | i tried it a little while back and ran into something funky right away. let me see what happens. |
| 19:00:56 | jarib | brixen: thanks, distclean worked. why is that? |
| 19:01:16 | brixen | jarib: I'm thinking something in libtommath |
| 19:01:23 | brixen | but I don't know exactly |
| 19:01:31 | jarib | ok |
| 19:02:02 | brixen | oh wait, no |
| 19:02:04 | brixen | libffi |
| 19:02:19 | brixen | the external libs are not rebuilt properly |
| 19:02:29 | brixen | which we will fix with the new build system |
| 19:03:07 | brixen | jarib: git show 74c1dce5 |
| 19:03:44 | jarib | ah, i see |
| 19:18:52 | jakedouglas | is there anywhere listing gem compatibility with rbx? |
| 19:19:02 | brixen | not yet |
| 19:19:26 | brixen | but we fervently hope someone will start a website :) |
| 19:19:30 | jakedouglas | well |
| 19:20:35 | jakedouglas | whoever had the idea to start isitjruby was very silly to go and build another impl-specific site instead of making a generic one |
| 19:21:32 | brixen | isitjruby.com runs on joyent |
| 19:21:35 | brixen | that was the first mistake |
| 19:21:39 | jakedouglas | do you guys get many complains that C gems fail to build because the build flags are different than they would be with MRI? |
| 19:21:45 | jakedouglas | that seems to be the cause of my current failure |
| 19:21:53 | brixen | hm, haven't seen that, no |
| 19:22:06 | jakedouglas | json 1.1.9 |
| 19:22:15 | brixen | our rbconfig.rb is hand crafted |
| 19:22:23 | jakedouglas | oh |
| 19:22:24 | brixen | rather than slurped in from autoconf |
| 19:22:30 | brixen | so we probably have holes |
| 19:22:42 | jakedouglas | http://gist.github.com/475900 |
| 19:23:08 | brixen | jakedouglas: do you know any of the brightbox guys? maybe they would run isitrubinius |
| 19:23:25 | jakedouglas | never heard of brightbox until now. |
| 19:23:54 | jakedouglas | i dont support isit<someimpl>. it should just be built into gemcutter or something |
| 19:24:12 | jakedouglas | so i dont have to go to a different website to look at stuff |
| 19:24:21 | jakedouglas | and so people dont have to maintain N sites |
| 19:24:32 | brixen | yeah |
| 19:24:38 | evan | json is it's own screwup |
| 19:24:47 | evan | they're build setup is wrong |
| 19:24:54 | evan | use github.com/evanphx/json |
| 19:25:09 | brixen | man, the situation with json is just agonizing |
| 19:25:19 | brixen | way to release a popular gem and then disappear |
| 19:25:25 | evan | the maintainer is basically gone. |
| 19:25:28 | brixen | yeah |
| 19:25:39 | jakedouglas | i see |
| 19:25:45 | brixen | it hits everyone with a rails app |
| 19:25:59 | brixen | well, in the past 2 years, since JSON became the new YAML |
| 19:26:32 | brixen | evan: hurry, start a new representation meme and release a gem! |
| 19:26:41 | brixen | everyone will upgrade their rails apps to use it instead of json |
| 19:27:21 | evan | i've sent a plee to twitter about flori |
| 19:27:26 | evan | we'll see if that helps. |
| 19:30:17 | evan | brixen: hahahah |
| 19:30:26 | evan | my if(vmm->debugging) thing worked first time. |
| 19:30:27 | evan | love it. |
| 19:30:31 | evan | i've earned lunch! |
| 19:30:33 | evan | and a movie! |
| 19:30:35 | evan | bbiab. |
| 19:34:26 | brixen | woot! |
| 19:40:39 | jakedouglas | why would i get these instruction output during runtime unless its crashing |
| 19:41:01 | jakedouglas | 0: passed_arg 1, 2: goto_if_true 10, etc |
| 19:41:33 | jakedouglas | (it appeared to continue running after displaying this) |
| 19:42:45 | brixen | jakedouglas: what is that? |
| 19:43:00 | jakedouglas | its rbx spewing at me :p |
| 19:43:03 | brixen | are you installing a gem? |
| 19:43:06 | jakedouglas | yes |
| 19:43:10 | brixen | I know what the output is |
| 19:43:17 | brixen | what gem? |
| 19:43:40 | brixen | has a hunch |
| 19:44:12 | jakedouglas | i attempted to use a newer version of the json gem to avoid having to download and build evans |
| 19:45:09 | jakedouglas | if i have to use evan's thats fine, just wanted to give it a shot |
| 19:45:53 | brixen | it is likely the json bin script prettify_json.rb |
| 19:46:01 | brixen | run rbx compile on that |
| 19:46:05 | brixen | also, look at the code :P |
| 19:46:15 | jakedouglas | im skared now |
| 19:46:26 | brixen | it's a prefect example of why rbx should have a "nuke from orbit" switch |
| 19:46:35 | brixen | er perfect rather |
| 19:48:45 | brixen | btw, you won't use prettify_json in normal use, so the gem should work fine |
| 19:49:12 | jakedouglas | k |
| 19:54:34 | jakedouglas | how about libxml-ruby? |
| 19:55:06 | dbussink | that's pretty outdated |
| 19:55:13 | dbussink | jakedouglas: not maintained for a while too afaik |
| 19:55:18 | jakedouglas | is there a compatible replacement? |
| 19:55:23 | dbussink | i'd suggest switching to nokogiri |
| 19:55:23 | brixen | jakedouglas: it needs a patch |
| 19:55:28 | brixen | yeah, try noko |
| 19:55:37 | jakedouglas | will noko work drop-in? |
| 19:55:55 | brixen | dunno |
| 19:56:03 | dbussink | not that i know, but i've also heard about problems in mri with libxml-ruby |
| 19:56:09 | jakedouglas | i mean, does it replicate the api of libxml-ruby? |
| 19:56:10 | jakedouglas | oh. |
| 19:56:18 | dbussink | so i'd try ditching libxml-ruby in general :) |
| 19:56:25 | dbussink | no, it has it's own api |
| 19:56:35 | jakedouglas | yea i mean this is just from old code, i wish it was as easy as 'switching' heh |
| 20:01:20 | jakedouglas | not all companies allocate time to do things the right way :/ |
| 20:04:26 | dbussink | well, part of running things is keeping things a bit up to date :) |
| 20:04:42 | jakedouglas | trust me, i don't disagree with you |
| 20:04:43 | jakedouglas | heh |
| 20:05:11 | jakedouglas | Installing soap4r (1.5.8) from rubygems repository at http://ec2-us-east-mirror.rightscale.com/rubygems/archive/20100513/ rbx: Precompiling 366 files... |
| 20:05:11 | jakedouglas | Assertion failed: (idx < DATA_MAX), function var_table_add, file var_table.cpp, line 86. |
| 20:05:25 | dbussink | nah, i guess it's more that i would go crazy in those cases |
| 20:05:33 | dbussink | jakedouglas: hmm, what rubinius version do you have? |
| 20:05:40 | jakedouglas | rvm install rbx-head |
| 20:05:48 | dbussink | since that looks like an error fixed long ago |
| 20:05:56 | jakedouglas | installed today. |
| 20:06:55 | jakedouglas | but that must be wrong |
| 20:07:04 | jakedouglas | because my copy of var_table.cpp doesn't even have a line 86 |
| 20:07:16 | dbussink | mine neither |
| 20:07:24 | dbussink | and i remember fixing that exact issue :) |
| 20:07:43 | dbussink | did you already have a rbx-head installed through rvm? |
| 20:07:43 | jakedouglas | i ran it again and it seems to have continued fine |
| 20:07:58 | jakedouglas | probably. does i need to remove and install again? |
| 20:08:02 | dbussink | yeah |
| 20:08:08 | jakedouglas | i see. |
| 20:08:09 | dbussink | rvm doesn't reinstall properly |
| 20:08:23 | jakedouglas | okay |
| 20:09:17 | wayneeseguin | dbussink: you can 'rvm remove rbx-head ; rvm install rbx-head' not 'optimal' but will work |
| 20:09:39 | dbussink | wayneeseguin: that's what i meant (not reinstalling rvm completely yeah) |
| 20:09:46 | dbussink | wayneeseguin: any idea why that's happening? |
| 20:10:47 | dbussink | evan: nicksieger is also calling for fixing json gem issues i see (making it a multiple platform gem) |
| 20:24:43 | jakedouglas | any way to change the build process to make it use more than 1 core? |
| 20:25:36 | dbussink | dunno if that would be easy |
| 20:28:45 | jakedouglas | oh. well it sure would build a lot faster :) |
| 20:30:55 | dbussink | dunno if rake has a parallel task capability though |
| 20:31:14 | Defiler | It does |
| 20:31:17 | Defiler | It just isn't any good |
| 20:31:45 | Defiler | http://rake.rubyforge.org/classes/Rake/MultiTask.html |
| 20:31:49 | dbussink | does mri allow other threads to run while it's shelling out something? |
| 20:31:56 | Defiler | no |
| 20:32:06 | dbussink | ok, so that defeats the purpose then |
| 20:32:07 | Defiler | at least not 1.8, don't know about 1.9 |
| 20:32:09 | Defiler | yeah |
| 20:32:26 | radarek | mri 1.9 has GIL |
| 20:32:28 | Defiler | It's useful if your work is all in ruby I guess though |
| 20:32:51 | Defiler | yeah but in 1.9 you can declare that your native code doesn't need the lock |
| 20:33:03 | Defiler | and I was wondering if 1.9 did that internally for 'system' and `` |
| 20:33:16 | Defiler | answer is probably no, though |
| 20:33:17 | dbussink | haven't tried that |
| 20:34:22 | radarek | Defiler: you mean rb_thread_blocking_region? |
| 20:35:43 | Defiler | yes |
| 20:37:31 | radarek | Defiler: looking at MRI src there are no many usage of that function |
| 20:37:56 | Defiler | yeah, so I see |
| 20:38:01 | Defiler | answers that question, I guess |
| 20:38:09 | wayneeseguin | dbussink: Sutto is looking into it, I haven't had a chance myself yet |
| 20:39:50 | jakedouglas | 1.8 appears to run other threads while shelling out, unless my test is dumb |
| 20:40:03 | jakedouglas | however, i have an rbx explosion |
| 20:40:04 | jakedouglas | http://gist.github.com/476030 |
| 20:41:48 | jakedouglas | but it works from within gdb :p |
| 20:42:13 | Defiler | http://gist.github.com/476035 |
| 20:42:16 | Defiler | try running taht |
| 20:42:26 | Defiler | prints '1' for me, meaning that the thread blocked while system was running |
| 20:44:29 | jakedouglas | ah. true then |
| 20:44:47 | jakedouglas | Assertion failed: (errorcode == 0), function setInstance, file ThreadLocal.cpp, line 61. |
| 20:45:30 | jakedouglas | i think my new rbx install is just completely fucked for some reason. |
| 20:45:42 | jakedouglas | tries again |
| 20:46:31 | jarib | Defiler: why would that mean the thread blocked? that code would never print more than 1 |
| 20:46:46 | jarib | did you forget a loop { } ? |
| 20:47:20 | Defiler | uhh yes I did hehe |
| 20:47:23 | Defiler | sorry, not much sleep |
| 20:47:56 | jarib | prints 10 here, with the loop :) |
| 20:48:01 | Defiler | with a loop it prints 10, yeah |
| 20:48:02 | Defiler | interesting |
| 20:48:05 | jakedouglas | ah. hurray for people that actually read the code. |
| 20:48:27 | Defiler | I'll have to dive into that code and figure out how |
| 20:55:00 | yipdw | so, maybe this is just really dense, but system doesn't start up a new thread -- it forks the ruby process |
| 20:55:07 | yipdw | so perhaps thread-blocking doesn't enter at all? |
| 20:56:22 | dbussink | yipdw: well, the question is whether the process that does the fork unlocks the interpreter or not |
| 20:56:58 | yipdw | oh ok |
| 21:01:02 | dbussink | but from those results from Defiler and jarib it looks like it does |
| 21:03:36 | brixen | jakedouglas: did you try libxml with tmm1's patch? http://github.com/cfis/libxml-ruby/issues#issue/2 |
| 21:04:03 | jakedouglas | brixen: no. im just trying to get rbx running with my rvm build, it was exploding for some reason. |
| 21:04:07 | brixen | discovers this after forking to submit the same patch |
| 21:04:31 | brixen | jakedouglas: you should just clone; configure; rake rbx |
| 21:04:44 | brixen | you don't have to install it to run |
| 21:05:05 | jakedouglas | how do i make it work nice with all the script/foo |
| 21:05:30 | brixen | hm, well, you are a difficult one, huh? :P |
| 21:05:50 | brixen | can you exec the script directly with rbx path/to/script/foo ? |
| 21:06:22 | brixen | for rvm, did you rvm remove, rvm install ? |
| 21:07:37 | dbussink | jakedouglas: did you reinstall gems after rvm remove / rvm install? |
| 21:08:33 | dbussink | because you might have some gems compiled with the older rbx version then |
| 21:08:43 | jakedouglas | almost guarantee you there will be some wonky shit somewhere in the code that will go and try to run other stuff that will need ruby to be rbx |
| 21:08:45 | wayneeseguin | rvm remove/install doesn't touch gems |
| 21:08:48 | wayneeseguin | FYI |
| 21:08:53 | jakedouglas | wayneeseguin: rake? |
| 21:09:08 | wayneeseguin | you'd have to do 'rvm remove --gems rbx' to remove gems for rbx with it |
| 21:09:10 | jakedouglas | it seg faulted on me when the rvm install was tiryng to install rake |
| 21:09:15 | jakedouglas | oh |
| 21:09:25 | wayneeseguin | I'm only speaking for RVM ;) |
| 21:09:31 | wayneeseguin | My family is waiting for me I'll be back later |
| 21:11:20 | brixen | begins work on a ragel state machine to explain the inner workings of rvm :) |
| 21:13:09 | jakedouglas | goes to take a shower while rbx builds |
| 21:14:56 | jakedouglas | oh. looks like it worked this time. |
| 21:15:11 | jakedouglas | Tried to use object of type String (53) as type Array (6) (TypeError) |
| 21:15:14 | jakedouglas | why am i getting stuff like that |
| 21:15:52 | jakedouglas | the precompiled stuff is different or something? |
| 21:16:26 | dbussink | jakedouglas: stuff probably changed in the mean time |
| 21:16:35 | jakedouglas | ok. so i delete the .compiled.rbc file |
| 21:16:38 | dbussink | jakedouglas: best is to also start with a clean set of gems |
| 21:16:42 | jakedouglas | and then i get a explosiion again :( |
| 21:17:11 | jakedouglas | http://gist.github.com/476089 |
| 21:17:27 | brixen | .rbc files are not highly combustible, so are unlikely to cause explosions |
| 21:17:45 | brixen | what did you run? |
| 21:18:16 | jakedouglas | ok i think i jut had another compiled file somewhere that it was loading |
| 21:18:33 | brixen | I mean, to get that segfault? |
| 21:18:43 | jakedouglas | just some silly bundler script |
| 21:19:16 | brixen | which perhaps exec'd gem |
| 21:19:39 | brixen | I really suggest trying a pure rbx clone; build |
| 21:19:48 | brixen | until you know something is working |
| 21:19:55 | jakedouglas | it seems to be working fine now |
| 21:20:09 | jakedouglas | installing gems |
| 21:20:34 | brixen | ok |
| 21:20:55 | brixen | submits a ticket for rvm --sledgehammer |
| 21:20:56 | jakedouglas | uninitialized stream (IOError) |
| 21:20:58 | jakedouglas | IO(IO::BidirectionalPipe)#sync= at kernel/common/io.rb:1512 |
| 21:21:06 | jakedouglas | this is one i've gotten a number of times |
| 21:21:10 | jakedouglas | this script uses popen or something |
| 21:21:16 | brixen | hm |
| 21:21:20 | jakedouglas | i've never seen it fail on MRI, happens every other time or so on rbx |
| 21:21:55 | jakedouglas | IO.popen("#{cmd} 2>&1", 'r') do |output| |
| 21:21:55 | jakedouglas | output.sync = true |
| 21:22:12 | brixen | where is that code? |
| 21:22:16 | jakedouglas | in the script |
| 21:22:31 | brixen | erm, which script? |
| 21:22:36 | jakedouglas | a script in my app |
| 21:22:41 | brixen | ahh |
| 21:23:05 | brixen | could you try to extract a repro? or are those 2 lines it? |
| 21:23:47 | jakedouglas | well, i could probably figure out exactly what command it's running with popen etc |
| 21:23:54 | jakedouglas | its just some helper for shelling out |
| 21:24:27 | jakedouglas | https://gist.github.com/5349b5456806044b1393 |
| 21:25:51 | brixen | ok |
| 21:25:53 | brixen | bbiab.. |
| 21:25:58 | jakedouglas | what would be helpful? |
| 21:26:27 | brixen | anything that reliably repros it |
| 21:26:30 | jakedouglas | k |
| 21:34:37 | jakedouglas | why not version the compiled code? |
| 21:44:47 | jakedouglas | Tried to use object of type LookupTable (36) as type Module (42) |
| 21:45:04 | jakedouglas | is there any way that could happen without having come from old compiled code? i removed my bundler directory, gem uninstalled everything |
| 21:45:14 | jakedouglas | not sure where it would be coming from |
| 21:48:39 | jakedouglas | i deleted the .rbc file for the file it was complaining about, same thing |
| 21:48:47 | jakedouglas | ERRNO_HASH = Hash[*Errno.constants.map{ |c| [Errno.const_get(c)::Errno, Errno.const_get(c).new.message] }.flatten] |
| 21:48:51 | jakedouglas | thats the line it says is the problem |
| 21:49:13 | jakedouglas | it's from memcached gem |
| 21:53:42 | brixen | jakedouglas: .rbc compiled code is versioned |
| 21:54:01 | brixen | you would not get a type error from old compiled code |
| 21:54:41 | brixen | a type error like that is happening in the vm where some C++ code did not get the type it expected |
| 21:54:54 | brixen | rather than segfaulting like mri, you get an exception :) |
| 21:55:32 | brixen | tries this code.. |
| 21:57:15 | brixen | ok, I've got the exception |
| 22:04:24 | brixen | jakedouglas: it is Errno::Mapping being in the constants table |
| 22:04:33 | brixen | brb... |
| 22:06:03 | jakedouglas | huh |
| 22:07:37 | jakedouglas | oh, I see. |
| 22:09:09 | jakedouglas | so what's the solution |
| 22:11:59 | brixen | that code is just plain wrong |
| 22:12:14 | jakedouglas | heh |
| 22:12:19 | brixen | there is no guarantee that a class/module is the only thing in a constants table |
| 22:12:24 | jakedouglas | of course not |
| 22:12:26 | brixen | very bad bit of code there |
| 22:12:50 | jakedouglas | so should i just change it because it isnt an rbx problem? |
| 22:12:51 | brixen | it needs to check that it's got a class/module |
| 22:12:59 | brixen | it's not an rbx issue, no |
| 22:13:02 | jakedouglas | yea. k |
| 22:18:45 | jakedouglas | not found: _ruby_digitmap |
| 22:19:04 | jakedouglas | hpricot :( |
| 22:19:21 | brixen | hpricot has a few issues |
| 22:19:35 | brixen | it will not work without some changes |
| 22:19:57 | jakedouglas | k |
| 22:19:59 | brixen | ruby_digitmap would be easy enough to add |
| 22:20:09 | brixen | but hpricot has bigger issues |
| 22:20:10 | jakedouglas | yea. are the other ones hard? |
| 22:20:11 | jakedouglas | ok. |
| 22:22:13 | brixen | whose hpricot mirror is the canonical one? |
| 22:22:28 | jakedouglas | no idea. |
| 22:22:32 | brixen | heh |
| 22:25:45 | jakedouglas | http://github.com/hpricot/hpricot i guess |
| 22:25:51 | jakedouglas | has most recent update |
| 22:26:20 | brixen | ok, cool |
| 22:26:31 | brixen | thanks *google* for not knowing that |
| 22:49:33 | jakedouglas | so what are the other issues |
| 22:49:40 | jakedouglas | with hpricot |
| 22:52:03 | brixen | ug, besides the fact that rake gem doesn't even work |
| 22:52:16 | brixen | seriously, who needs Markdown a readme |
| 22:52:20 | brixen | <roll eyes> |
| 22:52:51 | jakedouglas | oh. i guess i dont even care. it looks like someone has disabled the method thats using it in our code. |
| 22:53:38 | brixen | heh, sweet |
| 22:53:45 | brixen | so, this is the install output http://gist.github.com/476218 |
| 22:54:01 | brixen | but I think most of that can be handled by redefining 2 macros |
| 22:54:12 | brixen | it's on my list to look at |
| 22:57:32 | jakedouglas | k |
| 22:57:40 | jakedouglas | anyway, trying again now without hpricot. |
| 23:03:30 | jakedouglas | i think i got past the gem load stage. impressive |
| 23:06:56 | jakedouglas | hmm |
| 23:07:47 | evan | brixen: I should try and attack hpricot tomorrow |
| 23:07:54 | evan | maybe we should just fix it. |
| 23:08:27 | jakedouglas | the next thing im hitting is |
| 23:08:50 | jakedouglas | (im trying to run the test suite) |
| 23:09:17 | jakedouglas | its loading a migration file for some reason, in the migration for whatever reason the person is doing an Object.send(:remove_const, :SettingInfo) |
| 23:09:34 | evan | sounds genius! |
| 23:09:37 | evan | *eyeroll* |
| 23:09:43 | jakedouglas | well |
| 23:10:19 | jakedouglas | its just to be able to re-run the (2 year old) migration even though the model class is different now. stupid, maybe |
| 23:10:34 | evan | anyway |
| 23:10:36 | evan | that shouldn't be a problem |
| 23:10:39 | evan | are you having one? |
| 23:10:41 | jakedouglas | anyway, the call to remove_const is causing a const_missing and load_missing in active_support |
| 23:10:51 | evan | hm |
| 23:11:04 | evan | maybe we're running const_missing when we shouldn't |
| 23:11:07 | jakedouglas | and then i get a rails error "Expected /path/to/app/models/some_klass.rb to define SomeKlass" |
| 23:11:12 | evan | in the remove_const case. |
| 23:11:14 | jakedouglas | which does indeed define SomeKlass |
| 23:11:44 | jakedouglas | i see |
| 23:12:46 | evan | jakedouglas: one an issue with the backtrace |
| 23:12:48 | evan | and some details |
| 23:12:51 | evan | so I can track and fix it. |
| 23:12:53 | jakedouglas | k |
| 23:13:23 | evan | if you want to dig in |
| 23:13:35 | evan | find out the semantics of const_missing wrt remove_const in MRI |
| 23:13:39 | jakedouglas | k. |
| 23:13:43 | evan | and find out if we match it on rbx |
| 23:13:49 | evan | specs would probably be useful here too. |
| 23:13:54 | jakedouglas | indeed |
| 23:14:16 | jakedouglas | i guess i would find it hard to believe that no one has run into this, but who knows |
| 23:15:21 | evan | you'd be surprised. |
| 23:18:48 | jakedouglas | yea, ok |
| 23:19:15 | jakedouglas | MRI does not call const_missing when remove_const is called with an undefined constant, rbx does |
| 23:19:48 | jakedouglas | is there a place in the code you can point me to or is it going to be over my head? |
| 23:21:37 | brixen | kernel/common/module.rb:640 |
| 23:21:44 | brixen | write a spec first :) |
| 23:21:52 | jakedouglas | heh. of course. |
| 23:22:00 | jakedouglas | <evil grin> |
| 23:22:04 | brixen | heh |
| 23:28:21 | jakedouglas | damn. figuring out how to name my fixture module is going to be harder than writing the spec and the fix. |
| 23:28:33 | jakedouglas | settles in to read 5 paragraphs |
| 23:29:07 | brixen | ModuleSpecs::Nonexistent ? |
| 23:29:22 | brixen | or does Nonexistent already exist? :) |
| 23:31:30 | jakedouglas | oh. I was looking at 'constants' |
| 23:31:45 | jakedouglas | ConstantSpecs |
| 23:31:50 | jakedouglas | thats what the rest of remove_const_spec uses |
| 23:31:59 | brixen | hmm |
| 23:32:11 | jakedouglas | i assume i should use that?.. |
| 23:32:32 | brixen | no, it should be ModuleSpecs |
| 23:32:38 | brixen | because the method is on Module |
| 23:32:44 | jakedouglas | ok. |
| 23:32:59 | jakedouglas | so are the other ones wrong and need to be fixed? or mine is just special |
| 23:33:27 | brixen | well, rubyspec is a mess in places... le'me look |
| 23:33:37 | jakedouglas | thanks |
| 23:33:42 | brixen | the general rule is scope the fixtures to <class>Specs |
| 23:33:49 | brixen | which is why you'd use ModuleSpecs |
| 23:33:55 | brixen | but there are some special cases |
| 23:36:42 | brixen | jakedouglas: go ahead and use ConstantSpecs::Nonexistent |
| 23:37:25 | jakedouglas | well, now that i think about it, why do i need that at all? |
| 23:39:29 | jakedouglas | im testing that something isn't there. cant i just call Module.send(:remove_const, :Sekret__Mod__That_doeZ_Not_ExIStTTTTT)? |
| 23:40:00 | brixen | you can call ConstantSpecs.remove_const(:Nonexistent) is what I mean |
| 23:40:07 | jakedouglas | oh. okay |
| 23:40:25 | brixen | for the ConstantSpecs rationale, see my note at top of spec/ruby/fixtures/constants.rb |
| 23:41:05 | brixen | but yes, .send(:remove_const ... |
| 23:41:59 | brixen | or class ConstantRemovalFactory.create(:const_remover).new.class_eval { ... } |
| 23:42:04 | brixen | if that is more clear |
| 23:42:18 | jakedouglas | :p |
| 23:42:23 | brixen | heh |
| 23:49:59 | jakedouglas | ok. the spec and the fix should be different commits right? |
| 23:51:11 | brixen | yes, please |
| 23:52:09 | jakedouglas | does that look ok? http://gist.github.com/476287 |
| 23:52:56 | brixen | it "does not call..." and ConstantSpecs.should_not_receive(:const_missing) |
| 23:53:08 | jakedouglas | thanks |
| 23:53:12 | brixen | n/p |
| 23:54:05 | brixen | actually, better would be "it raises a NameError and does not call #const_missing ..." |
| 23:54:24 | jakedouglas | ok, so should i just put it into the test above it? |
| 23:54:32 | jakedouglas | (that tests for NameError) |
| 23:54:38 | brixen | you can leave it together |
| 23:54:46 | jakedouglas | i don't know what you mean |
| 23:55:11 | brixen | the should_not_receive and the should_raise can be in the same spec |
| 23:55:40 | brixen | just fix the description to be: it "raises a NameError and does not call #const_missing..." |
| 23:55:43 | jakedouglas | right. there's already a spec that asserts that NameError is raised. should i just put the const_missing part into that? |
| 23:55:53 | brixen | oh, yes |
| 23:55:55 | jakedouglas | k |
| 23:59:48 | jakedouglas | oh. so i guess theres some more granularity to this. |