Da
Show enters and exits. Hide enters and exits.
| 00:09:12 | evan | i wonder if FONC and such are dead. |
| 00:11:00 | brixen | I saw a couple emails recently |
| 00:11:06 | brixen | good question though |
| 00:11:26 | evan | the emails from today are weird |
| 00:11:33 | evan | they're not at all FONC related |
| 00:11:46 | evan | and I haven't seen anything in almost a year I think. |
| 00:12:11 | brixen | ahh hm, just got today's email |
| 00:12:38 | brixen | I thought there was one regarding the wiki that a vpri staff responded to recently |
| 00:12:42 | brixen | but I could be mistaken |
| 00:13:22 | evan | http://www.vpri.org/fonc_wiki/index.php?title=Main_Page&action=history |
| 00:13:33 | evan | ian's last change was in 2008 |
| 00:14:19 | brixen | hmm |
| 00:15:18 | evan | the last svn commit was 2009-04-20 |
| 00:15:29 | evan | and it was nearly a month from that to the one before it |
| 00:17:17 | evan | maybe I should email them and go have lunch again |
| 00:18:31 | evan | their NSF grant is still going I think |
| 00:18:36 | evan | so maybe they're just heads down on something |
| 00:18:43 | brixen | could be |
| 00:18:58 | brixen | would be neat to talk to Ian now with all you jit experience under your belt |
| 00:19:03 | brixen | I'd imagine |
| 00:19:44 | brixen | bin/rbx compile -S -s^kernel:runtime kernel/ almost completes |
| 00:19:53 | brixen | where -S is printing sexps |
| 00:19:59 | evan | oooh |
| 00:20:01 | evan | fantastic! |
| 00:20:14 | evan | are we loosing any info in creating the sexp's? |
| 00:20:30 | brixen | heh interesting you should ask that |
| 00:20:43 | brixen | I was going to build an old rbx and pipe it in to see :) |
| 00:20:52 | evan | hehe |
| 00:20:58 | brixen | I'm basically making the sexp much like ryan's unified form |
| 00:21:06 | evan | cool |
| 00:21:06 | evan | yeah |
| 00:21:10 | brixen | sexps are nice for the compact visual representation |
| 00:21:13 | brixen | but that's about it |
| 00:21:14 | evan | yeah |
| 00:21:28 | brixen | it's weird converting our nice AST back to MRI's weird parsetree |
| 00:21:29 | brixen | kinda |
| 00:21:55 | evan | hm, how should I write a spec for this autoload-tramples-on-current-exception bug |
| 00:21:55 | brixen | I think ast/control_flow.rb is my last file |
| 00:22:01 | brixen | hmm |
| 00:22:24 | evan | i could add it to the autoload specs i guess |
| 00:22:31 | brixen | sure |
| 00:22:35 | evan | k |
| 01:14:17 | rue | I thought Ian had something to do with Go now? |
| 01:14:34 | evan | not that I know of. |
| 04:29:10 | qbproger | evan, the link for the git repo seems dead: http://rubini.us/ |
| 04:32:23 | manveru | a lot of links on the site are dead |
| 04:32:44 | qbproger | bah, where is the git repo? |
| 04:33:45 | manveru | qbproger: on github |
| 04:34:29 | qbproger | http://github.com/evanphx/repositories |
| 04:34:33 | qbproger | i don't see it there |
| 04:34:41 | manveru | weird |
| 04:35:07 | manveru | it was there just a day ago |
| 04:35:27 | qbproger | hmmm wonder what's going on |
| 04:36:11 | manveru | one second |
| 04:36:23 | manveru | i can still pull from it |
| 04:36:30 | manveru | git://github.com/evanphx/rubinius.git |
| 04:36:33 | qbproger | alright |
| 04:36:38 | qbproger | i'll give it a go |
| 04:36:51 | manveru | maybe hiccup in github... i'll let them know |
| 04:44:27 | manveru | qbproger: ok, it's back |
| 04:44:37 | qbproger | alright, cool :) |
| 04:55:51 | manveru | i just ran klinkchecker over the site... only 3 dead links |
| 04:58:00 | manveru | 4 |
| 21:08:24 | dbussink | evan: ping? |
| 21:19:40 | dbussink | brixen: you there? |
| 21:29:05 | evan | dbussink: in and out, some friends with their baby over |
| 21:29:06 | evan | wassup? |
| 21:29:51 | dbussink | evan: ah, np, wanted to get your opinion on http://github.com/evanphx/rubinius/issues#issue/197 |
| 21:30:03 | dbussink | basically there are a bunch of asserts() where stuff is called inside the assert |
| 21:30:24 | dbussink | so if asserts are disabled, that code isn't executed which can cause problems |
| 21:30:36 | evan | we need to fix those |
| 21:30:37 | evan | yes. |
| 21:31:31 | evan | at the same time, we should switch them to something that can report better |
| 21:31:33 | dbussink | evan: any alternative pattern we should use? since there are quite a few cases where we probably do want to check the return value and bail or throw some exception if stuff fails |
| 21:32:13 | evan | well, i've changed the asserts in the interpreter to raise a Rubinius::InternaError |
| 21:32:40 | evan | but alot of those are done in a context we shouldn't throw a C++ exception, nor a ruby exception |
| 21:32:51 | evan | we should probably add rubinius::assert |
| 21:32:58 | testerjoe | that 197 asserts is the same problem in 193, just not such a pretty description.. |
| 21:33:03 | evan | as function, that is just passed a boolean |
| 21:33:14 | evan | and calls rubinius::abort() if the boolean is false |
| 21:33:28 | evan | we loose the ability to show what the code was that asserted |
| 21:33:31 | evan | if we do that though |
| 21:34:15 | evan | lose, rather. |
| 21:36:52 | dbussink | true, but it's probably better than now |
| 21:40:04 | dbussink | evan: and looks i also have some reliable crashes again that i can bug you with next week ;) |
| 21:41:06 | brixen | dbussink: :) |
| 21:42:24 | evan | dbussink: yay! reliable crashes are good |
| 21:42:29 | evan | much much much better than unreliable ones. |
| 21:43:11 | dbussink | brixen: do you see any downsides with increasing this constant mentioned in http://github.com/evanphx/rubinius/issues#issue/142 ? |
| 21:43:21 | dbussink | evan: definitely yeah :) |
| 21:44:14 | brixen | dbussink: hm, probably not an issue increasing it |
| 21:44:34 | brixen | dbussink: I wonder what value the guy increased it to |
| 21:44:54 | dbussink | brixen: i'll try if doubling it allows soap4r to be built |
| 21:45:11 | brixen | dbussink: yeah, evan just made that # up, as the comment says :) |
| 21:45:37 | brixen | at least I'm pretty sure he did :) |
| 21:46:12 | brixen | I'm amazed that soap4r has more that 128 vars in the table |
| 21:46:28 | brixen | wait, it's soap4r nvm |
| 21:47:26 | dbussink | brixen: it's very good at creating lots of classes with lots of variables |
| 21:47:33 | brixen | I see |
| 21:52:14 | evan | yeah |
| 21:52:15 | evan | make it huge |
| 21:52:18 | evan | no prob. |
| 21:52:22 | evan | also, if you want |
| 21:52:24 | evan | fix that assert |
| 21:52:34 | evan | to cause an internal error exception |
| 21:52:39 | evan | of some kind |
| 21:52:45 | evan | so it's not a hard stop |
| 21:54:48 | dbussink | evan: any example i could look at for how to best throw that exception? |
| 22:02:09 | evan | since thats in a c-api extension |
| 22:02:11 | evan | you can use rb_raise |
| 22:02:21 | evan | the asserts within the VM are the tricky ones |
| 22:04:04 | dbussink | evan: ah, true yeah, that makes it a lot easier |
| 22:04:27 | evan | if you do that though |
| 22:04:32 | evan | you'll need to do a little auditing |
| 22:04:50 | evan | because that C extension allocates memory with malloc() and new |
| 22:04:55 | evan | so you'll need to clean up that memory |
| 22:05:39 | dbussink | evan: the var table itself you mean? |
| 22:05:52 | evan | well, it and the thing that created it, etc. |
| 22:11:08 | dbussink | evan: hmm, i'm looking at some other places where rb_compile_error but that doesn't seem to do any cleanup |
| 22:12:49 | evan | yeah, thats likely an existing problem |
| 22:17:25 | dbussink | but i'm going to bed, i'll see what i can fix tomorrow |
| 22:17:27 | dbussink | nite! |
| 22:17:33 | brixen | dbussink: nite! |
| 23:15:52 | rue | Just macro around the assert function to preserve the invocation |