Da
Show enters and exits. Hide enters and exits.
| 00:17:42 | evan | i'm back! |
| 00:17:59 | brixen | wb evan! |
| 00:18:37 | evan | shane and I shoke off the mondays and went to a lunchtime movie |
| 00:18:42 | evan | and wow was it terrible! |
| 00:18:48 | brixen | in your absence luislavena decided that ascii pr0n app would be the killer app for rbx |
| 00:19:01 | brixen | heh, what movie? |
| 00:19:02 | evan | rad. |
| 00:19:04 | evan | +1 |
| 00:19:14 | brixen | but only on win64 |
| 00:20:50 | luislavena | evan: hey evan, what movie did you watched? |
| 00:20:59 | evan | daybreakers |
| 00:21:10 | evan | a vampire movie with Ethan Hawke |
| 00:21:18 | evan | which could have been good. |
| 00:21:44 | evan | could have a fun scifi movie about what would happen if vampires became the dominant force in the world |
| 00:22:00 | evan | but no, they had to go cheezy horror after they intro'd with a little scifi. |
| 00:22:35 | luislavena | evan: nah, movies are very disappointing lately... |
| 00:22:56 | evan | oh, i wasn't disappointed |
| 00:23:07 | evan | i expected terrible! |
| 00:23:35 | evan | anyone speak czech? |
| 00:23:43 | evan | google translate fails on the word "pomaleší" |
| 00:24:32 | botanicus | evan: yeah, me |
| 00:24:36 | botanicus | evan: slower |
| 00:24:43 | evan | ok, i figured it was so. |
| 00:24:44 | evan | just curious. |
| 00:26:27 | luislavena | does anyone know where kirk haynes uses to hang out? (on IRC I mean) |
| 00:29:16 | brixen | you mean channel or nick? |
| 00:29:21 | brixen | he's in #rubyspec |
| 00:29:33 | brixen | wyhaines |
| 00:29:47 | luislavena | brixen: both things, thank you. |
| 00:29:54 | brixen | luislavena: n/p |
| 00:48:50 | evan | i think i found the vmmethod leak. |
| 00:48:54 | evan | working on it now. |
| 00:49:03 | brixen | nice |
| 00:49:12 | evan | in other news |
| 00:49:24 | evan | i have to stop using TypedRoot<> to solve random problems :? |
| 00:49:25 | evan | :/ |
| 00:50:26 | brixen | hm, I didn't realize you were solving random problems with it |
| 00:51:04 | evan | well, it's used too much. |
| 00:51:12 | evan | and is keeping important garbage from being collected. |
| 00:51:20 | evan | i'm solving the problem now. :) |
| 00:51:39 | brixen | I see |
| 00:52:16 | brixen | so there are things we are stashing in roots that need to not be roots? |
| 00:52:35 | evan | in this case (and i'm only about 75% sure at this point) |
| 00:52:53 | evan | VMMethod has a TypedRoot<> for the original CompiledMethod it's for |
| 00:53:12 | evan | which means that CM is only cleaned up when the VMMethod is deleted |
| 00:53:15 | evan | so when is a VMMethod deleted? |
| 00:53:16 | evan | NEVER! |
| 00:53:18 | evan | (oops) |
| 00:53:36 | brixen | ok |
| 00:53:51 | evan | so I made it so VMMethods are cleaned up (before i found this bug) and was confused why it didn't make a difference. |
| 00:53:59 | brixen | but is that an issue of using a TypedRoot or not cleaning up VMMethods? |
| 00:54:05 | evan | both really. |
| 00:54:19 | brixen | ok, then I'm following I think |
| 00:54:31 | evan | anytime a TypedRoot<> is used, the lifetime of the TypedRoot<> must be carefully considered. |
| 00:54:37 | brixen | gotcha |
| 00:54:53 | evan | otherwise it will keep parts of the object graph alive too long. |
| 00:55:01 | brixen | yeah, makes sense |
| 00:55:01 | evan | (or forever) |
| 00:55:04 | evan | OOH |
| 00:55:08 | evan | VAMPIRE TYPEDROOTS! |
| 00:55:11 | evan | taking over1 |
| 00:55:11 | evan | ! |
| 00:55:14 | brixen | heh |
| 00:55:25 | brixen | SharpenedStakes to the rescue |
| 00:56:10 | evan | hah |
| 00:56:15 | evan | anywho |
| 00:56:21 | evan | this is good |
| 00:56:32 | evan | because this is pushing down a refactoring i've wanted to do for a while anyway |
| 00:58:30 | brixen | cool |
| 02:37:43 | slava | hi y'all |
| 02:39:00 | rue | Hi one |
| 02:43:06 | brixen | hey slava |
| 03:48:59 | rue | brixen: The problem is not quite as severe there, but apparently LED lights shone through the ear canal directly into the brain almost completely removes effects of depression caused by lack of sunlight |
| 04:16:55 | kronos_vano | Yep, one more spec fixed! |
| 04:17:10 | rue | There was a spec for that? |
| 04:19:47 | kronos_vano | rue, http://pastie.org/774519 |
| 04:21:34 | rue | Ah! Something different ;) |
| 04:22:16 | kronos_vano | now '% u' % -25 work properly |
| 04:22:21 | kronos_vano | *works |
| 04:27:44 | rue | Mhm, is the space just ignored? |
| 04:28:10 | kronos_vano | yes |
| 06:49:09 | brixen | rue: oh interesting! they should integrate the LEDs with ipod earphones |
| 07:01:04 | alexsuraci | are chained blocks simply impossible in ruby, or is it just sort of a syntax limitation? for example I wrote a method that would be used like choice { foo } { bar }; it would try blocks until it runs out or until one succeeded |
| 07:01:35 | alexsuraci | trouble is MRI doesn't seem to accept the syntax. i'm wondering if that's implementation-specific (sorry to be slightly off-topic, but the people with the brains for that are here I think ;)) |
| 07:02:20 | slava | you have to wrap the block in a Proc, and pass the Procs to the method like ordinary arguments |
| 07:03:23 | alexsuraci | I could do that, but I was more wondering specific to blocks. This is a parser combinator library so I wanted to try making the syntax as simple as possible, with the primary point of the blocks to just be delaying evaluation |
| 07:03:54 | slava | what about lambda syntax? |
| 07:03:59 | alexsuraci | I *think* the implementation of the method itself is fine, but the syntax is rejected so I can't really test |
| 07:04:14 | slava | blocks are one of ruby's weak points unfortunately |
| 07:04:42 | alexsuraci | I wanted to avoid that too for the same reason (not a *huge* deal having ->{} instead of just {}, but it's a bit nastier) |
| 07:11:17 | brixen | alexsuraci: matz has said he hasn't found a simple enough syntax for multiple blocks and their use cases are quite limited so he's not really interested in adding them |
| 07:15:11 | alexsuraci | brixen: ah, ok. I guess the parser has a certain set of things that look valid for blocks to be passed to? I was thinking that was all determined at runtime, but I guess not. |
| 07:16:32 | brixen | syntax is well before runtime |
| 07:21:44 | alexsuraci | right, I just didn't think valid targets for blocks were limited/determined at that level, e.g. something that returned returned something that took a block could be called with successive blocks |
| 07:22:14 | alexsuraci | example: def foo; if block_given? then yield; foo; end end, I expected to be able to do something like this: (foo { puts "foo" }) { puts "bar" } (perhaps without the parens) |
| 07:22:20 | brixen | that would be interesting but no, it doesn't work that way |
| 07:23:19 | alexsuraci | alright. thanks for clearing it up and please excuse my rambling. :) |
| 07:23:24 | scoopr | foo(proc {a}, proc {b}) .. |
| 07:23:30 | brixen | alexsuraci: n/p |
| 08:18:29 | dbussink | netsplit party! |
| 08:19:10 | brixen | splitazas |
| 08:19:21 | brixen | that's like a martini or something |
| 08:25:38 | dbussink | brixen: with ice cubes please |
| 08:34:44 | slava | hi brixen |
| 12:52:25 | danlucraft | question: when rbx moved to github, did you keep the open commit bit policy? |
| 12:52:34 | dbussink | danlucraft: yeah |
| 12:52:54 | danlucraft | dbussink: but using evanphx's github repo? |
| 12:53:24 | dbussink | danlucraft: although brixen was rethinking it a bit for rubyspec, to only give it if a patch doesn't need any changes afterwards for style concerns etc. |
| 12:53:30 | dbussink | danlucraft: yeah, that's the main repo |
| 12:53:46 | dbussink | not actively using forks / pull requests |
| 12:54:53 | danlucraft | so do you still have to have a patch accepted first |
| 12:54:54 | danlucraft | ? |
| 12:55:24 | dbussink | danlucraft: yeah, that's still the policy |
| 12:55:31 | dbussink | danlucraft: why the questions if i may ask? |
| 12:57:42 | danlucraft | just wondering about doing the same for redcar |
| 12:57:55 | danlucraft | it's a little bit different on github because it's so easy to fork |
| 12:58:34 | danlucraft | I know the padre guys have the same policy |
| 12:58:47 | danlucraft | and when you're on svn, it's *serious* :) |
| 12:59:33 | dbussink | distributed vc makes it a lot easier for people to play |
| 12:59:56 | dbussink | redcar editor? |
| 13:00:01 | danlucraft | yeah |
| 13:00:03 | danlucraft | and yeah |
| 13:00:26 | dbussink | well, it depends on different things imho |
| 13:00:50 | dbussink | if they would do it with rails it would go out of control i guess |
| 13:01:09 | danlucraft | it's for encouraging people to get involved I guess |
| 13:01:10 | dbussink | because of it's nature, rubinius has a higher entry bar which filters a lot of the crap i think |
| 13:01:19 | danlucraft | yes, I was thinking that |
| 16:56:50 | evan | morning |
| 16:57:06 | danlucraft | morning |
| 16:57:16 | danlucraft | did you get a chance to look at that rak benchmark? |
| 16:57:32 | evan | going to today hopefully |
| 16:57:37 | evan | been hunting a memory leak |
| 16:57:39 | danlucraft | coolio |
| 16:57:55 | evan | I suspect we've got something pathalogical in there to fix |
| 16:58:00 | danlucraft | it's pretty heavy on the IO. |
| 16:58:00 | evan | that was the case with pathname |
| 16:58:13 | danlucraft | though there's a smidgen of metaprogramming in the main path too |
| 16:58:32 | evan | of what kind? |
| 16:58:41 | danlucraft | hang on, I'll show you it's pretty simple |
| 16:58:46 | evan | k |
| 16:59:19 | danlucraft | it's a grep style program right? |
| 16:59:31 | tenderlove | evan: morning |
| 16:59:47 | tenderlove | evan: it's not so exciting in here |
| 16:59:56 | evan | danlucraft: yep |
| 17:00:00 | evan | i'm famaliar with what it does |
| 17:00:07 | danlucraft | evan: so there are lots of options that don't change for every line of every file. |
| 17:00:09 | danlucraft | so I did thi: http://github.com/danlucraft/rak/blob/master/bin/rak#L539 |
| 17:00:18 | danlucraft | and it sped it up about 50% |
| 17:00:33 | evan | ah yeah, i saw that |
| 17:00:37 | evan | i looked at this code a while back |
| 17:00:41 | danlucraft | pretty simple |
| 17:00:46 | evan | this is only run up front though, yes? |
| 17:00:50 | danlucraft | yep |
| 17:00:50 | evan | not every file |
| 17:01:10 | evan | we'll take a hit at the beginning |
| 17:01:25 | danlucraft | yep |
| 17:01:26 | evan | but the bulk of the work should outweigh that |
| 17:01:32 | evan | profiling will show. |
| 17:01:37 | danlucraft | yep |
| 17:01:53 | danlucraft | the latest benchmarks are very impressive in general though. |
| 17:02:40 | evan | yeah! they show potential |
| 17:02:57 | evan | so we need to tune and shape code algorithmicly more now |
| 17:03:02 | evan | which is a great position to be in |
| 17:03:27 | rue | Hmorgenborgen |
| 17:03:37 | evan | is that a place in sweden? |
| 17:03:40 | danlucraft | i had no idea it'd come so far |
| 17:03:46 | danlucraft | falling down on the evangelism? |
| 17:03:48 | danlucraft | :) |
| 17:04:05 | evan | well, we've just released an rc2 |
| 17:04:09 | evan | so you caught wint of it somehow |
| 17:04:10 | evan | oh. |
| 17:04:21 | rue | Aww he left |
| 17:04:30 | rue | Rak looks interesting |
| 17:04:41 | Defiler | Yeah, I added it to my watch list |
| 17:04:45 | rue | He returned! |
| 17:07:06 | evan | danlucraft: what drove you to try rak on rubinius? |
| 17:07:08 | rue | I think I will try to get some time to work on Rubinius again, probably to no avail...there is indeed a bunch of algo stuff that can be done at this point |
| 17:07:12 | evan | something we did caught your attention |
| 17:07:23 | evan | yes, we haven't done much evangelism/advertising |
| 17:07:24 | rue | evan: What kind of question is that? Of course he would want to run it on rbx :P |
| 17:07:29 | evan | :) |
| 17:07:37 | danlucraft | I've been trying rak on rubinius since I first hacked on rubinius and rak was my only release open source project :) |
| 17:07:49 | danlucraft | that was back in 2007 or something |
| 17:07:57 | danlucraft | 2008 |
| 17:08:00 | danlucraft | sometime |
| 17:08:20 | evan | ok |
| 17:08:26 | evan | you were saying you had no idea |
| 17:08:30 | evan | so did you just randomly try again? |
| 17:08:36 | evan | or did the release of rc2 spur you on? |
| 17:08:39 | danlucraft | no, it was rc2 |
| 17:08:42 | evan | ok |
| 17:08:44 | danlucraft | I tried it again |
| 17:08:58 | danlucraft | I meant, those great benchmarks I saw somewhere last week were news to me |
| 17:09:11 | evan | which did you see? |
| 17:09:13 | danlucraft | and I think I just came across them because someone mentioned them in the jruby channel |
| 17:09:21 | danlucraft | hmm |
| 17:09:34 | rue | If the benches hold up, I can use those to my advantage maybe.. |
| 17:10:01 | danlucraft | these ones: http://rvm.beginrescueend.com/benchmarks/2010-01-06/ |
| 17:11:08 | evan | ok |
| 17:11:21 | evan | it's important that benchmarks are released by some external party |
| 17:11:33 | evan | of which wayneeseguin qualifies. |
| 17:14:36 | evan | there will be a time when we shout about our performance from the rooftops |
| 17:14:41 | evan | we're just not there yet |
| 17:15:17 | rue | Are we there yet? |
| 17:15:33 | evan | not yet my friend. |
| 17:15:33 | brixen | what's all this shouting about |
| 17:15:43 | brixen | joins the morning crowd |
| 17:15:45 | evan | Get off my lawns damn kids! |
| 17:15:48 | brixen | heh |
| 17:17:13 | brixen | mm Kernel.abort specs... these should be tasty |
| 17:18:35 | evan | heh |
| 17:37:55 | botanicus | evan: Hi, I'm just wondering if you have few secs to take a look at my commits (I sent you a pull request). I just want to ensure I'm doing it right. |
| 17:38:20 | evan | sure |
| 17:39:54 | evan | the changes look ok, but I don't see any spec changes |
| 17:42:31 | botanicus | evan: that's right, I wasn't sure what should I change? |
| 17:42:48 | botanicus | evan: I'm a bit confused, as I understand, rubinius has its own specs + rubyspec? |
| 17:43:10 | evan | thats correct |
| 17:43:15 | evan | we sync in rubyspec |
| 17:43:27 | evan | on the one_nine branch, the sync'd rubyspecs are in spec/frozen |
| 17:43:44 | evan | we should discuss with brixen how he'd like you to update the specs |
| 17:43:54 | evan | since we haven't dealt with spec changes on a branch before |
| 17:44:03 | botanicus | evan: OK, so if I'm doing changes just in kernel, what I should change? |
| 17:44:16 | evan | we need to discuss with brixen |
| 17:45:00 | botanicus | OK |
| 17:45:22 | brixen | um le'me finish these Kernel.abort fixups |
| 17:45:27 | brixen | and I'll sync one_nine |
| 17:45:43 | brixen | shouldn't be long |
| 17:46:12 | brixen | one_nine needs to have a bunch of stuff update actually |
| 17:46:24 | brixen | config, rakelib, mspec, specs... |
| 17:47:43 | evan | yeah |
| 17:47:52 | evan | shall we just git merge it over? |
| 17:48:01 | evan | should be ok |
| 17:50:48 | brixen | evan: hm, I suppose we could |
| 17:50:57 | brixen | I didn't want to mess up any of marcandre's work though |
| 17:51:04 | brixen | will git merge handle that correctly? |
| 17:51:06 | evan | yeah |
| 17:51:09 | brixen | k |
| 17:51:16 | evan | but i don't want us to spend a few days trying to redo changes on it |
| 17:51:26 | brixen | sure |
| 17:51:57 | marcandre | if you have trouble rebasing one_nine, just let me know and I'll fix it. |
| 17:52:30 | brixen | hmm, well now I'm confused |
| 17:52:33 | marcandre | evan: btw, the new version with the catch and throw is quite nice. Nicer then I could make it with an exception |
| 17:52:46 | evan | ok, i'll look at it. |
| 17:54:06 | botanicus | marcandre: could you send a link pls? I'd like to see where catch/throw is nicer than exception. |
| 17:56:04 | rue | They have different purposes |
| 17:56:17 | marcandre | botanicus: It's in common/thread.rb, the detect_outermost_recursion method. Caution: recursion can mess with your sanity. |
| 17:56:23 | rue | Although in almost all cases, I would be happier if catch/throw did not exist |
| 17:57:10 | botanicus | marcandre: thanks |
| 17:57:19 | botanicus | :) |
| 17:57:25 | botanicus | resursion is great |
| 17:57:45 | botanicus | rue: me too, that's why I'm interested in marcandre's example |
| 18:00:36 | marcandre | This example is a bit peculiar. That method is only used in Array/Hash/Struct#hash and what it has to do is a bit ugly. |
| 18:17:08 | rue | I did implement a POC brute conditional compilation using catch/throw |
| 18:19:04 | evan | POC? |
| 18:19:18 | brixen | proof of concept |
| 18:19:29 | evan | ah yes. |
| 18:19:39 | brixen | I'm assuming |
| 18:40:02 | rue | Yes |
| 18:40:13 | rue | Conveniently also piece of crap |
| 18:41:17 | brixen | heh, oh I remember that now |
| 18:41:46 | rue | It worked is probably the best thing that can be said of it |
| 20:00:06 | brixen | marcandre: I don't mean to be an ass, but seriously wtf @ this line http://bit.ly/5npJii |
| 20:00:19 | brixen | local vars are not evil |
| 20:00:21 | brixen | please |
| 20:00:33 | evan | UG |
| 20:00:34 | marcandre | :-) |
| 20:00:34 | Defiler | oof |
| 20:00:38 | Defiler | That method is gnarly |
| 20:00:43 | brixen | yes, it is |
| 20:01:12 | evan | and it's extra slow |
| 20:01:23 | evan | all the splating and turning back into arrays |
| 20:01:59 | Defiler | You could avoid some more work by changing the partial_product + [obj] thing too |
| 20:02:04 | brixen | marcandre: I got a merge conflict on that method, I'm going to leave it for you to fix up |
| 20:02:04 | marcandre | evan: It has to produce new arrays, though, no? |
| 20:02:21 | evan | yeah, it does |
| 20:02:27 | evan | this method must go |
| 20:02:30 | evan | unless |
| 20:02:48 | marcandre | brixen: no problem. |
| 20:02:58 | evan | there is about twice as many comments as there is no |
| 20:03:01 | evan | one before each line |
| 20:03:04 | evan | because i can't follow this. |
| 20:03:07 | Defiler | I'll bet it would be faster to dup 'arg' and then modify it in place thereafter |
| 20:04:18 | marcandre | Defiler: probably, since it would avoid creating the temporary array [obj] |
| 20:04:23 | evan | no more code golf. |
| 20:04:25 | evan | please |
| 20:04:28 | evan | for the love of pete. |
| 20:04:33 | brixen | heh |
| 20:04:46 | Defiler | It would avoid two array contructions for every array element actually |
| 20:05:02 | Defiler | the one from [obj] and the one for the new array that results from partial_product + |
| 20:08:05 | evan | pretty sure this algorithm is untenable for anything but a small data set |
| 20:08:16 | evan | if there is an enumerator for every combinination |
| 20:08:21 | marcandre | Actually, this is an old version. I rewrote it with lambdas, dup and push |
| 20:08:22 | brixen | marcandre: aside from the other various things, I'm specifically objecting to breaking on the method call . |
| 20:08:23 | evan | then calling this on an array with 100 elements |
| 20:08:25 | Defiler | I've been trying to figure out the complexity order of it and it is hardcore |
| 20:08:26 | evan | will use up all memory. |
| 20:08:43 | brixen | marcandre: that is a horrible style for the reader tracking the left side of the code block |
| 20:09:51 | brixen | marcandre: especially since Array#inject exists and that looks like a self send |
| 20:10:28 | evan | oh shit. |
| 20:10:33 | evan | i thought it was a self send |
| 20:10:34 | evan | FAIL. |
| 20:10:37 | brixen | the end pairing is then totally fucked |
| 20:10:44 | brixen | yeah, it really threw me |
| 20:11:20 | evan | yay! solved the VMMethod leak. |
| 20:11:24 | brixen | I mean, I know you can do this, but please, don't do it |
| 20:11:28 | brixen | evan: woot! |
| 20:11:37 | evan | spec run with JIT on before: 360M |
| 20:11:41 | evan | after the fix: 216M |
| 20:11:47 | brixen | awesome! |
| 20:12:13 | evan | still got a little more work to do on it |
| 20:12:14 | marcandre | brixen: the link you gave me, is that in the one_nine branch? |
| 20:12:20 | brixen | marcandre: yes |
| 20:12:34 | dbussink | evan: w00t :) |
| 20:12:35 | marcandre | Ok. I forgot to copy paste the newer version (in trunk) |
| 20:12:36 | marcandre | http://github.com/evanphx/rubinius/blob/master/kernel/common/array.rb#L1065 |
| 20:13:05 | brixen | marcandre: ok, want me to just paste that in? |
| 20:13:27 | marcandre | yup |
| 20:13:48 | evan | this algorithm has the same problem |
| 20:13:48 | brixen | marcandre: k |
| 20:13:56 | evan | it's exponential isn't it? |
| 20:14:05 | evan | any usage on a large data set will use all memory |
| 20:14:05 | marcandre | evan: so what is the issue, then? |
| 20:14:29 | evan | well, the issue is that it should not use all memory. |
| 20:14:57 | marcandre | The algorithm itself uses n arrays of size 0..n |
| 20:15:31 | marcandre | The result size is much bigger than that, and there's nothing I can do about that, no? |
| 20:15:34 | evan | [self, *args] should just be args.unshift self |
| 20:16:01 | marcandre | that's fine |
| 20:16:45 | marcandre | I still don't get the memory issue. |
| 20:16:56 | evan | i think this might be ok |
| 20:16:58 | evan | i'm trying to follow it |
| 20:16:59 | evan | :/ |
| 20:17:25 | Defiler | why does this reverse before inject? |
| 20:17:26 | evan | lets see, give an array with N elements |
| 20:17:34 | brixen | marcandre: did you update the CI tags before? I'm getting hundreds of E/F with mspec ci |
| 20:17:36 | dbussink | looks like O(n^2) to me |
| 20:17:41 | evan | there will be N lambdas |
| 20:17:44 | marcandre | Defiler: the reverse is so that we iterate on self last, not first |
| 20:17:51 | dbussink | and i doubt that it can be lower in complexity |
| 20:18:09 | Defiler | Why not just put self at the end of the array? |
| 20:18:13 | evan | and N^2 arrays created |
| 20:18:42 | evan | yes |
| 20:18:49 | evan | ary.push(self).inject()... |
| 20:18:57 | marcandre | Defiler: well, more explicitely, we iterate on the last given argument first. It's up to the implementation, but I'm following MRI here |
| 20:19:13 | Defiler | so, wait.. the inject memo starts with a method object? |
| 20:19:28 | Defiler | and then gets replaced with a new lambda every time? |
| 20:19:54 | marcandre | Yup. Kind of a recursive method. |
| 20:19:56 | evan | marcandre: i'm fine ditching the reverse |
| 20:20:07 | evan | the order of the output should not matter. |
| 20:20:13 | marcandre | Personally I find that pretty cute, but tastes vary :-) |
| 20:20:22 | evan | i find it pretty obtuse. |
| 20:20:31 | evan | and Method#call is not exactly fast. |
| 20:21:19 | marcandre | Well, another would be a recursive function (which is equivalent to #call) or else it gets de-recursified and that I find ugly. |
| 20:22:26 | Defiler | http://gist.github.com/275563 |
| 20:22:34 | Defiler | is what I would expect the first part of this method to look like |
| 20:22:42 | evan | https://gist.github.com/e810d93314e507cd4aa5 |
| 20:23:01 | evan | thats much closer to the style i'd prefer |
| 20:23:07 | Defiler | you want arg = arg.map right? |
| 20:23:11 | marcandre | Looks good |
| 20:23:31 | evan | Defiler: nah, it's the splat |
| 20:23:35 | evan | so the method owns it. |
| 20:23:46 | evan | marcandre: you going to make the change? |
| 20:23:48 | evan | or should I. |
| 20:24:02 | marcandre | I'll do it if you want |
| 20:24:12 | evan | ok, thanks. |
| 20:24:51 | marcandre | and I'll update the one_nine branch (as I should have previously...) |
| 20:24:55 | evan | k |
| 20:25:10 | Defiler | evan: Oh, excellent point |
| 20:27:21 | marcandre | Damn, the doc doesn't state explicitely that the order is implementation dependant. It's #combination that does. |
| 20:28:02 | marcandre | I'll keep the reverse for now, then. |
| 20:29:54 | brixen | evan: can you set up CI reporting on one_nine of we'er going to have ppl working on it, pls |
| 20:33:36 | evan | yeah |
| 20:34:05 | evan | wrt the ruby-core pluggable GC discussion: |
| 20:34:25 | evan | it's like people are stating "the only thing thats holding MRI back from an awesome GC is that there is no pluggable interface!" |
| 20:34:32 | evan | never mind that thats the EASIEST part |
| 20:34:41 | evan | they're glossing over actually writing the GC. |
| 20:34:53 | brixen | heh, yeah |
| 20:35:14 | Defiler | It's like when people basically come claim that they would happily contribute <insert freaking difficult thing here> if our docs were better. |
| 20:35:26 | brixen | no one has a GC to plug in, but if you put the receptacle there, one will magically appear |
| 20:35:29 | Defiler | Dude, if you are blocked by the docs, you didn't have a chance at <difficult thing> |
| 20:39:45 | dbussink | there are dozens of GC's out there, we could just plugin in any one and it wil work! |
| 20:39:51 | dbussink | i don't understand what's so hard! |
| 20:40:21 | evan | we should be able to do as a weekend project! |
| 20:41:09 | dbussink | evan: gosh, you need a whole weekend for that? pfff |
| 20:41:19 | evan | heheh |
| 20:41:30 | Zoxc | I could plugin in the Boehm GC in mirb pretty quick, even without an API :D |
| 20:41:33 | brixen | friday night, coupla beers, done! |
| 20:41:45 | evan | Zoxc: thats the point of Boehm, there is no API! |
| 20:42:00 | Zoxc | there's the Boehm GC API? |
| 20:42:29 | Defiler | That's kinda the whole point of conservative collectors in general, right? |
| 20:42:34 | evan | Zoxc: this discussion "couldn't we have a GC plugin API so I could choose between reference counting, or accurate generational?" |
| 20:42:42 | evan | "also, could I have it hotswap via gems?" |
| 20:42:49 | evan | Zoxc: nope! |
| 20:42:54 | evan | well, there is |
| 20:42:57 | evan | GC_MALLOC rather than malloc. |
| 20:42:59 | evan | but thats it. |
| 20:43:08 | Zoxc | TinyGC and Boehm GC shares an API =P |
| 20:45:51 | evan | hehe |
| 20:46:37 | Zoxc | what platforms can rubinius run on? |
| 20:47:12 | evan | any unix platform atm |
| 20:47:15 | brixen | all reasonably good platforms |
| 20:47:21 | brixen | oh, I mean unixy ones |
| 20:47:27 | evan | but thats only because we haven't taken the time to port any APIs to non-unix |
| 20:47:35 | evan | there is nothing unix or platform specific |
| 20:47:43 | evan | no memory tricks, etc. |
| 20:48:29 | Zoxc | I was thinking of running it on ARM :) |
| 20:48:45 | dbussink | i think there have been people who tried that |
| 20:49:00 | dbussink | compiling llvm on a small box is going to be a pita though :p |
| 20:49:19 | dbussink | evan: btw, that reminds me, i've uploaded a new version of the llvm x86_64 linux prebuilt |
| 20:49:27 | Zoxc | rubinius doesn't like cross compiling? =P |
| 20:49:27 | evan | why? |
| 20:49:36 | dbussink | which is compiled with gcc 4.1, which seems to work with newer versions but not reverse |
| 20:49:37 | evan | Zoxc: i don't follow. |
| 20:49:54 | dbussink | evan: this actually followed from that guy trying on centos |
| 20:50:03 | dbussink | my gcc 4.3 debian build didn't work there |
| 20:50:13 | dbussink | so i built it there and tried that one on my debian box |
| 20:50:14 | evan | well shit |
| 20:50:15 | dbussink | which did work |
| 20:50:21 | evan | is the uname different though? |
| 20:50:25 | dbussink | nope |
| 20:50:30 | Defiler | evan: Hey, I watched your talk from the LLVM thing in October the other day.. did anything ever come out of the discussion about how to package LLVM in an open source project? |
| 20:50:32 | evan | then it won't help. |
| 20:50:39 | dbussink | it's all x86_64-unknown-linux-gnu |
| 20:50:41 | evan | because it will probably break other people |
| 20:50:45 | Defiler | Or is what rbx does now the result of that discussion? |
| 20:50:56 | evan | Defiler: nope. |
| 20:51:34 | dbussink | evan: well, from what i've tested with systems is that it does work if you have a 4.1 compiled version with a 4.3 compiled rubinius but not the other way around |
| 20:51:49 | dbussink | evan: so this version most likely works for more configurations |
| 20:52:16 | evan | we should actually find out first |
| 20:52:51 | dbussink | true, my sample size is pretty small i admit |
| 20:53:00 | evan | plus you're saying 4.1 LLVM works with 4.3 RBX |
| 20:53:07 | dbussink | yeah |
| 20:53:07 | evan | wouldn't that mean that 4.4 LLVM won't work with 4.3 RBX? |
| 20:53:14 | evan | so we would not want to change it. |
| 20:53:23 | dbussink | we have a 4.3 llvm build now |
| 20:53:31 | evan | oh, you compiled against 4.1 |
| 20:53:32 | evan | gotcha. |
| 20:53:33 | evan | hm. |
| 20:53:42 | dbussink | exactly |
| 20:53:50 | evan | i don't like the confusion. |
| 20:54:12 | dbussink | well, another option is no prebuilts for linux |
| 20:54:21 | dbussink | or include the gcc version or something in it |
| 20:54:41 | evan | yeah |
| 20:54:42 | Defiler | gcc's compatibility is just.. great. |
| 20:54:43 | evan | i'm thinking maybe that. |
| 20:55:15 | dbussink | Defiler: well, looks like it's compatible one way, but i'm sure there's some situation where it breaks |
| 20:55:50 | Defiler | Probably, yeah |
| 20:56:47 | evan | i need lunch. |
| 20:56:49 | evan | bbiab. |
| 20:57:02 | evan | also, i was wrong about the memory improvement. |
| 20:57:04 | evan | le sigh. |
| 20:57:37 | dbussink | puts the champagne back into the fridge |
| 20:58:00 | dbussink | it will come out some day though! |
| 21:01:51 | dbussink | evan: Office 2010: The Movie might cheer you up ;) |
| 21:01:52 | dbussink | http://www.youtube.com/watch?v=VUawhjxLS2I |
| 22:14:32 | rue | Is it the U.S. "Office"? |
| 22:16:21 | rue | *sigh* getmail has been off for a day :/ |
| 22:18:49 | rue | Effing launchd |
| 22:26:23 | evan | ok, i do have some memory fixes |
| 22:26:37 | evan | they just don't appear to go as far as I'd like yet. |
| 22:26:44 | evan | but i'm going to commit them anyway |
| 22:26:52 | brixen | cool |
| 22:27:00 | brixen | I almost have a clean CI on one_nine |
| 22:27:08 | evan | rad. |
| 22:28:09 | brixen | I'm making some empty stubs for Encoding to make it easier |
| 22:28:22 | brixen | so there are not exceptions during before/after actions |
| 22:29:19 | brixen | the syntax issues will just get excluded in the .mspec config files for now |
| 22:29:33 | brixen | and those are updated to run the 1.9-specific libs |
| 22:29:45 | brixen | *libs' specs |
| 22:29:45 | evan | k |
| 22:30:00 | brixen | so we can have a clean CI report |
| 22:52:48 | brixen | that was, kernel panic while running the specs |
| 22:52:55 | brixen | probably not related |
| 22:55:06 | evan | fun! |
| 22:55:35 | brixen | heh |
| 22:56:51 | evan | hm, is boyscout not working? |
| 22:57:18 | evan | oh, where is he? |
| 22:59:42 | brixen | ok, that's two in row |
| 22:59:55 | rue | Ah, awesome, the GC thread just keeps getting better |
| 22:59:59 | brixen | maybe I'll try running the specs with no ff running |
| 23:00:46 | rue | I tried politely saying to forget it and to target more modern platforms but it seems that did not have any effect |
| 23:03:56 | boyscout | CI: rubinius: 945145d successful: 3024 files, 11747 examples, 35948 expectations, 0 failures, 0 errors |
| 23:04:15 | evan | rue: yeah. the direction it's taken is pretty comical now |
| 23:04:53 | evan | sort of like "the only reason i'm not building this nuclear power plant is that you guys can't tell what color it should be! once you tell me that, i'll build it." |
| 23:06:21 | rue | Yes, and if they just wore gloves they would not need to build the plant. That is the part that puzzles me |
| 23:07:00 | evan | "my hands are cold! Can you put a nuclear heater in my coat pockets please?!" |
| 23:10:35 | BrianRice-work | GC thread? |
| 23:10:46 | evan | BrianRice-work: on #ruby-core |
| 23:10:50 | evan | the mailing list |
| 23:11:02 | BrianRice-work | oh, I was looking at the google group |
| 23:31:40 | evan | well, this is good |
| 23:31:50 | evan | I did figure out how to save 100M on a full spec run. |
| 23:31:59 | evan | not exactly the direction I was taking |
| 23:32:03 | evan | but a good one anyway |
| 23:32:04 | evan | :) |
| 23:33:58 | brixen | sweet |
| 23:39:28 | boyscout | Delete IR after JIT'ing unless -Xjit.debug - 94817d4 - Evan Phoenix |
| 23:40:27 | brixen | ahh |
| 23:42:24 | evan | i guess unladden swallow already knew this trick |
| 23:42:26 | evan | but they didn't tell me! |
| 23:43:21 | brixen | that's mean! |
| 23:43:40 | brixen | can't trust those pythonistas heh |
| 23:43:43 | evan | hehe |
| 23:44:44 | boyscout | CI: rubinius: 94817d4 successful: 3024 files, 11747 examples, 35948 expectations, 0 failures, 0 errors |