Show enters and exits. Hide enters and exits.
| 00:02:20 | brixen | should be pretty easy to write a shared one for #pos= and #seek(off) since whence defaults to SEEK_SET |
| 00:11:30 | evan | k |
| 00:11:33 | evan | let me get these passing |
| 00:11:37 | evan | then we'll explore that. |
| 00:11:40 | brixen | sure |
| 00:43:06 | boyscout | Cleanup IO#ungetc spec - 1efeb0a - Evan Phoenix |
| 00:43:06 | boyscout | Cleanup IO#pos=, IO#pos, and IO#seek specs - f1ba38e - Evan Phoenix |
| 00:43:06 | boyscout | Fix a whole bunch of IO failures, implement IO#ungetc - d15ff22 - Evan Phoenix |
| 00:43:39 | evan | brixen: i pulled the seek stuff into a shared spec |
| 00:47:36 | brixen | cool |
| 01:03:01 | boyscout | CI: Commit d15ff22 failed. http://github.com/evanphx/rubinius/commit/d15ff22de3c147a0f39a7f819a17dd78801856d4 |
| 01:05:29 | brixen | hmm, how does one see the CI output now? |
| 01:06:56 | evan | on ci.rubini.us |
| 01:07:30 | evan | hrm |
| 01:07:34 | evan | thats a 64/32 bit problem |
| 01:08:10 | brixen | hm |
| 01:08:21 | evan | hm. |
| 01:09:04 | evan | oh, I untagged these |
| 01:09:10 | evan | i'll bet they didn't run before anyways |
| 01:09:19 | evan | no prob |
| 01:09:36 | evan | this is because off_t is 64bits on 64bit platforms |
| 01:10:14 | evan | these are all on the boundary |
| 01:10:19 | evan | i'm going to just eliminate them |
| 01:10:26 | evan | the specs in question aren't boundary testing anyway |
| 01:10:45 | brixen | hm |
| 01:11:07 | brixen | why are these not guarded for 32/64bit? |
| 01:11:29 | evan | because the author wasn't thinking about that. |
| 01:11:34 | evan | and they were tagged |
| 01:11:41 | evan | but the specs aren't testing boundaries anyway |
| 01:11:47 | evan | so i'm removing these offending ones |
| 01:11:54 | evan | there is one boundary test in here |
| 01:11:59 | evan | that uses 2 ** 128 |
| 01:12:03 | evan | so it works everywhere |
| 01:12:07 | brixen | I don't know what you mean by testing boundaries |
| 01:12:09 | brixen | IO#pos= does not accept Bignums that don't fit in a C long |
| 01:12:12 | brixen | what is that testing? |
| 01:12:26 | evan | thats just testing that you can't pass a very large Bignum into seek |
| 01:12:30 | evan | it uses 2 ** 128 |
| 01:12:40 | evan | it's not guarded for 32 vs 64 |
| 01:12:55 | evan | so it uses a value that will cause the spec to work on both |
| 01:13:08 | brixen | if there is going to be such a spec, it should test both sides of the boundary |
| 01:13:16 | evan | none of these specs are trying to find the act number where a Bignum can't be a long anymore |
| 01:13:20 | evan | right |
| 01:13:23 | evan | it's missing that |
| 01:13:26 | evan | we should add that |
| 01:13:30 | evan | but i'm going to fix the failing ones |
| 01:13:34 | brixen | ok |
| 01:13:38 | evan | because they're not actually trying to test the boundary |
| 01:13:47 | evan | but they did accidentally |
| 01:16:24 | boyscout | Remove errant boundary use, use mock for real test - f6a642d - Evan Phoenix |
| 01:31:47 | boyscout | CI: Commit f6a642d failed. http://github.com/evanphx/rubinius/commit/f6a642d8ce4c051a74d0ace596c0328c0b707921 |
| 01:34:07 | evan | hrm |
| 01:34:44 | evan | oops. |
| 01:37:39 | boyscout | Remove boundary case - 98ef03a - Evan Phoenix |
| 01:41:34 | boyscout | CI: rubinius: 98ef03a successful: 3024 files, 11813 examples, 36125 expectations, 0 failures, 0 errors |
| 01:41:41 | evan | bingo. |
| 01:46:20 | brixen | sweet |
| 01:54:40 | evan | ok |
| 01:54:42 | evan | i think the time has come. |
| 01:54:47 | evan | frozen needs to be supported. |
| 01:55:27 | kronos_vano | wow |
| 01:55:33 | brixen | ok |
| 01:57:06 | evan | i'm adding a check_frozen instruction |
| 01:57:14 | evan | and i'm going to wire it up to Ruby.check_frozen |
| 01:58:19 | brixen | not too intrusive |
| 01:58:33 | brixen | almost just like tagging mutator methods |
| 01:58:59 | evan | right |
| 01:59:10 | brixen | suppose the jit would collapse redundant ones on inlining |
| 01:59:16 | brixen | since once frozen, always frozen |
| 02:00:02 | evan | sure |
| 02:02:58 | rue | You know, technically we should be able to benefit from frozen objects |
| 02:04:23 | rue | Though it does not really affect method lookup which is where the biggest gains would be |
| 08:00:06 | dbussink | evan: still there? |
| 08:00:13 | evan | yep |
| 08:00:34 | dbussink | evan: on your question why i'd need that method, it's because i'd want to chop some chars of a string from pack |
| 08:00:46 | evan | why not just @num_bytes -= count |
| 08:00:46 | dbussink | evan: http://github.com/evanphx/rubinius/issues#issue/173 |
| 08:00:56 | dbussink | evan: because i have a string object and i'm not in string |
| 08:01:22 | evan | why are you chopping a string you aren't in? |
| 08:01:32 | dbussink | evan: http://github.com/evanphx/rubinius/blob/master/kernel/common/pack.rb#L38 |
| 08:02:00 | dbussink | evan: that's actually really slow, making the string shorter there increases performance by a pretty big factor |
| 08:02:20 | evan | i'd prefer you throw all that code away |
| 08:02:23 | evan | and redo it entirely. |
| 08:02:43 | evan | but i see what you mean |
| 08:02:46 | dbussink | evan: what would be the preferred approach then? |
| 08:02:52 | evan | actualy X is pretty short |
| 08:03:11 | evan | sure, add a method |
| 08:03:17 | evan | it's not really a helper method. |
| 08:03:22 | evan | it's a straight up mutator. |
| 08:03:29 | dbussink | evan: on the string you mean? |
| 08:03:34 | evan | yes. |
| 08:03:52 | dbussink | evan: any suggestion for it's naming? |
| 08:04:02 | dbussink | since i haven't really been able to think of a good one |
| 08:04:15 | dbussink | chop! already exists and has different semantics |
| 08:04:31 | evan | shorten! |
| 08:04:38 | dbussink | ah, that's a good one yeah :) |
| 08:12:43 | rue | #truncate |
| 08:13:07 | rue | Shortening implies some intelligible result, I think. |
| 08:28:18 | dbussink | rue: let's start bikeshedding on this ;) |
| 08:31:38 | dbussink | evan: any luck with those datamapper spec issues or leaving them for now? |
| 10:02:47 | hedge-hog | #rvm is a little quite now so thought I'd ask this here too.... when installing rbx-1.0.0-head, without 1.8.7 installed, the rbx install errors out, error is in ~/.rvm/log/rbx-1.0.0-head/rake.error.log... I'm uncertain which project would want to see what went wrong... is this an rbx issue or should I raise it with rvm group? |
| 10:45:41 | rue | Pastie it over on #rvm, I will take a look at it when I come back from errands unless someone makes it first |
| 10:48:09 | dbussink | hedge-hog: you need an 1.8 version before you can install rbx |
| 10:50:24 | hedge-hog | dbussink: I see that ruby-1.8.7p278 gets installed before hand without errors it seems. The rake error log seems to indicate a gcc error, but I'm not sure which group is interested in the error :) |
| 10:51:12 | hedge-hog | rue: thanks will do. |
| 10:57:56 | hedge-hog | s/ruby-1.8.7p278/ruby-1.8.7p248/ |
| 11:17:11 | mccvmimxeuh | VERSION Learn more at http://free.sweettits.net/ |
| 11:17:11 | mccvmimxeuh | VERSION Learn more at http://free.sweettits.net/ |
| 11:17:11 | mccvmimxeuh | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:08 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:08 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:08 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:09 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:11 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:13 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:15 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:17 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:19 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:21 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:23 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:25 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:27 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:29 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:31 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:33 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:35 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:37 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:39 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:41 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:43 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:45 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:47 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:49 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:51 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:53 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:55 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:57 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:22:59 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:01 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:03 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:05 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:07 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:09 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:11 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:13 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:15 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:17 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:19 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:21 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:23 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 11:23:25 | gduxu | VERSION Learn more at http://free.sweettits.net/ |
| 17:11:22 | brixen | morning |
| 17:11:30 | evan | morning! |
| 17:18:05 | evan | well, i removed almost all of the String fails tags now |
| 17:18:11 | evan | by adding freeze check support. |
| 17:18:26 | evan | and, yay, we had already refactored stuff into modify! |
| 17:18:31 | evan | so i can just do the freeze check there. |
| 17:18:37 | evan | and get 95% of the methods |
| 17:20:54 | brixen | sweet! |
| 17:27:47 | boyscout | Move Frozen and Tainted to the header, add Ruby.check_frozen - 8a51d5b - Evan Phoenix |
| 17:28:09 | evan | I didn't fix all the frozen check failures |
| 17:28:22 | evan | but you just need to put "Ruby.check_frozen" into a method where self should be checked |
| 17:28:40 | evan | there is another mode where you can pass in one argument and that object will be checked for frozeness |
| 17:29:18 | evan | but the vast, vast majority of cases check self, so thats what the argless version does. |
| 17:29:44 | evan | brixen: could you look at line 508 of string/gsub_spec.rb |
| 17:29:44 | evan | ? |
| 17:33:17 | brixen | sec.. |
| 17:37:44 | boyscout | CI: rubinius: 8a51d5b successful: 3024 files, 11837 examples, 36173 expectations, 0 failures, 0 errors |
| 17:37:51 | evan | sweeet. |
| 17:39:13 | brixen | ok, read thread on that ruby_bug |
| 17:39:26 | brixen | evan: what's the question? |
| 17:39:35 | evan | oh |
| 17:39:37 | evan | ack |
| 17:39:37 | evan | sorry |
| 17:39:47 | evan | i just wanted you to see that one |
| 17:39:50 | evan | it's running on rubinius |
| 17:39:57 | evan | even though i'm assuming it's 1.9 only |
| 17:40:13 | brixen | no, it needs a ruby_version_is if it's 1.9 only |
| 17:40:29 | brixen | ruby_bug is a no-op period unless the impl is mri |
| 17:41:03 | evan | k, one sec. |
| 17:41:05 | evan | let me double check... |
| 17:41:09 | brixen | see eg 466 |
| 17:41:21 | evan | it seems to be running |
| 17:41:37 | evan | bin/mspec spec/ruby/core/string/gsub_spec.rb |
| 17:41:41 | brixen | it? |
| 17:41:43 | evan | oh wait. |
| 17:41:47 | evan | why are the line numbers wrong... |
| 17:41:55 | evan | hold on. |
| 17:42:07 | evan | something is up... |
| 17:42:15 | evan | because it does run line 513 |
| 17:42:30 | evan | but under the spec for "with pattern and block raises a RuntimeError when self is frozen" |
| 17:42:37 | evan | oh wait |
| 17:42:39 | evan | no, thats the one |
| 17:42:41 | evan | yeah, it's running. |
| 17:43:10 | evan | so, ruby_bug should or shouldn't not run on rubinius? |
| 17:43:31 | brixen | anything that is guarded by ruby_bug should run in any impl that is not MRI |
| 17:43:41 | evan | ooh |
| 17:43:44 | brixen | those ruby_bug guards should also not be there |
| 17:43:49 | brixen | since we are not guarding 1.9 bugs |
| 17:43:51 | evan | when you said no-op guard |
| 17:43:56 | evan | i figured you meant that it was always false then. |
| 17:44:00 | evan | but you mean it's always true |
| 17:44:04 | brixen | yes |
| 17:44:08 | evan | my mistake |
| 17:44:09 | evan | ok |
| 17:44:19 | evan | so this needs a ruby_version_is around it |
| 17:44:26 | evan | i see there is a 2nd argument to ruby_bug |
| 17:44:30 | evan | that says "1.9" |
| 17:44:33 | evan | should that be doing anything? |
| 17:44:39 | brixen | right, that's purely for MRI |
| 17:44:45 | brixen | ruby_bug is for MRI |
| 17:44:47 | brixen | only |
| 17:44:48 | brixen | ever |
| 17:44:50 | brixen | :) |
| 17:45:12 | brixen | the spec inside ruby_bug should run on any impl not MRI unless otherwise guarded with something else |
| 17:45:14 | evan | ok, so if the 2nd argument is "1.9" to ruby_bug |
| 17:45:20 | evan | it better be wrapped in a ruby_version_is as well |
| 17:45:29 | brixen | not necessarily no |
| 17:45:35 | brixen | the two are totally separate |
| 17:45:46 | evan | what does the 2nd argument to ruby_bug mean? |
| 17:45:52 | brixen | the version to ruby_bug is for the MRI version that the bug was fixed in |
| 17:46:04 | brixen | it's guarded for anything less than the version |
| 17:46:16 | brixen | it's not necessarily a 1.9 specific behavior |
| 17:46:27 | evan | hm ok |
| 17:46:30 | brixen | it could be a bug that was finally discovered/fixed in 1.9 |
| 17:46:59 | phlebas-notebook | hi. i've heard about the great debugger that comes in rubinius, but have no idea how to start it. Rubinius::VM::debugger doesn't seem to work |
| 17:47:36 | brixen | evan: headed to a coffee shop, bbiab... |
| 17:47:43 | evan | k |
| 17:47:50 | evan | phlebas-notebook: it's been broken for a while |
| 17:48:02 | evan | phlebas-notebook: not sure who has been talking it up to you |
| 17:48:13 | phlebas-notebook | oh, shame |
| 17:48:33 | evan | who told you that? |
| 17:48:47 | khaase | *duck* |
| 17:49:07 | phlebas-notebook | yeah... |
| 17:50:05 | khaase | hmmm... but is there not so not-that-awesome-but-still-you-can-debug-ish solution? |
| 17:50:16 | khaase | s/so/a |
| 17:50:49 | evan | debug at the ruby layer? |
| 17:50:54 | khaase | yeah |
| 17:51:45 | evan | you can try --debug |
| 17:51:50 | evan | bin/rbx --debug thing.rb |
| 17:51:53 | evan | thats worked on and off |
| 17:52:03 | evan | using the debugger we have. |
| 17:58:35 | khaase | right, thanks evan. |
| 17:58:51 | evan | patches to fix the debugger are always welcome. |
| 18:08:01 | boyscout | Add a proper guard, expand the 1.8 case - 0f5700f - Evan Phoenix |
| 18:11:59 | boyscout | CI: rubinius: 0f5700f successful: 3024 files, 11838 examples, 36175 expectations, 0 failures, 0 errors |
| 18:32:56 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:32:56 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:32:56 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:32:57 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:32:59 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:33:01 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:33:03 | vvfi | VERSION Learn more at http://free.sweettits.net/ |
| 18:33:26 | ubtbzfbybre | VERSION Learn more at http://free.sweettits.net/ |
| 18:33:26 | ubtbzfbybre | VERSION Learn more at http://free.sweettits.net/ |
| 18:33:26 | ubtbzfbybre | VERSION Learn more at http://free.sweettits.net/ |
| 18:57:01 | dbussink | hmm the logger actually logs the spam: http://donttreadonme.co.uk/rubinius-irc/rubinius.log.html |
| 18:59:06 | brixen | spam is ham to loggers |
| 18:59:09 | brixen | or something :) |
| 18:59:16 | evan | what spam? |
| 18:59:21 | evan | there was spam? |
| 18:59:27 | brixen | in channel, yes |
| 18:59:32 | evan | weird, i didn't get it. |
| 18:59:37 | evan | i see the user connect and disconnect |
| 18:59:40 | evan | but nothing inbetween. |
| 18:59:45 | dbussink | evan: it are ctcp messages |
| 18:59:47 | brixen | hmm |
| 18:59:47 | dbussink | i've disabled them |
| 18:59:48 | brixen | yeah |
| 18:59:55 | evan | oooh |
| 18:59:56 | evan | ctcp |
| 19:00:07 | dbussink | because i was disconnecting too because of those spam messages |
| 19:00:11 | dbussink | just ignoring works better :p |
| 19:00:22 | evan | brixen: so, i've decided to try and implement your each_object stategy |
| 19:00:24 | evan | strategy. |
| 19:00:29 | brixen | ahh ok |
| 19:00:55 | evan | most of the code is going to be the code for actually walking all the objects |
| 19:01:10 | evan | since thats a bit more complicated than MRI. |
| 19:01:26 | boyscout | Improve performance of Array#pack's X, see ticket #173 - b19d56d - Dirkjan Bussink |
| 19:02:15 | brixen | evan: I thought you could hijack the transitive closure code maybe |
| 19:02:34 | brixen | although, hmm... |
| 19:02:48 | brixen | you'd see newly created objects then |
| 19:02:59 | evan | thats actually ok |
| 19:03:01 | evan | i could do that |
| 19:03:08 | evan | hm. |
| 19:04:30 | evan | the problem with the transitive closure code is it requires using the mark bit |
| 19:04:36 | evan | so you don't retrace graph branches. |
| 19:05:24 | boyscout | CI: rubinius: b19d56d successful: 3024 files, 11838 examples, 36175 expectations, 0 failures, 0 errors |
| 19:05:43 | brixen | hm |
| 19:06:37 | brixen | well, what about piggy backing the each_object on a normal GC cycle? |
| 19:06:52 | brixen | ok, we don't have concurrent GC |
| 19:06:55 | evan | i'd considered that |
| 19:06:55 | brixen | nvm heh |
| 19:07:07 | evan | well, i can reuse the mark bit |
| 19:07:12 | evan | and actually, I think you're right |
| 19:07:16 | evan | i think thats the way to go |
| 19:07:23 | evan | i'm not sure i can even iterate over immix |
| 19:07:36 | evan | it's not designed for that |
| 19:07:40 | brixen | yeah |
| 19:07:46 | evan | because it doesn't track where in a line an object starts |
| 19:07:59 | evan | ok! |
| 19:08:03 | evan | well, i've wanted to do this anyway |
| 19:08:08 | brixen | fun! |
| 19:08:36 | evan | i'll just pull out the transative closure code from immix into a seperate iterator class |
| 19:09:00 | evan | we can use it for _id2ref too |
| 19:09:12 | brixen | cool |
| 19:09:12 | evan | by just searching the entire object graph |
| 19:09:37 | evan | I actually want to build a small query language |
| 19:09:46 | evan | that _id2ref would be built on |
| 19:10:13 | brixen | heh that'd be slick |
| 19:10:13 | evan | ObjcectSpace.query [:find_one, [:object_id, 342]] |
| 19:10:16 | brixen | yeah |
| 19:10:37 | brixen | very cool |
| 19:11:00 | evan | ObjcectSpace.query [:find_all, [:ivar, :@name, "Evan"]] |
| 19:11:05 | brixen | my first dabbling with yacc was an sql syntax to query a CAD program's file format for objects |
| 19:11:08 | brixen | fun stuff |
| 19:11:21 | evan | a stringified syntax comes last |
| 19:11:23 | evan | :) |
| 19:11:38 | brixen | heh |
| 19:37:23 | khaase | SELECT map { |f| f.camel_case } FROM Enumerable WHERE all? { |e| e.is_a? String } |
| 19:40:15 | evan | heh |
| 19:49:03 | jvoorhis | slava: seen this yet? http://denkspuren.blogspot.com/2010/01/factor-heilbronn-university.html |
| 20:05:53 | brixen | man #require you kill me |
| 20:06:21 | evan | :( |
| 20:06:28 | brixen | writing the rbx-specific require specs is dicey because we can't put .rbc fixtures in the repo |
| 20:06:35 | brixen | because of the compiler signature |
| 20:06:44 | brixen | which is fine, I've got a clean scheme working |
| 20:07:15 | brixen | but why oh why is requiring a .rbc directly behaving differently re $LOADED_FEATURES from requiring a .rb |
| 20:07:26 | evan | :( |
| 20:07:27 | brixen | anyway... |
| 20:07:27 | evan | you know |
| 20:07:42 | evan | we have never used being able to explicitly require a .rbc |
| 20:07:47 | evan | if you wanna tear it out |
| 20:07:51 | evan | feel free to. |
| 20:08:22 | brixen | well, it's fine as far as a feature goes |
| 20:08:31 | brixen | but it should work exactly like requiring a .rb |
| 20:08:32 | evan | HOT DOG |
| 20:08:36 | brixen | in terms of $L_F |
| 20:08:48 | evan | http://gist.github.com/289092 |
| 20:08:49 | brixen | and the fact that it doesn't was masked by these existing specs |
| 20:08:54 | evan | outputs |
| 20:08:55 | evan | [#<IO:0x1e>, #<IO:0x20>, #<IO:0x22>] |
| 20:09:02 | brixen | awesome |
| 20:09:05 | brixen | rockin! |
| 20:09:19 | evan | i made the primitive just append them to an array if you pass one in |
| 20:09:25 | evan | otherwise it sends #call |
| 20:09:27 | evan | going to test that now |
| 20:09:53 | evan | hey! that works too! |
| 20:09:54 | evan | yay |
| 21:49:09 | brixen | finds foods |
| 21:49:19 | evan | going to find or found? |
| 22:04:37 | hedge-hog | Am I right that ~/.rvm/rubies/* is where you'd expect to find ruby installations pre rvm version 0.1? |
| 22:04:49 | evan | i'll have to ask in #rvm |
| 22:05:04 | hedge-hog | blush, wrong tab |
| 22:05:24 | evan | no prob. |
| 22:31:34 | maharg | hm |
| 22:33:54 | maharg | rubinius seems to handle {raise exception_instance, "some descriptive text"} (where eg exception_instance might actually be MyError.new(1)) differently from MRI. It seems to make a new exception object except passing the second arg to raise to the constructor, where MRI raises the object you pass it and tacks the description on |
| 22:38:36 | evan | just a bug then. |
| 22:38:57 | evan | lets see... |
| 22:39:36 | evan | if there are 2 arguments, MRI calls .exception on 1st argument passing the 2nd |
| 22:39:59 | evan | which it appears we do. |
| 22:40:31 | evan | and Exception#exception clones self |
| 22:40:47 | evan | and calls some internal initialize |
| 22:41:00 | evan | ah, thats normal initialize |
| 22:41:07 | evan | so seems the same to me |
| 22:43:13 | evan | maharg: could you show me the behavior you're seeing in ruby code? |
| 22:43:28 | maharg | I'm writing a spec, will have a patch in a sec |
| 22:49:54 | maharg | http://friendpaste.com/6p6ou6TLu41KriuWAMl3QF |
| 22:50:03 | maharg | works on MRI, not on rbx |
| 22:50:20 | evan | yeah |
| 22:50:24 | evan | thats because MRI sucks. |
| 22:50:32 | evan | it's not calling #initialize like normally |
| 22:50:43 | evan | it's staticly calling Exception#initialize |
| 22:50:50 | evan | by calling the C function for it. |
| 22:50:51 | evan | :/ |
| 22:52:07 | maharg | hah |
| 22:52:30 | evan | the fact that this has allowed people to write invalid #initialize methods on Exception subclasses blows. |
| 22:52:42 | evan | there is an easy fix though. |
| 22:53:21 | evan | alias Exception#initialize to __initialize__ |
| 22:53:30 | evan | and then call __initialize__ from Exception#exception |
| 23:04:58 | brixen | evan: find, found, and consumed |
| 23:05:06 | brixen | greasy breakfast for lunch, yum |
| 23:05:07 | evan | Defiler taunted me |
| 23:05:18 | evan | and I ended up building a full on object query system. |
| 23:05:28 | brixen | heh |
| 23:05:32 | evan | ObjectSpace.find_object([:and, [:kind_of, Blah], [:ivar, :@name]], ary) |
| 23:06:22 | brixen | does :kind_of dispatch to kind_of? or is that just query syntax? |
| 23:06:34 | evan | thats query syntax |
| 23:06:40 | evan | it uses Object::kind_of() in C++ |
| 23:06:44 | brixen | ok |
| 23:06:52 | evan | ary can be something that responds to call |
| 23:06:59 | evan | and if so, it's sent on every object |
| 23:07:02 | brixen | I thought you'd hooked up arbitrary method sends |
| 23:07:18 | brixen | oh, with ary |
| 23:07:27 | evan | you'd do that in the block |
| 23:07:34 | brixen | cool |
| 23:07:37 | evan | actually |
| 23:07:44 | evan | since this is running with the GC inhibited |
| 23:07:47 | evan | i could probably call a method |
| 23:08:05 | evan | perhaps |
| 23:08:17 | evan | ObjectSpace.find_object([:call, obj]) |
| 23:08:25 | evan | obj is just expected to respond to #call |
| 23:08:48 | evan | and if #call comes back true, the object passed in is used |
| 23:09:33 | brixen | hm |
| 23:11:07 | evan | boyya |
| 23:11:10 | evan | added :or |
| 23:11:15 | brixen | heh |
| 23:11:56 | evan | so |
| 23:12:01 | evan | we got _id2ref for free |
| 23:12:18 | evan | there are 6 conditions now |
| 23:12:30 | evan | and, or, kind_of, ivar, method, and object_id |
| 23:12:42 | evan | _id2ref is just |
| 23:12:53 | evan | ObjectSpace.find_object([:object_id, id]) |
| 23:15:26 | brixen | heh, sweet |
| 23:16:03 | evan | not as fast as MRI |
| 23:16:05 | evan | but oh well. |
| 23:16:37 | brixen | yeah, this is not intended for tight loops or per request processing |
| 23:16:46 | brixen | despite that some bonehead will surely use it so |
| 23:18:23 | evan | probably |
| 23:18:24 | evan | oh well. |
| 23:19:42 | brixen | offering the functionality is awesome |
| 23:21:07 | evan | yeah, totally. |
| 23:22:14 | matthewd | Heh... just did an idle-curiousity google code search for _id2ref... weakref.rb, weakref.rb, gc.c, gc.c, my code... crap. :P |
| 23:22:43 | brixen | matthewd: busted! heh |
| 23:22:52 | evan | matthewd: you should not be using it in your own code probably. |
| 23:24:06 | matthewd | Seemed like a good idea at the time? :) |
| 23:25:05 | matthewd | I think in Johnson, we just cast between void* and VALUE... which is not necessarily better ;) |
| 23:25:18 | evan | ha yeah |
| 23:25:23 | evan | also not a good idea. |
| 23:33:14 | brixen | heh, great |
| 23:33:27 | brixen | loading .rbc's from a .rba appears to be quite broken atm |
| 23:33:34 | brixen | despite having a passing spec |
| 23:33:38 | evan | yeah |
| 23:33:46 | evan | we really still have not used that |
| 23:33:48 | brixen | that is likely only passing because the .rb file still existed |
| 23:33:54 | evan | i suggest we pull it out entirely |
| 23:33:57 | brixen | we used to use it |
| 23:33:59 | evan | and add it back in later |
| 23:34:00 | brixen | really? |
| 23:34:11 | brixen | yeah |
| 23:34:18 | brixen | I'd not want to completely ditch it |
| 23:34:27 | brixen | I'm just trying to get these specs ironed out |
| 23:34:31 | evan | k |
| 23:34:36 | brixen | and love rewriting a passing spec and have it fail |
| 23:34:43 | brixen | so I'm like "what did I do" |
| 23:34:49 | brixen | oh, I wrote the spec correctly |
| 23:34:51 | brixen | ugh |
| 23:35:01 | evan | hehe |
| 23:36:53 | maharg | evan: implemented that 'fix' as suggested. It's in a branch on my github: http://github.com/stormbrew/rubinius/tree/fix-raise-behaviour, not sure if there's a more preferred way to get it included. The github issue tracker seems flakey and doesn't support attachments that I can see. |
| 23:36:53 | evan | using the mark bit appears to be causing some kind of GC confusion |
| 23:36:56 | evan | i'm hunting it down now. |
| 23:36:59 | brixen | ahh I see, CompiledFile.load really expects an IO |
| 23:37:21 | evan | maharg: the prefered way is to use git format-patch |
| 23:37:24 | evan | open an issue |
| 23:37:30 | evan | and put a link to the gist with the patch in it. |
| 23:38:16 | evan | maharg: you're fix is wrong |
| 23:38:20 | evan | you need to clone the object |
| 23:38:24 | evan | and send the clone __initialize__ |
| 23:39:04 | maharg | ah ok |
| 23:46:20 | maharg | is it preferred to have the change to the specs in the same change as the fix? |
| 23:46:46 | evan | NO |
| 23:46:48 | evan | do NOT do that. |
| 23:46:51 | maharg | didn't think so |
| 23:47:28 | evan | it's too hard to sync the specs upstream with rubyspec if you do that. |
| 23:49:25 | maharg | look better now? Same branch link as above |
| 23:50:20 | evan | yeah, that passes right? |
| 23:50:26 | maharg | yep |
| 23:50:35 | evan | i might have thought __initialize__ would be private unless you explicitley change that. |
| 23:50:36 | evan | ok |
| 23:56:36 | maharg | issue created |
| 23:56:58 | evan | k |