Show enters and exits. Hide enters and exits.
| 01:58:05 | haruki_zaemon | evan: You around? |
| 02:01:29 | wayneeseguin | evan: around? |
| 02:01:33 | wayneeseguin | LOL |
| 02:02:15 | haruki_zaemon | I guess not :/ |
| 02:02:17 | haruki_zaemon | lol |
| 02:02:47 | haruki_zaemon | Been looking at LLVM code to improve tail call optimisation |
| 02:03:07 | haruki_zaemon | but not sure what/how rubinius has modified LLVM |
| 02:17:10 | rue | It is not modified |
| 02:20:32 | haruki_zaemon | rue: Ahh ok. Great. Thanks. |
| 02:23:52 | haruki_zaemon | I notice Rubinius never makes use of createTailCallEliminationPass() |
| 02:23:56 | haruki_zaemon | Is that deliberate? |
| 02:30:57 | rue | Essentially yes |
| 02:31:26 | rue | You could see if enabling it produces any usable results |
| 02:31:52 | haruki_zaemon | ? |
| 02:32:02 | rue | If so, could add it in as an optional feature, i.e. something like -Xopts.tailcall |
| 02:32:10 | haruki_zaemon | ahh ok |
| 02:32:20 | haruki_zaemon | The reason I ask is I'm working on improving the TCO in LLVM |
| 02:32:35 | haruki_zaemon | which would ironically have no effect in rubinius |
| 02:32:46 | haruki_zaemon | the original driver for me working on LLVM haha |
| 02:32:54 | rue | Unless enabled, you mean? |
| 02:32:58 | haruki_zaemon | which leads me to believe that the TCO In rubinius is hand-rolled |
| 02:33:06 | haruki_zaemon | sorry, yes, unless enabled |
| 02:34:52 | rue | If you modify the TCO pass or create an alternate one, I do not see why it could not be added as an option (provided it actually can analyse our calls, i.e., works) |
| 02:36:12 | haruki_zaemon | indeed |
| 02:36:18 | haruki_zaemon | I'll keep investigating |
| 02:36:42 | haruki_zaemon | Could you point me where in rubinius the TCE that currently exists is done? |
| 02:37:36 | rue | I thought we established there is none :P |
| 02:38:19 | haruki_zaemon | well there appears to be _something_ |
| 02:38:38 | rue | What effect are you seeing? Maybe just inlining? |
| 02:38:45 | haruki_zaemon | ahh perhaps thats it |
| 02:38:58 | haruki_zaemon | I wrote a few examples to see what, if anything, worked |
| 02:39:05 | haruki_zaemon | inlining would cover the simplest case |
| 02:39:12 | haruki_zaemon | makes sense |
| 02:39:27 | haruki_zaemon | well, a colleague and I are looking into llvm (he's a c++ guy) |
| 02:39:44 | haruki_zaemon | will try enabling it in rubinius and see what happens :/ |
| 02:44:03 | haruki_zaemon | I'm getting: |
| 02:44:04 | haruki_zaemon | GEN lib/compiler/opcodes.rb |
| 02:44:04 | haruki_zaemon | rake aborted! |
| 02:44:04 | haruki_zaemon | no such file to load -- ext/digest/sha1/sha1 |
| 02:44:51 | haruki_zaemon | aoh, just noticed I was using ruby 1.9. Would that be the cause? |
| 02:44:51 | rue | Do a distclean and rebuild if you have not updated in a while |
| 02:44:57 | haruki_zaemon | ahh |
| 02:44:57 | rue | Yes, 1.8 to build |
| 02:44:58 | haruki_zaemon | ok |
| 02:45:09 | haruki_zaemon | thanks (sorry for being a pita) |
| 02:56:08 | rue | Nops |
| 03:07:24 | haruki_zaemon | Should I be expecting this: Date#strftime should be able to show the week number with the week starting on sunday and monday FAILED |
| 03:07:25 | haruki_zaemon | Expected #<Date: 4910581/2,0,2299161> |
| 03:07:25 | haruki_zaemon | to equal #<Date: 4910595/2,0,2299161> |
| 03:07:25 | haruki_zaemon | spec/ruby/library/date/strptime_spec.rb:82 |
| 03:09:23 | rue | I think there might be some remaining issues with the year having changed, but I am not quite certain...should run the specs, but it is way past bedtime so that will have to wait. Any other errors? |
| 03:19:34 | haruki_zaemon | Haha no. thanks |
| 03:19:46 | haruki_zaemon | and I enabled TCO and no extra errors |
| 03:19:55 | haruki_zaemon | just need to berify that it actually does something useful :) |
| 03:21:06 | rue | Hopefully it will not increase compile time unduly |
| 03:25:55 | haruki_zaemon | indeed, if it does we can always use a switch to enable it :) |
| 04:30:40 | haruki_zaemon | OK so after talking to the guys on the LLVM list, LLVM already supports some very sophisticated TCO. |
| 05:00:43 | haruki_zaemon | So the support is already in LLVM |
| 05:01:06 | haruki_zaemon | Which means perhaps only some Ruby work to identify the call sites? |
| 05:01:10 | evan | hi haruki_zaemon |
| 05:01:15 | evan | it's not nearly that easy. |
| 05:01:15 | haruki_zaemon | hey evan |
| 05:01:19 | haruki_zaemon | oh :( |
| 05:01:36 | haruki_zaemon | I was afraid you'd say that ;-) |
| 05:02:09 | haruki_zaemon | Guess I'll go back to pushing another barrow LOL |
| 05:02:13 | evan | just 2 things off hand |
| 05:02:34 | evan | 1) TCO has to be supported in the interpreter as well |
| 05:03:58 | evan | 2) TCO in native code only works if inlines are always use tail calls, ie, there can be nothing between the source and target method |
| 05:04:05 | evan | er, inline caches |
| 05:04:45 | evan | a 3rd, LLVM's TCO is only supported if fastcc is used |
| 05:07:25 | haruki_zaemon | 1) not sure I understand, 2) bugger 3) don't know what that is but I presume it's not used ;-) |
| 05:07:30 | haruki_zaemon | oh well |
| 05:08:00 | haruki_zaemon | Stepping back, I presume there's no way to just do it in Ruby instead? :/ |
| 05:11:12 | evan | #1 is the most important |
| 05:11:32 | evan | rubinius uses an interpreter to run code in addition to LLVM |
| 05:11:49 | haruki_zaemon | you mean at the same time? or as an alternative? |
| 05:11:55 | evan | at the same time. |
| 05:12:06 | evan | it's a mixed mode interpreter. |
| 05:12:12 | evan | mixed mode VM, that is. |
| 05:12:12 | haruki_zaemon | ahhh gotcha |
| 05:12:16 | haruki_zaemon | yeah |
| 05:12:29 | evan | unlike macruby, which compiles things to LLVM before it runs anything |
| 05:12:30 | haruki_zaemon | so LLVM is really used as a JIT? |
| 05:12:32 | evan | rubinius does not |
| 05:12:43 | evan | it runs code in the interpreter and learns more about it |
| 05:13:02 | evan | before it sends it out to be JIT'd by LLVM (which happens in the background) |
| 05:13:03 | haruki_zaemon | gotcha |
| 05:13:12 | haruki_zaemon | yeah |
| 05:13:30 | haruki_zaemon | So should I just give up? Or do you see a way? |
| 05:14:19 | evan | you could work out how to do TCO in an interpreter |
| 05:14:39 | haruki_zaemon | That would be fine with me :) |
| 05:15:01 | haruki_zaemon | As I mentioned on te list, I have a bih incentive to get ot working |
| 05:15:11 | haruki_zaemon | and my job is cool with me working on it |
| 05:15:18 | evan | i'm open to you playing with it |
| 05:15:28 | evan | but i won't allow it to be automatic. |
| 05:15:33 | haruki_zaemon | but I don't want to even bother trying if you think it's largely a waste of time :) |
| 05:15:34 | haruki_zaemon | no no |
| 05:15:38 | evan | the destruction of backtraces is not acceptable |
| 05:15:58 | haruki_zaemon | for the most part yes I agree |
| 05:16:04 | haruki_zaemon | but if I say it's ok,, then it's ok :) |
| 05:16:10 | haruki_zaemon | so a switch would be fine |
| 05:16:20 | evan | no |
| 05:16:22 | evan | it would not be. |
| 05:16:32 | haruki_zaemon | ? |
| 05:16:45 | evan | because you'll want to write a library that requires TCO |
| 05:16:53 | evan | and no one will be able to use it without having that switch on |
| 05:17:05 | haruki_zaemon | Well, yes and no |
| 05:17:09 | haruki_zaemon | I only need it in large cases |
| 05:17:11 | haruki_zaemon | but even so |
| 05:17:21 | haruki_zaemon | I'm over caring how it's enabled |
| 05:17:26 | haruki_zaemon | explicit in code is fine |
| 05:17:27 | evan | which means that they'll complain to me that their backtraces are wrong if they use your library |
| 05:17:32 | haruki_zaemon | LOL |
| 05:17:42 | haruki_zaemon | I understand your motivation :) |
| 05:18:19 | haruki_zaemon | As I said on the list Rubinius.tailcall … is fine with me |
| 05:18:39 | haruki_zaemon | I have no issue with people needing to use Rubinius to use my code :D |
| 05:19:31 | haruki_zaemon | My other option is is to wait for Java 7 and JRuby LOL |
| 05:19:37 | haruki_zaemon | It's an internal project anyway |
| 05:19:40 | evan | gotcha |
| 05:19:44 | haruki_zaemon | so it's unlikely to ever see the light of day |
| 05:20:05 | evan | if you can make the interpreter work, that will get you somewhere |
| 05:20:12 | evan | because you can at least run with -Xint then |
| 05:20:21 | haruki_zaemon | gotcha |
| 05:20:46 | evan | once that is working, getting the JIT to work too is more likely. |
| 05:21:36 | haruki_zaemon | right |
| 05:21:58 | haruki_zaemon | thanks for the info |
| 05:22:12 | evan | i can think of a couple of things to overcome in the interpreter |
| 05:22:13 | haruki_zaemon | I realise it's low priority and no one else seems to care about it :) |
| 05:22:30 | evan | one is that you'll probably have to piggyback of gcc's tailcall support |
| 05:24:20 | evan | the interpreter itself will probably need to be collapsed into one function, so that gcc's tailcall support can completely cleanup a frame before starting the next one |
| 05:25:18 | haruki_zaemon | ick :/ |
| 05:34:03 | haruki_zaemon | *sigh* |
| 05:34:04 | haruki_zaemon | :) |
| 06:15:25 | tarcieri | evan: headgib @ wycats vcall bug |
| 06:16:41 | evan | :) |
| 06:17:55 | tarcieri | and uhh jeezus, you are a god for sorting that shit out |
| 06:18:54 | tarcieri | concurrency-related bugs ftl |
| 06:26:51 | scoopr | oh yeah, nice little wtf |
| 06:27:09 | scoopr | I never really realized the nameerror vs nomethoderror distinction |
| 06:42:18 | tarcieri | me either |
| 17:12:08 | brixen | morning |
| 17:23:14 | tenderlove | brixen: ZOMG!!!! HAPPY MONDAY MORNING TO YOU!!! |
| 17:23:27 | tenderlove | :-D |
| 17:23:39 | brixen | tenderlove: HAPPY MOOOOOONDAY TO YOU, SIR!!! |
| 17:23:49 | tenderlove | :-D :-D :-D |
| 17:24:34 | brixen | heh |
| 17:26:34 | evan | morning |
| 17:28:39 | brixen | there is another library/date spec failing |
| 17:28:51 | brixen | VVSiz and I are looking at it |
| 17:29:51 | evan | brixen: so, I pounded out signature support |
| 17:29:56 | evan | i'm going to push to a branch for you to check out. |
| 17:30:28 | brixen | evan: ok |
| 17:31:56 | evan | brixen: so, when the compiler itself is out of date |
| 17:32:02 | evan | should we just print out a message? |
| 17:32:07 | brixen | yep |
| 17:32:20 | evan | oh, and by out of date, i don't mean via mtimes |
| 17:32:20 | brixen | graceful fail like when we can't find runtime |
| 17:32:25 | brixen | yes |
| 17:32:30 | evan | i mean that compiler .rbc's have a version/signature mismatch. |
| 17:32:36 | brixen | *nod* |
| 17:32:39 | evan | k |
| 17:32:42 | evan | doing that now. |
| 17:32:45 | brixen | ok |
| 17:33:38 | evan | so, i'm also thinking that for the compiler, we should have a --rebuild-compiler option |
| 17:33:50 | evan | that would actually ignore signature mismatches on the compiler |
| 17:34:02 | evan | and allow rubinius to at least try to recompile the compiler |
| 17:34:57 | brixen | sure |
| 17:35:25 | brixen | I was thinking of an option to just force load the compiler |
| 17:35:25 | evan | since otherwise, i'm not sure what to tell the user. |
| 17:35:37 | brixen | but maybe making that only rebuild the compiler |
| 17:50:32 | rue | Morning |
| 17:50:54 | evan | morning |
| 17:50:58 | rue | Another cheer: http://files.kittensoft.org/photos/kittens/rue_0005.png |
| 17:54:33 | brixen | haha, that's what I feel like looking at these Date.strptime specs |
| 18:02:16 | dbussink | evening ppl |
| 18:02:20 | dbussink | evan: available for a question? |
| 18:02:26 | evan | sure wassup. |
| 18:03:44 | dbussink | evan: i was running some stuff with rspec and found a small issue with exception handling |
| 18:04:05 | evan | ok, shoot. |
| 18:04:07 | dbussink | evan: basically comes down to the fact that stuff breaks if you define a custom initialize for an exception with no parameters |
| 18:04:18 | evan | can you show me? |
| 18:04:57 | dbussink | evan: https://gist.github.com/017d13653aff049d918e |
| 18:05:39 | dbussink | evan: so, in order to fix this i used undefined in two places additionally, problem with that is that it exposes another issue |
| 18:05:40 | evan | ah, ie you don't call super |
| 18:05:57 | evan | ok, we've hit this many times before |
| 18:06:01 | evan | with Hash for instance |
| 18:06:08 | evan | what happens when you do that? |
| 18:06:14 | evan | what wierdness do you get? |
| 18:06:32 | dbussink | evan: a bunch of failures with SystemCallError and the Errno exceptions that inherit from it |
| 18:07:01 | dbussink | since you have to give at least one parameter to SystemCallError, but you can raise the Errno exceptions without any parameter |
| 18:07:16 | dbussink | evan: that used to work because implicitly it was passed a nil as the first parameter |
| 18:07:22 | evan | what real world code is doing this? |
| 18:07:30 | evan | i'd like to understand that as well |
| 18:07:31 | dbussink | evan: rspec |
| 18:07:37 | evan | before coming up with a solution |
| 18:07:39 | evan | no |
| 18:07:41 | evan | i mean the actual code |
| 18:07:44 | evan | not the project. |
| 18:07:51 | evan | show me in rspec where this happens. |
| 18:08:39 | dbussink | evan: you mean the exception with an initialize without arguments or what my change exposes? |
| 18:08:58 | evan | the original problem |
| 18:09:16 | dbussink | evan: https://gist.github.com/6aaf5f4d79ebb80febc6 |
| 18:09:23 | dbussink | evan: pending specs in rspec use that exception |
| 18:09:36 | evan | that appears to call super |
| 18:09:42 | evan | so i don't get what you mean |
| 18:09:55 | dbussink | evan: yeah, but that fails since the initialize has no parameters |
| 18:10:07 | dbussink | evan: and our raise code always passes nil as the first parameter |
| 18:10:09 | evan | ok... |
| 18:10:17 | evan | could you show me a backtrace? |
| 18:10:19 | evan | actually |
| 18:10:20 | evan | full stop |
| 18:10:25 | evan | please formulate this as a proper ticket. |
| 18:10:35 | evan | otherwise i'm just going to keep asking you for more info |
| 18:10:38 | evan | better it's all in one place. |
| 18:11:17 | dbussink | evan: this is a gist with all the changes i have locally here that make it work, but i'm not sure if it's the correct way to fix the issue |
| 18:11:19 | dbussink | evan: https://gist.github.com/77b822417ef7b335c872 |
| 18:12:43 | evan | please make the ticket |
| 18:12:46 | evan | then we'll discuss. |
| 18:14:10 | dbussink | evan: problem is that this really is a two step problem |
| 18:14:29 | dbussink | evan: solving the first step exposes other issues and i'm not sure how to address those |
| 18:14:34 | evan | thats fine |
| 18:14:38 | evan | lets get the original problem documented. |
| 18:14:42 | evan | then we'll work on it. |
| 18:15:13 | dbussink | evan: http://github.com/evanphx/rubinius/issues/#issue/144 |
| 18:15:32 | evan | dbussink: from now on |
| 18:15:39 | evan | please use <pre> around preformatted text in issues |
| 18:15:45 | evan | otherwise i just have to go in and fix it. |
| 18:16:06 | evan | also |
| 18:16:16 | evan | please include the backtrace from rspec |
| 18:16:46 | dbussink | evan: but this is already the distilled issue |
| 18:17:03 | evan | well alright |
| 18:17:14 | evan | i typically prefer to have the source of the problem documented as well |
| 18:17:19 | dbussink | evan: the backtrace is exactly the same for rspec |
| 18:17:33 | evan | i'm checking out the code for raise in MRI now |
| 18:17:35 | evan | to see what it does. |
| 18:17:51 | dbussink | evan: for other projects i always prefer smaller scale repro's so i don't have to set it all up myself :) |
| 18:17:59 | evan | i prefer both |
| 18:18:09 | evan | because sometimes the small repo is too small |
| 18:18:19 | evan | we need more context to figure out why it happened |
| 18:18:22 | evan | so we can figure out the fix. |
| 18:19:30 | evan | anyways |
| 18:19:33 | evan | i see your changes |
| 18:19:36 | evan | what problem do they cause |
| 18:20:13 | dbussink | evan: well, if i add the undefined to raise and Exception#exception, raising Errno exceptions breaks |
| 18:20:27 | evan | breaks how |
| 18:20:28 | evan | does what |
| 18:20:50 | dbussink | evan: i'll show you my initial change, you can run the ci to see what breaks then |
| 18:21:03 | evan | ok. |
| 18:21:11 | evan | i see some changes in your diff that are probably not necessary |
| 18:21:18 | evan | like moving error = ... up a line |
| 18:22:19 | dbussink | evan: the nasty thing here is that raising a SystemCallError directly should throw an argumenterror if no parameters are given, but raising one of it's subclasses is allowed without parameters |
| 18:23:54 | rue | Man, I guess I have to start using BadgerWhale or whatever it is, Github is m o l a s s e s |
| 18:24:02 | evan | brixen: the Date#strftime error is expected atm, yes? |
| 18:24:08 | brixen | evan: yes |
| 18:24:18 | dbussink | evan: that's why there is the explicit 'raise ArgumentError, "given 0, expected 1"' in my patch suggestion |
| 18:24:25 | evan | rue: BadgerWhale sounds like a fun website |
| 18:24:33 | evan | dbussink: are you going to show me your inital change? |
| 18:24:37 | brixen | evan: we're trying to figure out why 1.8 and 1.9 disagree parsing a date |
| 18:25:05 | dbussink | evan: https://gist.github.com/16b6ee0421d83988e2dd |
| 18:25:29 | evan | dbussink: ok, one sec. |
| 18:25:49 | dbussink | evan: that change is to make sure an argument is only passed down if it's explicity passed to raise and / or Exception.exception |
| 18:26:32 | evan | ok, i'm running the initial change now. |
| 18:26:36 | evan | hold on. |
| 18:27:26 | evan | btw, yes, SystemCallError is a broken ass class hierarchy. |
| 18:27:54 | evan | for a fun time |
| 18:28:07 | evan | go read syserr_initialize in 1.8.7 in error.c |
| 18:28:08 | dbussink | evan: that's what i realized too when diving into this :) |
| 18:28:15 | evan | it does |
| 18:28:20 | evan | RBASIC(obj)->klass = klass |
| 18:29:12 | dbussink | evan: it has a comment ;) |
| 18:29:17 | dbussink | /* change class */ |
| 18:29:31 | evan | yes, i'm glad we've got that completely covered. |
| 18:29:36 | evan | *eyeroll* |
| 18:32:00 | dbussink | evan: but i want to make a rubyspec out of this exception with a custom constructor thing anyway so it's documented there too |
| 18:32:10 | evan | yes please. |
| 18:33:54 | evan | dbussink: let me finish up this compiler sig change |
| 18:33:59 | evan | then i'll tackle this with ya |
| 18:34:18 | brixen | UGH at lib/date.rb |
| 18:34:25 | brixen | any date experts around? |
| 18:34:41 | evan | yeah |
| 18:34:45 | evan | mega fail on date.rb |
| 18:34:52 | evan | that should be a show on discovery |
| 18:34:56 | brixen | in 1.8 Date.strptime("2010/1", "%Y/%W").to_s gives "2010-01-10" |
| 18:34:58 | evan | right after mega disasters |
| 18:34:59 | brixen | this can't be right |
| 18:35:00 | evan | mega fail |
| 18:35:08 | evan | or they could change the name of mega distasters to mega fail |
| 18:35:11 | evan | that would be awesome. |
| 18:35:21 | brixen | in 1.9 it gives "2010-01-04" which makes sense |
| 18:35:31 | brixen | VVSiz: poke |
| 18:35:35 | evan | brixen: sounds like a bug in date.rb |
| 18:35:45 | evan | gotta love date bugs |
| 18:35:52 | brixen | evan: right? the 1.8 seems like it can't be right, yes? |
| 18:35:53 | evan | they lay dorminant |
| 18:36:05 | evan | just waiting for literally their time to strike. |
| 18:36:07 | brixen | 1/4 (today) is week 1 of 2010 |
| 18:36:19 | brixen | with the week starting on Monday |
| 18:36:24 | brixen | correct? |
| 18:36:35 | evan | i'd assume so |
| 18:39:05 | dbussink | brixen: correct |
| 18:39:13 | dbussink | brixen: i work with week numbers on a daily basis ;) |
| 18:39:28 | boyscout | Fix Marshal'ing a tuple - fa3a8d2 - Evan Phoenix |
| 18:39:28 | boyscout | Remove cruft - 5447903 - Evan Phoenix |
| 18:39:40 | evan | brixen: pushed the signature branch |
| 18:39:52 | evan | brixen: let me know once you'd checked it out and ok'd it. |
| 18:41:11 | brixen | dbussink: heh, well it's your change I'm trying to fix |
| 18:41:22 | dbussink | brixen: i saw it yeah |
| 18:41:26 | brixen | evan: ok, one sec... |
| 18:41:36 | dbussink | brixen: but it looks like a bug in the spec or in 1.8? |
| 18:41:44 | brixen | dbussink: yeah, it does seem to be a bug |
| 18:41:59 | brixen | dbussink: I'm looking at -r24500 right now |
| 18:42:14 | brixen | dbussink: oh, bug in 1.8's date.rb |
| 18:42:42 | brixen | dbussink: but this spec is really terrible |
| 18:42:57 | brixen | dbussink: you added this + 7 * 13 mystery math |
| 18:43:03 | dbussink | brixen: yeah, i know, it might be clearer to describe a few explicit cases |
| 18:43:10 | brixen | and these specs need to be against a fixed date |
| 18:43:19 | brixen | not some random rolling date |
| 18:43:23 | dbussink | brixen: yeah, that's probably better |
| 18:43:29 | dbussink | brixen: but it did expose a bug now ;) |
| 18:43:43 | brixen | if there are edge cases calculating/parsing a date, they should have their own spec |
| 18:43:52 | brixen | which is hard when we are writing the specs after the fact |
| 18:43:57 | brixen | but still |
| 18:44:49 | dbussink | brixen: yeah, 2009 / 2010 is actually a good sample, since it has 53 weeks etc. |
| 18:50:49 | evan | how ironic |
| 18:51:04 | evan | i'm listening to a song where the chorus is "you're the only exception" while working on exception code! |
| 18:51:11 | brixen | heh |
| 18:51:14 | dbussink | evan: hehe |
| 18:51:41 | dbussink | brixen: are you ok with adding cases to rubyspec that basically come from rubinius bugs? |
| 18:51:55 | brixen | dbussink: sure |
| 18:52:02 | brixen | dbussink: all implementations do |
| 18:52:18 | brixen | it's how we find edge cases in implementing ruby |
| 18:53:12 | brixen | evan: how do you want to handle this date.rb issue? |
| 18:53:14 | brixen | evan: http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=24500 |
| 18:53:19 | boyscout | CI: Commit 5447903 failed. http://github.com/evanphx/rubinius/commit/54479032471d232b3b1c27a5487817d83de92adb |
| 18:53:24 | dbussink | evan: i've added the spec to rubyspec, want me to add it to rubinius too? |
| 18:53:41 | brixen | that rev makes Date.strptime("2010/1", "%Y/%W") parse to 2010-1-4 as it should |
| 18:53:54 | brixen | dbussink: I'm about to sync the specs |
| 18:54:02 | dbussink | brixen: ah ok |
| 18:54:02 | brixen | dbussink: as soon as I can get this date spec fixed |
| 18:54:29 | evan | dbussink: sure |
| 18:54:32 | evan | ah ok |
| 18:54:34 | evan | whichever. |
| 18:54:38 | evan | i'm working on the bug now. |
| 18:55:03 | evan | i'm making Exception.exception a true alias for .new |
| 18:55:04 | dbussink | evan: how do you feel about my final patch? with the changes to SystemCallError? |
| 18:55:11 | dbussink | evan: ah ok |
| 18:55:16 | brixen | I wish there were a way to link back from an MRI rev to a bug ticket # |
| 18:55:25 | evan | i don't like the hardcoded Argument error message |
| 18:55:36 | evan | i'm playing with it now. |
| 18:55:43 | dbussink | evan: me neither, hence why i was asking you ;) |
| 18:56:28 | dbussink | evan: one thing i noticed too is that in mri Errno::EINVAL.new => #<Errno::EINVAL: Invalid argument> |
| 18:56:50 | dbussink | evan: in rubinius it has an unknown message and not the default strerror message |
| 18:57:10 | evan | mm |
| 18:57:17 | evan | your'e change is wrong then |
| 18:57:18 | evan | because it should. |
| 18:57:35 | evan | .errno_error does that |
| 18:58:44 | dbussink | evan: my change made it so it does that |
| 18:58:52 | dbussink | evan: it didn't before my final change |
| 18:59:02 | dbussink | evan: but just something i wanted to give a heads up about |
| 18:59:07 | evan | it did? |
| 18:59:19 | evan | what is that self::Errno thing? |
| 18:59:38 | evan | oh, i see. |
| 18:59:45 | dbussink | evan: Errno is set on an exception if it's a subclass |
| 18:59:46 | evan | i got it. |
| 18:59:49 | evan | yeah |
| 18:59:51 | evan | i got it. |
| 19:00:38 | dbussink | evan: that actually makes sure it sets the message correct too |
| 19:02:17 | evan | dbussink: https://gist.github.com/e1ec0d7d9de26e051789 |
| 19:02:23 | evan | that seems to pass everything for me |
| 19:02:32 | evan | without any SystemCallError changes |
| 19:02:46 | evan | do you have a test for some SystemCallError behavior i'm missing. |
| 19:02:47 | evan | ? |
| 19:03:42 | evan | ok, got one |
| 19:03:45 | dbussink | evan: i might even have, let me check |
| 19:03:46 | dbussink | evan: Errno::EINVAL.new |
| 19:03:50 | dbussink | evan: try that one |
| 19:03:50 | evan | raise Errno::ENOENT |
| 19:03:55 | evan | that shows the other. |
| 19:05:15 | evan | hrm. I kind of want to insert another ancestor in there |
| 19:05:20 | evan | to fix the hierarchy. |
| 19:06:03 | dbussink | evan: hmm, core/exception/errno_spec.rb is empty... |
| 19:06:18 | evan | super. |
| 19:08:35 | brixen | it "should be able to parse ..." => it "parses ..." |
| 19:08:40 | brixen | ppl please :( |
| 19:08:48 | evan | active voice! |
| 19:09:11 | brixen | it "on a good day with a warm sun and butterflies may effectively parse a date..." |
| 19:09:35 | dbussink | brixen: i'd love specs like that ;) |
| 19:09:44 | brixen | dbussink: I see that :P |
| 19:10:02 | brixen | dbussink: so, if you have to fix specs with mystery math, let's please discuss them |
| 19:10:10 | brixen | there is something very likely completely broken |
| 19:11:05 | dbussink | brixen: yeah, well, basically did a quick fix since it was failing in a few days, might better have quarantined them and better review them |
| 19:11:20 | brixen | dbussink: yes, quarantine in this case is better I think |
| 19:12:35 | evan | dbussink: https://gist.github.com/42727795ccbadaae9e37 |
| 19:12:40 | evan | that seems to pass everything |
| 19:13:41 | dbussink | evan: ha, an explicit argumenterror ;) |
| 19:13:47 | evan | also fixes the fact that Errno subclass didn't have "Errno::" on the front |
| 19:14:02 | evan | yeah, all other ways of not using an explicit ArgumentError are uglier |
| 19:14:16 | evan | i've opted for one that has a very specific error message instea |
| 19:14:18 | evan | d |
| 19:14:53 | dbussink | evan: one thing that i can think of though, if you do a raise SomeException, nil the nil isn't passed into SomeException |
| 19:15:06 | evan | should it be? |
| 19:15:20 | dbussink | evan: dunno, i can try and write up an example |
| 19:15:39 | evan | you mean because raise is conditional on msg? |
| 19:16:09 | evan | easy enough to make that use undefined |
| 19:16:36 | dbussink | evan: something like this: https://gist.github.com/662dd9c4cc4eafa18281 |
| 19:16:54 | evan | ok, i'll make msg use undefined in raise |
| 19:17:25 | dbussink | evan: no idea whether this is used somewhere in real life though |
| 19:17:33 | evan | sure |
| 19:17:39 | evan | it's an edge case that we should just fix now |
| 19:17:43 | dbussink | evan: but i guess if it's possible, someone did it at some point :P |
| 19:17:49 | evan | p |
| 19:17:51 | evan | yeah |
| 19:18:06 | dbussink | that's what i've seen with other stuff that first classified as "nah, no one ever does that" |
| 19:20:10 | evan | yeah |
| 19:20:15 | evan | well, if the fix is trivial |
| 19:20:21 | evan | it's silly to not just support it now. |
| 19:31:31 | evan | dbussink: i'm restructuring SystemCallError.new |
| 19:31:40 | evan | and seperating out the 2 use cases entirely |
| 19:31:43 | evan | to make the logic clearer |
| 19:35:11 | dbussink | evan: ah, cool |
| 19:36:01 | evan | this helps fix a few other edge cases |
| 19:36:23 | evan | like a Errno subclass that defines a self::Errno that is invalid |
| 19:44:44 | cored | hi guys |
| 19:46:16 | evan | hi |
| 19:47:04 | cored | evan: i'm watching your Rubyconf 2007 Rubinius talk |
| 19:47:12 | cored | evan: that was fun |
| 19:47:15 | evan | cool |
| 19:47:16 | evan | :) |
| 19:50:00 | evan | MMMM chained exceptions |
| 19:50:01 | evan | i love you. |
| 19:50:37 | brixen | evan: will gdb 7 make it easier to debug through these jit frames or will we need to write some code to help it understand? |
| 19:50:59 | brixen | evan: it's a bitch locating these hangs when I fall into the ??? frames |
| 19:51:09 | brixen | and I always do it just stepping along |
| 19:51:12 | evan | we'll still have to write a bunch of stuff |
| 19:51:13 | brixen | then tarpit |
| 19:51:17 | evan | to make it work |
| 19:51:19 | brixen | ok |
| 19:51:22 | evan | using -Xint doesn't help? |
| 19:51:39 | brixen | well, I get a hang running the specs then attach to process |
| 19:51:51 | brixen | so I don't really have the option of picking my context |
| 19:51:56 | brixen | if it's repeatable, sure |
| 19:52:00 | evan | sure you do |
| 19:52:07 | evan | mspec -T -Xint |
| 19:52:12 | brixen | not when it's a random hang |
| 19:52:20 | brixen | if it's repeatable, sure |
| 19:52:33 | evan | it should never hang within a JIT frame |
| 19:52:46 | evan | so with luck you'll at least have a CallFrame |
| 19:52:48 | evan | to help isolate |
| 19:53:20 | brixen | yeah, but I'll be stepping along and then I hit one of them |
| 19:53:35 | brixen | finish doesn't seem to help me |
| 19:53:37 | brixen | what do you do? |
| 19:53:37 | evan | yah, thats a pain |
| 19:53:49 | evan | well |
| 19:53:52 | evan | you can try doing |
| 19:54:01 | evan | tb VMMethod::intepreter |
| 19:54:04 | evan | if you hit one |
| 19:54:09 | evan | then do continue |
| 19:54:19 | evan | you'll stop at the next interpreted method |
| 19:54:24 | evan | that should at least let you skip JIT methods. |
| 19:54:28 | evan | but you might skip too much. |
| 19:54:36 | brixen | ok |
| 19:55:08 | evan | i should add a nint to our .gdbinit |
| 19:55:17 | evan | for next intepreted method |
| 19:56:55 | boyscout | Redo how SystemCallError interacts with it's subclasses - 45f34bb - Evan Phoenix |
| 19:56:59 | evan | dbussink: ^^ |
| 19:58:39 | dbussink | evan: cool :) |
| 19:58:59 | dbussink | evan: there's a spec for the Exception.exception case, will probably come in when brixen merges rubyspec |
| 19:59:19 | brixen | dbussink: yeah, was just about to push |
| 19:59:36 | evan | k |
| 20:02:44 | brixen | evan: after pulling I get PrimitiveFailure in SystemCallError#errno returns the errno given as optional argument to new |
| 20:03:01 | evan | hrm. |
| 20:03:13 | evan | gr. |
| 20:03:19 | evan | those specs have shitty boundaries i'm betting. |
| 20:03:31 | evan | i think on 32bit, they pass in a Bignum |
| 20:03:44 | brixen | looks |
| 20:04:00 | brixen | yep |
| 20:04:06 | evan | *eyeroll* |
| 20:04:10 | evan | ok, one sec. |
| 20:05:10 | evan | probably need to change that spec |
| 20:05:14 | evan | it's going to be system dependent |
| 20:06:40 | brixen | hmm |
| 20:07:03 | evan | MRI has these icky boundary cases |
| 20:07:13 | evan | where you can pass in a Bignum that will work because it can fit into a long |
| 20:07:20 | evan | but otherwise, it raises a RangeError |
| 20:07:48 | evan | this happen to work before because the rubinius code only let it through to SystemCallError.errno_error if errno was a fixnum |
| 20:07:53 | evan | i'll go ahead and put that code back into place |
| 20:07:58 | evan | one sec. |
| 20:08:51 | brixen | yeah, there are all kinds of these leaky boundaries in MRI with bignum |
| 20:09:15 | brixen | we need to handle them consistently in the specs though |
| 20:09:29 | brixen | they are scattered all over |
| 20:09:34 | brixen | hmm |
| 20:09:36 | boyscout | Only pass Fixnums through to be become Errno instances - d380d72 - Evan Phoenix |
| 20:10:44 | boyscout | CI: Commit 45f34bb failed. http://github.com/evanphx/rubinius/commit/45f34bb0e5ffcedaab7fc272330339a7c89e58c6 |
| 20:14:45 | boyscout | Define X86_ESI_SPEEDUP to put vmm->addresses in esi. - 2d8775d - Brian Ford |
| 20:14:46 | boyscout | Updated CI specs to RubySpec b295a3f5. - d11a930 - Brian Ford |
| 20:14:46 | boyscout | Fix for Date.strptime with %W from MRI r24500. - 8e28e0d - Brian Ford |
| 20:14:46 | boyscout | Update CI tags for merged rubyspecs. - a7b2947 - Brian Ford |
| 20:16:55 | dbussink | brixen: hmm, where does that X86_ESI_SPEEDUP come frome, can't seem to find anything on google |
| 20:17:07 | evan | eh? |
| 20:17:13 | evan | he defined it. |
| 20:17:19 | evan | it doesn't come from anywhere but us. |
| 20:17:32 | evan | look at the commit. |
| 20:17:33 | dbussink | well, it's only checked, not defined anywhere |
| 20:17:56 | evan | right |
| 20:17:59 | evan | we're not using that feature atm. |
| 20:18:02 | evan | so we're not defining it. |
| 20:18:24 | boyscout | CI: rubinius: a7b2947 successful: 3022 files, 11677 examples, 35868 expectations, 0 failures, 0 errors |
| 20:18:49 | dbussink | evan: ah, since __i386__ was used as a guard before |
| 20:18:56 | evan | right. |
| 20:19:14 | evan | at some future time, we can define ESI_SPEEDUP and enable it again |
| 20:19:48 | brixen | evan: signature branch looks good to me |
| 20:19:57 | evan | ok, i'll merge it in. |
| 20:20:58 | brixen | dbussink: heh, that commit msg is a directive |
| 20:21:26 | brixen | dbussink: *You* define X86... if you want to explicitly put the addresses in esi |
| 20:21:44 | brixen | dbussink: it was causing gcc to choke on same builds |
| 20:23:09 | dbussink | brixen: ah ok |
| 20:24:09 | evan | brixen: I still have the date failure |
| 20:24:10 | evan | should I? |
| 20:27:23 | brixen | evan: no |
| 20:27:37 | evan | hm. |
| 20:27:40 | evan | oh wait. |
| 20:27:44 | evan | i'm a silly pants. |
| 20:27:47 | evan | who needs lunch. |
| 20:27:53 | evan | nevermind! |
| 20:28:05 | evan | you can ignore my silly pants. |
| 20:28:20 | brixen | ok |
| 20:28:32 | brixen | I thought it could be a 64bit thing with date |
| 20:29:21 | evan | no |
| 20:29:25 | evan | i merged but didn't update first. |
| 20:29:28 | evan | my sillyness only. |
| 20:30:45 | brixen | evan: ok n/p |
| 20:31:49 | evan | ok, so i'm headed to lunch |
| 20:31:54 | evan | but i'm putting the rc2 clamp on |
| 20:32:06 | brixen | ok |
| 20:32:09 | evan | if there are things that we must get in, lets discuss them. |
| 20:32:12 | brixen | sure |
| 20:32:13 | evan | otherwise, lets cut it. |
| 20:32:18 | brixen | let's do it |
| 20:32:25 | evan | k |
| 20:32:26 | brixen | I was still working on these requires specs |
| 20:32:27 | evan | i'll do that post lunch |
| 20:32:36 | brixen | but I can redo Requirer for rc3 |
| 20:32:39 | evan | they can wait though? |
| 20:32:42 | brixen | yes |
| 20:32:42 | evan | ok, cool. |
| 20:32:49 | brixen | the sig stuff was most important |
| 20:32:52 | evan | i've got some fixes i want to do to |
| 20:32:56 | evan | but i'm waiting til rc3 |
| 20:32:57 | brixen | ok |
| 20:33:02 | brixen | cool |
| 20:33:12 | evan | retesting the signature branch |
| 20:33:16 | evan | ok, it's good, pushing. |
| 20:33:17 | brixen | k |
| 20:33:31 | boyscout | Add compiler signature/version checking - 6fa3dc4 - Evan Phoenix |
| 20:33:31 | boyscout | Merge branch 'signature' - 0c2b951 - Evan Phoenix |
| 20:33:38 | evan | brixen: oh before lunch |
| 20:33:39 | evan | real fast. |
| 20:33:44 | evan | the signature checking has an out |
| 20:34:03 | evan | if the .rbc's version field (what we're using to store the sig) is 0, it's always accepted |
| 20:34:16 | evan | and if we're asked to compare a .rbc's version against 0, it's always accepted |
| 20:34:28 | brixen | ahh ok |
| 20:34:38 | evan | we can remove that eventually |
| 20:34:42 | brixen | sure |
| 20:34:42 | evan | but for now, an out is useful. |
| 20:34:45 | brixen | yep |
| 20:34:57 | evan | ok, lunch time! |
| 20:35:03 | brixen | ok, me too! |
| 20:38:55 | boyscout | CI: rubinius: 0c2b951 successful: 3022 files, 11677 examples, 35868 expectations, 0 failures, 0 errors |
| 21:45:11 | evan | brixen: so, i'm going to change configure slightly pre-rc2 |
| 21:45:28 | evan | rather than using svn to get LLVM, i'm going to have it just download a llvm-2.6-source.tar.bz2 |
| 21:45:32 | evan | from elle |
| 21:52:53 | wayneeseguin | ears perk |
| 21:53:03 | wayneeseguin | evan: that doesn't change the interaction points at all does it ? |
| 21:53:13 | wayneeseguin | eg it's internal to rbx installer ? |
| 21:53:23 | evan | nope |
| 21:53:29 | evan | it will be the same. |
| 21:53:31 | wayneeseguin | ok great |
| 21:56:01 | brixen | evan: that sounds good |
| 21:56:09 | brixen | svn is so damn slow usually |
| 21:58:23 | evan | yeah |
| 21:58:28 | evan | plus it has to be installed, etc |
| 21:59:43 | brixen | ah yeah |
| 22:00:05 | brixen | evan: are you handling curl not being installed? |
| 22:00:18 | evan | we don't use curl anymore |
| 22:00:22 | evan | just using net/http |
| 22:00:34 | evan | so yes! |
| 22:00:52 | brixen | ah ok cool |
| 22:12:36 | evan | ok, testing the new llvm source build now |
| 22:12:43 | evan | then on to rc2 packaging |
| 22:17:55 | brixen | k |
| 22:27:41 | rue | It would be good form to explicitly undefine if it should not be used |
| 22:50:28 | dbussink | evan: got some nice heisenbugs when running datamapper specs on rubinius now |
| 22:50:37 | evan | sweet. |
| 22:52:04 | rue | Technically they are only heisenbugs before they exist |
| 22:52:12 | evan | correct! |
| 22:52:22 | evan | also, if you put them in a box |
| 22:52:24 | dbussink | evan: only start happening after running for a whole though |
| 22:52:24 | evan | they should disappear. |
| 22:52:29 | dbussink | evan: or not |
| 22:55:29 | dbussink | evan: also a full spec run takes almost 10x longer on rbx |
| 22:55:48 | evan | interesting. |
| 22:55:51 | dbussink | evan: only with in memory objects, so no database access |
| 22:55:58 | dbussink | evan: mainly churning through ruby code |
| 22:56:04 | dbussink | no c parts |
| 22:56:06 | evan | but meaningless because of the complexity |
| 22:56:18 | evan | for all I know, we're 10x just running rspec |
| 22:56:31 | dbussink | evan: true, the complexity is pretty heavy |
| 22:57:02 | dbussink | evan: dunno if it's something you'd be interested in diving into |
| 22:57:03 | evan | if they run at all |
| 22:57:05 | evan | thats a success. |
| 22:57:14 | evan | not at the macro level you're at |
| 22:57:15 | evan | no |
| 22:57:19 | evan | i'm not terribly interested. |
| 22:57:20 | dbussink | evan: they run ok if i run them in smaller pieces |
| 22:57:27 | evan | oh? |
| 22:57:31 | evan | see thats the kind of info i'm interested in. |
| 22:57:41 | evan | perhaps there is a pathalogical slowdown. |
| 22:57:49 | dbussink | evan: all failures i'm seeing run ok if i run them separately |
| 22:58:19 | evan | what about the speed |
| 22:58:30 | evan | is the total greater than the sum of the parts? |
| 22:59:59 | dbussink | evan: i'm running some smaller subsets to compare |
| 23:00:22 | dbussink | evan: one subset is 0.9 secs on mri, 7 secs on rbx |
| 23:00:28 | evan | is the wierdness causing exceptions or segfaults? |
| 23:00:36 | dbussink | no, no segfauls or exceptions |
| 23:00:45 | evan | well, thats a win. :) |
| 23:00:48 | dbussink | the specs are failing because of wrong objects |
| 23:00:57 | evan | "wrong objects"? |
| 23:01:00 | dbussink | or sometimes assertions failing etc. |
| 23:01:11 | dbussink | getting nil back when a certain object is expected |
| 23:01:33 | dbussink | seems like it's only happening after a while which makes me suspect something gc related |
| 23:02:32 | dbussink | evan: although failures like this are pretty weird: https://gist.github.com/a5fe7d1f94f7c7b190c3 |
| 23:02:34 | evan | thats possible |
| 23:02:56 | evan | hm, that is wierd. |
| 23:03:12 | evan | gc bugs usually cause crashes though |
| 23:03:14 | evan | not just wierd behavior. |
| 23:03:41 | dbussink | evan: this is also without any capi extensions |
| 23:03:52 | dbussink | evan: so those don't influence it either |
| 23:04:03 | evan | ok |
| 23:04:03 | dbussink | i've been trying to isolate it better, but haven't been able to yet :* |
| 23:04:05 | dbussink | :( |
| 23:04:13 | evan | ok, well keep at it. |
| 23:06:31 | dbussink | evan: also adding some debugging output in places makes it behave differently, and long runs also don't help in the debugging |
| 23:06:40 | dbussink | evan: otherwise maybe something compiler related? |
| 23:06:59 | evan | well |
| 23:07:03 | evan | nothing points to that |
| 23:07:17 | evan | i don't see why we'd assume that. |
| 23:07:44 | evan | are Threads being used? |
| 23:08:09 | dbussink | evan: nope, this is single threaded afaik |
| 23:08:25 | evan | i'd make any assumptions about it at this stage |
| 23:08:27 | dbussink | only stores some things in Thread.current |
| 23:08:29 | evan | close no door. |
| 23:10:33 | dbussink | but i'm going to grab some sleep |
| 23:10:41 | evan | sounds good |
| 23:10:42 | evan | sleep well |
| 23:10:43 | dbussink | evan: good luck with doing the rc2 :) |
| 23:10:48 | evan | thanks! |
| 23:20:32 | boyscout | Use a tar.bz2 of llvm source rather than svn - fadeb39 - Evan Phoenix |
| 23:21:16 | wayneeseguin | w00t |
| 23:21:31 | wayneeseguin | trys installing NOW |
| 23:22:37 | evan | was svn giving you a problem? |
| 23:23:03 | slava | yo yo evan in da house |
| 23:23:20 | evan | yo yo |
| 23:23:50 | tarcieri | headgib @ CoffeeScript |
| 23:23:55 | boyscout | CI: rubinius: fadeb39 successful: 3022 files, 11677 examples, 35868 expectations, 0 failures, 0 errors |
| 23:26:50 | evan | tarcieri: good or bad? |
| 23:26:52 | evan | it's kind of cute. |
| 23:28:00 | evan | brixen: the only place with the version number is in configure now |
| 23:28:01 | evan | right? |
| 23:28:04 | tarcieri | evan: I'm a fan of the idea, not the syntax |
| 23:37:00 | boyscout | Bump version to rc2 - e8f5ae8 - Evan Phoenix |
| 23:38:34 | evan | tarcieri: which idea is there other than the syntax? |
| 23:38:48 | tarcieri | evan: a language less shitty than JavaScript that compiles to JavaScript |
| 23:39:13 | evan | aah. |
| 23:39:19 | tarcieri | being a rubyfag would try to give it a Ruby-like syntax :) |
| 23:39:30 | tarcieri | with blocks! |
| 23:39:43 | wayneeseguin | <3 blocks |
| 23:39:44 | brixen | heh, of course |
| 23:40:08 | evan | and clocks! |
| 23:40:19 | evan | blocks and clocks |
| 23:40:19 | boyscout | CI: rubinius: e8f5ae8 successful: 3022 files, 11677 examples, 35868 expectations, 0 failures, 0 errors |
| 23:40:30 | tarcieri | and... docks? |
| 23:40:48 | brixen | what's a dock without a lock |
| 23:41:12 | evan | block locks and clock docks! |
| 23:41:38 | evan | ack. I think the signature stuff isn't working with install |
| 23:41:40 | evan | oops. |
| 23:41:56 | brixen | hm |
| 23:42:16 | evan | looks like it didn't load the file with Signature in it. |
| 23:42:37 | evan | mm, yes, it's shelling out to compile to do it. |
| 23:42:42 | evan | thats probably why. |
| 23:44:08 | brixen | why is it shelling out? |
| 23:44:17 | evan | you tell me :) |
| 23:44:21 | brixen | heh |
| 23:44:23 | brixen | I'm looking |
| 23:44:31 | benschwarz | morning gents |
| 23:44:31 | brixen | I explicitly did not in kernel.rake |
| 23:44:40 | evan | brixen: it's an easy fix |
| 23:45:09 | brixen | hey there benschwarz |
| 23:45:16 | benschwarz | happy new year etc |
| 23:45:23 | brixen | likewise |
| 23:46:02 | brixen | evan: you just adding a -rpath/to/signature ? |
| 23:46:09 | evan | no i trued that |
| 23:46:12 | evan | it didn't work |
| 23:46:17 | evan | because it said there was no Rubinius |
| 23:46:21 | evan | which is another easy fix |
| 23:46:29 | evan | instead i'm just calling Rubinius::CompilerNG directly |
| 23:46:35 | evan | in install.rake |
| 23:46:38 | evan | rather than shelling out. |
| 23:46:38 | brixen | k |
| 23:46:40 | evan | that fixed it. |
| 23:46:54 | evan | i'll need to update the rc2 tag |
| 23:47:45 | wayneeseguin | evan: Question, I keep gettin gthis: /Users/wayne/.rvm/src/rbx-head/lib/compiler/compiled_file.rb:40:in `dump': uninitialized constant Rubinius::Signature (NameError) |
| 23:47:57 | brixen | wayneeseguin: evan just fixed it |
| 23:48:00 | wayneeseguin | lol |
| 23:48:00 | wayneeseguin | w00t |
| 23:48:02 | wayneeseguin | ok |
| 23:48:05 | wayneeseguin | removes and re-installs |
| 23:48:10 | wayneeseguin | man he's fast ;) |
| 23:48:13 | brixen | wayneeseguin: you have to wait for the push |
| 23:48:14 | brixen | ;) |
| 23:48:22 | evan | thats what i'm fixing now. |
| 23:48:26 | wayneeseguin | oh |
| 23:48:36 | evan | not pushed yet |
| 23:48:36 | wayneeseguin | I thought git was able to do time travel ::grin:: |
| 23:48:38 | wayneeseguin | git pull future master |
| 23:48:44 | evan | wayneeseguin: can you hold up for about 20 minutes? |
| 23:48:46 | wayneeseguin | waits |
| 23:48:48 | evan | so you can use rc2 |
| 23:48:49 | wayneeseguin | evan: absolutely |
| 23:48:51 | wayneeseguin | it's only for benchmarks |
| 23:48:54 | evan | we're tagging it now. |
| 23:48:57 | wayneeseguin | ok great |
| 23:49:43 | wayneeseguin | evan: will it be @ http://asset.rubini.us/rubinius-1.0.0-rc2-20100104.tar.gz |
| 23:50:32 | evan | yes. |
| 23:50:57 | wayneeseguin | updates rvm |
| 23:51:01 | tarcieri | noice |
| 23:51:15 | evan | hrmph. |
| 23:51:23 | evan | the os x package building isn't working now. |
| 23:51:25 | evan | hrm. |
| 23:52:09 | evan | haha |
| 23:52:11 | evan | no, i'm wrong |
| 23:52:17 | evan | i was looking on the wrong machine |
| 23:52:21 | evan | i'm hilarious today. |
| 23:52:22 | brixen | heh |
| 23:52:24 | wayneeseguin | lol |
| 23:53:12 | brixen | it's the first monday of the year, has to have a higher than avg wtf % |
| 23:53:42 | evan | brixen: of the decade! |
| 23:53:50 | brixen | oh snap |
| 23:53:54 | brixen | you are right |
| 23:54:08 | brixen | the year of the decade |
| 23:55:02 | evan | oh yay |
| 23:55:05 | evan | i didn't push the rc2 tag yet. |
| 23:56:23 | boyscout | Fix how installed files are precompiled - 31f2d7b - Evan Phoenix |
| 23:58:13 | evan | ok, tags are pushed and tar.gz is in place |
| 23:58:20 | evan | going to build the 10.6 installer now |
| 23:58:45 | brixen | builds 10.5 |
| 23:58:55 | evan | brixen: build it from the tar.gz |
| 23:58:58 | evan | not from git. |
| 23:59:02 | evan | so the -v is correct |
| 23:59:20 | brixen | ok |
| 23:59:43 | boyscout | CI: rubinius: 31f2d7b successful: 3022 files, 11677 examples, 35868 expectations, 0 failures, 0 errors |