Index

Show enters and exits. Hide enters and exits.

00:55:01ruedbussink: Hi-Fi
02:46:29brixenhm bin/rbx -e 'p Object.send(:initialize_copy, String)'
02:46:31brixenfun
06:51:36evanhm, i guess macruby doesn't support SystemStackError
06:53:36brixenI wonder why
06:54:03evanalthough
06:54:05slavai evan
06:54:09slavahi*
06:54:13evanthe crashreport is sweet.
06:54:16slavahow and when do you reset PICs?
06:54:55evanit's pretty coarse atm
06:55:05evanright now, whenever a method is defined
06:55:14evanall PICs for a method of that name are reset
06:56:04evanthat what ya mean?
06:56:39evanslava: you don't detect a stack depth error, do ya?
07:17:40slavaevan: call stack?
07:20:11evanyes.
07:20:35slavayeah it just segfaults if you recurse too deep
07:20:54slavahowever, I've almost never seen this
07:21:22slavausually you blow the retain stack first
07:21:32slavawhich has a guard page
07:21:44evanaaaaah
07:21:46evanok
07:21:49slavaI plan on doing better green threads soon, which will have their own call stack each
07:21:52evanhow do you implement that?
07:21:54slavainstead of copying the stack in and out using continuations
07:22:03evani got fibers working this weekend
07:22:07slavawhen I do this, I'll be able to put guard pages on the green thread callstacks too
07:22:10evangoing to push tomorrow
07:22:21slavaso if it blows the call stack it will give a nice error message
07:22:32evanhow is the retain stack guard implemented?
07:23:04slavathe retain and data stacks ar eaallocated by a routine that mmaps some memory, then calls mprotect on the first and last page
07:23:33evansure
07:23:55evanbut do you then define a SIGSEGV handler to try and detect what happened?
07:24:05slavayes
07:24:17slavahttp://gitweb.factorcode.org/gitweb.cgi?p=factor/.git;a=blob;f=vm/os-unix.cpp;hb=HEAD
07:24:26slavaI call them 'segments'
07:24:37slavathis file has both the segment constructor (which does the mprotect) and the signal handler
07:25:11slavabut on mac os, I don't use SIGSEGV, I use the mach native API to listen for protection faults
07:25:24evanooh
07:25:30slavaon windows I use SEH
07:25:37slavathis is how I catch division by zero too
07:25:40evanyou reset the uap
07:25:41slavayou must handle that signal right?
07:25:56evanso that when the signal returns, it starts running the error handler code
07:25:58evanclever.
07:26:11evani'd imagine that UAP_PROGRAM_COUNTER is a bitch to maintain
07:27:00slavahttp://paste.factorcode.org/paste?id=1262
07:27:25slavayes.
07:27:54evanwhy oh why can't that be standard
07:27:55evanle sigh.
07:27:56evanso
07:28:09evanwould you mind if i spun that code out into an external lib?
07:28:19slavanot at all my friend
07:28:28evanwonderful!
07:28:35slavaare you going to use my windows and mac os x code too?
07:28:42slavalook at mach_signal.cpp
07:28:44evani might!
07:28:48evanat the very least
07:28:59slavamach_signal.cpp makes my cry :(
07:29:13evani'd like to put together a library of ucontext/setjmp things
07:29:38slavaon windows, you define a callback with AddVectoredExceptionHandler()
07:29:42slavathis is in os-windows-nt.cpp
07:29:52evanok
07:29:57slavaits almost like a signal handler; you get a PCONTEXT which is like a ucontext and you can change the pc and sp in it
07:30:07slavaits win32/win64 specific too
07:30:16slavaif I had this implemented as a library, wouldve saved so much time
07:30:33evanhm nice
07:30:44evanwhat i'll probably do is structure it a layered way
07:30:51slavathere's libsigsegv but it sucks
07:30:51slavaand its gpl
07:31:04evanone lib that tries to handle unifying the unix APIS
07:31:22slavaand a C++ API on top with templates right? :)
07:31:26evanso there would be at least unix/macos/windows
07:31:35evanha
07:31:39slavaare you interested in ucontext only, or signal handlers too?
07:31:45evanno templates unless they really make sense
07:31:55slavawhat's the scope of your abstraction lib?
07:32:19evanwell, the ability to reset a ucontext so that things can be handle after a signal handler is big.
07:32:42slavaI'd use your library if you made it :)
07:32:44evanthats sort of the missing piece in a puzzle in my head
07:33:00evani've looked at libsigsegv
07:33:02evanyikes
07:33:04evanAND GPL.
07:33:19evani really need helpers
07:33:23evanso thats going to be the structure for now
07:33:28evanyour UAP_* macros
07:33:30slavaa portable way to respond to segfaults and arithmetic exceptions, by changing the pc and sp to your routine of choice
07:33:33evana little icing
07:33:34evanto start.
07:33:43evanyeah
07:33:48evanthat's definitely the goal
07:33:52evani think we can easily get there.
07:34:00evanhell
07:34:03evanyou're already there!
07:34:12evanwe just need to library-ize it.
07:38:45evanslava: BSD license ok?
07:40:23slavaevan: factor is BSD licensed
07:40:30evanok, rad
07:40:33evanjust wanted to be sure
07:40:35slavajust to clairfy: http://factorcode.org/license.txt
07:40:43evani'll probably dig in and abstract a little tomorrow
07:41:00slavaawesome
07:41:45evanso, i'm assuming you've had good luck with the UAP_* macros
07:41:58slavayeah, they work reliably
07:42:01evanawesome.
07:42:21slavawe have an extensive test suite that covers stack under/overflows, division by zero, and FP traps
07:42:32evanperfect.
07:42:45evanhow do you do platform detection right now?
07:43:00evanfor instance, the difference between the freebsd UAP_* and the linux versions
07:43:07evani see there in different header files
07:43:15slavaits pretty ghetto, http://gitweb.factorcode.org/gitweb.cgi?p=factor/.git;a=blob;f=vm/platform.hpp
07:43:22slavajust one central include that has all the ifdefs in it
07:43:23evanaah
07:43:24evani found it!
07:43:26evanwooo!
07:43:34evancpp ghetto!
07:43:35evanlove it.
07:43:42evanthis is wonderful
07:43:50evanno autoconf!
07:44:02slavawell, the makefile varies by platform too
07:44:11slavabecause there's OS-specific .cpp files
07:44:21slavabut we have a shell script which sniffs out the default target
07:44:28slavaso calling 'make' with no args works
07:44:37slavayeah, no autoconf!
07:44:39evanok
07:44:46evanwell, i really really really do not want to use autoconf.
07:44:51evanreally.
07:44:54slavagood
07:45:04evani'm glad we agree.
07:45:14slavahow paranoid are you about EINTR?
07:45:32evannot as much so since we switched to stackfull
07:45:36evanand native threads
07:45:54evanwhy? are you very?
07:46:11slavaI'm not clear on what conditions can cause a system call to return EINTR
07:46:15slavaI've seen it happen before
07:46:24evanah
07:46:31slavaon sockets, but also stdin
07:46:32evansignal is pretty much it.
07:46:44evanat least
07:46:54evanthats what i've always seen
07:46:58slavaso in theory, any time you have a system call which is documented as failing with EINTR
07:47:05slavayou have to wrap it in logic which re-tries it if needed?
07:47:11evanit depends on the call
07:47:21evanthats the option to sigaction that specifies restart
07:47:22slavaotherwise, there's a 1 in a zillion chance that a signal will arrive and screw up your code?
07:47:42evanok
07:47:45evancheck the sigaction man page
07:47:53evanjust below where it describes the SA_* macros
07:47:58evanit talks about EINTR
07:49:19scoopron the plaform includes, I do something very similar, but I don't even vary makefiles usually, just wrap the .cpp in a #include "config.h" #ifdef PLATFORM_OF_CHOICE .. #endif .. ranlib bitches about empty .o files, but I still find it convenient =)
07:49:33evanas do I.
07:49:39evanfind it convienent
07:50:10slavaoh, nice
07:50:37slavaso do you set SA_RESTART?
07:50:45evanyeah
07:50:50evanand you won't get EINTR
07:51:04evansometimes you want EINTR
07:51:08slavawe have a unix-system-call macro that we wrap everything in that restarts it if it returns EINTR
07:51:11evanfor stuff like SIGVTALARM
07:51:20slavawhy?
07:51:48evanlets you specify a timeout of any kernel blocking call
07:51:56evanlike select's timeout, but on anything you need.
07:52:12slavabut if its inside of a C lib, and they don't handle EINTR properly, yu're fucked
07:52:17evantrue enough.
07:52:22evanbut it's still done.
07:52:51slavabut other than that, there's no downside to enabling SA_RESTART?
07:53:32slavaman, I was pretty proud that my unix non-blocking IO code was completelyEINTR safe and no-one else's was
07:53:35slavahaha
07:53:42slavabut now I see there's an easy solution that does not involve macro meta programming
07:53:47evan:)
07:54:13evanhey! that means you get to participate in the greatest activity a programmer can undertake
07:54:15evanDELETING CODE
07:55:14evanok, well, i'm going to get to bed
07:55:39slavaBAI
07:55:39evani'm planning on redoing my stack overflow logic tomorrow with your UAP_* macros and our new library
07:56:37slavacan I be a contributor to your library? :)
07:56:46evanof course!
07:56:52evanyou're the #1 author.
07:57:07slavaI'll let you think of a catchy name, though.
07:57:15evani'm meerly the baker that puts some nice wrapping on it
07:57:25evanoh yay!
07:57:27evannaming rights!
07:57:35evanEvan Phoenix Arena!
07:57:38evanoh wait, this is a library.
07:57:39evanhm.
07:57:41evani'll think on it.
07:57:49evannite! :)
07:57:59slava:)
08:06:21scooprhow about libwigwag ;) http://en.wikipedia.org/wiki/Flag_signals
08:40:20boyscoutUpdated CI specs to RubySpec 10f861de. - 95ed29e - Brian Ford
08:40:20boyscoutEnsure flip-flop operators don't cause unbalanced stack errors. - 1bfc55d - Brian Ford
08:40:20boyscoutUpdated CI tags for merged rubyspecs. - 8852f54 - Brian Ford
08:53:04boyscoutCI: Commit 8852f54 failed. http://github.com/evanphx/rubinius/commit/8852f5428364075c99a2f2f8177fd788dd6cd7bd
14:34:11cremesseeing a weird SIGSEV when running the latest checkout: http://gist.github.com/292703
14:34:24cremesosx 10.6.2
14:34:36cremesi can/will create an issue on this if someone else can confirm it
14:35:14cremeswhat's odd is that it crashes during the initial mspec FULL run, but it's okay for my subsequent runs (bin/mspec ci -T -XJ)
14:55:54kronos_vanocremes, If you have steps to reproduce.... Why not?
14:56:17cremeskronos_vano: the steps to reproduce are to type "rake" :)
14:56:38kronos_vanohm...
14:56:53cremesi'll try a distclean and a rerun to see if it still occurs; maybe i have a bad file in my environment
14:57:09kronos_vanoruby -v == 1.8.7 ?
15:15:30cremeskronos_vano: yes, 1.8.7
15:15:55cremesknown issue with that ruby release & rubinius?
15:17:49kronos_vanohm
15:18:12kronos_vanoI just now got it too
15:23:43kronos_vanocremes, unknown.
15:24:02cremesi'll open an issue
16:42:12goyox86Hi people, i'm interested in helping somebody can tell me where?
16:42:53goyox86I've aseked the same thing some days ago and some people told me that is a lot of work to be done , in the GC
16:43:16goyox86other people suggested me fix some failing specs
16:50:49kronos_vanogoyox86, http://github.com/evanphx/rubinius/issues
16:57:22evangoyox86: you can fix an failing specs
16:57:24evanrun
16:57:29evanbin/mspec tag --list fails
16:57:33evanto see all the failing ones
16:58:47goyox86ok #evan
16:59:18goyox86evan there is some work can i do for the implementation itself
16:59:20goyox86?
16:59:36evanwell, what do you want to work on?
17:00:23goyox86well i have some knowledge in programming languages design
17:00:35goyox86some people here told me about the GC
17:01:02goyox86it's needs to be rewritten?
17:02:06evanno
17:02:10evanthey should not have said that
17:02:12evanthey were kidding.
17:03:48goyox86ok evan, i took it i seriously an cheched out the code is a generational one :-)
17:04:03evanyeah, it's a generational collector
17:04:48goyox86is it similar to the squeak's one?
17:06:14evani haven't looked
17:06:20evanbut i didn't think that squeaks was generational
17:06:54BrianRice-workit is.
17:07:22BrianRice-workotherwise it would be quite a dog, consing lots of temporary objects for its renderer and graphics toolkit
17:07:31evantrue
17:07:48evanwhats it use for the generations?
17:07:54evansemispace + marksweep?
17:08:18BrianRice-workquick overview: http://wiki.squeak.org/squeak/1469
17:08:20goyox86mmmmm i don't know exactly
17:08:48BrianRice-workbasically mark-sweep-compact with a simple eden and a forwarding-pointer feature which is used for a few different things
17:09:34BrianRice-workso, no semispaces
17:11:08evani know that squeak uses a wild and wacky object header
17:12:11evanBrianRice-work: hm, i wonder what write barrier it uses.
17:12:38BrianRice-workoh, I used to know offhand. slate's original GC was a port/cleanup of it.
17:12:57evanwhat does slate use for GC now?
17:13:39BrianRice-worksomething similar, but the details are different... looking to remind myself
17:14:44BrianRice-workyeah, we use card-marking, but are still a mark-sweep-compact 2-generation gc
17:15:02BrianRice-workhttp://github.com/briantrice/slate-language/blob/master/src/vm/gc.cpp
17:16:57evanso you lay out all of the objects in contigious memory?
17:17:51evanI see 2 mmaps
17:17:59evanso they're not fully contigious?
17:19:10BrianRice-workright, they're not
17:19:40evandoesn't look like card marking
17:19:42BrianRice-workmmap or malloc as a fallback
17:20:01evanI see what looks like a std::vector holding intergen objects
17:20:04BrianRice-workcard pinning? maybe I'm using the wrong term ;)
17:21:02evanwhat code do ya mean in that file?
17:21:48BrianRice-workobject-pinning. duh
17:22:14BrianRice-workhonestly, I don't keep track of much detail in our VM :)
17:22:41evan:D
17:22:49evanobject pinning isn't really write barrier related.
17:23:26BrianRice-workright, it has more to do with putting things on the c stack (or elsewhere like ffi) safely
17:23:43evanright, I see the Pinned<> template
17:23:53evanthats a trick I also use.
17:25:41BrianRice-workhm yeah, we *did* have card marking... until the SSA VM
17:26:03BrianRice-workprobably just got lost in the shuffle. I recall that the gc was simplified for debugging purposes
17:26:33evanslava and I have been discussing how well a JVM style giant-mmap-at-beginning setup would work
17:26:59evanand then using the tricks to commit and uncommit pages
17:27:17BrianRice-workyeah I've heard about this technique. it's intriguing
17:28:06evanit's like also implementing your own virtual MMU
17:28:11evanin addition to a virtual CPU
17:28:20BrianRice-workI recall in particular a paper which involved a modified linux kernel which offered an api to query the state of pages, then the gc would avoid scanning pages which were on disk; managing to save huge amounts of overhead
17:28:30evanoh
17:28:32evanyeah
17:28:33evanthat would help
17:28:41evanthats piggy backing off the REAL MMU
17:28:54BrianRice-worknods
17:29:19BrianRice-workalas, kernel hackers don't give two shits about this sort of thing
17:29:38evanyeah
17:29:56BrianRice-workmaybe if the right guy were teased with the idea... hm, linus does live in PDX ... :)
17:30:32BrianRice-workpays attention to work again
17:31:43brixenevan: so, this random segv running the spec...
17:31:58evanyeah
17:32:01evani haven't looked
17:32:28brixenok
17:39:43evani'm going to spend a little time on tickets today
17:41:21brixenjust rebuilding in debug to see if I can get more info
17:41:44brixenfrom the bt, looks like it's in the GC
17:41:57evanyeah
17:42:35brixenevan: so, question on this "Mutex#lock waits if the lock is not available, even by the same thread"
17:42:43brixenit's failing on 1.8.7 and 1.9
17:42:43evanyes.
17:42:47brixenpasses on 1.8.6
17:42:52evanrad!
17:42:58evanok so
17:43:07evani should have been clearer about whats going on
17:43:17evanthe failure your getting is probably a ThreadError
17:43:26evansaying that you can't sleep the only thread?
17:44:02brixenum related
17:44:12evanhow are they failing?
17:44:16brixenThreadError: deadlock; recursive locking on 1.9
17:44:26brixenThreadError: thread 0x33b47c tried to join itself on 1.8.7
17:44:33evanrad.
17:44:37evan*eyeroll*
17:45:01evani don't know what to do then.
17:45:29evansince it appears that Mutex#lock changes behaviors
17:46:05evanhm
17:46:09evanit passes on 1.8.7 for me
17:46:16evanotherwise I wouldn't have checked it in.
17:46:23brixenwhat patchlevel?
17:46:30evan72
17:46:37brixenok, try on latest stable
17:46:39brixen248
17:46:42evanah
17:46:44evanwell shit.
17:47:06evani'm not sure how to spec whether or not Mutex#lock is recursive or not
17:47:17brixenhmm, me neither
17:47:24evansince that fact appears to change IN 1.8.7
17:47:31brixenyeah
17:48:39VVSizevan: and jruby does: ThreadError: Mutex relocking by same thread
17:48:47evanok
17:48:51evanso no one agrees on what to do.
17:49:31evanaaaah
17:49:38evansome later version of 1.8.7 includes fastthread
17:49:42evanie, Mutex is implemented in C
17:50:48evanwell crap.
17:50:49evanno clue.
17:50:55evani guess it's undefined behavior at this point.
17:51:00brixenseems so
17:51:14brixenI'm not understanding why it should be so hard though
17:51:19evanit "behaviors erraticly" do
17:51:22evanit's not hard
17:51:23brixenhaha
17:51:39brixenso, perhaps a bug ticket for MRI?
17:51:40evanit's that it seems that people took issue with it not being recursive
17:51:51evanyou'll just hear "we fixed the bug in 1.9"
17:52:07evanie, i'm betting they consider it not detecting recursive locking a bug.
17:52:23brixenok, well then that is explicit enough
17:52:35evanconsidering how it's been changed.
17:52:43brixen"you cannot lock a locked mutex on the same thread" ?
17:52:49brixenI'm not sure how to describe it
17:52:52evanuse the word recursive
17:52:59evansince thats the typical language for this behavior of a mutex
17:53:07evanit "raises a ThreadError when used recursively"
17:53:12brixenk
17:53:13VVSizevan: yeah
17:53:34evanbrixen: so, what about older 1.8.7s?
17:53:39evanis there a patchlevel guard?
17:53:54brixenseems like this needs a ruby_bug guard
17:54:01brixenif they consider recursive locking a bug
17:54:09evaneverything points to that fact.
17:54:57brixenk
17:55:11brixenthanks evan
17:55:16evannp
17:56:18evanyay
17:56:30evani've eliminated the tick checker in ::interpreter
17:56:40evanand simplified the stack check
17:56:58evanit should be the same speed
17:57:11evanand we'll catch stack overruns better.
17:57:36brixenawesome
17:57:45evanbtw
17:57:52evanfor those that care
17:57:53evanyou can do
17:58:05evanrake build:normal_flags <cpp file>.S
17:58:18evanto have it assembled to human readable assembly.
17:58:35evanthats what I do to check what the generated assembly is for things
17:58:51brixenah yeah, I saw the rule in there
17:59:27brixenwell, not getting the segv under gdb with a debug build :(
17:59:42evani'm not surprised.
18:00:03evani'm getting random String spec failures for some reason...
18:00:20brixenhrm
18:00:22brixenlike?
18:00:44brixenok, got it... USZ!
18:01:33evanweirdly
18:01:35brixenwell, it's not the same as the CI bot got
18:01:36evanit's frozen errors.
18:02:03evani'm poking at it.
18:02:11evanoh, did CI get a failure too?
18:02:17evani thought you meant the issue
18:02:17brixenyeah, the segv
18:02:22evanthere is an issue about one
18:02:30brixenlooks
18:02:49evanhm
18:02:58brixengithub sure is slow lately
18:03:02evani've seen a few segfaults in the LookupTable mark code
18:03:05evani wonder if something is up
18:03:05brixenat least for website and gist stuff
18:03:33brixenI'll add a bt to the ticket if mine is different
18:04:06brixenmaybe
18:04:18brixengithub fail
18:05:27evanyeah, i've got a GH fail too.
18:24:21tarcieriumm weird, so Facebook's thing really is an AOT "compiler"
18:24:25tarcierifor PHP
18:24:28tarcierithat translates it to C++
18:24:29tarcieriwtf?!
18:24:30tarcieriheh
18:26:07vhost-tarcieri: are you talking about the php runtime rebuild thing?
18:26:22tarcieriyeah, except it's not
18:26:27tarcierihttp://developers.facebook.com/news.php?story=358&blog=1
18:26:44tarcieriit's not a compiler, it's a source code transformer!
18:26:45tarcierilol
18:26:48tarcieriwhat?
18:27:05evanrad.
18:27:08evansource translation to c++.
18:27:10evanlove it.
18:28:18vhost-it's really called hiphop?
18:28:28tarcieriwonder if it has a crazy type inference engine like Starkiller
18:28:51tarcieriprobably not
18:29:43tarcieriI guess it does some basic type inferencing
18:33:05evantarcieri: well, when they release the source we'll see.
18:34:06tarcieriyeah
18:34:40evansounds like they just bail on the parts of PHP that are truely dynamic
18:35:05tarcieriheh
18:36:54evanooh
18:37:08evanGH is slow because Hiphop is on GH.
18:37:15evanso all the facebookers are flooding GH.
18:37:23evanthe price of success.
18:37:26brixenoh fun
18:38:00tarcieriheh
18:38:04brixenI blame the dedicated servers for not scaling well :)
18:38:10evanhah
18:38:21tarcierilol
18:41:43dbussinkeverybody from kenai is moving there ;)
18:42:20burkelibbeyboth of them? >_>
18:43:04burkelibbeyI guess it only seems small to me because I don't use java.
18:44:13dbussinkburkelibbey_: you're ruining the joke :P
18:44:28burkelibbeyheh
18:44:56dbussinkis going to restart his new irc proxy for the last time hopefully
18:47:37evanpretty sure i've got the random spec failured sorted out.
18:48:09evandamn
18:48:13evanstill there.
19:01:49brixenpoor GH
19:02:01brixennow just getting 404s instead of mad horses with horns
19:02:14evanyeah
19:02:26evanthe facebook thing about Hiphop had link to a github wiki
19:02:42evanmaybe the wiki sucked and brought the whole site down.
19:49:30brixenevan: updated #181 with a gist of vm and ruby bt's
19:49:38evank
19:49:40brixenI'll leave that process running if you want me to poke at anything
19:49:42evani've got a crash here too
19:49:45evanin the GC
19:49:47brixenok
19:49:49evanpossibly the same one
20:14:55evanI think I have the crash figured out.
20:15:21brixenwhat is it?
20:15:36evanI think that ObjectSpace.find_object using the mark bits in the header is ending up confusing the GC later on
20:15:50brixenahh
20:16:33brixendo we need a find_object bit in the header?
20:17:01evanperhaps
20:17:06evani've got with the pragmatic approach for now
20:17:17evanusing a std::map to keep track of if i've seen an object
20:17:58brixenmakes sense
20:18:08evanit's a map allocated per call to find_object
20:18:18evanso it doesn't confuse anything
20:19:29evanit's got the side benefit that i can now implement find_object to look down a specific object graph
20:19:38evannot just all objects
20:19:40evanack!
20:19:50evanstill getting a random spec failure
20:19:56evanthis time inside REXML....
20:20:37dbussinkevan: random spec failures looks like the issue i was seeing with the datamapper specs too
20:20:57evanmaybe
20:21:04evannever seen it in running the ci specs though
20:22:14evanI did find some places where the methodcache wasn't being cleared
20:22:21evani wonder if thats whats up with the DM specs
20:26:14evanok, using the map in find_object seems to have solved the problem.
20:27:58dbussinkevan: i'll just keep running them after each change that could potentially fix it ;)
20:28:07dbussinkevan: jit method cache issue?
20:29:00evanperhaps
20:31:41evanGR
20:31:47evanstill getting these random spec failures.
20:31:50evanwtf
20:32:30brixenis it the same spec randomly or random specs?
20:33:35evanit's frozen specs in String
20:33:37evana lot
20:33:42evanbut I saw a random one in REXML
20:34:36brixendrm
20:34:40brixener hrm
20:34:43evanit might be JIT
20:34:45evanrelated.
20:34:49evani'm going to poke a bit and get lunch.
20:34:57brixenk
21:13:15dbussinkezmobius: decided to put up the pressure a bit? ;)
21:13:41ezmobius;) i already have ruby aliases to rbx on my own laptop and i am trying to use it for all my local dev
21:33:46evanthis spec weirdness is ... weird.
21:34:35evanoooooooh
21:34:36evanhm.
21:46:57dbussinkevan: that sounds like "i found it!", "ah, no, probably not"
21:57:00evanwell, i thought maybe the JIT was reading or update the wrong header bits
21:57:02evanbut that seems ok.
22:08:25evanhrmph
22:08:29evani'm just going to push what I have
22:36:23boyscoutFix Socket#accept - b412c1b - Evan Phoenix
22:36:23boyscoutInliners changed name - f924362 - Evan Phoenix
22:36:23boyscoutMinor cleanup - 9c761a0 - Evan Phoenix
22:36:23boyscoutCheck that something is a reference before using it - 3016598 - Evan Phoenix
22:36:23boyscoutUse a std::map for marking rather than the header - 78cdc9d - Evan Phoenix
22:36:24boyscoutImprove how the stack depth is checked - 4318087 - Evan Phoenix
22:36:24boyscoutUpdate LLVM generated type info - 2b15601 - Evan Phoenix
22:36:25boyscoutAdd experimental Fiber support - a227ba1 - Evan Phoenix
22:36:25boyscoutImprove arguments to Fiber.yield and Fiber#resume - 2d09dea - Evan Phoenix
22:38:04evanexperimental fiber support has landed.
22:38:07evanyou guys dared me
22:38:55brixensweet!
22:39:18evanit only works on platforms that have makecontext(2)
22:39:36kronos_vanohm... Does ruby 1.8.7 have fibers?
22:39:48evanno
22:40:04evanbut it has continuations
22:40:09evanand fibers are a path to continuations
22:40:44kronos_vanook. So, is fibers in rubinius similar to fibers in 1.9 ?
22:40:50evanyeah
22:41:00evanif you wanna play with them
22:41:26evanhere's how to use them: http://gist.github.com/293128
22:44:02brixenheh FiberOne.com
22:44:11brixenRubinius: now better for your digestion (tm)
22:44:15evanhehe
22:44:27evanif there is no makecontext(2) on a platform
22:44:33evanFiber.new will raise an exception
22:46:05boyscoutCI: rubinius: 2d09dea successful: 3041 files, 11834 examples, 36109 expectations, 0 failures, 0 errors
22:46:40evanwell, thats nice.
23:01:56kronos_vanoevan, Ah, about tickets. I rewrite Array#pack (~5x speed up) #173, make some small patches (#174, #177), find quick solution for #33 . Also alias method cause StackError exception. (#180)
23:02:27kronos_vanotake a look if you have enought time
23:02:37evani'm going to apply them today
23:02:48evando you have all your pack changes in one patch?
23:03:05evani think #33 is already solve
23:03:16evani'm going to spend some time this afternoon going through tickets
23:10:16kronos_vanoNo, #33 is actual. I just test :). What about one patch: I'll do it now.
23:11:49evanhuh?
23:12:01evani'll check out #3
23:12:04evan#33
23:12:07evani meant to fix that
23:12:10evanbecause I was just in that code
23:12:18evanif it's not fixed, something is up.
23:12:46evanok, bbiab.
23:30:31kronos_vanoevan, http://gist.github.com/293163