Show enters and exits. Hide enters and exits.
| 00:15:34 | evan | ok! |
| 00:15:42 | evan | finally got the MOP sorted out. |
| 00:16:29 | brixen | sweet! |
| 00:16:48 | evan | MetaClass is gone. |
| 00:16:57 | brixen | long live MetaClass |
| 00:17:01 | evan | in it's place, there is Class#__metaclass_object__ |
| 00:17:10 | brixen | mm interesting |
| 00:17:13 | evan | which returns non-nil for a metaclass |
| 00:17:19 | evan | sounds kludgy |
| 00:17:21 | evan | it is a bit |
| 00:17:32 | evan | but the semantics dictate it to a certain extent |
| 00:17:54 | brixen | sadly, correct is always better than elegant |
| 00:18:33 | brixen | did this affect #32 at all? |
| 00:19:17 | evan | checking |
| 00:19:45 | evan | dunno yet |
| 00:19:49 | brixen | k |
| 00:19:54 | brixen | just curious |
| 00:20:28 | evan | but 37 runs properly now. |
| 00:20:38 | evan | which is pretty much the MOP horror test. |
| 00:22:59 | brixen | heh, small world |
| 00:23:14 | brixen | I'm sitting here and realized a former client is seated next to me |
| 00:23:20 | evan | ha |
| 00:23:40 | brixen | I'm not at my desk obviously |
| 00:23:45 | brixen | heh, that'd be too weird |
| 00:24:41 | brixen | I'm going to ask them about testing their sites on rbx :) |
| 00:24:47 | evan | go for it! |
| 00:24:52 | brixen | heh, I am! |
| 00:28:24 | brixen | ok, maybe early jan we're going to sit down and run in a staging env |
| 00:28:34 | brixen | looks like they're using nokogiri |
| 00:31:30 | evan | we can do that :) |
| 00:31:38 | brixen | yep |
| 00:33:46 | evan | MOP MOP MOP |
| 00:33:47 | boyscout | Fix the MOP. Fixes #37. Passes MOP horror test. - ab073c4 - Evan Phoenix |
| 00:33:47 | boyscout | Work spec around broken unpack() - 3e593f9 - Evan Phoenix |
| 00:33:50 | evan | MOP MOP MOP |
| 00:34:17 | brixen | heh MOP Horror Test (tm) |
| 00:34:58 | evan | seriously |
| 00:35:08 | evan | that thing makes metaclasses of metaclasses of metaclasses |
| 00:36:30 | brixen | crap, just remembered... |
| 00:36:48 | brixen | evan: seen? http://www.flickr.com/photos/yugui/3571683843/ |
| 00:37:00 | brixen | and http://www.flickr.com/photos/yugui/3572489968/ |
| 00:37:21 | brixen | there's ones for 1.9 too |
| 00:37:24 | evan | mmm, not these ones specifcly |
| 00:37:28 | evan | but ones that were close |
| 00:37:32 | brixen | ah ok |
| 00:37:52 | evan | btw |
| 00:38:05 | evan | it's the horiz lines coming out from metaclasses that the MetaClass class went away |
| 00:38:19 | evan | the reason it went away |
| 00:38:48 | evan | because Meta:Bar.class == Meta:Class |
| 00:39:23 | brixen | hm |
| 00:40:57 | evan | gets his tools out and attacks String::Unpacker |
| 01:59:01 | rue | Metaobject protocol may be a nonobvious acronym. |
| 02:00:08 | brixen | I think all acronyms are non-obvious |
| 02:02:40 | rue | I like trying to guess acronyms |
| 02:03:00 | rue | Perhaps s/nonobvious/little-known/ |
| 02:06:07 | evan | it will be fun for them to find out |
| 02:06:13 | evan | it's like a scavenger hunt |
| 02:11:31 | brixen | evan: boyscout never reported and I think you need to remove metaclass.rbc from bootstrap and delta load_order.txt |
| 02:11:41 | brixen | gotta run to class or I'd push this |
| 02:11:47 | brixen | but I don't want to push and run |
| 02:11:48 | evan | ack. |
| 02:12:12 | brixen | ok, bbl... |
| 02:23:30 | rue | Maybe. |
| 02:23:50 | rue | Wonder if the standardisation to "eigenclass" will work out. It is an unwieldy word |
| 02:28:15 | rue | Huh, it dropped to -2ºF, going to see how the kitties like it and go to bed |
| 03:09:28 | boyscout | Hide a tasty MOP tidbit in the glossary - 750f10d - Wilson Bilkovich |
| 03:11:05 | boyscout | CI: Build 750f10d failed. http://ci.rubini.us/rubinius/builds/750f10d011ea7d12fea0aabe0473497de269331b |
| 03:16:46 | Defiler | brixen: These flickr shots of the 1.8 metaclass hierarchy.. am I reading the diagram wrong? It looks like it shows Class as the metaclass of Object's metaclass |
| 03:17:35 | Defiler | but Object.metaclass.metaclass is Class:<Class:Object>, right? |
| 03:53:55 | dwaite | ooh, < < metametaclass > > |
| 05:00:22 | boyscout | Moved compiler signature file. - fb79289 - Brian Ford |
| 05:00:22 | boyscout | Removed metaclass.rbc from kernel loading files. - c573065 - Brian Ford |
| 05:09:48 | boyscout | CI: c573065 success. 3017 files, 11576 examples, 35678 expectations, 0 failures, 0 errors |
| 07:58:18 | Defiler | I've found some more places where the MOP is different from 1.8, got all but one of them fixed, and a bunch more things commented |
| 07:58:29 | Defiler | but I should get some sleep so I will finish it tomorrow |
| 07:59:33 | Defiler | Class.metaclass.metaclass.superclass and Class.metaclass.superclass.metaclass should be the same object |
| 08:06:02 | Defiler | aha, got it |
| 08:13:02 | dbussink | evan: i saw you didn't reopen 114 yet, got time to take a look at it? |
| 08:16:10 | boyscout | Correct superclass for meta-metaclasses, document MOP - de83717 - Wilson Bilkovich |
| 08:16:17 | Defiler | that was fun |
| 08:17:06 | Defiler | brixen: evan: please feel free to review that commit; I'm pretty sure it is now exactly like 1.8.7, minus an inconsistency that isn't worth emulating |
| 08:20:07 | Defiler | The superclass of (Class's metaclass) changes in 1.8.7 after you open a metametaclass on it |
| 08:20:16 | Defiler | and that is insane |
| 08:24:14 | boyscout | CI: de83717 success. 3017 files, 11576 examples, 35678 expectations, 0 failures, 0 errors |
| 08:33:53 | evan | Defiler: you still there? |
| 08:33:58 | Defiler | yeah |
| 08:34:44 | evan | line 420 in object.cpp is bad news. |
| 08:34:59 | Defiler | How so? |
| 08:35:02 | evan | don't ever cast like that |
| 08:35:12 | Defiler | Oh, crap, forgot, yeah |
| 08:35:16 | evan | well for one |
| 08:35:25 | evan | there is no promise that class_object() is actually a MetaClass |
| 08:35:30 | evan | if you expect it to be |
| 08:35:32 | evan | you need to validate that |
| 08:35:38 | evan | and handle the case for it not being there |
| 08:36:03 | Defiler | Yeah, that part is ill-advised, definitely |
| 08:36:27 | evan | that line alone is why metaclass returned a Class* |
| 08:36:31 | evan | because for, say, Fixnum |
| 08:36:37 | evan | a Fixnum, rather. |
| 08:36:39 | Defiler | It seems like a place for an assert, so therefor an as? |
| 08:36:41 | evan | Fixnum the class is returned |
| 08:36:45 | evan | which is not a MetaClass. |
| 08:37:01 | evan | so either you should assert that metaclass can't be called on non-references |
| 08:37:10 | evan | or change metaclass back to just returning a Class* |
| 08:37:26 | evan | and require the caller of metaclass() to sort it out |
| 08:37:57 | Defiler | Virtually everything casts it to a Class* by passing it straight into something that expects that |
| 08:38:17 | Defiler | so there isn't much fuss in putting it back to Class*, but I'll take a look at what guarantees there are for a sec here.. |
| 08:38:19 | evan | whats it? |
| 08:38:31 | Defiler | the return value of metaclass() |
| 08:38:35 | evan | gotcha |
| 08:38:42 | evan | probably easier to have it return a Class* then. |
| 08:38:59 | Defiler | OK, so we never actually get to this code for a Fixnum accessed from ruby |
| 08:39:13 | Defiler | so calling this on an immediate in the VM would be a bug, I'd say |
| 08:39:50 | evan | nah |
| 08:39:59 | Defiler | but I'll just change it back |
| 08:40:01 | evan | not a bug |
| 08:40:07 | evan | Fixnum is the metaclass of 1 |
| 08:40:25 | Defiler | you get a typeerror doing that in ruby though |
| 08:40:29 | evan | a comment in there indicating that non-reference's metaclass is the class itself |
| 08:40:34 | evan | would be prudent. |
| 08:40:59 | Defiler | Why should this mechanism have a different definition of metaclass than the one ruby exposes? |
| 08:41:08 | evan | it doesn't. |
| 08:41:20 | evan | in ruby, the metaclass of 1 is Fixnum. |
| 08:41:25 | Defiler | How so? |
| 08:41:44 | Defiler | well, I mean, its 'klass' is Fixnum |
| 08:41:46 | evan | it's documented as such. |
| 08:41:52 | evan | the MRI docs indicate that. |
| 08:42:21 | Defiler | Huh. That just doesn't seem like a useful definition of metaclass to me, but oh well |
| 08:42:33 | Defiler | since the object system already handles the case of an object not having a metaclass |
| 08:42:48 | evan | if thats going to be the case |
| 08:42:55 | evan | i'd rather NOT have this method hard fail. |
| 08:43:03 | evan | ie, raise an exception |
| 08:43:10 | evan | since it's at such a lowlevel. |
| 08:43:25 | evan | and thusly, returning a best try is better imho. |
| 08:43:28 | Defiler | yeah, makes sense |
| 08:43:34 | Defiler | there's lots of code guarding this already |
| 08:44:18 | evan | ok, i'm off to bed. |
| 08:44:39 | evan | nite |
| 08:44:55 | Defiler | nite. thanks for noticing that haha |
| 08:54:12 | boyscout | Change metaclass() return value back to Class* - e86eb17 - Wilson Bilkovich |
| 09:00:40 | boyscout | CI: e86eb17 success. 3017 files, 11576 examples, 35678 expectations, 0 failures, 0 errors |
| 13:44:14 | scoopr | http://blip.tv/file/2232410 =) |
| 15:48:57 | dwaite | man what is with all the net splits lately? |
| 16:02:13 | cypher23 | dwaite, there's a DDOS going on against a few Freenode servers |
| 17:40:42 | brixen | morning |
| 17:51:48 | rue | Hi ho |
| 17:51:50 | evan | morning |
| 17:51:52 | evan | reading http://qntm.org/?destroy |
| 17:51:53 | evan | and loving it. |
| 17:55:35 | brixen | it's much easier to destroy all the people on the earth |
| 17:56:00 | dwaite | def. |
| 17:56:11 | dwaite | BYOO2, nice |
| 17:56:35 | evan | heheh |
| 17:56:37 | evan | Swallowed up as the Sun enters red giant stage |
| 17:56:37 | evan | You will need: patience |
| 17:56:45 | brixen | I like the "You will need" |
| 17:56:48 | brixen | heh yeah |
| 17:57:30 | evan | hehe |
| 17:57:32 | evan | Crunched |
| 17:57:32 | evan | You will need: considerably more patience |
| 17:57:47 | evan | that one is wait for the universe to finish expanding. |
| 18:14:52 | rue | Hm, it gets crunched? |
| 18:17:06 | evan | thats one of the scenarios |
| 18:17:18 | evan | after it expands, it contracts |
| 18:17:39 | evan | crushing all matter into a single point |
| 18:17:55 | evan | then bigbang, the next generation, begins! |
| 18:18:14 | evan | i'd call it BigBang 2.0, but we've got no idea how many times that might have already happened. |
| 18:28:26 | brixen | alas, time to tackle these #require specs |
| 18:29:10 | brixen | lasso, tie up, brand, drug, kick in the butt back out to pasture |
| 18:29:48 | evan | sounds like my teens. |
| 18:30:07 | evan | i helped a friend during calving season on his ranch in my teens. |
| 18:30:12 | brixen | fun! |
| 18:30:15 | evan | it was not I that was branded and drugged. |
| 18:30:20 | brixen | heh |
| 18:30:21 | evan | at least not in my teens. |
| 18:30:28 | evan | now college.... |
| 18:30:42 | brixen | pics or it didn't... |
| 18:30:43 | brixen | heh |
| 18:30:53 | evan | then it didn't happen. |
| 18:30:56 | evan | thats why there are no pics. |
| 18:31:17 | brixen | too bad |
| 18:31:27 | evan | *wink, wink8 |
| 18:31:28 | evan | * |
| 18:31:31 | brixen | heh |
| 18:32:03 | rue | Hm. I think I walked past this "LA Ink" place last time I was there |
| 18:32:19 | evan | on La Brea |
| 18:32:22 | evan | near Fountain |
| 18:32:32 | evan | across the street from Jon's, the grocery store |
| 18:32:55 | evan | next to Edible Arrangements!~ |
| 18:33:08 | evan | thats in my hood |
| 18:33:12 | evan | if you couldn't tell. |
| 18:37:08 | rue | Haha |
| 18:37:25 | rue | Maybe you could get rbx some air time by getting an elaborate tattoo |
| 18:37:45 | evan | maybe when 1.0 is out. |
| 18:37:55 | dwaite | would be a great time to announce the logo was changed to a reuben |
| 18:37:56 | evan | I think that kat has a long waiting list. |
| 18:37:57 | rue | Maybe :P |
| 18:38:09 | evan | as do the rest of the artists that are on the show. |
| 18:38:22 | rue | Fame does that to a place, I imagine |
| 18:38:23 | boyscout | Refactor String::Unpack into some methods - 28d6afc - Evan Phoenix |
| 18:38:24 | boyscout | Fix unpack's i and l modes - d19c3f1 - Evan Phoenix |
| 18:38:24 | boyscout | Add better i and l String#unpack specs - 8cf171e - Evan Phoenix |
| 18:38:24 | boyscout | Remove debugging in spec - 0c47b7e - Evan Phoenix |
| 18:38:27 | evan | this subject has come up among my friends before |
| 18:38:29 | rue | I had not seen the show until now |
| 18:38:40 | evan | are you watching one with Pixie? |
| 18:38:50 | evan | Kat's friend who was the receptionist |
| 18:39:01 | rue | Mm, no, some guy is the receptionist |
| 18:39:05 | evan | k |
| 18:39:10 | evan | i haven't watch in a whil |
| 18:39:11 | evan | e |
| 18:39:16 | evan | don't think i saw it at all last season. |
| 18:39:19 | rue | Season 2 apparently |
| 18:39:30 | evan | yeah, we watched some of season 1 |
| 18:39:38 | evan | it's what abby and I call "vacation TV" |
| 18:40:57 | rue | I am thinking of finally getting another tattoo...been planning a día de los muertos skull done as a mosaic , or an art nouveau piece |
| 18:41:02 | evan | TV you only watch on vacation |
| 18:41:05 | rue | Heh |
| 18:41:09 | evan | not TV that is itself a vacation. |
| 18:41:28 | evan | rue: oh nice. |
| 18:41:31 | rue | My TV watching has gone up 100% because I ran out of movies to watch while on the trainer |
| 18:41:35 | evan | i've been considering a bit more ink myself |
| 18:42:53 | evan | rue: hows the knee? |
| 18:42:57 | dwaite | I've never been inspired or drunk enough to get something inked perminently on my skin |
| 18:43:04 | boyscout | CI: 0c47b7e success. 3017 files, 11580 examples, 35697 expectations, 0 failures, 0 errors |
| 18:43:06 | dwaite | I think I'd actually need to be both |
| 18:43:21 | evan | you do have to sign a waiver when you get a tattoo that says you're not drunk. |
| 18:43:36 | evan | not that that keeps people from getting tattoo's drunk. |
| 18:44:12 | dwaite | yep, but it does help make you look like an ass when you go back and threaten to sue the next day |
| 18:44:39 | evan | thats the idea |
| 18:45:01 | dwaite | maybe I could get one on my back that says 'dude' or 'sweet' |
| 18:45:16 | dwaite | (that'd be a tough choice though) |
| 18:46:14 | evan | hah. |
| 18:46:22 | evan | how will you decide!? |
| 18:46:38 | evan | WHAT DOES MINE SAY?! SWEET! WHAT DOES MINE SAY?! DUDE! |
| 18:46:58 | evan | ah Dude Where's My Car, that bastion of modern cinema. |
| 18:47:03 | dwaite | that one scene made that whole movie bearable |
| 18:48:15 | dwaite | there are other good ones |
| 18:50:24 | evan | no and then! |
| 18:50:45 | dwaite | this is an emergency dude! so's this, its a breakdancing stripper emergency! |
| 18:52:03 | evan | who wants to talk about Undefined briefly |
| 18:52:15 | evan | i need to bounce some ideas around. |
| 18:56:29 | evan | i'm boggled at this: http://www.python.org/download/releases/2.3/mro/ |
| 18:56:33 | evan | so complicated |
| 18:56:34 | evan | man. |
| 19:01:00 | brixen | evan: shoot |
| 19:01:08 | evan | so |
| 19:01:13 | evan | doing |
| 19:01:19 | evan | Object.const_get "Undefined" |
| 19:01:20 | evan | doesn't work |
| 19:01:35 | evan | because recursive_const_get uses Undefined internally as a sentinal value |
| 19:01:41 | evan | to indicate that no values was retrieved |
| 19:01:50 | brixen | k |
| 19:01:58 | evan | now, i can special case Undefined in #const_get |
| 19:02:28 | evan | but I'm wondering if Undefined shouldn't be supported via a compiler plugin |
| 19:02:39 | evan | and perhaps an instruction |
| 19:02:43 | evan | ie, not a real constant. |
| 19:03:06 | brixen | hm, how does that change this case? |
| 19:03:28 | evan | it wouldn't be in Object.constants |
| 19:03:35 | evan | and thusly you wouldn't expect to be able to get it via const_get |
| 19:03:38 | evan | thats how this came up |
| 19:03:41 | brixen | ok |
| 19:03:43 | evan | Object.constants shows Undefined |
| 19:03:47 | brixen | gotcha |
| 19:04:05 | evan | i should note also that Undefined is going to get us into trouble: http://www.google.com/codesearch?q=lang%3Aruby+Undefined&hl=en&btnG=Search+Code |
| 19:04:08 | evan | other people do it too. |
| 19:04:23 | brixen | heh, yeah |
| 19:04:24 | Defiler | brixen: Got a second to let me bounce a MOP concept off you? |
| 19:04:25 | evan | and they create a toplevel Undefined class |
| 19:04:29 | evan | which will break instantly. |
| 19:04:34 | brixen | Defiler: sure, sec.. |
| 19:04:44 | evan | because we've got it as pointing to an bare object |
| 19:04:49 | brixen | yeah |
| 19:04:59 | brixen | well, it needs to be a lower level thing then |
| 19:05:25 | brixen | crazy how many things just get totally broken in Ruby based on impl details of MRI |
| 19:05:38 | evan | yep. |
| 19:05:46 | brixen | like, we could have a nice interesting system, in an alternate universe |
| 19:05:52 | evan | so, I can make it so that Qundef in the VM is spelled Undefined in rubyland. |
| 19:06:05 | brixen | that's what I was wondering |
| 19:06:18 | brixen | since we have Qundef, how to make it work in rubyland |
| 19:06:19 | Defiler | Ruby should just introduce None, a la Python |
| 19:06:23 | brixen | without breaking something else |
| 19:06:33 | brixen | None is nil, no? |
| 19:06:37 | evan | how about LikelyNot |
| 19:06:47 | evan | or MMMMMMMMMNo |
| 19:06:53 | brixen | how about NUL |
| 19:06:55 | brixen | heh |
| 19:06:58 | Defiler | I thought of an evil hack |
| 19:06:59 | Defiler | NaN |
| 19:06:59 | rue | evan: Knee is fine, no more bone showing on the ankle and even the back is in usable shape. Probably only 80-90% of what it was |
| 19:07:04 | brixen | Mu |
| 19:07:45 | evan | rue: thats good to hear it's getting back in shape |
| 19:07:47 | brixen | make it french Non |
| 19:08:20 | rue | Probably never going to be better than the 90% :) 'S not so bad though |
| 19:08:28 | brixen | Non, non, je ne regrette rien |
| 19:09:13 | evan | Rien |
| 19:09:14 | evan | hehe |
| 19:09:33 | evan | camu would be proud. |
| 19:09:37 | rue | It is not used a lot |
| 19:09:41 | evan | if he knew what a programmer was. |
| 19:09:43 | rue | Undefined, that is |
| 19:09:48 | evan | true, it's not. |
| 19:10:09 | rue | All uses thereof are for the same purpose, too |
| 19:10:15 | evan | yep |
| 19:10:29 | evan | a sentinal non-value.. |
| 19:10:37 | rue | So one avenue would be to have it added to spec |
| 19:10:46 | evan | ruby-std? |
| 19:10:52 | evan | i need to do this today |
| 19:10:54 | evan | not in 3 years. |
| 19:10:56 | rue | Heh |
| 19:11:14 | evan | people use use nil normally |
| 19:11:18 | evan | and live with the downside. |
| 19:11:22 | rue | I think I would leave it as-is |
| 19:11:27 | brixen | I'd make it a singleton like nil |
| 19:11:32 | brixen | but with a different name |
| 19:11:52 | brixen | since nil masquerades as a value too often |
| 19:12:03 | evan | hm |
| 19:12:08 | rue | Could add it as a pseudo-value "undefined", sure |
| 19:12:09 | evan | rue: well, i have to change something about the setup |
| 19:12:28 | evan | sure, i can turn a vcall to undefined into push_undef |
| 19:13:07 | evan | and have that only on in the kernel |
| 19:13:15 | rue | I kind of like the option to offer it to end-developers too as an internal sentinel, but that does require some co-operation |
| 19:13:21 | evan | yeah |
| 19:13:26 | rue | And does not need to be done immediately |
| 19:13:27 | evan | we can do that |
| 19:13:34 | evan | but i think we should solve our need first |
| 19:13:40 | rue | Yep |
| 19:13:53 | evan | ok, so |
| 19:13:55 | rue | brixen: Pseudo-var? |
| 19:14:06 | evan | you guys think turning some syntax into a push_undef instruction is fine though |
| 19:14:07 | evan | yes? |
| 19:14:15 | evan | so it's really then deciding on what syntax |
| 19:14:28 | Defiler | It seems like something that would be less likely to conflict than a toplevel constant |
| 19:14:41 | rue | Along with true/false/nil, undefined seems best |
| 19:14:43 | evan | Undefined is nice because we already have it |
| 19:14:51 | evan | i don't have to change any code |
| 19:15:01 | evan | and we don't have to open the reeducation camps |
| 19:15:01 | Defiler | the problem with Undefined is that if you bump into it, there's not a good workaround |
| 19:15:06 | rue | Plus Undefined stands out a bit better |
| 19:15:09 | Defiler | whereas undefined would let you do undefined(), self.undefined, etc etc |
| 19:15:25 | evan | Defiler: it's not going to be a real method though. |
| 19:15:26 | Defiler | but I agree with rue that Undefined is a little more obviously a constant/singleton thing |
| 19:15:30 | evan | k |
| 19:15:33 | evan | Undefined it is! |
| 19:15:39 | evan | toils away |
| 19:15:40 | Defiler | right, but I mean you can make it not be a vcall pretty easily, in client code |
| 19:16:37 | Defiler | brixen: So, let's pretend that I have a kernel alias 'm' for class << self;self;end |
| 19:16:41 | rue | Changing it is only a sed line, of course |
| 19:16:43 | evan | i'm wondering if i can just return Qundef |
| 19:16:52 | evan | i'm checking out how we use Qundef in the VM now |
| 19:16:57 | evan | and trying to figure out if anything will break |
| 19:17:04 | evan | i can add another Q var too. |
| 19:17:20 | Defiler | brixen: actually, I'll just make a self-contained gist |
| 19:17:26 | evan | hm, yeah, i'll add another Q. |
| 19:17:28 | rue | It should be fine to use in both cases, or then we are using it wrong, it would seem |
| 19:17:43 | evan | Qundef is used by the VM for some critical things |
| 19:17:50 | evan | i'm worried about it slipping in for a valid value |
| 19:17:54 | evan | and confusing things in the VM. |
| 19:18:12 | rue | Mm, it is a possibility |
| 19:18:16 | brixen | evan: if you're going to go compiler transform, I'd use 'undefined' |
| 19:18:25 | evan | :( |
| 19:18:29 | evan | why/ |
| 19:18:30 | evan | ? |
| 19:18:37 | evan | because we've got call transforms already? |
| 19:18:40 | brixen | well, we don't tranform constants now |
| 19:18:45 | brixen | Undefined is a call? |
| 19:19:08 | evan | right, i'd have to add the ability to transform a constant |
| 19:19:21 | evan | i think not breaking all the existing code has an big upside. |
| 19:19:21 | brixen | right |
| 19:19:37 | brixen | how does s/U/u/ break existing code? |
| 19:19:42 | evan | i have to change it all :) |
| 19:19:44 | rue | Changing the existing Undefineds is easy though |
| 19:19:51 | evan | and we have to tell people to not use it |
| 19:19:53 | evan | oh and plus |
| 19:19:57 | brixen | it's much easier than adding a new transform |
| 19:19:58 | evan | google code search for undefined |
| 19:20:04 | brixen | hm |
| 19:20:09 | evan | though, because it's a kernel transform |
| 19:20:11 | evan | that should be ok. |
| 19:20:31 | evan | hrmzers. |
| 19:20:59 | evan | ok. |
| 19:21:01 | evan | i'll do call. |
| 19:21:08 | evan | undefined it is. |
| 19:21:14 | evan | and to make the transition easy |
| 19:21:22 | evan | i'm going to have it return the same thing as Undefined |
| 19:21:25 | evan | ie, a bare object |
| 19:21:45 | evan | so we can use them interchanged briefly. |
| 19:22:33 | rue | $ sed -i s/Undefined/undefined/g kernelfiles # ? |
| 19:22:45 | evan | oh so clever. |
| 19:22:46 | evan | :D |
| 19:22:49 | evan | you're right. |
| 19:22:52 | evan | i never pull sed out. |
| 19:23:51 | Defiler | brixen: OK, so.. http://gist.github.com/258096 |
| 19:24:04 | Defiler | brixen: I am unable to reconcile that behavior with any of the recent diagrams that have been floating around |
| 19:27:09 | Defiler | updated it with an extended example |
| 19:27:23 | evan | huh. |
| 19:27:28 | evan | i'm not surprised terribly |
| 19:27:44 | Defiler | There are two 1.8 behaviors I didn't get going in rbx last night |
| 19:28:03 | evan | Defiler: try with a normal class |
| 19:28:08 | evan | class Blah; end |
| 19:28:10 | evan | and also |
| 19:28:12 | evan | a normal instance. |
| 19:28:59 | Defiler | I will in a sec. I did that last night and I'm pretty sure it works the same |
| 19:29:07 | Defiler | but I'll check it again after a quick meeting |
| 19:29:21 | evan | k |
| 19:29:27 | Defiler | this is behavior #2 that we don't comply with.. #1 is that on rbx Class.m.m.superclass == Module.m.m |
| 19:29:39 | Defiler | (which, according to the diagram, is actually true) |
| 19:29:45 | Defiler | on 1.8 that returns false, but I consider that a bug in 1.8 |
| 19:29:52 | evan | hm ok. |
| 19:30:06 | Defiler | since the superclass of Class's meta-metaclass is the meta-metaclass of Module ha ha |
| 19:30:10 | Defiler | back in a sec though |
| 19:33:06 | rue | 1.9.1 changes this slightly |
| 19:47:56 | boyscout | When immediates are frozen or tainted, they return themselves, not false - 6acdbf1 - Yehuda Katz |
| 19:47:56 | boyscout | Fix issue where negative integers were being treated incorrectly in sprintf. This was causing a bug in ActiveSupport. - 40bfb00 - Yehuda Katz |
| 19:47:56 | boyscout | included is called over and over again even if the module was already included (append_features is not) - c934da9 - Yehuda Katz |
| 19:47:56 | boyscout | Gives Enumerator #with_index powers - 016902e - Yehuda Katz |
| 19:50:22 | evan | now |
| 19:50:25 | evan | to recall how to use sed. |
| 19:50:50 | boyscout | CI: 016902e success. 3017 files, 11584 examples, 35722 expectations, 0 failures, 0 errors |
| 19:52:00 | evan | there we go. |
| 19:52:03 | evan | a little for + sed magic. |
| 19:52:18 | brixen | argh with the commits to spec/frozen embedded in other commits |
| 19:52:21 | brixen | le sigh |
| 19:52:29 | evan | bad wycats! |
| 19:52:33 | evan | i told him not to do that. |
| 19:52:38 | brixen | destroys rubyspec and moves everything back to rubinius |
| 19:52:42 | brixen | evan: you did it too |
| 19:52:45 | evan | brixen: i did? |
| 19:52:49 | evan | bad me. |
| 19:52:51 | evan | sorry. :( |
| 19:52:56 | evan | sorry. |
| 19:53:00 | brixen | d19c3f17 |
| 19:53:02 | evan | maybe we should revoke committing to frozen. |
| 19:53:10 | evan | if it's too much trouble. |
| 19:53:14 | brixen | how do we enforce that? |
| 19:53:21 | brixen | I'm not sure which is more trouble |
| 19:53:30 | brixen | I'm going to sync specs once a week at least |
| 19:53:34 | evan | well, there are few updates to specs these days |
| 19:53:41 | evan | a lot fewer than in the past |
| 19:53:41 | brixen | I just don't want to lose stuff |
| 19:53:44 | evan | and they're mostly by me now. |
| 19:53:52 | evan | how about this |
| 19:54:01 | evan | sync from rubyspec one way |
| 19:54:08 | evan | and require changes to frozen to go into rubyspec too |
| 19:54:19 | evan | require as in say "don't jsut make them in frozen or they'll disappear!" |
| 19:54:29 | evan | that gives me what I want |
| 19:54:36 | evan | which is changing a spec, making it pass, commiting. |
| 19:54:43 | brixen | yes |
| 19:54:50 | brixen | and you can work right in spec/ruby for that |
| 19:54:56 | evan | yeah |
| 19:54:59 | evan | but sometimes i have to change a spec |
| 19:55:01 | evan | or somethnig |
| 19:55:01 | brixen | but I don't have a way to enforce it |
| 19:55:02 | evan | to make it pass |
| 19:55:10 | evan | sure we do! |
| 19:55:17 | evan | we say "make it just in frozen, it will disappear!" |
| 19:55:22 | brixen | heh |
| 19:55:29 | scoopr | post-receive-hook? ;) |
| 19:55:42 | evan | scoopr: i considered that, but github doesn't have that support I don't think. |
| 19:55:49 | scoopr | ah right'o |
| 19:56:23 | evan | brixen: i wanna make it easier on you |
| 19:56:24 | brixen | I can set spec/frozen to read-only though, right? |
| 19:56:43 | evan | well, how about the one way sync only |
| 19:56:50 | brixen | sure |
| 19:56:52 | evan | that way people can basically update frozen as they work on it |
| 19:56:59 | evan | but they have to put the changes in rubyspec at the same time |
| 19:56:59 | brixen | but I don't like losing stuff |
| 19:57:02 | brixen | seems heavy handed |
| 19:57:13 | evan | i think at this stage we can be heavy handed |
| 19:57:19 | wycats | brixen: just doing what evan said :) |
| 19:57:20 | evan | because spec changes are slowing down. |
| 19:57:33 | brixen | wycats: no, evan would not say that |
| 19:57:39 | wycats | ? |
| 19:57:41 | brixen | I've berated him enough about it |
| 19:57:44 | evan | wycats: well, you're not supposed to change spec/frozen with other commits |
| 19:57:45 | wycats | evan would not say what? |
| 19:57:54 | wycats | evan: you didn't tell me that |
| 19:57:54 | evan | if I did not communicate that |
| 19:57:56 | evan | thats my mistake. |
| 19:57:58 | wycats | :) |
| 19:58:05 | evan | anyway |
| 19:58:07 | wycats | I was just trying to follow instructions :/ |
| 19:58:09 | rue | The submodule approach has some merit |
| 19:58:10 | evan | lets figure out how to make this the last time. |
| 19:58:20 | wycats | I knew I was doing something controversial! |
| 19:58:23 | wycats | sighs |
| 19:58:33 | evan | rue: it's the same, since you can't esaily commit back to a submodule |
| 19:58:34 | evan | and we tried that |
| 19:58:41 | evan | thats the extreme way |
| 19:58:42 | brixen | no submodules |
| 19:58:52 | rue | Sure you can, it is a live repo |
| 19:59:32 | rue | But, in the absence of submodules, committing to rubyspec and pulling would probably be easier to enforce |
| 19:59:58 | brixen | evan: I'll sync one way from rubyspec |
| 20:00:21 | evan | ok |
| 20:00:21 | brixen | evan: but I'll still try to check commits to spec frozen |
| 20:00:27 | evan | brixen: so |
| 20:00:28 | evan | lets do this |
| 20:00:29 | evan | if you find them |
| 20:00:32 | evan | just tell the person |
| 20:00:37 | brixen | yeah |
| 20:00:39 | evan | let them clean up their own mess |
| 20:00:40 | evan | like me! |
| 20:00:49 | evan | since i'm the one that creates the most mess. |
| 20:01:23 | brixen | well, the problem is, ppl create messes in rubyspec too |
| 20:01:31 | brixen | and I try to clean that up before syncing |
| 20:01:57 | brixen | I'd like to remove any reason to commit to spec/frozen at all |
| 20:02:04 | evan | ok |
| 20:02:12 | evan | my only reason is broken specs |
| 20:02:12 | wycats | I have commit to rubyspec |
| 20:02:13 | brixen | the only reason to do is is because the tags are out of sync with rubyspec |
| 20:02:18 | wycats | but I don't know how to pull into frozen |
| 20:02:21 | rue | Sure. There is just a sync lag, which makes it a little less convenient |
| 20:02:23 | evan | or adding specs for behaviors |
| 20:02:25 | wycats | so I could just push to rubyspec |
| 20:02:30 | evan | that i wanna test now. |
| 20:02:34 | brixen | wycats: you don't need to pull into spec/frozen |
| 20:02:34 | evan | those could wait though |
| 20:02:43 | brixen | wycats: you need to commit rubyspecs to rubyspec |
| 20:02:49 | wycats | brixen: I'd want to so I could run the tests and make sure things pass |
| 20:02:57 | wycats | brixen: there's a weird dichotomy here |
| 20:03:00 | brixen | wycats: you can |
| 20:03:05 | wycats | on the one hand rubyspec *is* the spec suite for rbx |
| 20:03:10 | wycats | on the other hand, it's its own project |
| 20:03:12 | brixen | rake rubyspec:update |
| 20:03:14 | wycats | k |
| 20:03:21 | brixen | bin/mspec ci spec/ruby/blah |
| 20:04:02 | brixen | evan: so, get this flow... |
| 20:04:06 | rue | That would be the better workflow |
| 20:04:16 | brixen | rue: hang on a sec |
| 20:04:27 | wycats | brixen: it would be helpful if there was a rake task that did the right thing |
| 20:04:28 | brixen | evan: you are working on the specs for Foo#bar |
| 20:04:40 | brixen | wycats: there isn't a simple right thing |
| 20:04:44 | brixen | please listen |
| 20:04:47 | brixen | I have the mic |
| 20:04:48 | brixen | k |
| 20:04:49 | brixen | ? |
| 20:04:56 | wycats | ok |
| 20:05:09 | brixen | you are working on Foo#bar |
| 20:05:14 | brixen | some method in some core class |
| 20:05:22 | brixen | you are writing a spec for some behavior |
| 20:05:31 | brixen | you rake rubyspec:update |
| 20:05:40 | brixen | which pulls the current rubyspec into spec/ruby |
| 20:05:53 | brixen | you run bin/mspec ci spec/ruby/core/foo/bar |
| 20:05:59 | brixen | you should get no failures |
| 20:06:11 | brixen | because the tags work with both spec/frozen and spec/ruby |
| 20:06:23 | brixen | you write your specs and commit to rubyspec |
| 20:06:28 | brixen | you make your specs pass |
| 20:06:38 | brixen | commit that to rubinius |
| 20:06:50 | evan | well, for me at least |
| 20:06:54 | brixen | the CI specs continue passing (they run on spec/frozen) |
| 20:06:56 | evan | writing the specs isn't a solo activity |
| 20:07:00 | evan | i don't do it all upfront. |
| 20:07:08 | evan | so it's going to be interleaved with doing the impl. |
| 20:07:09 | brixen | it wouldn't need to be |
| 20:07:10 | evan | anyway, continue. |
| 20:07:23 | brixen | well, why would it need to be up-front? |
| 20:07:37 | brixen | I'm just saying, commit to rubyspec and run directly from spec/ruby |
| 20:07:56 | evan | ok |
| 20:08:02 | brixen | at least once a week, I'll sync to spec frozen |
| 20:08:04 | rue | What is in spec/ruby? Just pure clone? |
| 20:08:15 | brixen | the only problem is, the CI specs run on spec/frozen, not spec/ruby |
| 20:08:20 | evan | yes |
| 20:08:20 | evan | so |
| 20:08:31 | brixen | so your new specs would not be reflected in CI for up to a week |
| 20:08:33 | brixen | is that ok? |
| 20:08:34 | wycats | brixen: what's special about spec/frozen? |
| 20:08:35 | evan | what if doing "rake" run 'ci spec/ruby' if it existed. |
| 20:08:54 | evan | rather than 'ci spec/frozen' |
| 20:09:05 | brixen | well, the problem is new specs get commited to rubyspec that don't have tags for rbx |
| 20:09:14 | rue | I would be on the side of doing that and solving issues as they came up... |
| 20:09:18 | brixen | you can't get a guaranteed clean CI if you broke nothing |
| 20:09:32 | brixen | spec/frozen is for CI |
| 20:09:38 | evan | right |
| 20:09:39 | evan | ok |
| 20:09:43 | brixen | everyone should run it before commiting |
| 20:09:48 | brixen | the bot runs it as insurance |
| 20:09:54 | evan | the issue is that people wanna run all the specs to make sure they didn't break anything unassociated |
| 20:10:02 | evan | which i guess they can do by running the frozen specs |
| 20:10:02 | brixen | right, that still works |
| 20:10:05 | wycats | bin/mspec ci spec/frozen? |
| 20:10:06 | brixen | yes |
| 20:10:15 | brixen | and your own new specs you should run directly |
| 20:10:18 | rue | Complemated |
| 20:10:24 | brixen | since that's what you are working on |
| 20:10:39 | brixen | rue: use words if you want to be taken seriously |
| 20:10:40 | brixen | please |
| 20:11:03 | rue | I dun think there is any risk of that happening. |
| 20:11:11 | brixen | wycats: rake is all you need to do to run the CI specs and vm tests |
| 20:11:32 | brixen | anyone who pushes should run rake before pushing |
| 20:11:49 | wycats | did not know that, but now do |
| 20:12:08 | brixen | I'm trying to simplify one specific flow: 1) new specs are needed, AND 2) new rbx code is needed |
| 20:12:39 | brixen | if fixing an existing spec failure, you just commit to rbx |
| 20:12:48 | brixen | if just writing specs, just commit to rubyspec |
| 20:13:03 | brixen | so it's just this one intersection of rubyspecs and rbx code |
| 20:13:06 | rue | And then pull to have coverage. |
| 20:13:14 | evan | i think this is fine if and only if the sync from spec/ruby to frozen is often. |
| 20:13:16 | evan | if it's rare |
| 20:13:19 | evan | then it won't work. |
| 20:13:27 | brixen | evan: yeah, it will be often |
| 20:13:45 | evan | say there is a bad spec |
| 20:13:46 | brixen | or, we can just let it be |
| 20:13:50 | evan | a tag works for you, but not me. |
| 20:13:54 | evan | should I change that in spec/frozen? |
| 20:14:02 | brixen | change the spec or the tag? |
| 20:14:05 | evan | should I change the spec rather |
| 20:14:06 | evan | it depends |
| 20:14:09 | evan | say the spec is bad |
| 20:14:12 | rue | Weekly is not very often, and on the other hand, it is not fair to have you wade through all that code |
| 20:14:17 | evan | should I just tag those |
| 20:14:27 | evan | and never fix specs in frozen |
| 20:14:28 | brixen | a bad spec should be fixed |
| 20:14:34 | brixen | hm |
| 20:14:44 | evan | i really do not want to add more tags. |
| 20:14:51 | evan | we have a big problem with tags atm. |
| 20:15:03 | evan | because things get tagged and forgetten about |
| 20:15:06 | rue | I think I would prefer to live on the edge and use rubyspec head, fixing issues as they occur (or, as a last resort, tagging them away) |
| 20:15:06 | brixen | we have relatively few tags really |
| 20:15:09 | wycats | brixen: it's a weird intersection but it's where I live |
| 20:15:13 | wycats | because I'm fixing issues with Rails |
| 20:15:29 | evan | brixen: i wanna avoid creating any unnecessary fails tags. |
| 20:15:36 | evan | because fails tags are hidden. |
| 20:15:47 | evan | we can try and make them not hidden |
| 20:15:50 | brixen | they're only hidden from CI |
| 20:15:54 | evan | perhaps by reporting how many there |
| 20:15:58 | evan | sure, but because rake runs ci |
| 20:16:08 | evan | everything but ci is more hidden |
| 20:16:08 | rue | The most common breakage from head would be unguarded stuff anyway, no? Might as well fix those at the same time |
| 20:16:22 | brixen | rue: it's not that simple, believe me |
| 20:16:30 | brixen | that is why I just tag when syncing |
| 20:16:42 | rue | Probably not, but this is not really very simple either |
| 20:16:42 | brixen | it's often very hard to fix new failures |
| 20:16:44 | evan | rue: it's more about people changing rubyspec and then brixen having 100 new failures |
| 20:16:54 | evan | we can't expect him to fix all those 100 before he syncs |
| 20:17:13 | evan | so they're tagged as fails |
| 20:17:15 | evan | and we move on |
| 20:17:25 | evan | but we don't prune those fails tags often enough |
| 20:17:27 | brixen | the simplest possible thing is this: if you commit to spec/frozen, ONLY commit to spec/frozen |
| 20:17:29 | evan | thats an influencing factor here. |
| 20:17:30 | rue | That could be done by whoever is adding the spec |
| 20:17:31 | brixen | that is seriously the simplest |
| 20:17:41 | brixen | and everyone can go about their business |
| 20:17:47 | brixen | cus I can find the commit easily |
| 20:17:50 | evan | but thats more work for you. |
| 20:17:51 | rue | I was specifically trying to avoid having a "bottleneck" (not meant negatively) |
| 20:17:56 | rue | Exactly |
| 20:18:07 | brixen | no, more work is trying to extract changes embedded in commit |
| 20:18:17 | evan | ok |
| 20:18:22 | evan | so you no longer do that |
| 20:18:23 | evan | ever. |
| 20:18:24 | brixen | I can git fp, change paths and commit to rubyspec very easily |
| 20:18:27 | evan | if people do that |
| 20:18:28 | evan | well oops |
| 20:18:30 | evan | we loose it. |
| 20:18:33 | evan | thats how it goes. |
| 20:18:36 | brixen | k |
| 20:18:52 | evan | so without that |
| 20:19:00 | evan | is the frozen => spec/ruby sync very time consuming? |
| 20:19:06 | evan | could it be codified in a rake task? |
| 20:19:06 | brixen | no |
| 20:19:13 | brixen | rake rubyspec:sync |
| 20:19:19 | brixen | then fix up the tags |
| 20:19:41 | brixen | the problem is making sure idiotic shit is not committed to rubyspec |
| 20:19:47 | brixen | which it often is |
| 20:19:52 | evan | ok |
| 20:19:54 | brixen | so, it's not just running the rake task |
| 20:19:58 | brixen | it's paying attention |
| 20:20:03 | evan | so frozen, baring the embedded change, is not really the issue |
| 20:20:03 | brixen | something no often done :P |
| 20:20:06 | evan | thats a red herring |
| 20:20:20 | brixen | losing specs embedded in other commits to rbx is the issue |
| 20:20:28 | rue | That should never happen anyway |
| 20:20:39 | evan | brixen: ok, but thats no longer going to be your concern |
| 20:20:54 | rue | Spec and code should always be separate commits |
| 20:21:10 | brixen | I'm sure it will happen, but less I hope |
| 20:21:19 | evan | if it happens a lot (does it?) then we can have boyscout report it |
| 20:21:24 | rue | But I think that having more people more immediately impacted by the rubyspec head would only be beneficial |
| 20:21:24 | brixen | rue: yes, we agreed on that almost 3 years ago :) |
| 20:21:27 | evan | and rather than brixen fixing it |
| 20:21:32 | evan | the committer needs to fix it. |
| 20:21:46 | evan | if we lose specs |
| 20:21:53 | evan | thats a lose i'm prepared to take |
| 20:22:34 | evan | brixen is not our personal janitorial service. |
| 20:22:46 | evan | I'M LOOKING AT YOU EVAN. |
| 20:22:55 | evan | shys away from himself. |
| 20:23:10 | rue | So, make everyone run off rubyspec head |
| 20:23:53 | brixen | well, it would play out like this: broken spec in rubyspec, fixed in spec/frozen, I sync, and now weird shit fails |
| 20:23:57 | brixen | and it's lost |
| 20:23:59 | brixen | and that sucks |
| 20:24:11 | rue | All spec commits directly to rubyspec |
| 20:24:14 | brixen | haha |
| 20:24:15 | evan | the issue with running off rubyspec head is that not everyone who makes rubyspec head changes checks their spec changes on all impls |
| 20:24:38 | evan | brixen: then wierd shit it is |
| 20:24:42 | evan | i'm ok with that. |
| 20:24:59 | brixen | evan: how hard would it be to have boyscout report if there are other files changed if there are spec/frozen changes? |
| 20:25:03 | brixen | that would be nice |
| 20:25:06 | brixen | and visible |
| 20:25:10 | evan | because if that broken spec is embedded in another commit (like I did) then we loose it. |
| 20:25:13 | rue | True, not everyone does. But it would A) be possibly found quicker and B) fixed quicker by the developer who is committing a spec |
| 20:25:25 | brixen | rubyspec head is not a viable option |
| 20:25:35 | evan | brixen: sure, i can do that. |
| 20:25:39 | rue | I do not see why it is not |
| 20:25:44 | brixen | evan: that would be rad |
| 20:26:12 | evan | brixen: can we automate rubyspec:sync? |
| 20:26:19 | evan | have it just tag all failures |
| 20:26:19 | brixen | not really |
| 20:26:25 | brixen | I don't want to automate that |
| 20:26:30 | rue | It would simplify the workflow and consistency on the implementation side |
| 20:26:34 | brixen | I want to ensure I don't lose spec fixes |
| 20:26:56 | brixen | evan: you can't just tag segfaults and hangs |
| 20:27:06 | evan | m true |
| 20:27:07 | brixen | I don't want to automate rubyspec:sync |
| 20:27:14 | evan | ok |
| 20:27:21 | brixen | I want to automate not allowing spec/frozen changes embedded |
| 20:27:25 | brixen | I think that's it |
| 20:27:27 | evan | ok |
| 20:27:28 | rue | In contrast to having to juggle two spec sets on this side, and having you wade through all the specs by yourself. |
| 20:27:29 | evan | lets do that. |
| 20:28:07 | brixen | in fact, maybe we should change spec/frozen to something |
| 20:28:18 | brixen | and just have ppl commit to that in rbx |
| 20:28:23 | brixen | not rubyspecs |
| 20:28:46 | brixen | but still complain about combining spec and code changes |
| 20:29:19 | evan | how do ya mean? |
| 20:29:21 | brixen | spec/therealdeal/ |
| 20:29:23 | evan | just a different directory? |
| 20:29:25 | brixen | spec/mehere |
| 20:29:37 | evan | how does that help? |
| 20:29:40 | rue | I think that is the wrong way to solve the problem. |
| 20:29:45 | brixen | just name it different so ppl aren't confused |
| 20:29:59 | brixen | because there would be a single place ppl are commiting |
| 20:30:08 | brixen | and it's all contained in rbx |
| 20:30:14 | brixen | easy to push to rubyspec |
| 20:30:18 | brixen | easy to sync back |
| 20:30:21 | brixen | easy to explain |
| 20:30:32 | brixen | as long as no specs are embedded in other commits |
| 20:30:55 | evan | how is that not frozen? |
| 20:31:01 | evan | actually, don't answer that. |
| 20:31:03 | evan | i need lunch. |
| 20:31:04 | brixen | it's exactly the same |
| 20:31:06 | brixen | heh |
| 20:31:13 | brixen | me too |
| 20:31:21 | evan | ok, lets ponder over lunch |
| 20:31:21 | brixen | in fact, I need to see a guy about internets |
| 20:31:25 | evan | and discuss afterwords. |
| 20:31:27 | brixen | ok |
| 20:31:53 | rue | I will just type this up in the meanwhile. |
| 20:32:43 | evan | k |
| 20:32:53 | evan | rue, official scribe. |
| 20:33:17 | rue | Nuh, just my workflow from an rbx point of view. |
| 20:34:02 | rue | 1. Everyone should be committing to rubyspec directly. Single point of entry. Also avoids duplication of work (rare as it may be) |
| 20:35:15 | Defiler | evan: Sorry, meeting took longer than I thought. Same behavior for non-class-objects http://gist.github.com/258096 |
| 20:35:20 | rue | 2. Pull from rubyspec to get the new stuff to rbx, with $ rake spec:update or whatever. Run specs. |
| 20:35:58 | Defiler | I guess I need to break out omnigraffle and make a revised MOP diagram for 1.8 |
| 20:36:05 | Defiler | because I don't think the current one is quite right |
| 20:36:32 | rue | 3. Solve issues caused by other commits to rubyspec head (unless already did before your commit). brixen: Which issues are likely to be encountered, aside from missing guards? |
| 20:37:17 | rue | 4. Automation, including CI, runs off head as well. Avoids sync lag. |
| 20:44:12 | Defiler | anyone happen to know where the meta-metaclass code lives in MRI? |
| 20:46:43 | wycats | Defiler: what problem are you having? |
| 20:46:56 | Defiler | this: http://gist.github.com/258096 |
| 20:47:17 | rue | http://gist.github.com/258150 |
| 20:47:29 | Defiler | Trying to make our behavior match that, but changing the superclass of the receiver just seems like a gnarly thing to do when attaching a metaclass |
| 20:48:06 | rue | Slightly easier to see ;) |
| 20:48:52 | Defiler | Yeah, there you go. Looks like the last line got cut off though |
| 20:49:17 | rue | Mm, mibbe |
| 20:49:48 | rue | 1.9.1 also produces #<Class:Object> for Module.m.superclass |
| 20:50:07 | wycats | this stuff is actually rather important |
| 20:50:12 | wycats | breakage can cause weird bugz |
| 20:50:50 | wycats | yeah lots of diffs |
| 20:50:51 | Defiler | Yeah, 1.9 is definitely different |
| 20:50:53 | rue | And Module.m.m.superclass |
| 20:51:05 | rue | We are pretty much 1.9.1 except BasicObject |
| 20:52:17 | wycats | superclass of a metaclass not being class seems odd |
| 20:52:29 | wycats | ahh |
| 20:53:07 | Defiler | rue: after last night, we are 1.8 other than this one behavior |
| 20:53:29 | rue | Two? |
| 20:53:36 | wycats | I thought rue said 1.9 |
| 20:53:52 | Defiler | Yeah, I disagree. heh |
| 20:55:41 | Defiler | So, it looks to me like the 1.8 logic is... |
| 20:56:02 | Defiler | when opening a metaclass on something that is already a metaclass, determine the correct superclass for the new metaclass.. |
| 20:56:14 | Defiler | ..and then set the superclass of the receiver to be the same |
| 20:59:34 | rue | Updated http://gist.github.com/258150 |
| 21:01:11 | rue | There are several differences, maybe caused by same you mean? |
| 21:01:41 | Defiler | Yeah |
| 21:01:53 | Defiler | I mean, it all looks like the same mechanism in all of those differences |
| 21:03:20 | rue | Added 1.9.1 output down there too just for fun |
| 21:16:39 | wycats | so I guess one question is whether this is important |
| 21:17:24 | Defiler | Personally I think the answer is no, but I would like to have a canonical diagram for 1.8 |
| 21:17:47 | Defiler | meta-metaclasses are totally useless anyway, much less their superclass chain |
| 21:18:47 | rue | I do not really like the changing midstream |
| 21:19:31 | Defiler | What are the other scenarios in Ruby where the superclass of an object changes? |
| 21:19:44 | Defiler | (as in, the return value of .superclass, not the effective superclass) |
| 21:24:45 | rue | Anything in the specs? |
| 21:25:05 | Defiler | Nope. I haven't found any specs for the meta-metaclass stuff at all |
| 21:25:11 | Defiler | wanted to fully understand it before adding some |
| 21:27:12 | dbussink | evan: did you my question about issue #114? |
| 21:28:09 | wycats | superclasses should not actually change |
| 21:28:09 | wycats | that sounds bad |
| 21:30:05 | rue | Likely why the behaviour is different in 1.9.1 |
| 21:30:06 | Defiler | It sure feels like a bug in 1.8 to me, yeah |
| 21:37:05 | rue | Checking with 1.8.7 head, but I doubt it has been changed |
| 21:37:28 | Defiler | I've been doing this testing on 1.8.7 174 |
| 21:38:46 | evan | man freenode is a mess. |
| 21:39:08 | rue | Join/leave turned off, dunno |
| 21:40:14 | Defiler | some DDoS going on apparently |
| 21:42:18 | rue | My workflow is above somewhere. |
| 22:01:25 | evan | rad |
| 22:01:37 | evan | i updated my ruby.vim to highlight undefined the same as true/false/nil/self |
| 22:03:04 | Defiler | oh no you've forked ruby.vim and caused a schism in the community! |
| 22:03:04 | evan | gah :/ |
| 22:03:10 | evan | Undefined is used in stringio.rb |
| 22:03:21 | evan | Defiler: the great schism! |
| 22:03:24 | evan | of ruby.vim users! |
| 22:03:38 | Defiler | now we can have xruby.vim and gnuruby.vim |
| 22:04:06 | evan | maybe i should have called the rubinius executable xuby |
| 22:04:07 | evan | rather than rbx |
| 22:04:19 | evan | abby asked me the other day "why is the rubinius command rbx?" |
| 22:04:24 | evan | "there is no x in the word, why not rbs?" |
| 22:04:40 | evan | me: "um, because it looks cooler? and phoenix ends with an x?" |
| 22:04:42 | Defiler | Clearly she will never understand our religion |
| 22:04:56 | rue | Was she cross about it? |
| 22:05:01 | evan | nah |
| 22:05:02 | evan | jsut curious |
| 22:05:06 | rue | Pun! |
| 22:05:13 | evan | OH DAMN |
| 22:05:15 | evan | I GOT PUNIFIED |
| 22:05:26 | rue | OK, so I am not trying 1.8.7 head, apparently I installed 1.9.2dev |
| 22:05:47 | evan | oops. |
| 22:05:50 | Defiler | haha, i've done that |
| 22:05:52 | evan | well, we're glad you checked. |
| 22:27:16 | boyscout | Change Undefined to undefined. - ff082ab - Evan Phoenix |
| 22:34:03 | boyscout | CI: ff082ab success. 3017 files, 11584 examples, 35722 expectations, 0 failures, 0 errors |
| 22:39:13 | brixen | I can't wait for xmas to be over |
| 22:39:21 | brixen | what a lame holiday :P |
| 22:39:35 | brixen | thanks to all the crazy people |
| 22:40:30 | brixen | also, people who have no clue should not be sales reps for something like wimax |
| 22:40:38 | brixen | </rant> |
| 22:40:56 | evan | sounds unfun. |
| 22:41:13 | brixen | it was |
| 22:57:11 | dwaite | oh nice |
| 22:57:18 | dwaite | Windows XP, IE6 and IE7 all end of life in July |
| 23:42:03 | brixen | this is going to be painful |
| 23:42:07 | brixen | hmm |
| 23:44:29 | brixen | evan: poke |