Index

Show enters and exits. Hide enters and exits.

00:01:23BrianRice-workdylan/slate stick with linear ordering. slate modified this to allow per-type linearization of all supertypes at type definition time
00:02:17evanslava: so given to unrelated classes, how do you pick which one goes first?
00:02:19slavain factor there's no ordering among the superclasses of a class though
00:02:54slavaevan: if they're unrelated, it uses a tie breaker (class name and meta class type)
00:03:24evanso is the bug because sometimes the ordering is different based on who created the generic word?
00:06:29evanhm, we should be sure that rubinius works with sinatra 1.0
00:07:01brixenyah
00:09:46binary42would test it on the sinatra app they are working on right now but the code is written for 1.9.
00:10:19evanthats too bad.
00:10:27evanwhat 1.9 stuff do you use?
00:11:00ohdouhrVERSION irc.gnaa.fr #gnaa GNAA > j00
00:11:00ohdouhrVERSION irc.gnaa.fr #gnaa GNAA > j00
00:11:00ohdouhrVERSION irc.gnaa.fr #gnaa GNAA > j00
00:11:03binary42Fibers, new symbol hash key syntax, blocks with block args mostly.
00:11:10brixenrspec's handling of shared specs is odd
00:11:20evanoh, fibers
00:11:25evanhow are you using them?
00:11:29evani mean, whats the workflow
00:11:50binary42Well, the first place they are used is in FiberSpawn mode for Rainbows.
00:12:03slavahow does MRI do fibers?
00:12:24binary42Then I also use them for pausing execution if a rendering job is synchronous.
00:12:37binary42The rendering is done in another process and this is just a web api.
00:12:37slavaI'd switch stacks from assembly but they're too pussy so how do they do it from C?
00:12:47binary42But the whole rendering system is event based.
00:12:56binary42slava: ucontex in 1.9
00:13:05slavaah
00:13:15binary42in 1.8 people have shim libraries that sleep regular green threads which is done with memcpy.
00:13:28binary421.8 fibers == mostly useless.
00:13:30evanwell, not just ucontext
00:13:34evanucontext is not nearly enough
00:13:37evanit uses stack copying too.
00:13:41slavayou have to allocate a stack too
00:13:42binary42evan: Not at all.
00:13:50evanbinary42: yeah, bigtime.
00:13:53binary42slava: Yeah. It's a 4k stack.
00:13:56evanuseless you use makecontext()
00:14:00evanwhich it doesn't appear to
00:14:27binary42evan: It didn't but I talked to koichi about this and he has worked on it.
00:14:29evanit appears to still use setjmp/longjmp also, not ucontext
00:14:43binary42evan: Which head are you on?
00:14:53evanlooking at an older 1.9
00:14:56binary42:-)
00:14:58evanlet me look at trunk
00:15:32binary42Regardless, ucontext isn't perfect either but it's hell-a better than copying stacks.
00:15:50evanwell, again, it's not ucontext
00:15:57evanit's allocate seperate stacks
00:16:00evanyou can do that with setjmp.
00:16:09slavasetjmp saves and restores registers
00:16:15slavanot the stack contents
00:16:24evanle sigh.
00:16:25evani know.
00:16:38slavaoh, I was talking to binary42
00:16:44evani mean that you can use the heap stacks method with just setjmp
00:16:46binary42Right. The problem with setjmp is you can't guarantee w/o reverse engineering where in the struct each register is.
00:16:47evangnu pth does it.
00:17:04evanbinary42: on 1.9 trunk
00:17:07slavabinary42: ucontext layouts aren't portable either
00:17:08binary42So ucontext at least exposes the register layout.
00:17:11evankendall :: svn/ruby-trunk » ack makecontext
00:17:12evankendall :: svn/ruby-trunk »
00:17:16binary42slava: More portable.
00:17:28binary421.9 reverts to copying if it can't find a suitable ucontext implementation.
00:17:32evanso it's still stack copying.
00:18:10slavaI count 13 implementations of #define UAP_STACK_POINTER in factor's VM :)
00:18:17slavaone for each platform.
00:18:24evanno surprise!
00:19:55evanucontext doesn't expose the stack pointer in the same place
00:19:55slavaif that's considered portable, then I dunno what to say :)
00:19:55evaneach platform is seperate.
00:19:55binary42evan: Regardless... It doesn't matter how it does it. I switch once per block which is a rare case.
00:19:55evansure
00:19:55evanbut what is the workflow
00:19:55evani'm curious why you needed fibers
00:19:55evanimplementation aside.
00:20:42binary42Because how else am I going to pause sync code and do other things?
00:20:47binary42i.e. it's a rack stack.
00:20:59binary42Threads don't work here.
00:21:12binary42Or at least if you think stack copying is bad, threads are 2x worse here.
00:21:49ezmobiusevan any chance of rbx getting a decent Fiber impl?
00:21:56evanwhen is it unpaused?
00:22:11evanezmobius: we'll probably use heap stacks when we get around to it
00:22:15evanso yeah, no stack copying.
00:23:01ezmobiuscool
00:23:13ezmobiusi'd really love to be able to use fibers in 1.8
00:23:15binary42I just did over 1 million Fiber switches in 1.9 in 1.45 seconds.
00:23:21binary42So I'd say it is fast enough.
00:23:23ezmobiusthey make evented code libraries so much more palatable
00:23:42evanbinary42: why not use continuations in 1.8?
00:23:50rueEw
00:24:05binary42evan: slow. In that case you have to copy because of how continuations work.
00:24:11binary42I don't need delimited control.
00:24:49evani think you guys are daring me to implement Fibers.
00:25:02binary42evan: I can't verify how 1.9 is working right now but it is pretty obvious that Fiber in 1.9 is many many times faster than callcc.
00:25:04rueNaw, you would not dare anyway
00:25:12evanafter yesterdays OS#each_object support
00:25:19evani'm flush with confidence.
00:25:26slavaheh
00:25:36binary42evan: Well, I'd just vote for you to implement 1.9 and say hell with 1.8. I know the argument but that's my position is all.
00:25:54evanand I know it's wrong, yes.
00:25:55evan:)
00:27:03binary42Anyway... fast fibers are possible and portable to the practical platforms. Other platforms can be supported with simple fallback code that's already used.
00:27:27binary42So I see no reason to use them to enhance the organization of asynchronous systems that have to deal with synchronous parts.
00:27:29evanbinary42: when is the sync code you have "paused" unpaused?
00:27:46slavaevan: I dare you to implement fibers
00:27:56binary42evan: When other work is done, aka. a fiber resumes.
00:28:47binary42So lets say I have an asynchronous service that I need to present optionally as a synchronous one. So instead of a post-back I literally just render back.
00:28:53evanI suspect that you feel like Fibers are faster than Continuations probably because 1.9 is on the whole faster than 1.8
00:28:55binary42I could do this with a custom stack.
00:28:58evanbecause implementation wise
00:29:03evanthey appear to be the same.
00:29:07binary42But I'd like to use Rack + Sinatra as a lot of the code is pretty simple.
00:29:27binary42evan: No. On the same process Fibers are orders of magnitude faster.
00:29:33binary42In 1.9
00:29:45evanso you mean Fibers vs. Continuations in 1.9
00:29:46evan?
00:29:49binary42Yes.
00:29:53evanwell thats fucked.
00:29:57evanthey must have really fucked something up then.
00:30:03binary42How so?
00:30:08evanthey should be the same speed.
00:30:15binary42Continuations are slow in 1.9 like they are in 1.8.
00:30:19binary42Not at all.
00:30:22evanunless i'm missing something.
00:30:37binary42Delimited continuations require preservation of the original stack.
00:30:57slavawhy do oyu call them delimited continuations?
00:31:07slavadelimited continuations are something elsea nd ruby doesn't have this feature
00:31:19binary42slava: callcc is delimited in 1.8 and 1.9 AFACT.
00:31:23binary42AFAICT*
00:31:47binary42i.e. the stack frames are kept separate. Heap data will remain mutated of course.
00:31:56binary42Multiple calls work the same etc..
00:32:02binary42Don't see how they aren't delimited.
00:32:17slavaa delimited continuation is, essentially, a slice of the call stack
00:32:44slavahalf way between a function call and a full continuation
00:32:48slavayou can 'return' from one, for instance
00:33:07binary42slava: Maybe I have my terms wrong then but you can return multiple times from Ruby callcc.
00:33:19slavamulti-shot continuation
00:33:36binary42Okay. So it's a multi-shot then. :-)
00:34:05binary42slava: So delimited means the stack under the continuation is mobile?
00:34:21slavayes
00:34:41binary42I always thought it was the multi-return but this makes sense. Anyhow... the multi-return of callcc is the problem vs. fibers.
00:34:44evanhm
00:34:50evani'll have to go through the 1.9 code
00:35:04evanbecause it appears that fibers call all the same stack copying code that continuations do
00:35:24matthewdShould ENOMEM cause a SIGSEGV, or be reported? Just worked out my ulimit was the cause of the SIGSEGV I was hitting running full.mspec.
00:35:32binary42evan: It might be swapped out somehow but you might be right. I just remember 1.8 doing 1m thread copies per second.
00:35:40evanin fact, fiber_switch() even calls cont_restore_0(cont)
00:35:44binary42evan: It might be the stack size is minimized.
00:35:47evanbecause a Fiber contains a continuation
00:36:02binary42Since it knows only certain parts/sections need copied.
00:36:06binary42Rather than the whole stack.
00:36:12evanmatthewd: thats a tough one
00:36:20evanbecause running out of stack usually causes a SIGSEGV
00:36:32evanENOMEM is for when there is no more heap
00:36:44binary42And there is a fast switcher in progress on two fronts that I know of but people don't want to merge because of the portability constraints.
00:37:01evanor, er, do you have a ulimit on the heap size?
00:37:05evanmatthewd: ^^
00:37:10matthewdAh, okay. I'll admit I hadn't investigated... just assumed the SIGSEGV was the result of an unchecked malloc + use
00:37:10binary42evan: Yeah. You have to mark the last page with mmap'ed stacks IIRC.
00:37:17matthewdulimit -v 512000
00:37:31binary42Otherwise it's hard to detect overflows.
00:37:38evannot much I can do about that
00:37:40evanhonestly.
00:37:55binary42And when it does, stack growth is hard...
00:37:57evanthere is almost no good recovery from ENOMEM
00:37:59binary42Since you can't move.
00:38:06binary42You can chain but that's in the hot path.
00:38:26binary42evan: Mostly. I like how Erlang manages it.
00:40:10evanhow do they?
00:40:24evani wish that the Fiber/Continuation code in 1.9 wasn't so tangled
00:40:27matthewdevan: Fair enough... just thought I'd mention it, because it took me a bit to recognise the cause; normally JVM is the only thing that barfs on me for having it.
00:40:28evanso I could get to the bottom of this.
00:40:43evanmatthewd: what were you running?
00:40:54evani've been hunting memory leakes as of late
00:42:06evanmaybe there is another.
00:42:06evanthat i haven't exercised in valgrind
00:43:02binary42evan: Literally process killing but the supervisors can respawn. It has more to do with isolation.
00:43:59evani'm... not even sure what that means in the context of stacks
00:45:08matthewdevan: It was a clean checkout, ./configure, rake... specifically, dying during bin/mspec ci -B full, maybe about 40% through, judging by dots. But that doesn't sound like useful information... it's entirely reproducible... can I extract more interesting facts?
00:45:22binary42evan: Each process basically is a coroutine.
00:45:37evanmatthewd: hm,
00:45:38evanyeah
00:46:01binary42http://www.atdot.net/~ko1/activities/rubyconf2009_ko1_pub.pdf
00:46:14evanmatthewd: if you could, do 'rake vm:clean; rake build DEV=1; bin/mspec ci -B full --gdb'
00:46:42evanyou should be able some kind of backtrace
00:46:45evanwhich should help.
00:47:01evanalso, identify that it did use all 512M of heap
00:47:07evanso we're sure thats the case
00:47:59rue$ rake build:debug
00:48:38binary42evan: The 1.9.2 speed up was impressive as shown. Only the cost of 3 proc invocations now. Rubinius could do better with LLVM generating the context switch code.
00:48:52binary42(i.e. no signal proc mask setting)
00:49:38evanwhat is the cost of 3 proc invocations
00:49:39evan?
00:49:46binary42It's in the slides I linked.
00:50:11matthewdOkay, I'll do that. The slight backtrace I got before sounded like the GC mark phase... ImmixGC saw_object, and running with --gdb, it died in melbourne.
00:50:16binary42Past halfway if you want to skip scrolling.
00:50:54binary42Page 38.
00:51:13binary42(page 37 has the code run)
00:51:28binary42Micro bench of course but it's relevant to switch cost.
00:52:35evanhm
00:52:40evani guess that code hasn't landed in trunk yet.
00:52:41evani'm assuming.
00:54:01binary42evan: I've seen a boost in 1.9 trunk but it might just be copy region limitations since a fiber only needs to copy it's own stack since it can't return.
00:54:19evanwhere do you see that in cont.c?
00:54:21binary42Which is a big boost as long as the stack size starts small.
00:54:28binary42evan: I am guessing. I don't see it.
00:54:36binary42I just know from benchmarks.
00:54:39evanso it could be something completely different?
00:54:45binary42Possible.
00:55:09binary42I've bugged him multiple times about fibers and they've improved.
00:56:07matthewdevan: Running under gdb with DEV=1, I get "LLVM ERROR: Allocation failed when allocating new memory in the JIT" (and it exits) :P
00:56:20evanthats fun.
00:56:23matthewdChecking that's consistent...
00:56:24evannever seen that before.
00:56:36binary42evan: If you want Fiber emulation on 1.8 for comparison check out this: http://gist.github.com/4631
00:56:47binary42Of course the fast patch is here: http://timetobleed.com/fibers-implemented-for-ruby-1867/
00:57:15evangeez
00:57:19evanthat line 16 is a killer.
00:57:21matthewdI guess in theory, I should be able to affect where we run out of memory by tweaking the limit, if it helps
00:57:47evanbinary42: right, i've seen that patch
00:57:50evanthat uses heap stacks.
00:57:51binary42=D tmm1 will acknowledge it is slow but I'm not sure there is an easy way around it.
00:58:13binary42evan: Yeah. I've been talking to them a very long time about those patches.
00:58:13evanby killer I mean silly.
00:58:20evan[ *anything ]
00:58:22evanis pretty dumb.
00:58:32evananyway
00:58:33ezmobiusevan i dare you to implement fibers
00:58:43ezmobiusdouble dog dare
00:58:45evanwell lets see
00:58:52binary42evan: Not so much actually. there are simple edge cases handled by that.
00:58:56evani'll bet I could do a quick impl that was platform guarded.
00:59:05evanbinary42: did he mean
00:59:07matthewdevan: Not consistent. This time I got "[BUG] Uncaught C++ internal exception".
00:59:16evanArray(yield(...))
00:59:16evan?
00:59:16binary42evan: I'd be happy with a non-portable method for starters.
00:59:37evanmatthewd: weird.
00:59:43evancan you remove the ulimit and see if it works?
00:59:48binary42evan: Yeah. I guess in 1.8 it's similar.
00:59:50evani'd like to be sure we're seeing the effects of the ulimit.
01:00:04binary42But in 1.9 you collapse nil and such which is a good thing.
01:00:04evanpeople have just the strangest style imho.
01:00:28binary42Array() is pretty ugly you have to admit. ;-)
01:00:31evanit's pretty hard to read that line 16 and know what it does
01:00:43evanit's about 10x less ugly than [*anything]
01:00:47matthewdevan: Yeah, I did that... that's how I decided that was the cause. ulimit -v unlimited, and it runs through happily.
01:00:55evanmatthewd: hm. ok.
01:01:07evanwell, file a ticket with some details
01:01:10evanso we don't forget about it
01:01:12binary42Actually I don't find it confusing but maybe i'm just too used to it.
01:01:20evanbinary42: sounds like it.
01:01:22evan:)
01:01:51evanpeople need to stop being afraid of an extra conditional
01:01:57evanit can make code 10x easier to understand.
01:02:02evananyway
01:02:06evanstyle debates never end.
01:02:12evanback to real work.
01:03:50evanon the fibers talk
01:04:05binary42evan: Just checked... [* ... ] is quite a bit faster than Array()
01:04:06evani wonder if makecontext works on 10.6
01:04:15binary42I think it's the avoidance of dispatch in this case.
01:04:18evansorry
01:04:27binary42In 1.9 at least.
01:04:33evanbut thats a ridicilous argument.
01:04:39binary42evan: How so?
01:04:41evanfor this.
01:04:59evani have a hard time betting that that line is a bottleneck.
01:04:59binary42Context switch speed requiring an extra dispatch?
01:05:12evananyway, i'm not going to debate this.
01:05:15binary42:-)
01:05:18evanit will only ruin my friday
01:05:49binary42Cool... anyway... ping me if you want me to run or talk about Fibers. =D
01:06:15evanwe can discuss fibers
01:06:38evani was just pulling myself out of a silly style debate that I put myself in.
01:06:42binary42evan: Do you imagine a better workflow for me that won't use fibers?
01:06:53binary42Or coroutine-ish stuff.
01:07:01binary42I'm open to suggestions.
01:07:16evanwhy is your thing "sync"?
01:07:24evanwhy not break it up into 2 distinct phases
01:07:35evanthat are methods on an object that can be called at different times.
01:07:36binary42Because rack and sinatra and 90% of the rest of the web is sync (aka HTTP).
01:08:02evanthats beside the ponit
01:08:07evanbecause you want your thing to be NOT sync
01:08:07binary42I have a request come into Ruby and a response go out. Now I could dump Rack and stop using sinatra and write everything from scratch.
01:08:27evani still don't see when your sync thing is unpaused.
01:08:32evanperhaps thats the thing i'm missing.
01:08:45binary42Right. Being sync is lame when I am basically a web interface to a complex async rendering engine.
01:10:04binary42So I get the request. It posts a job. the job is pushed to a queue which is worked on by a pool of workers. They push it back asynchronously because I need to maximize concurrency here (lots of IO blocks during rendering). Now how to I connect that response to the result of the orig. request?
01:10:35binary42If I block (Fiber.yield) on the async push, then I can Fiber#resume when something comes back.
01:10:44evanso you "pause" the rack request
01:10:56binary42During that time the server can take more connections and keep work flowing w/o hanging everything behind one request.
01:10:58evanand it's "unpaused" in the other thread
01:11:00evanwhen the data is ready?
01:11:04binary42Yeah.
01:11:37evandoes rack/sinatra spin up a thread per request?
01:11:42evanor does it do everything in the one thread
01:11:51evani don't know them well enough to know
01:11:57binary42Of course this is wrapped up so it looks like regular IO code and will run fine in regular ruby but to make it scale nicer I put fibers under it.
01:12:12binary42The app server spins up a fiber, yes.
01:12:47binary42There are no threads though.
01:12:54binary42Well, just the main thread.
01:12:57evansinatra uses fibers internally?!
01:13:01binary42evan: Nope.
01:13:08yakischlobaevan: hes using his own modified thing
01:13:08evanthats what i mean
01:13:09binary42That's why this works.
01:13:15binary42It doesn't need to know about it.
01:13:18evanso you've got your own version of sinatra?
01:13:20binary42It's why fibers are nice.
01:13:36binary42Nope. I pause the entire fiber which is the rack exec stack wrapped up.
01:13:48evanok, so yakischloba is wrong.
01:13:48evanok
01:13:53binary42It's a coroutine so code in it doesn't really need to know because it's like any other stack.
01:13:56binary42Yeah.
01:14:03evanthe fiber usage is entirely in code that is yours
01:14:08evanthat sinatra calls
01:14:21binary42yakischloba: I had a rack extension at first but got frustrated by that so I use fibers now.
01:14:33evanso
01:14:38yakischlobaright. and your fibers are resumed by what? EM?
01:14:39binary42evan: Nah. Fiber calls sinatra but close.
01:14:43evanit seems to me that this wouldn't be concurrent at all
01:14:56evanbecause there is still just one fiber for the current rack request
01:15:02evanyou can't get anything request into the system
01:15:05binary42App server has a scheduler that knows about blocking IO. Not EM but it could be later.
01:15:13evanbecause you don't give control back to rack to go back and ask for another request
01:15:23evanwait
01:15:26evannow i'm so confused.
01:15:41evanso you have your own webserver
01:15:41binary42evan: Yeah. It won't take anything new till it blocks or finishes.
01:15:42evanthat uses fibers.
01:15:53evanthat calls through rack to sinatra
01:15:59binary42Which means the internals are very async to keep progress smooth.
01:16:05evanso if it's not concurrent
01:16:12evanwhy not use condition variable
01:16:18binary42It's basic event design. i.e. you don't spin in a loop in javascript so I don't do that here either.
01:16:21evanto get data from the backtrace thread back to the webserver thread
01:16:59binary42evan: first of all threads perform much worse here.
01:17:08evanyou're already using a thread though
01:17:09binary42Esp when I have more than 100 connections.
01:17:11evanyou just said
01:17:14binary42Fibers do fine here.
01:17:17yakischlobastays out of it
01:17:21evani don't mean a thread per request
01:17:25evani still don't get the architecture
01:17:30evani don't see what fibers are affording you
01:17:41evanbecause it feels like every request is still sync
01:17:47binary42Second of all, a condition var doesn't help since I'd have to modify the app server which gives me fibers. I did not write it.
01:17:55evanand one must complete fully before the next one can come in
01:18:02binary42So it basically turns the system into spaghetti.
01:18:20binary42Here I have no dependence between each layer. Just consistent APIs.
01:18:25evanso the app server is some internal web server you have?
01:18:33binary42Nope. It's rainbows.
01:18:45evanhm, never heard of it.
01:19:03binary42http://rainbows.rubyforge.org/
01:19:09binary42Based on unicorn.
01:19:27binary42But it handles long polling/slow connections while unicorn can't really do it.
01:19:44evanyou're using fiberpool or fiberspawn?
01:20:01binary42fiberspawn right now.
01:20:24binary42fiber spin up time is not my bottleneck so fiberspawn is more flexible.
01:20:45binary42(i.e. I can set a high connection limit w/o incurring memory overhead before I actually need it)
01:22:36binary42btw, I think rubinius fails to build with 1.9 set as ruby. I think it's just the fact that they removed '.' in $LOAD_PATH.
01:22:45binary42no such file to load -- rakelib/git
01:23:18binary42Running with RUBYOPT="-I." fixes it.
01:23:51matthewdevan: Anything else I should add while I have scrollback etc? http://github.com/evanphx/rubinius/issues/issue/178
01:24:08evanbinary42: you need to use 1.8 to build rubinius
01:24:20evanwe don't support building with 1.9
01:24:26evanno one has submitted patches to fix it.
01:24:52evanmatthewd: hm, no, i think thats fine.
01:24:54evanok
01:24:58binary42evan: Ah. Well, it's building fine for me with the workaround I mentioned. Not done but I'll let you know if it finishes.
01:25:03evanwell, i don't have time to figure out how rainbows works
01:25:03lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:03lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:03lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:04lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:06lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:07evanso i'm going to have to just leave it for now.
01:25:08lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:10lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:12lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:14lywlwVERSION irc.gnaa.fr #gnaa GNAA > j00
01:25:44binary42evan: np. I'll write something up later. I'm not in a rush since I'm on 1.9 these days. I'll submit a 1.9 build patch if you want though.
01:25:55evansure
01:26:27brixenafaik, dwaite has built with 1.9
01:26:48brixenRUBYLIB=. is the typical way to handle 1.9's braindead #require
01:26:48evani haven't yet heard of anyone doing it
01:26:53binary42It seems to be just a load path issue. Right.
01:26:53evanso i still consider it not supported.
01:27:06binary42brixen: I actually prefer w/o .
01:27:07brixenwe can add explicit paths to the Rakefile requires
01:27:17brixenbinary42: -I. is the same
01:27:18binary42Minimizing unneeded filesystem stats is good.
01:27:20evanor have Rakefile put it back
01:27:35brixenbinary42: oh, I misunderstood
01:27:39binary42brixen: Yeah. I tend to use RUBYOPT because I'll pass other options in from time to time like -w
01:28:31brixenI think checking one more dir (ie .) is not a huge filesystem stat load
01:28:34binary42Should be easy to add in the Rakefile. One line check for . or possibly just inserting File.dirname(__FILE__) regardless.
01:28:50brixenyeah, wasn't sure which approach to use
01:29:27binary42brixen: Possibly. I haven't measured but I plan on minimizing $: as often as possible.
01:29:34evanlets be sure to throw [ *[*thing, a], b] in there
01:29:45evanso we can make it really new.
01:29:52binary42Well, considering pwd can change... I'd use File.dirname(__FILE__).
01:30:14binary42evan: Supporting 1.9 splats?
01:30:14ruedbussink was working on 1.9 build
01:30:48binary42Well, I won't duplicate any work but this is one line if you guys want to add it.
01:31:06binary42no such file to load -- ext/digest/sha1/sha1
01:31:19binary42Looks like a few other things fail still but it got relatively far.
01:32:00binary42Hmm. I'll check back later.
01:32:09binary42I need to get some dinner here soon.
01:33:21brixenthere is this issue http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/27522
01:35:07maharg1.9 doesn't have . in LOAD_PATH? Wtf
01:35:51matthewdSo, I tried building Johnson with rbx.. complaints about missing ruby_errinfo lead me to recent IRC logs where, in reference to rice, evan said "eh gads. it reads ruby_errinfo directly? i hope it doesn't write it directly."
01:36:00evanwow
01:36:02evanyou're brave.
01:36:11matthewdAnd, um... well... :P
01:37:03evanyeah, we need to add ruby_errinfo to the capi
01:37:40matthewdYeah... Johnson writes it.
01:37:54evanwow.
01:37:58evanwe..
01:38:00evancan't support that.
01:38:13matthewdBut looking back at the code, I'm not sure it actually achieves anything.
01:38:33mahargspeaking of web servers, btw, I put in a bug report about mongrel under rbx locking rubinius up completely once it passes about 4200 requests (no matter how complex those requests are). It looks like a semaphore deadlock in Channel stuff
01:39:19evanmaharg: yeah, i've been looking into it.
01:39:26matthewdWe read ruby_errinfo before a call to rb_protect, then (if status indicates a jump) grab the resultant errinfo, and put the original one back.
01:39:29evanSocket is kind of a mess.
01:39:35evanit uses FFI for accept and bunch of things
01:39:37evanwhich block hard
01:39:41evanso i'm fixing that.
01:40:02evanit's not a mess, thats the wrong word. but it can't use FFI for blocking IO calls.
01:42:14evanmatthewd: i've got no way to form some C code that will intercept "ruby_errinfo ="
01:42:19evanso i just don't tihnk I can support it.
01:43:08brixenmaharg: yeah http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/24155?help-en
01:43:42matthewdevan: Yeah.. I'll investigate, but I now suspect setting it isn't actually achieving anything anyway.
01:45:54brixenmaharg: but it's apparently only a security risk for #require but not #load
01:45:57brixenmaharg: http://gist.github.com/290334
01:46:05brixenI need to file a ticket on that
01:46:20brixenI discovered it rewriting the #require/#load specs
01:56:36evanzoinks
01:56:40evan /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined
02:05:41mahargevan: cool, thanks
02:06:51mahargbrixen: seriously, wtf. 1.9 gets more dumb every time I hear about one of its breaking changes.
03:27:57ruebinary42: As I recall, the issue is that 1.9 first searches all $: for .rb files in sequence, and only then .<so ext>
03:28:22rueUnlike 1.8, which searches .rb, then .so for all
03:28:23binary42Ah didn't know that.
03:28:51binary421.9 has relative require mechanisms so it's less of a problem.
03:30:01binary42(aka. see Kernel#require_relative)
03:30:10binary42Which is much better for than using -I.
03:30:28binary42Because then those files are always fast because there is no $: scanning.
03:30:37rueTrue
03:30:38binary42Relying on $: in the first place kind of sucks.
03:30:56binary42Of course they didn't really make the transition clean.
03:31:05binary42They could have done a little better.
03:31:40rueSlightly
03:32:02rueOn the whole, I would have been satisfied with just not doing 1.8.8
03:32:20binary42I have mixed feelings on that still.
03:32:40binary42First of all 1.9 is a bit faster so it made sense to use it. It's not the most mind blowing improvement but it's there.
03:32:52binary42i.e. the first step doesn't have to be the last.
03:33:32binary42The other part is that some things needed cleaner semantics. It feels odd coming from 1.8 but I like 1.9 after using it awhile.
03:33:51binary42Even little things like new syntax has helped keep my code easier to read.
03:34:00binary42Encoding support is also huge.
03:34:11binary42It's been sooo much easier to deal with complex text now.
03:34:22binary42oniguruma as the default regexp is also super nice.
03:34:24mahargman I really haven't been paying attention. There's another "part way to 1.9" 1.8 release? Guh
03:34:29binary42etc... it's tons of small things.
03:34:44binary42And regarless of what the jruby guys say, I find generators useful.
03:35:04binary42maharg: 1.8.8 is the final "bridge" release.
03:35:16mahargthey really don't have any respect for the sanity of version numbers in MRI land, do they?
03:35:22binary42Though I gave up on it when they broken to_ary in the 1_8 branch.
03:35:37binary421_8 is defunct IMO.
03:35:42rueWhich is just stupid since it is not fully backwards-compatible with 1.8.7 anyway
03:35:58mahargbreaking changes in a third level version number is just so fundamentally wrong
03:36:01binary421.8.7 was a mess we can all avoid talking about.
03:36:25binary42Though if you are on 1.8 I'd use 1.8.7+REE patches.
03:36:25mahargcomplete language redesign in a second level version number is also insane
03:36:45binary421.8.7 includes some nice things to make slightly more mordern Ruby a bit faster.
03:38:12binary42Either way, I've seen plenty of benefit in 1.9 and core is going that way. Kicking and screaming is just delaying things not changing it.
03:38:40binary42I'd almost suggest that 1.8 supporters should fork the language if they feel so strongly about avoiding 1.9 now.
03:38:58Zoxcdoesn't see any reason to use 1.8, except for heroku
03:39:04binary421.9 was moving way to much pre 1.9.2 + rubyspec work but I don't see that anymore.
03:39:12mahargto be perfectly blunt, part of my interest in other implementations comes from a complete and utter lack of trust in the MRI team to keep things sane
03:39:18binary42Zoxc: Yeah. They are working on 1.9 support IIRC. Same with EY.
03:40:10binary42maharg: I kind of thought the same thing 3 years ago with Rubinius. Not being done is understandable but it obviously isn't as easy as it looks.
03:40:50mahargwhether I have to deal with the messes they've made now, I'd like a future without those messes being repeated and there's no sense of contrition about the fragmentation that's resulted from their boneheaded decisions.
03:41:51binary42maharg: Yeah. Well, I'm just saying everyone I know has made a bonehead decision with implementation.
03:42:00binary42They are all working on fixing it or recovering.
03:43:12binary42I can point things out but it's not the past I care about anymore. It's today and tomorrow.
03:44:19dxzhpvmmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
03:44:19dxzhpvmmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
03:44:19dxzhpvmmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
03:44:20dxzhpvmmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
03:44:22dxzhpvmmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
03:44:34binary42Ever implementation also has strengths and weaknesses. It's pretty awesome to have the opportunity to chose like this.
03:44:43rueI would agree to some degree that "they" do not really look like they have learned from the past, though.
03:45:02binary42But it'd be nice if it were based on the emerging version of ruby rather than something historical.
03:45:16binary42rue: Have you talked to them?
03:45:21binary42Like Yugui?
03:46:16binary42ruby-core isn't a fishbowl. Language barrier blah-blah-blah. If there is a problem still, point it out or help fix it.
03:47:22binary42Anyway... I'm done for the day on this. I would continue talking but we all know this conversation so I'll save our time and just tell people to do what they think works.
04:33:54repelcbnVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
04:33:55repelcbnVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
04:33:55repelcbnVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
04:33:56repelcbnVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
04:33:58repelcbnVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:39mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:39mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:39mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:40pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:40pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:40pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:40mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:41pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:42mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:43pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:44mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:45pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:46mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:47pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:48mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:49pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:50mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:51pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:52mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:53pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:54mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:55pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:56mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:57pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:58mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:15:59pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:00mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:01pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:02mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:03pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:04mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:05pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:06mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:07pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:08mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:09pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:10mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:11pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:12mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:13pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:14mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:15pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:16mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:17pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:18mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:19pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:20mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:21pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:22mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:23pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:24mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:25pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:26mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:27pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:28mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:29pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:30mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:31pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:32mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:33pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:34mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:35pugeaVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:16:36mrvckuyurtVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:23:07kxcxdVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:23:07kxcxdVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:23:07kxcxdVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:23:08kxcxdVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:32qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:32qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:32qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:33qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:35qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:37qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:37cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:37cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:37cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:38cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:39qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:40cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:41qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:42cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:43qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:44cwxVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:45qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:47qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:49qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:51qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:53qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:55qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:56:57qivrmVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
05:57:12yakischlobaok, this is getting really fucking annoying
05:57:21yakischlobais there some way I can ignore these?
06:03:49rueDisable CTCP or wait until the upgrade
06:04:21yakischlobaIs there any disadvantage to disabling CTCP?
06:04:30yakischlobai don't really know anything about IRC
06:10:35rueNot in particular
06:30:47evansome lively debate earlier tonight.
07:05:46ridlcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:05:46ridlcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:05:46ridlcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:05:47ridlcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:05:49ridlcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:15:27matthewdI'll precede this by saying that I intend to remove the references to ruby_errinfo from Johnson; we seem to just be doing what rb_rescue would do for us anyway. But in the interests of considering all means of maximizing compatibility...
07:15:51matthewdIt occurs to me that there is actually a way to have code run upon an assignment, in C.
07:17:05matthewd(I'll also throw in an I-don't-really-know-what-I'm-doing warning here -- this might actually just be stupid, instead of merely ill-considered)
07:18:40matthewd#define ruby_errinfo (*ruby_errinfo_p)
07:19:07matthewdVALUE *ruby_errinfo_p = 0x100;
07:24:50qoybeuawgtcqVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:24:50qoybeuawgtcqVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:24:50qoybeuawgtcqVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
07:44:38evanmatthewd: well, thats not really running a function
07:44:43evanwhich is what I need to do
07:44:52evanwere this C++, i could do some operator overloading tricks
07:48:02matthewdevan: Isn't a signal handler a reasonable approximate of a function?
07:48:24evanew.
07:48:27evanno, not really.
07:48:31matthewdI won't claim to know whether you could actually extract enough info
07:48:38matthewdI didn't say it was pretty ;)
07:49:00evanbetter is to say that we can't support setting it directly and introduce a set_ruby_errinfo() to compat.h
07:49:14evanin MRI, that will just do ruby_errinfo = val
07:49:21evanand in rbx, we can do whatever we want then.
07:49:37matthewdYep, fair enough
08:08:42rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:42rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:42rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:43rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:46rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:47rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:08:49rontiucygVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:48upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:48upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:49upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:49upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:51upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:53upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:56upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:17:57upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:00upwiifmqyeVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:47wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:47wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:47wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:48wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:50wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:52wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:54wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:56wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
08:18:58wfruhrcVERSION http://www.theregister.co.uk/2010/01/30/firefox_interprotocol_attack/ LOL FREENODE DISSED
19:46:04kemetanyone have advice on getting the hpricot gem to install on rubinus
19:51:16khaasekemet: you could use nokogiri
19:51:47kemetkhaase: thx
19:52:16khaasekemet: (that is an alternative to hpricot which has about the same api)
19:53:15kemetkhaase: yeah i know - just have some code that already uses hpricot and wanted to test out with rubinius
19:53:35kemetalso tried running script/console but that seems to fail miserably
19:54:21khaasehttp://nokogiri.rubyforge.org/nokogiri/Nokogiri/Hpricot.html
19:54:41kemethttp://gist.github.com/evanphx/rubinius/issuesearch?state=open&q=execvp#issue/134
19:55:52kemetdoes this work for anyone here?
20:09:28dbussinkkemet: just tested here with a new rails app, and it can load the console
20:09:44dbussinkkemet: if you can add a reliable reproduction to the ticket that would be very useful
20:10:04kemetdbussink: thx - i guess i should try a new app - was testing with an existing one
20:11:11kemetstill failing with new app
20:11:19kemetFWIW I did add a note to the ticket
20:11:36kemetwill add a few additional details
20:11:53dbussinkkemet: could you try this with master?
20:12:02dbussinkwe're already quite a few commits further than rc2
20:12:23kemetwill do - hopefully can install this via rvm
20:12:35dbussinkkemet: dunno if that's supported
20:13:04dbussinkkemet: but using a git clone isn't that hard either
20:13:29kemetdbussink: noted, thx
20:14:27kemetdbussink: at the moment, rvm appears to be doing exactly that
20:27:05kemetdbussink: can't even create a rails app with head
20:27:29dbussinkkemet: yeah, i saw that too, but rails hasn't had a lot of attention lately
20:27:44dbussinkkemet: could you create a ticket with details steps how you reproduced it?
20:27:56dbussinkand if it's a different error, preferably in a new ticket
20:28:00kemetand unfortunately script/console still fails
20:28:21kemetdbussink: yeah i'll update the script/console ticket and create a new one for the rails issue
20:42:42kemetdbussink: http://gist.github.com/evanphx/rubinius/issuesearch?state=open&q=2.3.5#issue/179
21:02:47dbussinkkemet: you don't see the issue with the rc2 release?
21:06:05kemetdbussink: not the rails app creation issue
21:18:00dbussinkevan: adding frozen support did expose some new tricky issues :)
21:20:06dbussinkkemet: just got a rails app running again on webrick with a new app (i did create the new app with mri)
21:24:45kemetdbussink: script/console works for you right?
21:27:10dbussinkkemet: it works for my test app here yeah
21:35:36kemetdbussink: for me, script/console fails both in head and rc2. script/server on the other hand does work on rc2, but not head
21:37:12kemetAn exception occurred running script/server
21:37:12kemet unable to modify frozen object (TypeError)
21:37:12kemetBacktrace:
21:37:12kemet String#modify! at kernel/common/string.rb:2257
21:37:26dbussinkkemet: yeah, i've got a fix for that here locally
21:37:31kemetah
21:39:53kemetdbussink: are u on mac os? wondering if the script/console issue might be platform specific
21:40:06dbussinkkemet: yeah
21:40:22kemetdbussink: version?
21:40:30dbussinkkemet: 10.6
21:41:14boyscoutAdd spec to verify File.join doesn't mutate the first argument when to_str is used - af22448 - Dirkjan Bussink
21:41:14boyscoutBe sure we have a fresh copy and don't mutate the argument directly - 9fb3828 - Dirkjan Bussink
21:41:45kemetdbussink: ok, FWIW i'm on 10.5.8
21:42:27dbussinkkemet: that should fix the frozen issue
21:42:48kemetdbussink: excellent thx
21:45:29boyscoutCI: rubinius: 9fb3828 successful: 3024 files, 11900 examples, 36302 expectations, 0 failures, 0 errors
23:47:52Zoxcdoes ruby have a reentrant mutex in it's standard library?