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 |
| 07:59:11 | dbussink | brixen: so did you get sick? ;) |
| 08:00:04 | brixen | yeah |
| 08:00:29 | brixen | I've ordered commercial quantity of barf bags |
| 08:01:20 | dbussink | brixen: you should send them to people writing weird specs as a token of appreciation |
| 08:01:28 | brixen | haha |
| 08:01:38 | brixen | oh man, would that I could |
| 08:02:01 | dbussink | i would go as far as writing something fucked up just to get one ;) |
| 08:02:09 | brixen | heh |
| 16:27:53 | rue | Hola |
| 16:34:56 | wayneeseguin | ohaithere rue |
| 16:37:07 | rue | I am in the boonie sticks |
| 16:38:49 | wayneeseguin | o.O |
| 16:49:56 | evan | hola. |
| 16:53:17 | antirez | evan: hola |
| 16:53:35 | antirez | evan: please can I query you? |
| 16:53:50 | evan | sure, wassup? |
| 16:54:01 | antirez | evan: just I need a few feedbacks :) |
| 16:54:08 | rue | ¡Hola! |
| 16:54:50 | rue | I think query == pm |
| 16:55:08 | evan | yep. |
| 18:02:46 | binary42 | Is there a way to get rbx to use an alternate path for storing rbc cache files? |
| 18:03:15 | evan | no. |
| 18:03:35 | binary42 | :-/ rbc's are starting to give me the .svn itch. |
| 18:03:36 | evan | it's been discussed |
| 18:03:38 | evan | but no. |
| 18:03:59 | evan | add *.rbc to your svn/git exclude |
| 18:04:15 | binary42 | Yeah. I do and then use git clean to remove them |
| 18:04:29 | binary42 | Just saying that I don't like how svn has all those .svn dirs. |
| 18:04:36 | binary42 | It's a noisy filesystem. |
| 18:04:45 | evan | i'm open to ideas for an alternative |
| 18:04:46 | binary42 | Anyway, I've also done some Fiber testing. |
| 18:04:59 | binary42 | But I haven't had a chance to try my rack app yet. |
| 18:05:09 | evan | Fiber working ok? |
| 18:05:16 | binary42 | They seem to. |
| 18:05:24 | binary42 | I need to try some more evil with them though. |
| 18:05:41 | evan | i don't have it in yet |
| 18:05:50 | evan | but i've figure out how to allow fibers to migrate between Threads too |
| 18:06:15 | binary42 | Ah. I don't use threads much so I haven't hit that yet. |
| 18:06:38 | binary42 | That should be a good feature since thread switching just for fiber resumption/yield is heavy. |
| 18:07:07 | binary42 | Anyway... lunch time over here. |
| 18:07:07 | evan | yeah |
| 18:07:25 | evan | enjoy. |
| 18:08:38 | wayneeseguin | evan / brixen FWIW I just pushed a new rvm that allows you to do stuff like this: 'rvm install 1.8.6 --patch ~/.tmp/ruby186gc.patch' |
| 18:08:46 | wayneeseguin | Not sure if you guys use that but :) |
| 18:08:54 | evan | cool |
| 18:12:31 | brixen | wayneeseguin: nice |
| 18:17:19 | brixen | wonders with futility why anyone would write 'ret = (Foo.method)\nret.should ...' |
| 18:43:53 | brixen | http://redmine.ruby-lang.org/issues/show/2728 looks interesting |
| 18:45:54 | evan | fun |
| 18:52:04 | Zoxc | "ruby segfaults (on windows XP), or bus errors (on OS X)." wtf is that |
| 18:54:20 | evan | hm |
| 18:54:29 | evan | where does String#dump differ from String#inspect |
| 18:56:06 | brixen | good question |
| 18:56:15 | Zoxc | it handles non-printing charaters and doesn't add quote marks? |
| 18:56:30 | evan | inspect does that too |
| 18:56:41 | evan | i'm looking through the C code, trying to figure it out |
| 18:57:00 | evan | they use slightly different ways of building the output |
| 18:57:05 | evan | but the transforms appear to be the same |
| 18:57:44 | brixen | http://gist.github.com/299524 |
| 18:57:57 | brixen | that's based on rubyspec |
| 18:58:06 | brixen | I'm looking at the specs trying to tell the difference |
| 18:58:28 | evan | k |
| 18:58:40 | evan | i'm breaking down and writing a primitive to speed up doing this |
| 18:58:54 | evan | being 100x slower than MRI for dump and inspect is unacceptable |
| 18:58:57 | rue | String#dump is a bottleneck somewhere? |
| 18:59:12 | evan | rue: no, but it's TOO slow. |
| 18:59:17 | evan | well, it might be a bottleneck. |
| 18:59:25 | evan | we need to have a minimum performance |
| 18:59:29 | evan | for things. |
| 19:05:38 | brixen | it looks like the representation of ascii is the same |
| 19:06:02 | evan | oh |
| 19:06:02 | evan | hm. |
| 19:06:04 | brixen | but dump returns subclass instances while inspect does not |
| 19:06:07 | evan | try a utf8 character. |
| 19:06:13 | brixen | and I'm still not sure about encodings |
| 19:06:14 | brixen | yeah |
| 19:06:27 | evan | i notice there is an if(ismbchar(..)) |
| 19:06:29 | evan | branch in inspect |
| 19:06:49 | evan | that I don't see in #dump |
| 19:10:09 | brixen | dump appears to represent utf-8 chars escaped but #inspect does not |
| 19:10:36 | brixen | ie "äöü".dump => "\"\\303\\244\\303\\266\\303\\274\"" |
| 19:10:54 | brixen | "äöü".inspect => "\"äöü\"" |
| 19:11:03 | evan | yep |
| 19:11:04 | evan | ok |
| 19:11:32 | brixen | but that's with $KCODE='utf-8' |
| 19:11:48 | brixen | if $KCODE == 'none' #inspect has the same output as #dump |
| 19:11:55 | evan | really? |
| 19:11:55 | brixen | this is in 1.8 of course |
| 19:11:56 | brixen | yes |
| 19:12:10 | evan | hm |
| 19:12:16 | evan | ismbchar must be tied into $KCODE |
| 19:12:19 | evan | crazily. |
| 19:12:43 | brixen | that would make sense |
| 19:12:59 | brixen | for some values of sense |
| 19:13:29 | evan | ha |
| 19:13:37 | evan | the kcode parser just uses the first letter |
| 19:13:37 | evan | so |
| 19:13:42 | brixen | yeah |
| 19:13:45 | evan | $KCODE="UNDEFINED" is utf-8 |
| 19:13:52 | brixen | yup |
| 19:13:59 | evan | $KCODE="AWESOME" => ascii |
| 19:13:59 | brixen | just found that out this week |
| 19:14:20 | evan | $KCODE="EEEEW" => EUC |
| 19:14:26 | brixen | heh |
| 19:14:27 | evan | i'm going to use those from now on |
| 19:14:36 | evan | instead of utf-8/ascii/euc |
| 19:16:08 | dbussink | evan: eeew, that so undefined awesome |
| 19:16:16 | evan | hah |
| 19:17:04 | evan | ok, it appears that $KCODE manipulates a pointer to a table called re_mctab |
| 19:17:25 | evan | and that table indicates, for 0..255, if the value is a multibyte character |
| 19:34:20 | evan | ok, since i'm in here |
| 19:34:25 | evan | i'm going to give us real kcode support. |
| 19:34:37 | imajes | nice! |
| 19:51:24 | dbussink | evan: btw, i have a freebsd 8 amd64 image if you're interested |
| 19:51:33 | dbussink | evan: from debugging some stuff on freebsd |
| 19:51:54 | evan | sure |
| 19:51:57 | evan | zip it up |
| 19:52:02 | evan | and put in on elle. |
| 19:52:57 | boyscout | Return false if download is erronuous, for example with a 404 - b87bcad - Dirkjan Bussink |
| 19:53:29 | dbussink | evan: are you ok with a return statement like return (Fiber*) Qnil; ? |
| 19:53:48 | evan | yeah |
| 19:53:51 | dbussink | evan: since there are some compile errors / warnings if fibers are disabled that are cause by returning Qnil from that method |
| 19:53:57 | evan | i haven't figured out a better way |
| 19:54:01 | evan | ah ok |
| 19:54:05 | evan | yeah, please fix them up. |
| 19:54:58 | evan | zoinks, it's really raining. |
| 19:56:07 | evan | oh shit. |
| 19:56:08 | evan | hail. |
| 19:57:18 | boyscout | CI: rubinius: b87bcad successful: 3041 files, 11850 examples, 36139 expectations, 0 failures, 0 errors |
| 19:59:48 | evan | holy shit |
| 19:59:53 | evan | this is some mudslide rain. |
| 20:01:36 | brixen | crazy, it's all nice and sunny here |
| 20:02:32 | dbussink | we had minor snow here, again... |
| 20:02:40 | evan | rain has stopped. |
| 20:02:46 | evan | rain on the coast is so crazy. |
| 20:02:54 | evan | on/off/on/off/on/off |
| 20:02:55 | dbussink | the whole country is getting annoyed by this snow :P |
| 20:15:17 | dbussink | rue|W: we are yeah |
| 20:15:30 | dbussink | rue|W: which is why we live here and not in finland :P |
| 20:16:21 | dbussink | evan: any reason you didn't put the ucontext detection in vm/detection.hpp? |
| 20:16:31 | evan | nope |
| 20:16:37 | evan | just wasn't ready for that yet. |
| 20:16:42 | evan | go right ahead |
| 20:18:45 | boyscout | Add explicit casts when Fiber isn't supported - e1a33f9 - Dirkjan Bussink |
| 20:18:45 | boyscout | FreeBSD doesn't support sticky bit - 4f8a239 - Dirkjan Bussink |
| 20:23:11 | boyscout | CI: rubinius: 4f8a239 successful: 3041 files, 11850 examples, 36139 expectations, 0 failures, 0 errors |
| 20:24:04 | dbussink | evan: do you know if adding ucontext to configure would work? or are there too many broken versions out there? |
| 20:24:46 | brixen | now I know why bureaucracies require forms filled out in triplicate and signed, stamped, oiled, posted, filed, archived, etc before allowing anything |
| 20:24:55 | evan | dbussink: it might work |
| 20:24:56 | evan | sure. |
| 20:25:09 | evan | you can test and detect a broken version in configure actually |
| 20:31:35 | dbussink | evan: hmm, only annoyance is that it needs _XOPEN_SOURCE |
| 20:31:47 | dbussink | evan: isn't this then something they will completely remove since it's deprecated? |
| 20:32:13 | evan | who the fuck nows. |
| 20:32:14 | evan | knows. |
| 20:32:17 | evan | :) |
| 20:32:31 | evan | makecontext is a NEW unix api |
| 20:32:37 | evan | so i doubt they'll be removing it anytime soon |
| 20:32:50 | evan | thats why i've opted to keep fiber experimental |
| 20:33:06 | evan | so it's easy to say it doesn't work on certain platforms |
| 20:33:38 | evan | what we need to do is integrate the sigaltstack() alternative code to makecontext |
| 20:50:47 | ezmobius | evan you implemented fiber on rbx? |
| 20:51:10 | ezmobius | i dared him last week |
| 20:51:20 | ezmobius | didnt know he actually did it though ;) |
| 20:51:49 | dbussink | ezmobius: should dare him more ;) |
| 20:52:11 | ezmobius | so its true? rbx has fibers now? |
| 20:52:22 | ezmobius | dances a jig |
| 21:24:42 | evan | ezmobius: yeah, I did it on your dare! |
| 21:24:47 | ezmobius | sweet |
| 21:25:07 | ezmobius | how hard was it? |
| 21:25:17 | evan | to use or to implement? |
| 21:25:22 | ezmobius | impl |
| 21:25:28 | evan | it's not support everywhere |
| 21:25:34 | evan | only places where makecontext(2) works |
| 21:25:39 | evan | so easy. |
| 21:25:42 | evan | relatively. |
| 21:25:53 | ezmobius | so osx and linux work? |
| 21:25:56 | evan | yeah |
| 21:26:04 | ezmobius | thats all i care about then ;) |
| 21:30:43 | dbussink | ezmobius: even got it working on freebsd :) |
| 21:38:55 | wyhaines | w00T! |
| 21:39:25 | wayneeseguin | wyhaines: w00t! |
| 22:30:19 | kronos_vano | What do you think about this: http://gist.github.com/299757 (I'll write rubyspecs later). rubinius outputs false for all, but should true. This patch fix it: http://gist.github.com/299766. |
| 22:30:28 | kronos_vano | Hi all :) |
| 22:31:40 | evan | thats ok, except that our changes to sends.rb are styled wrong |
| 22:32:14 | evan | your changes, rather. |
| 22:32:49 | kronos_vano | hm |
| 22:33:01 | evan | they appear misstyled at least |
| 22:33:12 | evan | that might just be gist |
| 22:33:23 | evan | yeah |
| 22:33:23 | evan | nm |
| 22:33:25 | evan | it's just gist. |
| 22:34:21 | kronos_vano | :) ok |
| 22:34:31 | evan | i worry a little about your change |
| 22:35:34 | evan | i guess if it passes the specs |
| 22:35:36 | evan | should be fine. |
| 22:36:09 | kronos_vano | it pass all specs from rubinius and 1.8.7 |
| 22:36:13 | evan | ok |
| 22:36:21 | evan | go ahead and commit them. |
| 22:38:17 | brixen | kronos_vano: (I'll write rubyspec later) <- unacceptable |
| 22:38:25 | brixen | commits need to have specs or remove failing tags |
| 22:38:31 | brixen | we need to enforce that |
| 22:38:33 | brixen | evan: ^^^ |
| 22:38:37 | kronos_vano | em |
| 22:38:52 | evan | yes |
| 22:38:55 | evan | my mistake |
| 22:39:01 | evan | i got side tracked and thought I saw a spec in there |
| 22:39:07 | kronos_vano | Evan said to me that 1 commit can not have both specs and code change |
| 22:39:14 | evan | yes |
| 22:39:14 | brixen | that's right |
| 22:39:21 | evan | but you should commit the spec change first |
| 22:39:22 | evan | then the code. |
| 22:39:27 | kronos_vano | ok |
| 22:39:28 | evan | not the code and then a week later the spec. |
| 22:39:28 | brixen | I mean that changes need to have associated specs or remove failing tags |
| 22:39:29 | kronos_vano | np |
| 22:40:04 | brixen | or indicate that a change is a refactoring |
| 22:43:00 | evan | rad |
| 22:43:06 | evan | i've got a nice, efficient String#escape method |
| 22:43:13 | evan | that takes a Tuple of Strings |
| 22:43:27 | evan | and transforms the input based on the table |
| 22:43:40 | brixen | cool |
| 22:43:48 | evan | I thought we had something to do this with tr |
| 22:43:51 | evan | because i didn't see it |
| 22:44:38 | brixen | hm, I don't think so |
| 22:44:41 | brixen | other than #tr itself |
| 22:44:57 | evan | we've got these tr_expand methods |
| 22:45:06 | evan | they don't appear to use a table though. |
| 23:10:31 | boyscout | Speed up String#inspect, implement KCode support - d25e54b - Evan Phoenix |
| 23:11:02 | slava | evan: what's your time frame for a final 1.0 release? |
| 23:11:12 | evan | spring |
| 23:11:28 | slava | cool |
| 23:11:54 | slava | looks like you'll beat me to it :) i'm gearing up for a 1.0 alpha 1 in a couple of days |
| 23:12:15 | evan | congrats! |
| 23:12:22 | evan | hows .nz? |
| 23:12:31 | evan | you working yet? |
| 23:12:41 | slava | just hacking |
| 23:13:47 | evan | how long you going to be able to do that? |
| 23:14:12 | slava | until factor 1.0 is out :) |
| 23:19:28 | boyscout | CI: rubinius: d25e54b successful: 3041 files, 11850 examples, 36139 expectations, 0 failures, 0 errors |
| 23:23:04 | ezmobius | so how do i use fibers in rbx head? require 'fiber' blows up. cluestick please? |
| 23:24:15 | brixen | http://gist.github.com/293128 |
| 23:24:33 | ezmobius | ahh cool |
| 23:24:34 | ezmobius | thx |
| 23:24:37 | brixen | ezmobius: np |
| 23:24:43 | brixen | it's still experimental |
| 23:24:47 | ezmobius | sure |
| 23:24:57 | brixen | I'm getting it so the rubyspecs can be run without being on 1.9 |
| 23:25:07 | brixen | then we'll start polishing the API |
| 23:26:10 | evan | ezmobius: Fiber = Rubinius::Fiber |
| 23:26:12 | evan | then use away. |
| 23:26:16 | evan | the API should be the same |
| 23:26:24 | brixen | should be |
| 23:26:25 | ezmobius | sweet fiberey goodness |
| 23:26:30 | brixen | soon we will know, muhahaha |
| 23:26:32 | evan | there are only like 3 methods |
| 23:26:43 | evan | and 2 of them just pass their arguments through |
| 23:27:05 | brixen | considers MSpec.enable_feature :regularity as an alias for .enable_feature :fiber |
| 23:27:12 | evan | hahaha |