Da
Show enters and exits. Hide enters and exits.
| 00:00:03 | evan | other name suggestions? |
| 00:00:04 | wayneeseguin | essentially it looks like he's saying use 'rake' not 'rake install' |
| 00:00:12 | wayneeseguin | ohai btw :) |
| 00:00:18 | evan | wayneeseguin: he's wrong. |
| 00:00:27 | wayneeseguin | ok that's what I thought, wanted to go to the source thought |
| 00:00:31 | evan | rake install does build. |
| 00:00:39 | wayneeseguin | ok |
| 00:00:40 | evan | and if you've used --prefix |
| 00:00:44 | evan | you MUST use rake install to build |
| 00:00:50 | wayneeseguin | yes rvm uses --prefix |
| 00:00:54 | wayneeseguin | ok |
| 00:01:16 | wayneeseguin | Thank you very much! |
| 00:01:20 | evan | so guys, any thoughts on better names for #fill_locations? |
| 00:01:21 | evan | wayneeseguin: np. |
| 00:03:30 | evan | i know you are a creative bunch |
| 00:03:31 | evan | come on! |
| 00:05:23 | evan | bueller |
| 00:05:43 | evan | beuller... |
| 00:05:56 | brixen | hmm |
| 00:06:42 | brixen | I have no more creative |
| 00:06:52 | evan | it's similar to java's fillInStackTrace |
| 00:07:05 | brixen | I'm just the pulp left from squishing between the cogs of the rubyspec machine |
| 00:07:09 | evan | I guess I could call it fill_backtrace |
| 00:07:25 | brixen | fill_ seems a bit weird to me |
| 00:07:33 | brixen | but that could be the fatigue talking |
| 00:07:34 | brixen | heh |
| 00:07:46 | brixen | fill_backtrace is pretty descriptive |
| 00:07:55 | evan | ok. |
| 00:09:13 | maharg | I find fill strange too, and I only got up 2.5 hours ago. I'd probably call it set_backtrace, but that's not exactly more creative |
| 00:10:02 | evan | it's fill because it doesn't take a backtrace |
| 00:10:11 | evan | the backtrace is infered from the current call stack |
| 00:10:13 | evan | ie |
| 00:10:16 | maharg | ah, that makes sense |
| 00:10:17 | evan | exc.fill_backtrace! |
| 00:10:39 | brixen | seems like get_ or create_ might be better |
| 00:10:56 | evan | get_ sounds like it returns something |
| 00:10:59 | maharg | yeah |
| 00:10:59 | evan | it doesn't |
| 00:11:01 | brixen | true |
| 00:11:03 | evan | it's not creating anything really either. |
| 00:11:18 | evan | capture_backtrace! maybe? |
| 00:11:34 | evan | crystalize_backtrace |
| 00:11:39 | evan | formalize_backtrace |
| 00:11:41 | brixen | capture_ maybe |
| 00:11:47 | evan | stonify_backtrace |
| 00:11:53 | evan | (as in to write in stone) |
| 00:12:08 | brixen | if it were exc.fill_backtrace(obj_to_fill) it might make more sense |
| 00:12:19 | evan | huh? |
| 00:12:23 | evan | whats obj_to_fill? |
| 00:12:28 | brixen | exactly |
| 00:12:38 | evan | so to you |
| 00:12:38 | brixen | seems a bit odd to me that fill_ is referring to exc. |
| 00:12:42 | evan | you think of fill as a verb |
| 00:12:47 | brixen | yes |
| 00:12:47 | evan | where the exception isn't the target |
| 00:12:51 | brixen | right |
| 00:12:53 | evan | ah |
| 00:13:01 | evan | i see it as a verb where the exception IS the target. |
| 00:13:15 | brixen | yeah, probably makes more sense that way |
| 00:13:51 | brixen | I don't think of exc =~ backtrace object |
| 00:13:56 | brixen | maybe that's the problem |
| 00:14:07 | brixen | exc.backtrace.fill |
| 00:14:16 | brixen | now that makes sense to me |
| 00:14:35 | evan | ew. no. |
| 00:14:38 | brixen | because exc has_a backtrace not is_a backtrace |
| 00:14:40 | evan | that can't be the API. |
| 00:14:45 | brixen | well, just sayin |
| 00:15:26 | brixen | ruby *should* have a Backtrace |
| 00:15:31 | brixen | class |
| 00:15:33 | evan | well, yes |
| 00:15:41 | evan | but thats neither here nor there for now. |
| 00:15:50 | brixen | that's fine |
| 00:16:08 | brixen | I was trying to tease out why fill_backtrace seemed to need an object to operate on |
| 00:16:11 | brixen | in my mind |
| 00:16:58 | evan | ok |
| 00:17:00 | evan | when you do |
| 00:17:02 | evan | Exception.new |
| 00:17:07 | evan | the exception has no backtrace. |
| 00:17:12 | evan | no location information really. |
| 00:17:31 | evan | when you raise it, then it gets knowledge of where it was raised from |
| 00:18:16 | brixen | yep |
| 00:18:35 | evan | thus the fill_backtrace! |
| 00:18:48 | brixen | I understand |
| 00:18:54 | evan | ok |
| 00:19:07 | brixen | exc.backtrace = Backtrace.new is what I'd expect to see there |
| 00:19:21 | brixen | otherwise, #fill_backtrace is probably AGAIG |
| 00:19:23 | maharg | yeah I was just thinking that |
| 00:19:54 | evan | but then the the knowledge about how to create a Backtrace is spread out. |
| 00:20:13 | evan | additionally, i want to put it behind a method that you can override when you inherit |
| 00:20:19 | evan | ie, i just did a test where I did |
| 00:20:25 | evan | class FastError < RuntimeError; |
| 00:20:31 | evan | def fill_backtrace!; end; |
| 00:20:32 | evan | end |
| 00:20:37 | evan | fe = FastError.new |
| 00:20:41 | evan | looping { raise fe } |
| 00:20:47 | brixen | sure |
| 00:20:49 | evan | it's about 2.5x faster than normal |
| 00:20:58 | evan | because it doesn't have to capture/fill the backtrace |
| 00:23:18 | evan | binary42: have you seen Rubinius::Fiber yet? |
| 00:23:36 | binary42 | evan: Aha! No but I will check it out tonight! |
| 00:23:48 | evan | binary42: it's still experimental |
| 00:23:58 | evan | but it doesn't do any stack copying. |
| 00:24:17 | binary42 | evan: Awesome. I will definitely let you know. |
| 00:24:29 | binary42 | is used to "experimental" software. |
| 00:25:01 | evan | geez, the place where MRI actually fills the exception with the backtrace is buried |
| 00:25:10 | evan | it's in the middle of rb_longjmp() |
| 00:25:58 | binary42 | needs to sign out. bbl. |
| 00:26:07 | evan | later. |
| 00:31:10 | evan | ok, i think i'm going with capture_backtrace! |
| 00:33:28 | brixen | cool |
| 00:33:49 | evan | ha |
| 00:33:53 | evan | ironically it's not actually faster |
| 00:33:57 | evan | i screwed up the benchmark |
| 00:33:58 | evan | oh well. |
| 00:56:19 | tarcieri | so uhh yeah your response from earlier is decidedly noncomittal, should I be pointing people who want to embed a Ruby interpreter into their C(++) programs to Rubinius like "omg comparatively easy to embed vs MRI"? |
| 00:56:52 | evan | yeah |
| 00:56:53 | evan | please do. |
| 00:57:02 | tarcieri | seems to recall easy embed being one of Rubinius's early talking points |
| 00:57:22 | maharg | I would suggest to have them look at vm/drivers/cli.cpp and if they can understand that, they're probably good |
| 00:57:29 | tarcieri | cool |
| 00:57:30 | evan | it's still easy. |
| 00:57:51 | evan | if they find it hard/broken |
| 00:57:54 | evan | i'm open to fixing it! |
| 00:58:05 | evan | we don't yet link as a shared library |
| 00:58:11 | evan | so that makes it a little harder to embed. |
| 00:58:34 | tarcieri | heh, yeah sounds like what this one guy is trying to do |
| 00:58:45 | tarcieri | I'm just kinda blown away by the other guy's comments |
| 00:58:59 | tarcieri | "I looked at embedding Lua in my C program... it sounded hard so I decided to try embedding RUBY!" |
| 00:59:08 | maharg | hah |
| 00:59:11 | evan | hahah |
| 01:00:15 | maharg | not to denigrate rubinius in any way (since it hasn't been the focus), but the smoothest embed api I know of for a scripting language is TCL's. |
| 01:00:29 | maharg | I understand lua's is pretty good, but the language seems so barren |
| 01:00:36 | evan | I recall TCLs being good too |
| 01:00:43 | evan | they put about 10 years of work into making it good. |
| 01:00:52 | evan | course, no one writes much TCL anymore. |
| 01:01:15 | maharg | I still <3 tcl a bit. Turtles all the way down, but with strings |
| 01:01:27 | brixen | can someone remind me why we have IO.open f.fileno again, please? |
| 01:01:34 | evan | brixen: no one knows. |
| 01:01:37 | evan | no seriously. |
| 01:01:39 | brixen | fuck |
| 01:01:41 | brixen | f u c k |
| 01:01:46 | evan | after I debugged it last time |
| 01:01:46 | brixen | seriously |
| 01:01:47 | evan | i asked |
| 01:01:58 | brixen | ok |
| 01:02:08 | evan | there is some explanation about needing it because Socket.socket_pair returns 2 fds |
| 01:02:11 | evan | as Fixnums |
| 01:02:17 | evan | and you need to be able to pass those to IO.open |
| 01:02:29 | evan | "why doesn't socket_pair return 2 IOs?" is the next question |
| 01:02:34 | evan | to which I have no answer. |
| 01:02:35 | brixen | indeed |
| 01:02:37 | brixen | ok |
| 01:03:03 | brixen | some creative soul decided to write specs that use IO.new f.lineno, where f is some File.new |
| 01:03:11 | brixen | but you cannot close both those |
| 01:03:21 | brixen | so, it's just insanity |
| 01:03:47 | evan | OH |
| 01:03:50 | evan | those are the ones |
| 01:03:58 | evan | THE ones that I hit the bug before. |
| 01:04:43 | evan | that started me down the rabbit hole of going "UM. FUCK. This feature destabilizes the entire IO system." |
| 01:04:50 | brixen | yeah |
| 01:04:55 | brixen | so crazy |
| 01:05:28 | evan | i wonder if we shouldn't go ahead and leak fds in that case |
| 01:05:33 | evan | ie, you use IO.open |
| 01:05:37 | evan | and DON'T use #close |
| 01:05:44 | evan | fuck you. |
| 01:05:48 | evan | leak fds. |
| 01:06:09 | evan | that at least fixes the worst part of the destabilization |
| 01:06:15 | brixen | yeah |
| 01:06:22 | maharg | being able to manipulate fd numbers is kind of necessary for some things. Like fastcgi, for example. Not sure if that part in particular is used, but you need to be able to create an IO object on, say, fd 3 or whatever so the parent process can communicate. |
| 01:06:40 | evan | yeah |
| 01:06:42 | evan | thats the issue |
| 01:06:49 | evan | people have been able to use IO.open(fd) |
| 01:06:50 | evan | so they have. |
| 01:06:59 | evan | and now there are some crazy bugs in the wild. |
| 01:07:42 | brixen | IO.new on stdout, stdin, stderr is one thing |
| 01:07:49 | brixen | and you'd never leak those fds anyway |
| 01:08:20 | evan | right |
| 01:08:32 | evan | we can solve this with a level of indirection |
| 01:08:34 | evan | if we have to. |
| 01:08:51 | evan | IO's never get to hold a true fd |
| 01:08:57 | evan | they hold a handle to an fd table |
| 01:09:15 | evan | and the table uses ref counts to know how many IO objects are using an fd |
| 01:09:44 | evan | that also solves the issue, because we won't close an fd that has users. |
| 01:09:55 | evan | hm, actually... |
| 01:09:55 | brixen | I wish IO could have the fd only, and File, Socket, etc could never |
| 01:10:02 | brixen | they could only reference an IO |
| 01:10:24 | brixen | and every IO.new(fd) dup'd |
| 01:10:31 | evan | yeah |
| 01:10:35 | evan | the dup is so key. |
| 01:10:46 | evan | but it leaks fds too |
| 01:10:53 | evan | beacuse of crap like Socket.pair |
| 01:10:59 | evan | which return bare fds |
| 01:11:05 | brixen | well, in the case it does, I think the arch is broken |
| 01:11:12 | brixen | I dunno |
| 01:11:16 | brixen | it's such a mess |
| 01:11:21 | evan | agreed. |
| 01:12:57 | brixen | I'm just not going ot permit '@file.close unless @file.closed? rescue Errno::EBADF' in the specs |
| 01:13:04 | evan | fine |
| 01:13:06 | evan | totally fine |
| 01:13:09 | evan | i was about to say that |
| 01:13:16 | evan | those are entirely undefined behaviors. |
| 01:13:22 | brixen | if File < IO and there's no sensible way to get an IO otherwise, then fuck it |
| 01:13:24 | evan | jruby doesn't have the problem |
| 01:13:27 | brixen | test IO with a File |
| 01:13:34 | evan | because they use an indirection table |
| 01:13:49 | evan | in fact |
| 01:14:00 | evan | i'd say that almost anything that tests for EBADF should be removed |
| 01:14:13 | evan | EBADF is, pretty much definition, an undefined behavior/bug |
| 01:14:29 | evan | by definition, rather. |
| 01:14:33 | brixen | yeah |
| 01:14:57 | evan | so, i thought of a way to "fix" this for rubinius. |
| 01:15:12 | evan | all IO objects have a finalizer |
| 01:15:16 | evan | to call close() |
| 01:15:24 | evan | which is where the actual destabilization happens. |
| 01:15:35 | evan | actually, no, thats not true. |
| 01:15:39 | evan | IO#close can destablize too. |
| 01:15:40 | evan | nm. |
| 01:16:55 | evan | rad |
| 01:17:00 | evan | ok, i've got backtrace fixed up ab it |
| 01:17:20 | evan | using Exception#set_backtrace() is much more sane about what data it changes |
| 01:17:29 | brixen | cool |
| 01:17:35 | evan | check it |
| 01:18:26 | evan | http://gist.github.com/298802 |
| 01:18:55 | brixen | sweet! |
| 01:19:07 | evan | loosing the REAL backtrace for the Exception is dumb |
| 01:19:11 | evan | i might as well just show both. |
| 01:19:46 | evan | so, to mitigate this:http://gist.github.com/298803 |
| 01:20:33 | evan | the MRI compatible backtrace (Array of Strings) has hidden within it an ivar that points back to the Backtrace object it was for |
| 01:20:39 | evan | and raise will try and extract that back out |
| 01:21:13 | evan | hm, I need to probably verify it's not been changed |
| 01:29:59 | evan | ok, there |
| 01:30:02 | evan | works pretty well now. |
| 01:31:42 | brixen | evan: opinion on specs such as this http://gist.github.com/298812 ? |
| 01:32:24 | evan | i'm against warning only specs |
| 01:32:33 | evan | because warns mean nothing to the functionality. |
| 01:32:34 | brixen | moi aussi |
| 01:32:38 | brixen | yep |
| 01:32:59 | brixen | that's been my position since the beginning |
| 01:34:12 | boyscout | Cleanup backtraces, add Exception#capture_backtrace! - 274fd73 - Evan Phoenix |
| 01:34:14 | evan | ok, i'm going to head up to office depot briefly. |
| 01:34:15 | evan | bbiab. |
| 01:34:19 | brixen | k |
| 01:38:33 | boyscout | CI: rubinius: 274fd73 successful: 3041 files, 11850 examples, 36139 expectations, 0 failures, 0 errors |
| 01:39:22 | jvoorhis | are any gui libs running on rbx yet? |
| 01:43:08 | brixen | jvoorhis: not that I know of |
| 01:43:16 | brixen | someone was asking about fxruby recently |
| 01:44:28 | jvoorhis | cool, just wondered what the climate was like |
| 01:45:20 | brixen | foggy |
| 01:45:28 | brixen | terrain undetermined :) |
| 01:46:49 | jvoorhis | needs more ffi |
| 01:48:00 | brixen | "but wait, there's more. compile now and you can use ffi to water your garden, write gui apps, send messags to your mother, all for only 19.99" |
| 01:49:19 | jvoorhis | ha |
| 01:49:58 | jvoorhis | or use ruby for realtime projects :) |
| 01:51:03 | brixen | that's a bonus, but it will cost you extra S&H |
| 01:53:24 | brixen | I don't think I can take one more IO spec today without vomiting all over myself |
| 01:53:28 | brixen | le sigh |