Show enters and exits. Hide enters and exits.
| 00:15:50 | justin-george | yes, the magic of modules... order matters |
| 00:49:02 | rue | tarcieri: I dunno if they are currently asynchronous. Were |
| 01:52:09 | tarcieri | Defiler: heh, saw something even more confusing earlier today |
| 01:52:13 | tarcieri | rue: I see |
| 01:52:47 | tarcieri | Defiler: now *this* is confusing behavior: http://gist.github.com/237366 |
| 01:57:41 | rue | It follows aliasing logic |
| 02:01:33 | tarcieri | yes I'm sure it makes perfect sense... to Ruby implementers |
| 02:01:33 | tarcieri | heh |
| 02:58:36 | rue | You can always re-include it if you want changed behaviour, but if it changed automatically, you could no longer go back to the original |
| 16:08:37 | ddub | good morning |
| 17:23:24 | rue | Moderately sucky evening |
| 18:39:53 | Defiler | Whoa, 1.9 has a different return value from *[5] than 1.8? |
| 18:40:02 | Defiler | How the hell am I supposed to write code that works on both versions? |
| 18:40:23 | Defiler | return *blah is totally different now |
| 18:41:06 | brixen | Defiler: yeah, fun |
| 19:22:19 | rue | Why are you returning a splat? |
| 19:26:47 | rue | Or do you just mean in general? A single-element Array splatted to one argument is itself rather than the value now |
| 19:27:50 | rue | I surmise the change was to make single-and multiple-value splattables behave the same with one lhs |
| 19:28:57 | Defiler | rue: I'm returning a splat because I have SomeClass.find(one_or_more_ids) |
| 19:29:07 | Defiler | and if they are looking for one, I don't want to return an array |
| 19:30:27 | rue | Hm. You then handle Array vs. something else differently in further code? |
| 19:31:01 | Defiler | The caller knows how they are using it |
| 19:31:12 | Defiler | So they expect an array or a single object, depending on what they are using this API for |
| 19:32:16 | rue | Mm, perils of lack of overloading. Just have to add an explicit check in .find then |
| 19:32:23 | Defiler | It's not an 'omg I can't do it any other way' kind of situation |
| 19:32:32 | Defiler | but it's a surprisingly big behavior change |
| 19:32:54 | Defiler | I can just make find and find_one as well |
| 19:33:42 | rue | I dunno, I can see the virtual overload being intuitive |
| 19:33:52 | Defiler | It is, yeah |
| 19:33:56 | rue | Could be unintuitive to some too, I suppose. |
| 19:34:04 | Defiler | @source = Source.find params[:source_id] |
| 19:34:11 | rue | So make both and delegate from .find |
| 19:34:14 | evan | return ary.first if ary.size == 1 |
| 19:34:15 | Defiler | vs. @sources = Source.find(list_of_sources) |
| 19:34:15 | evan | return ary |
| 19:34:19 | evan | that works everywhere. |
| 19:34:26 | Defiler | Yeah, that's what I changed it to |
| 19:34:36 | evan | and is much less clever. |
| 19:35:09 | Defiler | I'm not sure the original was 'clever', but yeah |
| 19:35:21 | Defiler | I ended up changing it to ary.size > 1 ? ary : ary.first |
| 19:35:36 | Defiler | because I want a nil back from an empty array |
| 19:36:05 | rue | Defiler: Hey, if it takes me a moment to figure out, it is clever ;) |
| 19:36:22 | Defiler | I didn't take me a moment to figure out :) |
| 19:36:34 | evan | it did me! |
| 19:36:49 | Defiler | If only you knew more Ruby heh |
| 19:38:13 | Defiler | I should look at how ActiveRecord changed their code, since this is the behavior of AR::Base.find as well |
| 20:27:51 | boyscout | Fix bad ref GC bug. Fixes #69, Closes #20. - 87a7776 - Evan Phoenix |
| 20:27:51 | boyscout | Add more super specs - b2a0175 - Evan Phoenix |
| 20:27:51 | boyscout | Fix super in define_method - 54943a4 - Evan Phoenix |
| 20:27:51 | boyscout | Expose backtrace max level in rubinius::print_backtrace - f7c0568 - Evan Phoenix |
| 20:34:33 | boyscout | CI: f7c0568 success. 3002 files, 11426 examples, 35494 expectations, 0 failures, 0 errors |
| 20:35:33 | rue | Hu, weird GC thing |
| 20:35:42 | rue | Think I was hitting that |
| 20:51:20 | ddub | evan, want a newer config.guess? (nov 2009 vs. feb 2003) |
| 21:23:38 | evan | ddub: only if it properly detects darwin 64 |
| 21:25:38 | ddub | evan: as x86_64-apple-darwin10.2.0 |
| 21:26:10 | evan | seems right |
| 21:26:13 | evan | whats the diff? |
| 21:26:16 | evan | what did they change? |
| 21:29:51 | Defiler | evan: in http://github.com/evanphx/rubinius/commit/87a77767d6af0ff6f689a545ca32d7779964f877 |
| 21:30:05 | evan | yes? |
| 21:30:10 | Defiler | am I reading it wrong, that it fetches the native method frame from env, and then sets it back on env without changing it? |
| 21:30:28 | evan | where? |
| 21:30:37 | Defiler | 173/172 |
| 21:31:02 | Defiler | (nativemethod.cpp, sorry) |
| 21:31:11 | evan | yes, that line sets that NativeMethodFrame to be the current frame |
| 21:31:12 | evan | and? |
| 21:31:31 | Defiler | but nmf came from env->current_native_frame() a few lines up, right? |
| 21:32:00 | evan | um. no? |
| 21:32:08 | evan | it's created on line 169 |
| 21:32:11 | evan | on the stack |
| 21:32:31 | evan | that line creates a new NativeMethodFrame as a C++ object allocated on the stack |
| 21:32:42 | evan | the argument to the constructor is the current nativemethodframe |
| 21:32:46 | evan | that it sets as it's previous one |
| 21:32:49 | evan | so there is a linked list of them. |
| 21:32:50 | Defiler | Aaah, ok |
| 21:33:02 | Defiler | I thought it was retrieving and casting it, sorry |
| 21:34:36 | evan | no prob. |
| 21:46:25 | ddub | evan, I'm looking at what it takes to make a universal binary with the new build system, I upgraded in hopes that it would correct a problem I had (it didn't) |
| 21:46:44 | ddub | they added support and fixes for about six and a half years worth of platforms |
| 21:52:43 | evan | seems fine to update it. |
| 22:08:10 | boyscout | Add File::Stat#sticky? - 12e8e70 - Mikko Perttunen |
| 22:08:10 | boyscout | Updated specs for File.sticky? and FileTest.sticky? - d7175ac - Mikko Perttunen |
| 22:08:10 | boyscout | Fix File#sticky? for darwin - 2876e14 - Evan Phoenix |
| 22:08:59 | cyndis | whee! first patch. |
| 22:09:05 | evan | :D |
| 22:09:10 | evan | want your commit bit? |
| 22:09:25 | cyndis | sure, have to learn how to use git push though :p |
| 22:09:31 | evan | heh |
| 22:09:54 | evan | whats your github username? |
| 22:09:59 | cyndis | cyndis |
| 22:09:59 | boyscout | CI: 2876e14 success. 3002 files, 11431 examples, 35502 expectations, 0 failures, 0 errors |
| 22:10:13 | evan | ok, added! |
| 22:10:15 | evan | thanks for the help! |
| 22:10:40 | cyndis | thank you for a nice project :) |
| 22:11:34 | cyndis | i have a working File.expand_path patch also, but haven't made specs for it yet |
| 22:12:04 | cyndis | i wonder if i can use etc.so/rb in the specs? |
| 22:18:49 | brixen | cyndis: we shouldn't in the core specs |
| 22:18:57 | brixen | cyndis: if you need a helper, we'll add that to rubyspec |
| 22:19:04 | cyndis | ok |
| 22:19:12 | brixen | but I try to keep the deps in core specs not using any stdlib stuff |
| 22:19:30 | brixen | there are some places that this rule is currently broken, but those need to be fixed |
| 22:19:49 | cyndis | i'm needing File.expand_path's spec to use Etc.getpwnam to get the home directory of probably root and check if expand_path gives the same result |
| 22:20:14 | brixen | hrm |
| 22:20:20 | brixen | you mean, when running as root? |
| 22:20:39 | cyndis | no, any user, but root is probably the safest thing to check |
| 22:20:53 | cyndis | I mean, File.expand_path("~root") must equal root's home dir |
| 22:21:17 | cyndis | or whatever other user, but root should exists pretty much everywhere |
| 22:21:56 | brixen | hmm |
| 22:22:06 | brixen | this is a tough one |
| 22:22:24 | brixen | root won't exist on windows, but we can use platform_is guard for that |
| 22:22:31 | cyndis | yes |
| 22:22:41 | Defiler | You could just expand "." as well, right? |
| 22:22:43 | brixen | nobody would be better than root, maybe |
| 22:23:01 | brixen | Defiler: not for the "~<username>" case |
| 22:23:03 | cyndis | Defiler: but the point is to check if expand_path supports the ~username thing |
| 22:23:14 | brixen | File.expand_path("~root") |
| 22:23:14 | Defiler | Aah, well. Heh |
| 22:23:28 | brixen | yeah, pretty crazy right Defiler :) |
| 22:23:54 | Defiler | That seems reasonable then, because Win32 doesn't have that feature anyway :) |
| 22:24:19 | Defiler | Though if I were running the show, ~SomeUser on windows would expand to whatever their %USERPROFILE% variable would have given |
| 22:24:21 | brixen | cyndis: perhaps we have to make a helper in mspec that implements the ability to get this info |
| 22:24:42 | cyndis | yes, i guess so |
| 22:26:47 | brixen | cyndis: I'm open to using etc.rb in the helper I guess |
| 22:27:03 | brixen | cyndis: that way a beginning impl could potentially provide a different helper |
| 22:27:20 | cyndis | true |
| 22:27:25 | brixen | and the specs would be written in terms of the helper, hence agnostic about how the info is being acquired |
| 22:27:56 | brixen | if you check out the spec/custom dir, you can see how this works pretty well |
| 22:28:10 | brixen | ie extending mspec facilities in a farely systematic way |
| 22:28:37 | brixen | so, why don't you take a crack at writing the helper and just use etc.rb for a first cut |
| 22:28:53 | cyndis | i'll do that |
| 22:28:57 | brixen | sweet |
| 22:30:26 | cyndis | should i make the patch first for rubinius's in-tree mspec for directly for rubyspec/mspec? |
| 22:30:52 | cyndis | s/for/or/ |
| 22:32:26 | evan | cyndis: there is an easy test |
| 22:32:38 | brixen | um, either is fine |
| 22:32:45 | cyndis | ok :) |
| 22:32:47 | evan | File.expand_path("~#{ENV['USER']}").should == ENV['HOME'] |
| 22:33:13 | cyndis | but then an implementation could cheat and only support the username it's running as :p |
| 22:33:16 | evan | that works without anything else. |
| 22:33:29 | cyndis | or is that good enough? |
| 22:33:33 | evan | cyndis: don't get crazy with exhaustive tests |
| 22:33:35 | evan | yes, thats good enoug.h |
| 22:33:37 | brixen | cyndis: true, but it's unlikely that would be the case |
| 22:33:43 | cyndis | ok :) |
| 22:33:56 | brixen | cyndis: consider, they could cheat with any literal user you put in there |
| 22:34:00 | brixen | like root :) |
| 22:34:07 | cyndis | heh, true :p |
| 22:35:03 | evan | similarly they could hardcode all methods to pass all specs. |
| 22:44:00 | ddub | I think next year I'll buy extra RC tickets and ebay them |
| 22:47:47 | rue | My Ruby implementation passes all specs* and runs on average 2-3x faster than 1.9* |
| 22:48:00 | Defiler | Just not at the same time |
| 22:49:00 | rue | cyndis: I knew there was another one of us in here... |
| 22:49:43 | cyndis | of course. |
| 22:49:56 | rue | Should totally create a new user just for this purpose |
| 22:59:08 | ddub | hardcoding methods for benchmark performance and to pass specs seems like a great idea |
| 22:59:16 | ddub | like hardcoding an implementation for any method named fib |
| 23:05:37 | cyndis | actually rbx does special-case the ~myusername case before my patch, so cannot make the specs fail without the patch :p |
| 23:06:38 | cyndis | but now i'm off to sleep and continue tomorrow. --> |