Da
Show enters and exits. Hide enters and exits.
| 00:25:21 | evan | people are so weird. |
| 00:25:35 | evan | i guy won't go to rubini.us because it's .us domain and he hates the US |
| 00:25:37 | evan | er. |
| 00:25:40 | evan | s/i guy/a guy/ |
| 00:26:00 | kronos_vano | )))) |
| 00:28:33 | brixen | I'm sure there's a proxy out there to sanitize it |
| 00:28:39 | brixen | is he from Iran or something? |
| 00:30:00 | BrianRice-work | wow, there's a squatter on the .com/.org for the project name? |
| 00:30:07 | evan | yes |
| 00:30:08 | evan | sadly. |
| 00:30:17 | evan | i screwed up and didn't get them |
| 00:30:18 | BrianRice-work | the wild west is all fenced off now :/ |
| 00:30:33 | kronos_vano | rubinius.ru is free :D |
| 00:30:35 | evan | it's obviously a squatter since rubinius isn't a word or used term before this project |
| 00:31:02 | BrianRice-work | christ, I should have bought slate.org - it's now yellowpages |
| 00:31:10 | BrianRice-work | it was some guy from bellevue, WA |
| 00:33:21 | kronos_vano | I think we really don't need extra fast perfomance in MatchData#inspect, so this code is ok: http://gist.github.com/315236, right? |
| 00:33:50 | evan | on |
| 00:33:51 | evan | ON |
| 00:33:53 | evan | er. |
| 00:33:54 | evan | NO |
| 00:33:59 | evan | unless/else is never allowed |
| 00:34:00 | evan | ever. |
| 00:34:28 | kronos_vano | Please explain |
| 00:34:29 | evan | otherwise it's fine. |
| 00:34:33 | evan | you used |
| 00:34:37 | evan | unless captures.nil? |
| 00:34:38 | evan | .... |
| 00:34:39 | evan | else |
| 00:34:40 | evan | ... |
| 00:34:42 | evan | end |
| 00:34:44 | evan | never do that. |
| 00:34:46 | evan | always |
| 00:34:50 | evan | if captures.empty? |
| 00:34:51 | evan | ... |
| 00:34:52 | evan | else |
| 00:34:54 | evan | ... |
| 00:34:56 | evan | end |
| 00:34:59 | kronos_vano | hm |
| 00:35:09 | evan | you didn't do .nil?, you did .empty? |
| 00:35:13 | evan | but you get it |
| 00:44:06 | boyscout | Fix MatchData#inspect - 1024ca2 - Ivan Samsonov |
| 00:49:09 | boyscout | CI: rubinius: 1024ca2 successful: 3037 files, 11969 examples, 36268 expectations, 0 failures, 0 errors |
| 03:21:28 | manveru | dbussink: thanks, it builds again |
| 03:21:55 | manveru | now i'm down to the failing Process.setpriority spec |
| 03:25:16 | Defiler | [22:24] <hova> someone started snoring during the .net user group meeting |
| 03:25:21 | Defiler | ouch hehe |
| 03:25:30 | evan | HAHA |
| 03:26:29 | manveru | evan: my error is "Errno::EPERM: Operation not permitted" |
| 03:26:34 | manveru | at main.__script__ {} at spec/ruby/core/process/setpriority_spec.rb:76 |
| 03:26:56 | manveru | it doesn't exepct that exception, but it's the same exception as in mri |
| 03:27:32 | evan | you mean it fails in MRI? |
| 03:28:46 | manveru | sigma ~ % ruby -e 'Process.setpriority(Process::PRIO_USER, 0, Process.getpriority(Process::PRIO_USER, 0) - 1)' |
| 03:28:48 | manveru | -e:1:in `setpriority': Operation not permitted (Errno::EPERM) |
| 03:28:54 | manveru | on ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux] |
| 03:28:57 | evan | does the spec fail. |
| 03:29:00 | evan | is my question. |
| 03:29:01 | manveru | yes |
| 03:29:05 | manveru | the spec fails for rbx |
| 03:29:11 | evan | le sigh. |
| 03:29:15 | evan | does the spec fail on MRI. |
| 03:29:29 | manveru | how do i check that? |
| 03:29:34 | evan | run them. |
| 03:29:39 | evan | pass -tr to mspec |
| 03:29:52 | evan | bin/mspec ci -tr <file> |
| 03:30:42 | manveru | http://pastr.it/16664 |
| 03:30:44 | manveru | fail :) |
| 03:30:58 | manveru | ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux] |
| 03:31:18 | manveru | oh, it says that... |
| 03:31:50 | evan | thats passing. |
| 03:32:17 | manveru | oO |
| 03:32:30 | manveru | ok, so it fails randomly |
| 03:32:50 | evan | did you run the specs before you made your patch? |
| 03:32:54 | manveru | http://pastr.it/16665 |
| 03:33:03 | manveru | yeah, it failed back then too |
| 03:33:20 | evan | oh manveru |
| 03:33:22 | evan | you so crazy. |
| 03:33:25 | evan | then it's fine |
| 03:33:28 | evan | you should have reported it back then |
| 03:33:41 | manveru | one ticket at a time :) |
| 03:33:44 | evan | are you trying to fix it or find out if your patch screwed something up |
| 03:33:47 | evan | ok, hold on |
| 03:33:51 | evan | i don't even know what you're trying to do. |
| 03:33:54 | evan | i need some context. |
| 03:34:12 | manveru | i just ran rake, it ran the specs, this is the only failure |
| 03:34:26 | evan | and you want to fix it? |
| 03:34:32 | evan | more context |
| 03:34:34 | evan | please. |
| 03:35:01 | manveru | the spec fails, of course it has to be fixed |
| 03:35:30 | evan | manveru: i'm having a hard time understanding you |
| 03:35:38 | evan | please clearly indicate what you want and how I can help. |
| 03:37:09 | manveru | http://pastr.it/16666 |
| 03:37:16 | manveru | i'd like to apply that patch |
| 03:38:07 | evan | what platform are you on? |
| 03:38:46 | manveru | the manpage says the error may be raised: http://linux.die.net/man/2/setpriority |
| 03:38:51 | manveru | archlinux 64bit |
| 03:39:55 | evan | feels like that spec should be changed in a different way |
| 03:39:58 | evan | to force EACCESS to be raised. |
| 03:40:44 | Defiler | I dunno, that manpage has some hazy shit under 'Notes' about eperm |
| 03:40:54 | Defiler | Sounds like you can get it on all kind of systems for all kinds of reasons |
| 03:40:58 | evan | actually |
| 03:41:02 | evan | your patch is fine. |
| 03:41:15 | evan | setpriority is really platform dependent |
| 03:41:31 | evan | manveru: if you would |
| 03:41:32 | Defiler | Hell, the section about it uses the phrase 'seems to be followed by' |
| 03:41:35 | evan | put in a comment above your change |
| 03:41:40 | Defiler | and 'on some systems' |
| 03:41:44 | evan | that gives a little description why you added it |
| 03:41:48 | manveru | aight |
| 03:41:51 | evan | these specs will likely need to be rewritten at some point |
| 03:41:53 | Defiler | I think that is unix speak for 'ha ha eat it' |
| 03:41:58 | evan | given their form |
| 03:42:06 | evan | so adding more info for the next person would be good. |
| 03:42:49 | manveru | thing is, it fails only sometimes :) |
| 03:42:57 | evan | right |
| 03:43:03 | manveru | so i have no idea what causes it... |
| 03:43:06 | evan | it appears to do that "p - 1" to get a process taht doesn't exist |
| 03:43:09 | evan | which is just stupid. |
| 03:43:18 | evan | because there could easily be a process with that pid |
| 03:43:22 | evan | thats why it's random. |
| 03:43:25 | Defiler | and this man page says it depends on process priority |
| 03:43:27 | manveru | right |
| 03:43:30 | Defiler | which can't help |
| 03:43:40 | evan | the spec'ing philosophy of these specs is terrible |
| 03:44:01 | Defiler | no human would stack books this way |
| 03:44:06 | evan | there are a dozen strange actions with no description why they're done. |
| 03:44:13 | evan | hah |
| 03:45:19 | manveru | hrm |
| 03:46:14 | manveru | i really don't think a comment like "this spec might depend on the priority of some random other process, but sometimes it doesn't, and the errors may vary per execution" helps |
| 03:46:47 | manveru | will think about a better fix later |
| 03:47:21 | evan | ok |
| 03:49:11 | evan | Excellent! |
| 03:49:16 | evan | i've earned myself dinner! |
| 03:49:27 | evan | pats himself on the back |
| 07:44:51 | dbussink | evan: still there? |
| 08:38:19 | dbussink | rue|Work: morning :) |
| 08:38:30 | dbussink | rue|Work: i can always try :) |
| 08:59:17 | dbussink | rue|Work: where's work for you these days? |
| 09:37:09 | dbussink | rue|Work: that's quite a commute :P |
| 09:44:13 | dbussink | rue|Work: man, how can you live with those working conditions |
| 09:54:36 | dbussink | is feeling old skool with doing a physical commute daily |
| 10:27:43 | dbussink | yeah, i don't mind it either, works better for me :0 |
| 10:27:45 | dbussink | :) |
| 17:56:25 | brixen | early morning errand in ass rain pdx for the mutha effen el |
| 17:56:32 | brixen | what did I miss? are we there yet? |
| 17:56:47 | evan | :D |
| 17:57:20 | brixen | I will never know why it took 20 min at 1 mph to cross the ross island bridge |
| 17:57:22 | brixen | alas |
| 17:59:32 | evan | ug. |
| 18:02:10 | BrianRice-work | I had a decent commute... except for crossing train track rails |
| 18:04:47 | evan | ok, $~ is rewritten and passing |
| 18:04:48 | brixen | BrianRice-work: such fun in the run, huh |
| 18:05:03 | brixen | evan: [:zweet] |
| 18:05:07 | evan | and for the record |
| 18:05:16 | evan | $~ and friends fucking suck |
| 18:05:24 | brixen | BrianRice-work: s/run/rain/ heh |
| 18:05:27 | evan | seriously terrible. |
| 18:05:41 | evan | being scoped to "the calling ruby method" is so fucked. |
| 18:05:52 | evan | because it makes implementing things IN RUBY so much harder. |
| 18:06:18 | brixen | we could blame them on a long night of sake drinking but we know 1. matz doesn't and 2. larry wall is to blame |
| 18:06:35 | BrianRice-work | matz doesn't drink? |
| 18:06:41 | brixen | nah |
| 18:06:46 | evan | he's mormon. |
| 18:06:52 | BrianRice-work | :O |
| 18:07:06 | brixen | BrianRice-work: pretty interesting to ponder huh? :) |
| 18:07:34 | BrianRice-work | I, uh, am suddenly less trusting of ruby leadership |
| 18:07:41 | brixen | heh |
| 18:07:43 | brixen | now now |
| 18:08:06 | brixen | interesting to me is the clash of japanese aesthetics with a (imo wacky) western philosophy |
| 18:08:17 | BrianRice-work | oh, sure, that is interesting |
| 18:08:20 | brixen | but I still love ruby, mostly |
| 18:08:54 | BrianRice-work | let's just say I have a background in wacky western religiosity and now don't trust anyone who doesn't drink and especially not a mormon |
| 18:09:16 | brixen | heh, my folks were JWs, so yeah... |
| 18:09:44 | BrianRice-work | anyway, $~ comments are spot-on |
| 18:13:12 | BrianRice-work | does rubinius provide something like "thisContext" and "thisContext sender" to see/crawl up the send-chain? (excuse the smalltalk idioms) |
| 18:14:04 | brixen | we have Rubinius::VariableScope.of_sender |
| 18:15:21 | brixen | and Rubinius::CompiledMethod.of_sender |
| 18:17:22 | brixen | you can get the StaticScope of the CM in the .scope slot |
| 18:17:58 | evan | BrianRice-work: yes is the main answer. |
| 18:18:21 | BrianRice-work | k |
| 18:20:18 | evan | BrianRice-work: do you use those for anything other than a debugger? |
| 18:21:13 | BrianRice-work | evan: generally, no, it's considered in poor taste. squeak continuations use it, of course, and similar system-level abstractions |
| 18:21:35 | evan | right, i'd consider it in poor taste too. |
| 18:21:40 | evan | it's quite brittle. |
| 18:26:50 | evan | BrianRice-work: ended up implementing invoke_primitive yesterday |
| 18:26:53 | evan | BrianRice-work: working great! |
| 18:27:27 | BrianRice-work | cool |
| 18:35:30 | evan | i'll probably add "Rubinius.invoke_primitive :name, args" |
| 18:35:35 | evan | as a compiler "macro" |
| 18:35:50 | evan | so that we can invoke primitives by name directly in the kernel |
| 18:36:13 | evan | this handles a wart we've had, which is having to wrap a primitive in a method that is never normally called |
| 18:38:28 | brixen | cool |
| 18:38:33 | BrianRice-work | hm |
| 18:39:01 | BrianRice-work | yeah, sounds reasonable to me. I take it your compiler has some rules for code that it transforms |
| 18:40:08 | evan | yeah |
| 18:40:14 | evan | we have some transform plugins |
| 18:40:27 | evan | that can match against part of the AST and run some code |
| 18:40:56 | BrianRice-work | ok |
| 18:41:22 | dbussink | evan: i've made some changes to openssl to silence the warnings, would you care reviewing it? |
| 18:41:31 | evan | i'd love to! |
| 18:41:33 | evan | hook me up. |
| 18:42:21 | dbussink | evan: https://gist.github.com/75a1d2c00985b4eef2ec |
| 18:43:48 | dbussink | evan: it missed a small thing, updated the gist |
| 18:45:02 | evan | um |
| 18:45:12 | evan | i'm highly against moving st_retval into ruby.h |
| 18:45:35 | dbussink | evan: well, it's used already in syck and now in openssl too |
| 18:45:49 | evan | regardless |
| 18:45:50 | evan | we're not doing that. |
| 18:46:01 | dbussink | and there were some hardcoded 0's and 1's in there |
| 18:46:07 | dbussink | what's the alternative? |
| 18:46:14 | evan | thats better than bleeding st stuff into ruby.h |
| 18:46:23 | dbussink | cause i'd like these changes to be compatible with mri too |
| 18:46:45 | evan | you deleted st_retval from syck's private st.h |
| 18:46:49 | evan | thats illegal. |
| 18:46:54 | evan | thats not MRI compat. |
| 18:47:03 | evan | lets ignore all st.h related things |
| 18:47:04 | evan | revert those |
| 18:47:14 | evan | we need a more holistic approach to st |
| 18:47:43 | evan | hah |
| 18:47:50 | evan | if he commits it, he'll be dealing |
| 18:47:53 | evan | thats not allowed. |
| 18:48:18 | boyscout | Reimplement $~, known as last_match. - 458a558 - Evan Phoenix |
| 18:48:18 | boyscout | Add more spec cases for when $~ is set - 24eb366 - Evan Phoenix |
| 18:48:31 | evan | rue|Work: oh yes. |
| 18:48:41 | dbussink | evan: well, st.h was added specifically for syck |
| 18:48:48 | evan | mm no |
| 18:48:48 | dbussink | evan: should we do that for openssl too? |
| 18:48:52 | evan | syck had it's own st |
| 18:48:54 | evan | as I recall. |
| 18:48:57 | evan | in MRI. |
| 18:48:57 | dbussink | nope |
| 18:49:09 | dbussink | i'm not seeing it in there at least |
| 18:49:09 | evan | well, i'm still not going to allow you to put st_retval in ruby.h |
| 18:49:23 | evan | for right now |
| 18:49:27 | evan | ignore it |
| 18:49:28 | dbussink | well, could put it in a st.h in lib/ext/openssl/ |
| 18:49:32 | evan | and lets come up with a better plan |
| 18:49:33 | evan | no no no |
| 18:49:39 | dbussink | well, that was done with syck |
| 18:49:41 | evan | lets do this cleanup without any st related things. |
| 18:49:51 | evan | then deal with st seperatly. |
| 18:49:55 | evan | please. |
| 18:50:09 | dbussink | well, then i'd have to make a return 0 or something like from it |
| 18:50:16 | evan | thats fine |
| 18:50:24 | evan | go back to the hack |
| 18:53:23 | dbussink | evan: but isn't offering rb_hash_foreach and not ST_* stuff a bit half of a solution? |
| 18:53:38 | evan | nope. |
| 18:53:47 | evan | rb_hash_foreach is provided by MRI's ruby.h |
| 18:53:54 | evan | all the ST stuff in MRI is in st.h |
| 18:53:59 | evan | i screwed up our st.h and st.c |
| 18:54:05 | evan | we need to fix it for reals |
| 18:54:21 | evan | that's why i'm not letting you move that st stuff around |
| 18:54:40 | dbussink | evan: well the behavior of rb_hash_foreach partly depends on the return value which is one of the ST_* values |
| 18:54:50 | evan | oh well. |
| 18:54:56 | evan | that actually doesn't matter. |
| 18:55:59 | evan | i don't see it depending on it |
| 18:56:06 | dbussink | evan: i've updated the gist |
| 18:56:55 | evan | ok, looks good. |
| 18:57:03 | evan | i'm not being gruff |
| 18:57:13 | evan | i just want to get st.* fixed first |
| 18:58:04 | dbussink | well, if it's wrong now i understand that yeah |
| 18:58:17 | dbussink | i'll commit these changes then |
| 18:58:41 | boyscout | CI: rubinius: 24eb366 successful: 3037 files, 11971 examples, 36275 expectations, 0 failures, 0 errors |
| 18:58:46 | evan | k |
| 18:58:48 | evan | thanks |
| 19:09:23 | evan | fuuuuck. |
| 19:09:36 | evan | rack-mount has a Hash subclass |
| 19:09:44 | evan | and uses ivars that collide with Hash's ivars. |
| 19:09:49 | evan | fail. |
| 19:09:53 | brixen | wow |
| 19:09:59 | brixen | what are the ivars? |
| 19:10:17 | evan | @count, @max, @min, @mean are the ones right here |
| 19:10:21 | evan | @max is the collision right now |
| 19:10:30 | brixen | argh |
| 19:11:10 | evan | i'm changing @max to @max_entries |
| 19:11:16 | brixen | cool |
| 19:12:36 | rue | Sweet |
| 19:12:41 | binary42 | evan: Maybe rubinius classes should use a _ prefix on ivars? |
| 19:12:51 | evan | so ugly though |
| 19:12:53 | evan | SO UGLY. |
| 19:13:01 | evan | and we don't do it on all of them |
| 19:13:08 | evan | because the VM translates them to slots in same cases |
| 19:13:11 | evan | like in Array |
| 19:13:27 | binary42 | evan: Yeah... just thinking it could cause other people some major headaches. |
| 19:13:44 | evan | subclassing these happens little enough that i'm willing to wait and see. |
| 19:14:17 | brixen | and the more ppl run their code on rbx, the more they will fix this stuff in their own code |
| 19:14:50 | brixen | we should not make kernel code ugly because Ruby programmers have lived in a world of isolated C code under their ruby code for so long |
| 19:14:56 | brixen | it's why we can't have nice things |
| 19:15:12 | evan | yes, i'm willing to push back. |
| 19:15:17 | brixen | indeed |
| 19:15:20 | binary42 | brixen: Fair enough but I can think of dozens of lame rails ivar names that killed me. |
| 19:15:32 | brixen | binary42: I can imagine |
| 19:18:14 | boyscout | Fix a whole bunch of warnings in the OpenSSL extension - d53a96d - Dirkjan Bussink |
| 19:21:27 | brixen | heh interesting that english has such a rich vocab for "many": bunches, lots and lots, gobs, oodles, shitton, bucketloads... |
| 19:24:30 | boyscout | CI: rubinius: d53a96d successful: 3037 files, 11971 examples, 36275 expectations, 0 failures, 0 errors |
| 20:19:18 | kronos_vano | evan, Array#hash is pretty strange. I think we should rewrite it. |
| 20:19:27 | evan | yeah, it's weird |
| 20:19:29 | evan | go for it. |
| 20:37:35 | mxey | I am not sure if this issue qualifies for a ticket, so I am asking here first. I just compiled a fresh Git clone of Rubinius. When I start rbx, it spawns two threads, one of which loops on the nanosleep syscall all the time. This is the strace -f output: http://gist.github.com/raw/316124/553ef6174f182424cfbf8237a904916c2e5067e8/gistfile1 |
| 20:52:10 | evan | mxey: it should be doing that. |
| 20:52:14 | evan | that not a bug. |
| 20:53:00 | mxey | evan: It should loop instead of sleep? that does sounds wasteful to me. |
| 20:53:17 | evan | it's a timer thread |
| 20:53:21 | evan | it's doing what it should |
| 20:53:50 | kronos_vano | I have only one idea: http://gist.github.com/316118 . Any suggestions? |
| 20:54:06 | mxey | evan: I thought nowadays people where trying to reduce CPU wakeups to increase battery life. |
| 20:55:43 | mxey | rbx shows a significant number of wakeups in my powertop. |
| 20:56:40 | evan | mxey: we haven't done anything related to wakeups |
| 20:57:05 | mxey | Are you planning to at some point? |
| 20:57:11 | evan | we need the timer thread |
| 20:57:15 | evan | so not off hand, no. |
| 20:57:19 | evan | i'm open to suggestions |
| 20:57:31 | mxey | i see. |
| 21:00:07 | evan | mxey: MRI uses a timer thread as well |
| 21:00:29 | mxey | i know. I thought I might have more luck with Rubinius, it all seemed more reasonable ;) |
| 21:00:38 | mxey | they ignored my issue altogether. |
| 21:00:55 | evan | well, we need the timer to do GIL release atm |
| 21:01:08 | evan | if you can help out with that, i'm happy to do it another way |
| 21:01:12 | mxey | Do you need GIL release if there is only one thread? |
| 21:01:13 | evan | timer wise |
| 21:01:21 | evan | no, I suppose not |
| 21:01:25 | evan | we could lazily start the timer thread |
| 21:02:10 | mxey | that sounds good. |
| 21:04:17 | mxey | evan: But no, I cannot help you. I have no idea at all about Rubinius internals or interpreter development in general. |
| 21:11:15 | evan | mxey: go ahead and open a ticket |
| 21:11:22 | evan | and reference this conversation |
| 21:11:28 | evan | i might be able to do that later today |
| 21:11:31 | evan | it should be an easy fix |
| 21:11:37 | mxey | evan: Lazy starting the thread? |
| 21:11:44 | evan | yah |
| 21:11:48 | evan | lazy starting of the timer thread |
| 21:12:12 | mxey | thanks :) |
| 21:12:15 | evan | np. |
| 21:14:23 | evan | kronos_vano: why the mask? |
| 21:14:29 | evan | you haven't really changed it |
| 21:16:14 | mxey | evan: Any label I should add? |
| 21:16:34 | kronos_vano | if array.size will be equal to Fixnum::MAX after =<< 1 we'll get Bignum |
| 21:16:55 | mxey | hm, i cannot apply them anyway. |
| 21:17:19 | kronos_vano | mxey, only commiters can apply its |
| 21:17:35 | kronos_vano | if you about labels in issues) |
| 21:17:50 | mxey | i see. |
| 21:19:03 | kronos_vano | MRI use h = (h << 1) | (h<0 ? 1 : 0); but << for ruby and C is diffrent |
| 21:19:32 | kronos_vano | h is hash_value here |
| 21:54:13 | evan | kronos_vano: ok |
| 21:54:19 | evan | why the << in there at all? |
| 21:55:15 | Defiler | Huh, I didn't know about these special names/commands you could pass to 'trap' |
| 21:55:30 | Defiler | e.g. 'IGNORE' and 'DEFAULT' |
| 21:55:36 | evan | yeah |
| 21:55:39 | evan | weird huh. |
| 21:55:47 | evan | there is a magical "EXIT" one too |
| 21:55:55 | evan | thats basically a very old form of at_exit |
| 21:56:01 | Defiler | Oh, so I see |
| 21:56:11 | Defiler | I misread that part and assumed it was still talking about SIGEXIT |
| 21:56:29 | Defiler | or signal 0 at least heh |
| 22:01:45 | kronos_vano | evan, Because hash function for array should affects not only element, but also element's index. I try to reproduce MRI but I can't do "h = (h << 1) | (h<0 ? 1 : 0)" so I use & and <<. And, it is just idea :). but it pass all specs. |
| 22:02:19 | evan | kronos_vano: just also do ^= idx |
| 22:51:28 | evan | wow |
| 22:51:31 | evan | Defiler: you'll love this bug. |
| 22:51:53 | evan | let me know when you're around, i'll tell ya about it. |
| 22:53:27 | Defiler | hit me |
| 22:53:51 | evan | the code looks something like this |
| 22:54:12 | evan | begin; raise "whatever"; rescue Blah; puts "something"; end |
| 22:54:29 | Defiler | OK |
| 22:54:30 | evan | the raise isn't going to match Blah |
| 22:54:37 | evan | Blah isn't a RuntimeError |
| 22:54:51 | evan | so it should get passed up to the caller |
| 22:54:57 | evan | normally no problem |
| 22:54:58 | evan | BUT |
| 22:55:27 | evan | if Blah triggers an autoload |
| 22:55:30 | Defiler | Hhaahahah |
| 22:55:33 | Defiler | hahaa |
| 22:55:38 | evan | :D |
| 22:55:39 | Defiler | people autoload exception classes? |
| 22:55:47 | evan | rails does! |
| 22:55:49 | Defiler | That is.. fantastic |
| 22:56:04 | evan | and thusly, the autoload wipes out the current exception |
| 22:56:09 | Defiler | and let me guess.. those files that get loaded are themselves full of rescue clauses |
| 22:56:14 | evan | and the reraise asserts |
| 22:56:21 | evan | actually in this case |
| 22:56:28 | evan | the autoloaded file did a long return |
| 22:56:33 | evan | which wiped out the current exception |
| 22:56:40 | BrianRice-work | huh |
| 22:56:49 | Defiler | circus_of_pain.rb |
| 22:57:05 | evan | hilarious. |
| 22:57:06 | BrianRice-work | *thinks* slate's autoload doesn't do that |
| 22:57:35 | evan | thankfully |
| 22:57:42 | evan | we've dealt with this sort of thing so often |
| 22:57:45 | Defiler | Yeah |
| 22:57:45 | evan | it's easy to fix |
| 22:57:50 | evan | Defiler: oh, i might not have seen |
| 22:57:54 | Defiler | I would have thought the existing 'exception stack manager' code would have handled this case |
| 22:57:57 | evan | i while back I added stack locals |
| 22:58:02 | evan | a while back, rather. |
| 22:58:24 | evan | they're locals completely seperatly from ruby's concept of a local variable |
| 22:58:31 | Defiler | aah, perfect for this then |
| 22:58:34 | evan | they're extremely simple |
| 22:58:40 | evan | they're just stored at the top of the stack |
| 22:58:42 | Defiler | one of the stack locals could be an array of $!s |
| 22:58:46 | evan | er, the bottom |
| 22:59:20 | evan | # Save the current exception into a stack local |
| 22:59:20 | evan | g.push_exception |
| 22:59:21 | evan | current_exc = g.new_stack_local |
| 22:59:23 | evan | g.set_stack_local current_exc |
| 22:59:25 | evan | g.pop |
| 22:59:35 | evan | completely hidden from ruby's idea of a local |
| 22:59:51 | evan | it's a really nice feature |
| 22:59:53 | Defiler | sweetness |
| 23:00:04 | evan | because it solves the "the value I need is on the stack, but I don't know how many values away" |
| 23:00:06 | evan | problem |
| 23:00:20 | evan | stack locals let you address the stack directly |
| 23:00:33 | evan | it's basicaly like adding registers to the stack machine |
| 23:01:00 | Defiler | Yeah, could get tricky as hell if anything complex were stored there |
| 23:01:39 | evan | i added them because of things like break out of a begin |
| 23:01:51 | evan | where you need to reset the exception |
| 23:01:56 | evan | but the break could be like |
| 23:02:06 | Defiler | I guess another way to say it is that when you add an escape hatch in order to handle some tricky semantics.. |
| 23:02:15 | evan | break lots, of, things |
| 23:02:21 | Defiler | ..you probably shouldn't use that hatch to build more semantics, because then it is going to need another hatch |
| 23:02:32 | evan | ie, the stack distance to a saved exception isn't known at compile time |