Show enters and exits. Hide enters and exits.
| 00:47:19 | Zoxc | is there a way to execute the block in some self context without defining a method on that context? |
| 01:10:23 | jarib | Zoxc: instance_eval ? |
| 01:15:21 | Zoxc | yeah, I just forgot that you could send an existing block to it :/ |
| 01:48:32 | benschwarz | Wheres that evan at? |
| 01:53:14 | evan | you rang? |
| 02:01:44 | benschwarz | evan: so here I sit, uglier than last month |
| 02:01:52 | benschwarz | with no donation from ephoenix |
| 02:02:00 | evan | i was waiting to see all the pictures |
| 02:02:08 | evan | so I could donate approriately. |
| 02:02:15 | evan | 11 and 18 are my faves. |
| 02:02:34 | benschwarz | I've got one to take today |
| 02:02:42 | benschwarz | I missed a couple through the month through travelling |
| 02:02:54 | benschwarz | got an idea for a last photo? |
| 02:03:07 | evan | maybe reaching to grab the ass of a little boy? |
| 02:03:11 | evan | or maybe thats taking it too far. |
| 02:03:13 | benschwarz | erm |
| 02:03:20 | benschwarz | women are already terrified of me |
| 02:03:20 | evan | yeah, lets back slowly away from that idea. |
| 02:03:31 | evan | now turn and RUN! |
| 02:03:46 | benschwarz | haha |
| 02:03:48 | evan | i'm going to throw $100 into the pot right now. |
| 02:04:01 | benschwarz | fucking brillient |
| 02:04:06 | benschwarz | brilliant |
| 02:04:38 | evan | with the knowledge that should I ever have prostate problems while on vaca down under |
| 02:04:40 | evan | i'll be safe. |
| 02:05:33 | benschwarz | and hopefully not having to take the prostate test "down under" |
| 02:06:36 | evan | pretty sure thats par for the coarse after age 40. |
| 02:06:43 | evan | so i've got 10 years of bliss left. |
| 02:07:17 | benschwarz | I'm holding on to my time |
| 02:07:32 | benschwarz | and enjoying the "no innys in the outie hole" status |
| 02:07:44 | evan | hah |
| 02:08:01 | evan | we've all heard stories of guys that get "EXIT ONLY" tattoo across their butt cheaks. |
| 02:08:09 | evan | I wonder what the proctologist must say. |
| 02:08:20 | evan | well, if you check your account |
| 02:08:28 | evan | you'll see a fat check from Uncle Evan. |
| 02:08:37 | evan | or electronic payment, as the case may be. |
| 02:10:19 | yakischloba | thinks this is a weird conversation to walk into and promptly retreats |
| 02:10:31 | benschwarz | its all about rbx yo |
| 02:13:58 | evan | yakischloba: you need to be dynamic in these trying times. |
| 02:14:09 | yakischloba | :) |
| 02:16:05 | evan | ujihisa!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| 02:16:18 | ujihisa | evan!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| 02:16:51 | evan | you've out done me again with !s |
| 02:16:55 | evan | next time I shall prevail! |
| 02:18:23 | ujihisa | hi :) |
| 02:18:26 | ujihisa | hahaha |
| 02:19:38 | evan | on rubinius related news |
| 02:19:44 | evan | I have found the source of the supurious hangs. |
| 02:19:53 | evan | spurious. |
| 02:20:08 | evan | the solution requires some thought though. |
| 02:21:01 | evan | in weird news, I get a sacajawea dollar coin today at a parking garage. Strange. |
| 02:21:50 | ujihisa | http://images.google.com/images?client=safari&rls=en&q=sacajawea%20doller&oe=UTF-8& ;um=1&ie=UTF-8&sa=N&hl=en&tab=wi |
| 02:21:54 | ujihisa | strange. |
| 02:22:45 | evan | yep, thats the one. |
| 02:23:20 | evan | the problem with large demonination coinage in the US is that |
| 02:23:26 | evan | 1) no machines take them |
| 02:23:30 | evan | 2) you never have them with you |
| 02:23:42 | evan | 3) 1 causes 2, 2 causes 1 |
| 02:24:31 | ujihisa | lol |
| 02:25:28 | ujihisa | I've heard that no US people use coins except quaters |
| 02:27:05 | evan | that is generally true |
| 02:27:13 | evan | you use the other coins for parking meters sometimes |
| 02:27:44 | ujihisa | I see |
| 02:28:23 | yakischloba | has a big pile of change on the desk that he has no use for |
| 02:32:09 | ujihisa | One of my friends collected such like one |
| 02:32:21 | ujihisa | He had a huge pile of change |
| 02:32:59 | ujihisa | When I was very poor, he gave it to me, and I used it to survive |
| 02:33:11 | ujihisa | (joking |
| 02:34:19 | evan | hehe |
| 02:34:22 | evan | poor ujihisa! |
| 02:34:29 | evan | maybe I should send you this dollar coin |
| 02:34:35 | evan | it would probably cost at least a dollar to send it though. |
| 02:34:36 | ujihisa | ($) |
| 02:37:49 | ujihisa | Shipping cost increases O(log n) while total money increases O(n) |
| 02:38:01 | ujihisa | So we can ignore the shipping cost when n is infinity |
| 02:42:08 | evan | well, thats good to know. |
| 02:42:18 | evan | for when I'm shipping you a universe-in-a-bottle |
| 02:43:04 | ujihisa | the bottle may be very handy |
| 02:43:25 | evan | it might have infinite mass, and there for have no mass |
| 02:43:29 | evan | so it might be easy to ship |
| 02:43:31 | evan | we'll never know. |
| 02:44:12 | ujihisa | we'll never know. |
| 02:44:26 | ujihisa | I found a photo of a handsome guy http://www.flickr.com/photos/tmaedax/4128581024/ |
| 02:46:00 | evan | ha! |
| 02:46:06 | evan | I've got some weird facial expression though. |
| 02:46:21 | ujihisa | haha |
| 02:48:01 | ujihisa | instantaneous shot |
| 02:55:50 | boyscout | Vastly improve "missing end" syntax errors - 7537128 - Evan Phoenix |
| 02:56:04 | evan | The tyranny of "syntax error, unexpected $end, expecting kEND" is OVER |
| 02:57:01 | evan | I give you: |
| 02:57:11 | evan | missing 'end' for 'class' started on line 3 |
| 02:57:40 | evan | no longer must you hunt to try and figure out what didn't get closed. |
| 02:57:55 | evan | it's my early holiday gift to all rubinius users! |
| 02:58:02 | evan | I should do a blog post on it. |
| 02:58:06 | evan | now... dinner! |
| 02:58:06 | will_l | that sounds awesome |
| 02:59:58 | boyscout | CI: 7537128 success. 3005 files, 11472 examples, 35615 expectations, 0 failures, 0 errors |
| 04:46:38 | will_l | What's a magic comment? I'm reading through the compiler and parser bits I've seen it pop up a few tiems |
| 05:04:12 | evan | will_l: it's a comment of the form |
| 05:04:17 | evan | # -*- foo -*- |
| 05:04:56 | will_l | what are they for? |
| 05:06:35 | will_l | oh, encoding types? |
| 05:07:13 | evan | 1.9 uses them for encoding |
| 05:07:27 | evan | in rubinius, i've made any available to the compiler |
| 05:07:34 | evan | right now, you can enable a compiler transform with one |
| 05:07:40 | evan | thats how array zen is enabled atm. |
| 05:12:31 | will_l | I'm looking at the Parser stage, and I've tracked things down to the file_to_ast call in melborune. It looks like this is taken care of by the grammer? |
| 05:12:48 | will_l | grammar |
| 05:14:03 | will_l | is this the part that's the MRI parser that i've read about? |
| 05:14:24 | evan | yeah |
| 05:14:34 | evan | file_to_ast is hooked up to the MRI parser we imported |
| 05:15:00 | boyscout | Added --show option to help configure debugging. - e93211e - Brian Ford |
| 05:15:43 | will_l | then once there's the ast, melboune visits itself around and we have a nice ruby ast |
| 05:16:04 | evan | sort of. |
| 05:16:15 | evan | when you call file_to_ast |
| 05:16:30 | evan | internally, a C NODE* tree is built |
| 05:16:32 | evan | just like in MRI |
| 05:16:42 | evan | but we then walk that tree and call methods for each node seen |
| 05:16:57 | evan | the called methods create AST node instances and return them |
| 05:17:12 | evan | so the internal visitor turns a NODE* tree into the ruby AST tree |
| 05:17:23 | evan | AST tree ug. That's like ATM machine. |
| 05:17:59 | boyscout | CI: e93211e success. 3005 files, 11472 examples, 35615 expectations, 0 failures, 0 errors |
| 05:20:38 | will_l | ah ok thanks. There's a lot of hopping around, but it's starting to make sense |
| 05:22:17 | will_l | also, not to pester, but I got a doc patch in the other week and I don't think I got the bit yet |
| 05:23:39 | evan | oh! |
| 05:23:41 | evan | sorry about that. |
| 05:23:44 | evan | whats your github name? |
| 05:23:54 | will_l | no worries. It's "will" |
| 05:24:12 | evan | There ya go! |
| 05:26:21 | will_l | thanks! |
| 05:34:43 | brixen | have bit, "will" commit :) |
| 05:35:02 | brixen | damn, closing... bbiab |
| 05:35:15 | will_l | I had some fun with my github username http://will.github.com/make_me/beautiful/ |
| 05:36:44 | brixen | haha |
| 05:38:16 | will_l | hah, also that reminds me I had a stab at implementing ruby in ruby over a year ago http://github.com/will/fauxbinius/ ;) |
| 05:38:54 | will_l | It's a bit harder than that I've come to realize |
| 05:44:31 | evan | the motto of that should be "Is it live or is it Memorex?" |
| 05:44:54 | evan | just pushed out a blog post about the enhanced syntax errors. |
| 08:47:11 | dbussink | evan: so what causes the weird hang? |
| 11:29:00 | rue | The Github ticket interface is slow to move around in |
| 11:47:48 | manveru | rue: i use the api to get the tickets and browse offline... |
| 11:49:21 | manveru | anw, what i wanted to ask, does EM run on rbx? |
| 11:51:13 | rue | Ah, good idea |
| 11:51:27 | rue | Dunno about EM, I think someone did get it to compile, though |
| 11:52:13 | manveru | got compile issues, doesn't EM have an FFI implementation? |
| 11:52:42 | manveru | hmm, seems not |
| 11:52:59 | manveru | ok, i'll just try whether ffi-tk works |
| 11:53:00 | rue | What do you see compiling? |
| 11:53:30 | rue | FFI does not have callback support currently, which may be a problem |
| 11:54:00 | manveru | might take a while to get that error again, had to nuke my rvm |
| 11:54:10 | manveru | uh, yeah, huge problem |
| 11:54:33 | manveru | i handle all the key events that way... |
| 11:55:53 | rue | It has not been an acute-enough itch up to now |
| 11:57:06 | manveru | heh |
| 11:57:13 | manveru | well, i guess ffi-ncurses would run |
| 11:57:35 | manveru | that doesn't need callbacks |
| 12:14:38 | dbussink | manveru: i saw someone tweet that all specs / tests passed for EM |
| 12:16:57 | rue | At any rate, a compile error compilation would be handy |
| 12:24:07 | manveru | yeah |
| 12:24:15 | manveru | if i can ever get it to build again ^^; |
| 12:32:05 | rue | I dunno if rvm got fixed...there was some problem with it trying to install Rake, but that should be solved |
| 12:33:52 | manveru | my issue is probably that the install of 1.8.7 fails |
| 15:01:26 | khaase | manveru: rue: the rvm issue is fixed |
| 15:12:23 | wayneeseguin | There was an issue? :) |
| 15:19:02 | rue | I talked at you about it ;) |
| 15:27:33 | wayneeseguin | oh haha |
| 15:27:42 | wayneeseguin | sorry, so busy I'm going crazy |
| 15:27:42 | wayneeseguin | :) |
| 17:06:12 | brixen | morning |
| 17:06:16 | brixen | agardiner!! |
| 17:06:41 | agardiner | brixen! howdy |
| 17:06:43 | agardiner | :-) |
| 17:06:49 | rue | `def foo(a = 1, *b, c); puts :yay; end` |
| 17:07:31 | evan | brixen: "super { |x| }" uses zsuper :/ |
| 17:07:35 | rue | Actually, make that `def foo(yeahforreals, a = 1, *b, c); puts :yay; end` |
| 17:07:36 | evan | i'm fixing the compiler now. |
| 17:07:49 | brixen | evan: erg, ok |
| 17:08:05 | Zoxc | should a benchmark that takes 4s on MRI use 120-240s and really slowdown X11 with rbx? |
| 17:08:08 | evan | zsuper, for when you sort of want the other stuff! |
| 17:08:19 | rue | Heh |
| 17:08:22 | evan | Zoxc: maybe! |
| 17:08:26 | evan | depends on the benchmark |
| 17:08:26 | rue | Zoxc: Elaborate? |
| 17:08:57 | rue | Oh, a trick question |
| 17:09:04 | rue | No, it SHOULD not ;) It might, though |
| 17:09:50 | agardiner | brixen: So I fired up the debugger today for the first time in ages, and hit an interesting problem immediately... |
| 17:10:14 | agardiner | seems rbx handles "%s" % "" differently to MRI |
| 17:10:22 | brixen | agardiner: hrm |
| 17:10:38 | rue | brixen: --show is good |
| 17:10:40 | agardiner | I found the problem, but it was a bit of a surprise to me |
| 17:10:54 | brixen | rue: cool |
| 17:11:04 | agardiner | i didn't know that *"" returns nil, but *"a" returns "a" |
| 17:11:19 | brixen | agardiner: um, ugh |
| 17:11:51 | Zoxc | http://binrapt-shares.googlecode.com/files/rbx_test.tar |
| 17:12:20 | agardiner | the problem is in string#%, where we spat args to pass to sprintf |
| 17:12:40 | slava | hi guys |
| 17:12:45 | brixen | hi slava |
| 17:13:45 | evan | Zoxc: in the future, please just paste them. |
| 17:13:57 | rue | Sec, going to find some tape |
| 17:15:21 | dwaite | good morning |
| 17:15:41 | evan | morning! |
| 17:15:43 | dwaite | brixen: want me to resend that patch? |
| 17:15:54 | rue | Hi ho |
| 17:16:04 | dwaite | evan: I moved bstring into melbourne and removed it, libcchash, libmquark and libmptr_array |
| 17:16:10 | Zoxc | know of any multi-file pastebins? |
| 17:16:23 | dwaite | well, some of bstring in, I left out a lot of the bits we don't use |
| 17:16:38 | dwaite | Zoxc: gist.github.com ? |
| 17:17:00 | brixen | dwaite: yes, could you redo the patch against evan's changes |
| 17:17:05 | evan | dwaite: sweet. |
| 17:17:16 | brixen | dwaite: and post a gist here so evan can look at it |
| 17:17:18 | evan | brixen: what is g.state.super ? |
| 17:17:43 | Zoxc | gist doesn't seem to accept files as input |
| 17:17:48 | brixen | evan: sec.. |
| 17:17:54 | evan | Zoxc: you still have to paste them into it. |
| 17:18:00 | evan | Zoxc: there is a command line gist tool you can use though |
| 17:18:40 | dwaite | brixen: I'll see if I can post a partial one. unfortunately, the removal made the patch size explode |
| 17:18:45 | rue | evan: Building Melbourne before the rest using the appropriate GCC works OK, though it is inelegant. |
| 17:19:16 | evan | rue: how so? |
| 17:19:17 | brixen | evan: it's a place to put super info on that generator |
| 17:19:25 | evan | who puts it there? |
| 17:19:32 | brixen | I'm looking heh |
| 17:19:56 | brixen | a method should |
| 17:20:25 | evan | k |
| 17:20:29 | evan | i've got the fix none the less |
| 17:20:29 | brixen | a defn defs |
| 17:20:30 | evan | just curious. |
| 17:21:07 | evan | btw, changing ast/sends.rb didn't cause the kernel to get recompiled |
| 17:21:10 | evan | did we change that? |
| 17:21:49 | brixen | no, it should |
| 17:22:00 | brixen | evan: git show 0deaf013d |
| 17:22:12 | evan | a deaf commit! |
| 17:22:17 | rue | That is in lib though? |
| 17:22:28 | brixen | evan: and 5d2851bf |
| 17:23:00 | evan | UG. i'm getting an unbalanced stack now. :/ |
| 17:23:10 | rue | evan: Mind, I dunno if there is a reasonable way to improve it, but having to grapple with two unrelated compiler chain choices in one workflow is just meh |
| 17:23:33 | rue | brixen: ^^ re #91. |
| 17:23:35 | evan | rue: well, they're not grappled together |
| 17:23:46 | evan | or rather, they shouldn't be |
| 17:23:49 | brixen | evan: hmm, yeah there is a problem not recompiling kernel, I'll fix it |
| 17:23:57 | evan | are we reused the Makefile generated for MRI on rbx? |
| 17:24:03 | evan | maybe thats the issue |
| 17:24:05 | evan | we shouldn't be doing that. |
| 17:24:17 | brixen | we should not be using any Makefiles in extensions now |
| 17:24:26 | brixen | le'me look at this ticket.. |
| 17:24:35 | evan | brixen: melbourne still has an extconf.rb |
| 17:24:51 | evan | no Makefile though, so perhaps the extconf.rb is cruft. |
| 17:24:54 | dwaite | http://gist.github.com/245576 |
| 17:24:54 | brixen | it is |
| 17:25:11 | brixen | dwaite: does that cleanly apply? |
| 17:25:18 | dwaite | brixen, evan: still big, but I left out deleting the bits in external_libs |
| 17:25:40 | dwaite | I rebased it ten minutes ago, but didn't pay attention if there were more posts :) |
| 17:25:58 | brixen | ok |
| 17:26:47 | evan | if it applies cleanly, compiles, and passes the specs |
| 17:26:49 | evan | then commit it. |
| 17:28:01 | rue | We are building an actual MRI extension though, right? |
| 17:28:45 | evan | yep |
| 17:28:50 | evan | melbourne is built twice |
| 17:28:52 | evan | once for MRI |
| 17:28:53 | evan | once for rbx |
| 17:28:54 | brixen | dwaite: yeah, go ahead |
| 17:29:08 | rue | In that sense it is fine that one may need to use different flags or whatever, it is just that this is in the same workflow as building the rest of rbx so there is no convenient way to separate the two toolchains |
| 17:29:25 | brixen | rue: why do they need to be separate? |
| 17:29:30 | brixen | ie what does separate mean? |
| 17:29:43 | evan | rue: is this because to build an MRI extension, you need to use gcc-4.2 |
| 17:29:47 | dwaite | brixen: I was really holding off to see if you had any tests you wanted to run to make sure my new quark impl isn't a performance regression. Although, I don't think the old implementation was super-streamlined either :) |
| 17:29:49 | evan | but you want to build RBX with 4.3 |
| 17:29:50 | evan | ? |
| 17:29:54 | rue | Yes |
| 17:29:56 | evan | AH |
| 17:29:59 | evan | put that in the ticket |
| 17:30:02 | rue | Or, 4.0 for MRI |
| 17:30:03 | brixen | dwaite: we'll address it if there are |
| 17:30:04 | evan | i think i've just put 2 and 3 together |
| 17:30:09 | dwaite | but if you are fine with me tossing it in, we can always fix that if it turns out to be a prob |
| 17:30:10 | evan | and gotten 5! |
| 17:30:13 | dwaite | yep, ok |
| 17:30:15 | evan | </monday math joke> |
| 17:30:38 | rue | It should already be there :) |
| 17:30:39 | evan | brixen: rue has a valid point |
| 17:30:45 | evan | brixen: when we compile an MRI extension |
| 17:30:57 | evan | we should just ignore the rbx CC variables and such |
| 17:31:02 | evan | and use whatever is MRI's rbconfig.rb |
| 17:31:30 | evan | rue: if it's there, my brain didn't distill it |
| 17:31:32 | brixen | evan: sure |
| 17:31:59 | brixen | evan: except that we won't always be bootstrapping with MRI |
| 17:32:09 | brixen | so we can't just pull out the rbconfig.rb stuff for MRI |
| 17:32:17 | dwaite | k, I'm going to do a fresh build 'just to make sure', should be 15 minutes |
| 17:32:27 | brixen | we need to add platform-specific settings for building the MRI ext |
| 17:32:41 | brixen | dwaite: sounds good |
| 17:32:44 | evan | brixen: right, lets just hack special MRI specific code in there for now |
| 17:32:50 | evan | this is a unique situation |
| 17:32:50 | brixen | evan: yes |
| 17:33:01 | evan | so a unique (aka hack) solution is warranted. |
| 17:33:10 | brixen | sure |
| 17:33:18 | evan | i think i'm going to start calling all my hacks "unique solutions" |
| 17:33:27 | evan | "check out the unique solution I did!" |
| 17:33:41 | dwaite | call it situational driven design ;-) |
| 17:34:49 | evan | wOO! |
| 17:34:51 | rue | Not so much driven as getting a ride |
| 17:35:11 | evan | we'll need a a flow chart of X driven design pragmas out there these days |
| 17:35:17 | rue | evan: I may have edited since |
| 17:35:19 | evan | which one you should be using |
| 17:35:24 | evan | rue: yep! i got it now. |
| 17:35:33 | evan | brixen: check out ast/sends.rb line 606 |
| 17:35:35 | rue | brixen: Yeah, it is not a straightforward issue |
| 17:36:05 | rue | Essentially doing the MRI build separately is the correct solution, it is just not optimal |
| 17:36:28 | evan | rue: how do you build MRI extensions now? |
| 17:36:33 | evan | do you pass CC= in everytime? |
| 17:36:43 | evan | not rubinius related stuff |
| 17:36:45 | evan | just normal extensions |
| 17:36:59 | dwaite | for example, I had to do a quite unique solution as part of this because I incorrectly assumed that Hash<const char*> and EqualTo<const char*> would carry over from the stl hash map extension |
| 17:37:15 | dwaite | so my hash was hashing and indexing by pointer value rather than string contents |
| 17:37:31 | dwaite | but the bootstrap uses MRI CFLAGS/CXXFLAGS, so DEV isn't honored |
| 17:37:35 | rue | evan: I rarely build them for 1.8 anymore, but that is probably how it would have to be |
| 17:37:44 | dwaite | I have a really unique patch to make it honored :) |
| 17:37:45 | evan | rue: ok |
| 17:37:48 | evan | rue: wanted to double check. |
| 17:38:09 | evan | dwaite: heheh |
| 17:39:09 | dwaite | I really dislike how languages 'give you' reference/pointer-wise hashing and equality concepts for free and by default |
| 17:39:27 | rue | I could possibly rebuild but I vaguely recall some issue; nevertheless, I think someone will potentially actually be tied to a particular MRI build |
| 17:39:30 | evan | lanugages being C++ stl :) |
| 17:39:36 | dwaite | and java |
| 17:39:42 | evan | oh yeah |
| 17:39:45 | dwaite | and CLR |
| 17:39:48 | brixen | evan: yes, line 606? |
| 17:39:50 | evan | they hash via Object.hash be default don't they |
| 17:39:54 | evan | brixen: pretty sure that line is wrong |
| 17:40:07 | evan | block_arg is a setter (BlockArgument object) for the block |
| 17:40:08 | evan | not a getter |
| 17:40:12 | evan | so i'm removing it. |
| 17:40:30 | rue | Oh, right, that is what I was asking before...I thought lib/ did not force a kernel rebuild |
| 17:40:31 | evan | and having zsuper use push_block if there is no explicit @block set |
| 17:40:47 | brixen | evan: it could very well be wrong, super was a bit of a mess |
| 17:40:54 | evan | brixen: ok, wanted to doublec heck. |
| 17:40:55 | brixen | nothing in there should be taken as 10 commandments :P |
| 17:41:01 | evan | i've got it sorted now. |
| 17:41:05 | brixen | sweet |
| 17:41:18 | dwaite | what would be the best way to not have to put ./lib on the load path for MRI |
| 17:41:37 | dwaite | hmm |
| 17:41:38 | rue | RUBYLIB? |
| 17:42:31 | rue | On the other hand, I am not sure about kernel code relying on lib code to that tight a degree |
| 17:43:01 | brixen | dwaite: for 1.9, that's probably the preferred solution |
| 17:43:26 | brixen | dwaite: well, if you mean for loading the compiler, I'm changing that |
| 17:43:39 | brixen | so running mri will not use -Ilib to require the compiler |
| 17:43:42 | dwaite | ahh excellent :) |
| 17:43:55 | brixen | since that fucks up stuff with RUBYOPT=rubygems for instance |
| 17:47:33 | boyscout | Write a new quark implementation in C++ for the compiler - 8e2acc8 - David Waite |
| 17:47:33 | boyscout | Remove now-unused libbstring, libcchash, libmquark and libptr_array - 05e8492 - David Waite |
| 17:48:26 | boyscout | CI: Build 05e8492 failed. http://ci.rubini.us/rubinius/builds/05e8492c82b267e57fa80d1f7746406538585ab9 |
| 17:48:50 | brixen | dwaite: hehe welcome to the jungle! |
| 17:49:09 | brixen | man, having to support building on 1.8 and 1.9 and all these install options now is carazy |
| 17:49:22 | dwaite | noo |
| 17:49:23 | brixen | we need to get some more/better CI in place |
| 17:49:34 | evan | ack |
| 17:49:39 | evan | i should change CI to not use -q |
| 17:49:43 | evan | so we can see what it's doing |
| 17:49:43 | evan | one sec. |
| 17:50:30 | evan | umm. |
| 17:50:37 | evan | dyld: lazy symbol binding failed: Symbol not found: _quark_from_string |
| 17:50:47 | dwaite | on.. huh? |
| 17:51:18 | dwaite | so its failing on link? |
| 17:51:26 | evan | I had to remove all the .o files from melbourne |
| 17:51:32 | evan | it didn't properly recompile things |
| 17:51:36 | dwaite | ahh |
| 17:51:50 | dwaite | it might be an issue with extern "C"'s |
| 17:52:31 | dwaite | but I tried with (apple gcc) 4.0, since its the oldest compiler I have |
| 17:52:56 | evan | erg. yeah, i had to clean out all melbourne build artifacts to get it to go |
| 17:52:57 | evan | here |
| 17:53:29 | dwaite | aha, yeah |
| 17:53:53 | dwaite | it didn't have any sort of dependency tracking to rebuild things that depended on quark, and the symbol subtley changed |
| 17:54:00 | dwaite | quark_from_string -> melbourne::quark_from_string |
| 17:54:14 | evan | right. |
| 17:54:30 | evan | trying to see if i can get rake to remove the build artifacts |
| 17:54:36 | evan | so everyone doesn't have to do this manually |
| 17:57:21 | evan | m, i think this will do it |
| 17:57:21 | evan | one sec. |
| 17:59:32 | dwaite | does a drumroll |
| 17:59:38 | evan | one sec! |
| 18:00:23 | rue | *tap, tap* |
| 18:00:56 | dwaite | starts to break into a drum solo |
| 18:01:13 | evan | i'm getting there, i'm getting there. |
| 18:01:55 | evan | chilax brohiam. |
| 18:02:32 | boyscout | Pull apart the yacc error message, report only the good part - f534f37 - Evan Phoenix |
| 18:02:32 | boyscout | Properly handle a block passed to zsuper. Fixes #103. - be625fa - Evan Phoenix |
| 18:02:32 | boyscout | Depend .o files on their own Rakefile - 49dc0e8 - Evan Phoenix |
| 18:02:53 | dwaite | back in 30 |
| 18:04:21 | boyscout | CI: Build 49dc0e8 failed. http://ci.rubini.us/rubinius/builds/49dc0e8e62bca99d135b817a86896e91f669db54 |
| 18:04:35 | evan | :/ |
| 18:04:38 | evan | still not reported. |
| 18:06:57 | boyscout | Include the string header - 6324fc5 - Evan Phoenix |
| 18:08:26 | rue | Hm, Activity Monitor is pretty nice |
| 18:09:33 | rue | Particularly Sample |
| 18:10:00 | boyscout | CI: 6324fc5 success. 3005 files, 11472 examples, 35615 expectations, 0 failures, 0 errors |
| 18:52:43 | rue | Mm, C++ string "handling" |
| 18:56:24 | dbussink | evan: what is the cause of the spurious hang? |
| 18:56:26 | dbussink | is having one right now :P |
| 18:57:23 | rue | Attach! |
| 18:57:50 | rue | (This is also why I always build:debug ;) |
| 18:58:59 | dbussink | rue: well, evan said he found it, so i'm curious :) |
| 19:23:49 | dwaite | I'm a little sad now, I wrote ptr_array and mquark for rubinius, and now they are no more |
| 19:25:42 | evan | heh |
| 19:25:54 | evan | their essence lives on in other code |
| 19:27:30 | brixen | dwaite: never mourn dead code |
| 19:27:49 | brixen | there lies the road to attachment, ego, and suffering :) |
| 19:28:51 | rue | Truep |
| 19:32:53 | evan | The past is but a workshop of horrors. |
| 19:33:41 | dbussink | evan: did you see my question? |
| 19:34:00 | evan | yes |
| 19:34:02 | evan | sorry |
| 19:34:18 | dbussink | np, just wondering |
| 19:34:20 | evan | basically, i changed it so the the JIT walks the opcodes via the control flow |
| 19:34:23 | evan | using a work list |
| 19:34:33 | evan | which means that the code is walked in any order |
| 19:34:37 | rue | Hm, apparently my Bank of America account is "undre imediate attack" and must be "clsoed down" right away using this handy link they provided |
| 19:34:48 | evan | but the JITVisit class expected it to be walked top to bottom |
| 19:35:02 | evan | so right now, it's easy for exception handlers to not get properly unregistered |
| 19:35:21 | evan | which means that commonly an ensure which is reraising an exception reraises it to itself |
| 19:35:24 | evan | thus hanging itself. |
| 19:35:43 | dbussink | that's a really tricky one :) |
| 19:35:50 | evan | i'm not sure if a VM is hung or hanged |
| 19:35:57 | evan | but it's stuck none the less. |
| 19:36:04 | dwaite | I still want to remove bstring, but now I feel a bit more confortable doing that via something like pegarus :) |
| 19:36:10 | dbussink | maybe stuck is the best description then ;) |
| 19:36:14 | evan | :) |
| 19:36:35 | evan | actually, we probably have had this bug before |
| 19:36:40 | evan | because the code for doing this is pretty brittle |
| 19:36:50 | evan | it's being redone as we speak. |
| 19:37:00 | dbussink | hehe |
| 19:37:17 | dbussink | evan: btw, what's your opinion on stylistic things like using return on the last line etc.? |
| 19:37:44 | evan | i flip flop on that |
| 19:37:51 | dbussink | i see that in the code :P |
| 19:37:53 | evan | but typically just have the thing I want to run at the end |
| 19:37:59 | evan | or I try to |
| 19:38:02 | evan | even though I think it looks wierd |
| 19:38:12 | evan | if you want to explicitly return something |
| 19:38:19 | evan | then I think that the return keyword is prudent. |
| 19:38:22 | evan | generally. |
| 19:38:33 | evan | except where it detracts |
| 19:38:33 | evan | like |
| 19:38:36 | evan | def foo |
| 19:38:40 | evan | ary.map { ... } |
| 19:38:42 | evan | end |
| 19:38:43 | dbussink | evan: well, i usually use return to break early, otherwise i just use the last statement way |
| 19:38:49 | evan | a return there adds nothing |
| 19:38:53 | evan | def foo |
| 19:38:54 | evan | a = nil |
| 19:38:57 | evan | <something blah> |
| 19:38:58 | evan | a |
| 19:38:59 | evan | end |
| 19:39:01 | evan | imho |
| 19:39:07 | evan | return a at the end is clearer. |
| 19:39:12 | evan | but i do try not to do that |
| 19:39:15 | evan | because I know most people don't. |
| 19:39:27 | dbussink | how about using the return of an if statement? |
| 19:39:36 | evan | like? |
| 19:40:06 | brixen | dbussink: paste your gist |
| 19:40:16 | dbussink | evan: https://gist.github.com/b6055f5b4892b4e8afbb |
| 19:40:21 | brixen | it has lots of good examples to discuss |
| 19:40:40 | evan | i don't really like the 2nd one |
| 19:40:45 | dbussink | brixen: i have a pretty big one atm |
| 19:40:58 | evan | mainly because it's hard to know if you intend to use the return value of if as the return value |
| 19:41:01 | evan | or if it's a bug. |
| 19:41:08 | evan | it's all about intention |
| 19:41:19 | evan | the value of an if is used so infrequently |
| 19:41:25 | dbussink | brixen: i'll grab some out of what i have now |
| 19:41:30 | evan | that i never intend for someone to use it. |
| 19:41:35 | dbussink | evan: personally i prefer the second one, but that's me |
| 19:42:34 | evan | sure, but i think you'd get a lot of "umms" if you asked people |
| 19:42:43 | evan | "what is the value of an if with a false condition" |
| 19:42:50 | rue | I almost never explicitly return from a conditional |
| 19:43:06 | dbussink | well, i think it's highly debatable :) |
| 19:43:08 | evan | because of those umms, people don't have the intention that it's used. |
| 19:43:14 | dbussink | also depending on your background etc. |
| 19:43:14 | rue | In first case, I would flip that around |
| 19:43:22 | rue | If you want to be explicit |
| 19:43:44 | evan | dbussink: i'd probably read the 2nd one as "he doesn't care what the return value is" |
| 19:43:53 | rue | `return unless lm = blah mah moogi` |
| 19:43:54 | evan | dbussink: not "he wants to return nil if the condition was false" |
| 19:44:20 | evan | lvar assigns on the far right hand side are hard to read |
| 19:44:22 | rue | I almost never explicitly return *after* a conditional, I should say. |
| 19:44:24 | evan | is my only nit with that. |
| 19:44:25 | dbussink | evan: well, the doesn't care to me implies nil, but i can see how that can also trick people sometimes |
| 19:44:44 | evan | dbussink: you better care that it implies nil |
| 19:44:48 | evan | because thats what you're returning. |
| 19:44:57 | dbussink | evan: i do, so therefore i use it |
| 19:45:10 | evan | you're confusing me. |
| 19:45:14 | dbussink | evan: but it's less clear for people who don't know the semantics |
| 19:45:18 | evan | "well, the doesn't care to me implies nil" <= ? |
| 19:46:05 | evan | in my opinion |
| 19:46:16 | evan | there is little upside in depending on that semantic |
| 19:46:16 | enebo | evan: You have a commit I can look at for your parser syntax error reporting magic? |
| 19:46:36 | evan | i prefer a little more typing fore more clarity |
| 19:46:42 | evan | i don't get paid per keystroke. |
| 19:46:47 | evan | enebo: i do! |
| 19:46:49 | enebo | The truth is that beyond jruby adding it we can probably push it back to MRI since they also probably hate those messages |
| 19:47:36 | dbussink | evan: hehe, well, for me both are clear and i find the return approach to be more verbose, but that's my opinion |
| 19:47:39 | evan | enebo: http://github.com/evanphx/rubinius/commit/7537128aa905b1721a58c719d25e44604a5ed6fe |
| 19:47:49 | evan | is more verbose a bad thing? |
| 19:48:13 | evan | imho, it's better to communication your intention to the next developer |
| 19:48:21 | evan | than to worry about the terseness of your communication to the compiler |
| 19:48:31 | evan | esp. since they turn into nearly the same thing |
| 19:48:56 | evan | it's not an absolutely maxium of course |
| 19:49:03 | evan | and i'd kill someone that went overboard in that dept |
| 19:49:07 | evan | but it's a happy medium |
| 19:49:19 | evan | we all just find that happy medium at different places is all. |
| 19:49:23 | evan | i don't really have a big issue with it. |
| 19:50:00 | evan | enebo: you just need a stack of <number, string> objects |
| 19:50:19 | evan | and then some carefully places push's and pop's |
| 19:50:26 | evan | s/places/placed/ |
| 19:50:45 | dbussink | evan: here are some other things i would like your opinion on: https://gist.github.com/424b2ce3948666af9864 |
| 19:51:01 | enebo | evan: yeah I figured you needed to maintain potential entry/exit points for relevent tokens |
| 19:51:51 | evan | dbussink: lines 40 and 41 should be indented |
| 19:51:52 | brixen | dbussink: I'm not a fan of the key? change :( |
| 19:52:01 | evan | otherwise it's very, VERY easy to miss the and |
| 19:52:29 | dbussink | evan: 30 / 31 you mean? |
| 19:52:39 | evan | no. |
| 19:52:41 | evan | in the gist |
| 19:52:44 | evan | 40 and 41 |
| 19:52:45 | enebo | evan: Yeah this is pretty simple and I don't think will impact perf if we pre-allocate the stack (and on overflow grow) |
| 19:52:48 | dbussink | i think i updated it :) |
| 19:52:51 | dbussink | evan: if you reload? |
| 19:53:05 | evan | ok, 31 and 32 now. |
| 19:53:13 | evan | you gotta tell me if you reload it! |
| 19:53:18 | evan | update, rather. |
| 19:53:18 | enebo | Largely code is not so deep so calculating a reasonable stacksize default will not be hard |
| 19:53:22 | dbussink | brixen: well, the !! is also used in other places |
| 19:53:29 | dbussink | evan: didn't know you were that fast ;) |
| 19:53:34 | brixen | dbussink: still not a fan |
| 19:53:39 | evan | enebo: huh? |
| 19:53:53 | dbussink | brixen: well, that could mean the other places should be changed too |
| 19:53:55 | evan | yes, i'm not a big fan of the !! mnemonic |
| 19:54:01 | evan | yeah, those should be changed as well. |
| 19:54:08 | evan | !! has bad intention, imho. |
| 19:54:11 | enebo | Sorry just saying stack maintenance can almost be free for this feature if we pre-allocate the stack |
| 19:54:24 | dbussink | evan: there is no other to_bool kind of thing is there? |
| 19:54:25 | evan | ah yeah |
| 19:54:37 | enebo | Our parser still needs to get faster not slower |
| 19:54:38 | evan | enebo: even a depth of like 20 or something is probably way more than any code will hit. |
| 19:54:48 | enebo | evan: yeah that is what I figured |
| 19:54:53 | brixen | dbussink: no, it doesn't mean other places need to be changed |
| 19:55:06 | brixen | dbussink: there is one place that !! is reasonable that I know of |
| 19:55:06 | evan | dbussink: brixen added a #to_bool |
| 19:55:20 | brixen | dbussink: changing #key? like that totally obscures it |
| 19:55:28 | brixen | I'd veto that change unless evan allows it |
| 19:55:35 | evan | i'd prefer the current impl. |
| 19:55:38 | evan | it's clear |
| 19:55:45 | evan | key? is true if find_entry returns anything |
| 19:55:50 | evan | otherwise it's false |
| 19:55:57 | brixen | simple |
| 19:55:59 | dbussink | and compared to find_entry(key).to_bool ? |
| 19:56:09 | evan | you can't actualy say it easily with !!find_entry(key) |
| 19:56:17 | evan | dbussink: nah |
| 19:56:22 | evan | nothing added |
| 19:56:27 | evan | only clearity taken away. |
| 19:56:34 | dbussink | evan: but how are you on the first ideas? |
| 19:56:43 | evan | which first ideas? |
| 19:56:48 | evan | you mean the other ones in this file? |
| 19:56:58 | evan | eof? is fine |
| 19:57:03 | evan | eql? is fine |
| 19:57:03 | dbussink | the first ones, 4,5,6 and 10,11,12,13 |
| 19:57:05 | evan | the change is fine |
| 19:57:07 | evan | i mean |
| 19:57:16 | evan | fix the indent on ==, then it's ok |
| 19:57:27 | evan | line 41 should stay |
| 19:57:38 | dbussink | evan: how do you feel on the return value of an assignment thing? probably no because of clarity right? |
| 19:57:41 | evan | line 52 should stay |
| 19:57:47 | evan | the last one is ok |
| 19:57:55 | evan | yep. |
| 19:58:00 | dbussink | evan: how are you on using () in general? |
| 19:58:09 | evan | it's too easy for it to appear that the return value of the method as anything |
| 19:58:28 | dbussink | evan: btw, these are some things that are inconsistent now anyway, so hence i want to point them out |
| 19:58:35 | evan | personally, when it's something with no reciever and no args and you know it's a method |
| 19:58:42 | evan | i prefer using () |
| 19:58:48 | evan | because it communicates the intention to the user |
| 19:59:09 | dbussink | well, i've also seen places where calling methods and not using () was advocated |
| 19:59:23 | evan | i find that more confusing that with () |
| 19:59:30 | evan | i don't know what the argument for no () is |
| 19:59:38 | evan | less typing is not a valid argument, btw. |
| 19:59:48 | evan | again, unless you get paid per byte. |
| 19:59:52 | dbussink | brixen: was that something you prefered or do i remember that wrong? |
| 20:01:26 | brixen | I don't use () unless it makes it clear |
| 20:01:34 | brixen | with no arguments, no () can be misunderstood |
| 20:01:48 | brixen | if there are arguments, I never use () unless syntax requires it |
| 20:01:56 | evan | me too. |
| 20:02:02 | brixen | you cannot look at these things like absolutes |
| 20:02:05 | brixen | they aren't |
| 20:02:06 | evan | again, because passing arguments makes it clear that you're calling a method. |
| 20:02:16 | evan | yeah, style is a feeling. |
| 20:02:16 | brixen | right |
| 20:02:19 | dbussink | true, but some places look a bit out of place |
| 20:02:20 | evan | like love. |
| 20:02:23 | evan | it's different for everyone. |
| 20:02:28 | brixen | communication is the point! |
| 20:02:29 | dbussink | where my feeling was tickling |
| 20:02:40 | dbussink | some places it tickles harder than others though |
| 20:02:41 | evan | yes, and like love, communication is the key to a long lasting relationship. |
| 20:02:43 | brixen | and remember, people comprehend things in chunks |
| 20:03:02 | brixen | if you have to string 10 things together, you are raising the cognitive burden |
| 20:03:16 | dbussink | btw, on a side note, any reason why attr_accessor is returning true? |
| 20:03:27 | evan | what should it return? |
| 20:03:28 | dbussink | in kernel/alpha.rb |
| 20:03:33 | dbussink | mri returns nil |
| 20:03:40 | evan | no reason. |
| 20:03:47 | dbussink | just like kernel/delta/module.rb sets up |
| 20:03:51 | evan | not that it geneally matters |
| 20:03:53 | evan | right |
| 20:04:01 | evan | because the alpha one is just to load stuff in the kernel |
| 20:04:08 | evan | the real one is what matters. |
| 20:04:23 | brixen | who uses the return value of attr_accessor? |
| 20:04:33 | brixen | especially if it's nil |
| 20:04:34 | brixen | haha |
| 20:04:47 | dbussink | brixen: i have no idea, but that's the reason i was wondering why it's true in kernel/alpha.rb |
| 20:04:56 | brixen | *shrug* |
| 20:05:29 | evan | it's fine to fix |
| 20:05:36 | evan | and you probably should |
| 20:05:43 | evan | because we've communicated noise to you |
| 20:05:45 | evan | which is our fault. |
| 20:05:55 | evan | the explicit true communicates that it means something |
| 20:05:57 | evan | when it doesn't. |
| 20:06:48 | dbussink | evan: hence me asking about it :) |
| 20:06:53 | evan | exactly. |
| 20:07:00 | evan | this just goes to my point |
| 20:07:11 | evan | that clearly communicating to the next programmer is one of the most important qualities |
| 20:12:13 | rue | dbussink: `find_entry(key) != nil` |
| 20:12:27 | evan | thats pretty good. |
| 20:12:37 | evan | clearly communications the intention |
| 20:13:07 | rue | A #to_bool might be handy, though |
| 20:13:17 | dbussink | rue: there is a to_bool already |
| 20:13:24 | evan | we have one, but I don't really like it. |
| 20:14:15 | dbussink | rue: but i like the idea, adding it :0 |
| 20:14:16 | dbussink | :) |
| 20:14:27 | dwaite | I still think conditionals should support coercions |
| 20:15:08 | dwaite | I want to create really negative objects who always are considered false |
| 20:16:05 | evan | please no. |
| 20:16:35 | dwaite | currently all of my objects are really positive |
| 20:17:19 | boyscout | Return value of attr_reader, attr_writer and attr_accessor should be nil - e5d76b1 - Dirkjan Bussink |
| 20:17:19 | boyscout | Some small stylistic changes to simplify the expressions - 53a9c32 - Dirkjan Bussink |
| 20:17:19 | boyscout | Prefer using do / end for multiline blocks - 54c5fd8 - Dirkjan Bussink |
| 20:17:19 | boyscout | Simplify Hash#key? - 0a2a702 - Dirkjan Bussink |
| 20:20:22 | boyscout | CI: 0a2a702 success. 3005 files, 11472 examples, 35615 expectations, 0 failures, 0 errors |
| 20:21:06 | dbussink | on a side note, ordered tickets and reserved hotel for the phusion tech talk at google next week, so crossing the pond then :) |
| 20:22:24 | evan | cool! |
| 20:23:19 | dbussink | actually just filled in the web thingy for the visa waiver program |
| 20:23:29 | dbussink | the next step in making me feel unwelcome :P |
| 20:23:36 | rue | That fucking asinine thing |
| 20:24:02 | rue | I, honestly, really hate crossing over because of the hassle they give me even though I am a resident. |
| 20:24:26 | dbussink | rue: i've never had any really big issues |
| 20:24:37 | dbussink | the most nasty check i ever had was actually at schiphol airport |
| 20:24:54 | dbussink | guess they want to crawl up the ass of the americans or something |
| 20:25:10 | evan | and they do! |
| 20:25:20 | dbussink | hehe |
| 20:25:23 | evan | I nearly got a full body search at schipol a while ago |
| 20:25:40 | evan | got the whole "so, did you go to any coffee shops?" line of questioning |
| 20:25:50 | evan | and then the complete search of everything I had. |
| 20:25:53 | dbussink | well, i still suspect that i don't have a lot of problems because i've visited the pentagon once and was probably screened for that :P |
| 20:26:07 | evan | I think they took the lining off my bag actually |
| 20:26:10 | evan | it was hilarious. |
| 20:26:53 | dbussink | that's really rediculous |
| 21:43:25 | enebo | evan: Do you guys have an AST dumper like our -S ast command (just prints out the tree) |
| 21:52:04 | rue | enebo: compile should allow you to see that |
| 21:52:52 | rue | enebo: $ vm/vm compile -A file.rb |
| 21:53:00 | enebo | rue: cool thanks |
| 22:05:13 | boyscout | -E does not produce sexp. - d37ccf0 - Eero Saynatkari |
| 22:08:09 | boyscout | CI: d37ccf0 success. 3005 files, 11472 examples, 35615 expectations, 0 failures, 0 errors |
| 22:32:08 | ujihisa | http://merbist.com/2009/11/30/lots-of-rubies-now-what/ |
| 22:32:19 | ujihisa | > Rubinius – use if you want to know what’s going on in your code |
| 22:32:22 | ujihisa | interesting |
| 22:37:57 | rue | Wait, MacRuby never released benchmarks? |
| 23:07:37 | evan | merbist appears to be down for me. |
| 23:07:43 | sbryant | same here |
| 23:08:43 | rue | Slashdotted, probably. |
| 23:10:50 | sbryant | I guess merb doesn't scale. LOLOLOLOLOLOLOLOLOLOL |
| 23:28:43 | evan | sbryant: ICE BURN |
| 23:29:07 | sbryant | hah |
| 23:29:57 | sbryant | TIME FOR BAKING! |
| 23:32:32 | evan | uptime is hard, lets go shopping!! |