Show enters and exits. Hide enters and exits.
| 00:24:37 | boyscout | Fixed rb_define_class_under. Thanks dbussink. - e8420c7 - Brian Ford |
| 00:25:22 | brixen | dbussink: fyi when you wake up, it still doesn't load but I have some other fixes that have to wait till I get to vegas |
| 00:29:59 | boyscout | CI: e8420c7 success. 2648 files, 10150 examples, 32392 expectations, 0 failures, 0 errors |
| 17:11:39 | boyscout | Fix Kernel#extend. - afe52b7 - Maximilian Lupke |
| 17:11:39 | boyscout | Made Array#unshift raise TypeError on frozen array - b75df5e - rohan |
| 17:11:39 | boyscout | Raise TypeError on attempts to modify frozen strings. - 1529cc6 - Nolan Darilek |
| 17:14:09 | boyscout | CI: 1529cc6 success. 2648 files, 10150 examples, 32392 expectations, 0 failures, 0 errors |
| 18:36:22 | dgtized | I thought we weren't implementing frozen checks everywhere for performance reasons? |
| 18:52:22 | dbussink | brixen: you there? |
| 19:13:02 | malumalu | dgtized: really? i never heard that before |
| 19:46:00 | dgtized | malumalu: for unshift that's something that should be fast and since it's got a helper method it has to do a dispatch for the local method, a check for size, and a check for the frozen field |
| 19:47:56 | dgtized | the patch doesn't untag the corresponding frozen specs either |
| 19:48:33 | dgtized | anyway, my understanding was we were supposed to hold off on anything related to frozen |
| 19:49:49 | malumalu | well, i didn't knew, sorry |
| 19:50:53 | malumalu | i just thought, if rubinius tries to be a compatible implementation, it should behave exactly the same |
| 19:50:59 | dgtized | it's ok, the last time it came up in discussion was at least a year ago I think, so don't worry about it -- my guess is even will want to revert, but it's fine |
| 19:51:39 | dgtized | yea, but it's a performance hog, and since nothing really uses frozen anyway, it's generally been something that we keep off table |
| 19:52:05 | dgtized | essentially the problem is we need some type of low level primitive to deal with the checks or else we are killing ourselves with needless dispatches from ruby land |
| 19:54:37 | malumalu | what about removing it from the specs, then? |
| 19:55:03 | malumalu | is it there because it's a copy of rubyspec? |
| 20:50:57 | marcandre | Hi guys. I'd like to understand what version(s) of ruby does rubinius target and how come the libraries seem like a mixup of 1.8.6 and 1.8.7. |
| 20:51:14 | marcandre | I couldn't find any thing, can someone point me to a source somewhere or enlighten me? |
| 21:00:31 | jptix | marcandre: what 1.8.7 features are you seeing? |
| 21:01:06 | marcandre | Well, for example Enumerable#all?, #any? |
| 21:01:24 | jptix | those are in 1.8.6 as well |
| 21:01:32 | marcandre | Also, a very screwed up #find_index I'd love to fix, but I don't know how to fix it since it shouldn't be there in 1.8.6 |
| 21:02:39 | marcandre | Oups, yeah, sorry about all? and any?, you're right. #find_index shouldn't be there though (plus it's not doing the right thing) |
| 21:04:10 | marcandre | There's also #max_by, #min_by, these are 1.8.7+ only. |
| 21:10:09 | marcandre | Here's the full list of methods which are defined in rubinius but new ti 1.8.7, just in Enumerable: count, find_index, first, group_by, max_by,min_by, none?, one? |
| 21:11:44 | marcandre | And as stated, I'd like to remove/fix Enumerable#find_index so that my backports gem be compatible with rubinius... I just don't know what I should be doing |
| 21:12:30 | rohan | hi |
| 21:12:58 | rohan | how do i get a commit bit after having a patch approved? |
| 21:54:21 | brixen | dbussink: pong |
| 21:54:56 | brixen | rohan: ping evan with you github name and the commit for your patch |
| 21:57:10 | rohan | brixen: ok, just message him on irc? |
| 21:59:14 | drbrain | rohan: yes |
| 21:59:36 | drbrain | rohan: but, he's at RailsConf, so it may be better to email him |
| 22:02:19 | rohan | ok thanks |
| 22:05:23 | dgtized | rohan: two comments on that patch, one is that since it fixed tagged failures it should have untagged those spec failures |
| 22:05:59 | dgtized | but secondly, and I guess brixen can comment on this better, but my understanding was that we are not supporting frozen at the moment |
| 22:06:25 | rohan | ah ok |
| 22:06:46 | rohan | that explains why all the frozen ones are still failing... |
| 22:06:52 | brixen | yes, that's right |
| 22:07:08 | brixen | frozen is something we will figure out eventually |
| 22:07:21 | brixen | we should not be adding it right now |
| 22:07:56 | dgtized | which means those two patches should probably be reverted? |
| 22:08:10 | brixen | I'll ask evan when I see him |
| 22:08:17 | brixen | which should be relatively soon |
| 22:08:26 | dgtized | k |
| 22:08:36 | brixen | but we shouldn't commit more frozen stuff until we write up how we'll do it |
| 22:09:04 | dgtized | rohan: I don't think this interferes with your commit bit though |
| 22:09:04 | brixen | marcandre: we generally are 1.8.6 compliant |
| 22:09:31 | brixen | marcandre: if 1.8.7 methods are not interfering with 1.8.6, it's probably ok to have them |
| 22:09:48 | brixen | but we have to be careful because code will check for those methods and make assumptions |
| 22:09:51 | brixen | stupidly |
| 22:10:01 | brixen | but even rails does that by checking for instance_exec |
| 22:10:34 | marcandre | brixen: Well, I wrote a gem that backports all of 1.8.7's features to 1.8.6... |
| 22:10:48 | brixen | that's an excellent way to do it |
| 22:11:06 | brixen | we should get that gem running and keep only 1.8.6 methods in rbx core lib |
| 22:11:09 | marcandre | brixen: I had the choice to either use method_defined? :something, or try things out, but I see no other way to go than to make assumptions |
| 22:11:35 | marcandre | brixen: So I'm assuming that either the method responds to 1.8.6's api, or 1.8.7. |
| 22:11:35 | brixen | well, sometimes it's ok to check for methods |
| 22:11:43 | brixen | I see |
| 22:12:03 | marcandre | But when it doesn't respond to either, ..., I'm not sure what to do :-) |
| 22:12:08 | brixen | right |
| 22:12:29 | brixen | well, it would be much better to have the API from MRI be tied to version instead of the existence of a method |
| 22:12:30 | rohan | so what are the parts of rubinius that need work? my c++ skills are rusty, but i've been working with ruby for a couple years now |
| 22:12:37 | marcandre | Anyways, I'll fix #find_index, coz it conflicts with 1.8.7 and I'll see about the others. Count is giving me problems too. |
| 22:12:48 | brixen | since all the alternative impl provide RUBY_VERSION |
| 22:13:06 | brixen | rohan: bin/mspec tag --list-all |
| 22:13:11 | rue | rohan: There are still Ruby parts, too |
| 22:13:41 | rohan | brixen: are the only things to ignore the frozen problems |
| 22:13:49 | brixen | rohan: yeah |
| 22:13:56 | rohan | brixen: ok cool |
| 22:14:00 | rohan | thanks |
| 22:14:16 | brixen | rohan: I've tagged most if not all the frozen specs with 'frozen' |
| 22:14:17 | marcandre | brixen: I'm _could_ be relying on RUBY_VERSION, but then I'd be screwing up with any other definition made by another lib |
| 22:14:23 | brixen | so you can do -G frozen |
| 22:14:49 | brixen | marcandre: yeah, I see the dilemna |
| 22:15:06 | marcandre | brixen: the more general question is: what's the plan for 1.9 compatibility? |
| 22:15:19 | brixen | it's a long ways off |
| 22:15:38 | brixen | 1.9 doesn't yet know the plan for 1.9 compatibility ;) |
| 22:15:45 | marcandre | brixen: Personally, I don't see why methods that are accessible only in 1.8.7 are accessible in 1.8.6 |
| 22:15:49 | brixen | focus on 1.8.6 |
| 22:16:20 | marcandre | brixen: lol, yeah. Still, 1.8.7 with all the enumerable stuff is really nice. It's because I want to use all of that while retaining 1.8 compatiblity that I wrote my gem |
| 22:16:36 | brixen | sure |
| 22:16:52 | brixen | if your gem runs on rbx, we'll be happy campers :) |
| 22:17:37 | marcandre | brixen: Well, it should, it runs on MRI and JRuby. I've submitted a first patch and I'll wait for the commit bit to fix the other stuff. |
| 22:17:43 | dgtized | rohan: they are kind of annoying, but Array#unpack and String#pack need some work |
| 22:17:51 | brixen | marcandre: ok cool |
| 22:18:23 | rohan | dgtized: ok great, i'll work on those. i've never used them for anything, so maybe after i implement them i'll know what they're good for and use them :) |
| 22:18:28 | brixen | fyi on Array#pack, don't untag specs unless you run them on PPC too |
| 22:18:35 | brixen | (or other big endian arch) |
| 22:18:48 | brixen | rohan: ^^^ |
| 22:18:56 | rohan | ok got it |
| 22:19:19 | brixen | I have access to a ppc machine running leopard if you need me to test stuff |
| 22:19:55 | dgtized | also for both pack and unpack I half converted those into a parser like architecture, but never got a chance to finish switching it to that style |
| 22:20:03 | dgtized | sorry not parser, but lexer |
| 22:20:21 | brixen | dgtized: yeah, that's a good idea |
| 22:20:44 | dgtized | with some parsing consumption of the tokens right after lexing, anyway I never quite got that changeover finished |
| 22:21:07 | dgtized | so even if it's not necessarily fixing spec failures, that code could do with some more cleanup |
| 23:10:09 | jarib | am i doing something wrong here, or should these tags be removed? http://gist.github.com/106709 |
| 23:12:04 | brixen | jarib: I think evan fixed a bunch of related stuff recently |
| 23:12:12 | brixen | tags probably should be removed |
| 23:12:25 | brixen | make sure full CI runs without them |
| 23:12:37 | brixen | eg bin/mspec ci -B full or rake |
| 23:12:38 | jarib | right |
| 23:16:25 | brixen | ok, I asked evan, we're reverting the frozen changes for now |
| 23:32:33 | jarib | brixen: full ci runs fine, i added a patch to lighthouse |
| 23:33:10 | brixen | jarib: ok cool, thanks |
| 23:33:21 | brixen | I'll take a look in just a sec |
| 23:39:20 | jarib | finding outdated tags seems like a task that could be easily automated |
| 23:44:01 | brixen | you might think that ;) |
| 23:44:26 | brixen | then you would work with tags a bit and discover that there can be dependent failures |
| 23:44:59 | brixen | but you can always do: bin/mspec tag --del fails :files |
| 23:45:41 | brixen | anyway, the best way is to fix a bug, remove those bugs tags, then run full CI to double check |
| 23:56:31 | boyscout | Fixed saving call_frame through native calls (pair Evan). - 9b9644d - Brian Ford |
| 23:56:31 | boyscout | Revert frozen commits: 1529cc63, b75df5e1, afe52b77. - 2ff4100 - Brian Ford |
| 23:56:56 | brixen | dbussink: it's a little closer |
| 23:57:38 | rbranson | OS X intel build working? I'm using 10.5.6 / gcc 4.2.1 / MRI 1.8.6 |
| 23:57:53 | brixen | should be, what are you seeing? |
| 23:57:55 | rbranson | (and it's bailing when trying to compile readline) |
| 23:58:11 | brixen | marcandre: what's the status of #767 ? |
| 23:58:18 | rbranson | Compiler::Node::Arguments#consume {} at kernel/compiler/nodes.rb:130 |
| 23:58:23 | rbranson | unshift method on nil |
| 23:58:41 | brixen | rbranson: use gist or pastie to paste the output, please |
| 23:59:15 | rbranson | http://gist.github.com/106723 |
| 23:59:33 | marcandre | brixen: I'm waiting for it to be accepted, committed and it should give me commit bit too :-) |