Index

Show enters and exits. Hide enters and exits.

06:40:13dkubbhow well does ruby2ruby work with rubinius?
06:43:48dkubbI thought I'd play around with getting dm-ambition to run on rbx tonight, but I get a bus error when I run the specs with rbx: https://gist.github.com/31ba1a1dfa6c4f6a0d37
09:20:24postmodernsay when will rubinius be able to build on ruby 1.9.x?
10:36:03kronos_vanopostmodern, I think when 1.1 will released :)
10:36:27postmodernkronos_vano, it just seems like a bunch of # encoding # issues
10:36:46rb2khm, "no method 'weakref_alive?' on an instance of Object. (NoMethodError)"
10:36:55rb2kI guess rbx doesn't support this by now? :)
10:37:36kronos_vanorb2k, Do you have steps for reproduce?
10:37:41kronos_vanoSeems like a bug
10:37:47rb2kjust looking what actually caused it for now :)
10:38:04kronos_vanoweakref_alive? is method of WeakRef class
10:38:17rb2kyeah, must be some library
10:38:58rb2khttps://gist.github.com/2fab5b4e0ece5864ae88
10:39:01rb2kthat's the backtrace
10:39:12rb2klauncher.rb:59 is just Thread.new
10:40:48rb2kuh, doesn't happen the 2nd time
10:40:52rb2kmaybe a race condition
10:41:06rb2koh , took longer this time
10:42:15rb2kthis time "no method 'weakref_alive?' on nil:NilClass. (NoMethodError)"
10:45:32kronos_vanorb2k, Open a ticket with as full info as you can. With steps we fix it very quickly
10:47:20rb2kok, I'll try to include some info
11:53:44eregonHi
16:10:49evanmorning boys and girls.
16:19:00brianmarioyo
16:19:03brianmarioback in LA?
16:19:06evanyep!
16:19:11brianmariohow was RC?
16:19:15evanfun
16:19:18evantiring
16:19:21evani gave 3 talks
16:19:24brianmariodaaamn really?
16:19:32evanremind me to not do that again
16:19:37brianmarioheh
16:19:46brianmarioall on rbx?
16:21:07evannope
16:21:16evanone with headius about weird ruby stuff
16:21:21imajesthat one was good
16:21:27evanwe talked mainly about concurrency and GC this year
16:21:30imajesa little esoteric though
16:21:33evanyeah
16:21:36evanwe know
16:21:39evanbut thats ok
16:21:43imajesglad to know i won't use id2ref ever
16:21:43evanthats the design of the talk
16:21:51evan:D
16:21:53imajesyeah, i am not complainin' :)
16:22:01evanand then my 10 minute EY keynote
16:22:09evanwhich is online, video wise, if you'd like to watch it.
16:22:11imajeswell, i say i won't use it, but perhaps i might use it to scare people
16:22:12evanand then a rubinius talk.
16:22:20imajesevan actually did four talks
16:22:27imajeshe made a guest appearance in aaron patterson's talk
16:22:52evanha! yes
16:22:59evanlets call it 3.2 talks
16:23:08imajeswas that planned btw
16:24:46evanyeah :)
16:24:54imajesthought so
16:24:56evanwe wanted to do that since our talks were at the same time
16:25:02imajesdid you have a ringer in the audience
16:25:09evanaaron did
16:25:10imajesor was aaron just hoping someone would ask a rbx q?
16:25:10evanyeah
16:25:12imajesright
16:25:13imajesthought so
16:25:16evanto ask the question
16:25:22imajesright
16:25:27evannever leave comedy to chance.
16:25:28evan:D
16:25:33imajestotally
16:25:36evanit's hard enough planned.
16:25:36imajesbtw
16:25:42imajesi'm going to pull the same one myself
16:25:47imajesit's pretty awesome
16:25:51evanhah! good!
16:25:56evanit was fun.
16:26:04imajesi'm going to try sjobs tho
16:26:10imajeshe seems to like video chat
16:26:11imajes;p
16:29:11evanhaha
16:29:14evanfacetime him!
16:29:48evanwhen I got back yesterday and abby and I were talking about iphone 4, she said "you know my birthday is only 20 days after the launch..."
16:29:56evan:)
16:40:01jeremyevansevan: I'm having the same issue as http://github.com/evanphx/rubinius/issues/issue/75, but vm/vm is not stripped. This is trying to get 1.0.1 running on OpenBSD 4.7-current with gcc 4.2.1.
16:40:41evanmust be something about openbsd's dlsym() that doesn't work the way I expect
16:40:49jeremyevansevan: build log available at Build log available at http://code.jeremyevans.net/build.log, patches so far at http://code.jeremyevans.net/patches.diff
16:40:49evanare you on 1.0.0, 1.0.1, or git master?
16:40:59jeremyevansevan: 1.0.1
16:41:06jeremyevansI can try master if you think it will help
16:41:24jeremyevansevan: I tried both with and without llvm
16:41:34evanllvm certainly won't matter for this
16:41:40evanyou also really want to be using it.
16:42:13evanopenbsd doesn't have uintptr_t ?!
16:42:29jeremyevansevan: Apparently it causes problems
16:42:40evanwhat problem?
16:42:57jeremyevansevan: Something about not a valid type IIRC
16:43:05evanthats bizarre.
16:43:32jeremyevansevan: I can try removing that patch and rebuilding if you want to know the exact error
16:43:36evantry adding #include <stdint.h> at the top if it's not there
16:44:19jeremyevansevan: OK
16:44:52evanjeremyevans: as for the issue with not finding symbols
16:45:35evanwe'll have to figure out why openbsd's dlsym() won't find symbols for the current process
16:47:11jeremyevansevan: OK, I'm building with a patch that just uses that include instead of changing uintptr_t to long
16:48:12jeremyevansevan: If you would like me to run any tests, just let me know
16:48:24evanwell, you can boot the VM
16:48:29evanso running the tests is going to be hard.
16:48:32evanyou could run the VM tests
16:48:40evanbut they're not going to show whether or not dlsym() works
16:48:45evanthough we should probably add that as a test.
16:48:56evanjeremyevans: let me write you a quick C program to run
16:49:01evanthat will tell us, maybe, whats up.
16:49:04jeremyevansevan: OK
16:53:35jeremyevansevan: Looks like the stdint include worked
16:53:48evanok, thats just a missing include then.
16:53:54evanhttp://gist.github.com/434747
16:53:57evanok, compile and run that.
16:55:00jeremyevansevan: func: 0x0
16:55:11evanok, thats what I expected for you.
16:55:18evanthats weird that openbsd's dlsym is broken.
16:55:24evani'll have to research that.
16:55:49jeremyevansevan: OK. If I can do anything to help, please let me know
16:56:39evanwill do.
16:56:43evani'm going to research a little right now.
16:58:12evanjeremyevans: in that file, change RTLD_LAZY to RTLD_LAZY | RTLD_GLOBAL
16:58:15evansee what happens
16:59:02jeremyevansevan: no change
16:59:08evandang.
16:59:13evanwhat version of OpenBSD?
16:59:38jeremyevansevan: OpenBSD 4.7-current as of a couple weeks ago
16:59:48jeremyevansevan: right after they moved to gcc 4.2.1
17:00:00evanok, i'll have to get VMWare booted with it.
17:00:23evanif you wanna help, you could poke around and try and see why it can't see symbols from the current process
17:00:51evanjeremyevans: how about replace handle with RTLD_DEFAULT in the call to dlsym
17:02:36evanshould be the same
17:02:40evanunless there is an openbsd bug.
17:02:49evanbut I'd like to know
17:03:12tarcieriso hmmm @ VMware/EngineYard
17:03:15jeremyevansevan: I'm googling right now, but I'm not a C expert. If I find out anything, I'll let you know
17:03:26jeremyevansevan: no change with RTLD_DEFAULT in dlsym
17:03:30tarcierithink Rubinius would survive that? or no comment...
17:03:31evank
17:03:41evantarcieri: i'd expect so
17:03:53evanif not, i'll raise hell.
17:03:55tarcieriit'd really suck if you guys got axed
17:04:12tarcierior if they stopped funding Rubinius
17:04:13evani've got it in my contract that I can walk away from EY with the last released version of Rubinius to do whatever I want with
17:04:21tarcieriyeah awesome
17:04:45evanif it happens, man, VMWare will really burn some fucking bridges.
17:04:50evanseems like a shitty move PR wise.
17:04:52tarcieriyeah
17:05:09evanso I guess if the plan is "Buy EY, get everyone to hate us" then they could do that.
17:05:15tarcierishould hold an MRI funeral at RubyConf X ala the IE6 funeral
17:05:31tarcieribetween REE, YARV, JRuby, and Rubinius there's like... no reason to continue using MRI
17:06:31evanhah
17:06:42tarcierievan: wish I got a chance to say hi at RailsConf
17:06:57tarcieriespecially since I'm actually using rbx again, heh
17:07:01brixentarcieri: yeah, where were you hiding?!
17:07:18tarcieribrixen: I should've like... stopped by the EY booth and tried to get a golden ticket or whatever
17:07:24brixenheh, yeah
17:07:29tarcieriI was... around
17:07:35brixenI kept seeing charlie and forgetting you were there
17:07:37evanI know! I was lookin' for ya.
17:07:37evan:/
17:07:37evanoh well.
17:07:37evan(i didn't look that hard)
17:07:37evanwere you in BohConf most of the time?
17:07:38evani didn't make it over there.
17:07:45tarcierinah
17:07:48tarcieriI only went to BohConf once
17:07:58brixenI did get to finally meet MenTaLguY
17:08:09tarcieriyeah same here
17:08:38brixenwe have to relaunch the scheme to take over the world with Actors
17:08:45tarcierihehe
17:08:49brixenscheme/effort
17:09:03tarcieristill working on it... just via Reia
17:09:33brixentarcieri: congrats on the big milestones
17:09:51tarcierithanks :)
17:09:57tarcierimaybe I can actually do a release here soon or something
17:10:00brixencool
17:10:07brixenlooks like it's coming along nicely
17:10:16brixenjust had to get that python out of your system :P
17:10:18tarcieriyeah lots of conference-driven development :)
17:10:22evantarcieri: you should come to rubyconf
17:10:28brixenagain
17:10:29brixen:)
17:10:30tarcieriI will!
17:10:32evani'll put your on my schedule
17:10:36evanyes, again. :)
17:10:38tarcierisweet
17:10:55tarcierithis was my first RailsConf and I definitely prefer RubyConf
17:11:09brixenyeah, it's different
17:11:21brixenthis railsconf was pretty dang good I think
17:11:30tarcieriyeah it was a lot of fun
17:11:53tarciericrazy to see Ilya getting Rails running on EventMachine
17:12:23tarcierialthough it seems like horrible hax around problems that should be solved at the VM level
17:12:31evanjeremyevans: try http://gist.github.com/434765
17:12:38evani added dlerror() to see if openbsd is telling us whats up.
17:13:16evantarcieri: i'd love to hear your opinions on what about IO jruby/java gets right
17:13:52tarcierievan: you're doing the same thing as the JVM, suppose I should've mentioned you guys too
17:13:56tarcieriand for that matter so is YARV
17:13:58jeremyevansevan: func: 0x0 (null)
17:14:10evantarcieri: which thing is that? not using stdio?
17:14:16evanjeremyevans: ok, well, worth a shot :)
17:14:23tarcierinative threads so syscalls don't hang the entire VM
17:14:39jeremyevansevan: I'm going to ask in #openbsd
17:14:41tarcieriwhich yeah, if Ilya is using 1.9 anyway that argument doesn't hold water
17:14:46evanjeremyevans: ok, perfect
17:14:52evanshow them our dlsym_test.c
17:15:04jeremyevansevan: Definitely
17:15:05evantarcieri: yeah
17:15:06tarcierievan: the JVM comment was more about threads than I/O
17:15:16evantarcieri: i've been thinking more and more about how to remove the GIL
17:15:17tarcierierr, JVM angle
17:15:20tarcierinice
17:16:13evantarcieri: yeah, i think not implementing your own IO scheduler is important at this stage
17:16:25tarcieriyeah heh
17:16:28evanjust don't tell the event programming libraries.
17:16:35tarcieriurgh
17:16:42tarcieridoes EventMachine run on Rubinius?
17:17:16evanyep.
17:17:23tarcierinice
17:18:42tarcieriwere either of you at Ilya's talk?
17:19:09tarcierihe got a lot of people interested in the whole Rails on EventMachine with Fibers providing concurrent I/O
17:19:23evanI wish I had been, but no.
17:19:28brixenI missed it too :(
17:19:32tarcierirequiring everyone to use EventMachine protocol implementations, then monkeypatching Fiber stuff into it
17:19:35evanwhats the big takeaway?
17:19:43tarcieriumm, my reaction was MADNESS
17:19:45tarcieriheh
17:19:48evanhah
17:19:56tarcieriI mean, that's what I was wanting to do with Revactor
17:19:58tarcierilike 2 years ago
17:20:03tarcierithen I decided it was dumb
17:20:12evanyeah, seems UG to say "lots build our own thread model and our own scheduler and put it on top of a user space thread model"
17:20:40tarcieriyou more or less have to throw away every single library that talks to the network ever and start from scratch
17:20:59tarcierior does any kind of I/O for that matter, and isn't an EventMachine implementation
17:21:05evanyah
17:21:09evansounds fun!
17:21:10evan:/
17:21:14tarcieriand then you have to (monkey)patch every EventMachine implementation
17:21:59tarcieriwith Revactor I was trying to get to something that was a duck type of TCPSocket, so you could monkeypatch non-evented libraries that do synchronous I/O
17:22:13evanwhy did they have to monkeypatch EM itself?
17:22:46tarcierihe had to monkeypatch the EventMachine implementations of various protocols and add the hooks for pausing and resuming fibers when they "block" on I/O
17:22:55evanoh righ
17:22:56evanright
17:23:00evanmake EM fiber aware.
17:23:02tarcierihttp://github.com/igrigorik/em-synchrony
17:23:04tarcieriyeah
17:23:28evanok know, it would be a fun experiment to make an alternate rubinius kernel that implemented MxN threads
17:23:36evansince we have fiber support
17:23:38evanit's doable.
17:24:16tarcieriand like... letting multiple threads share a single I/O scheduler, or what?
17:24:53evanhave a scheduler in ruby, yeah
17:25:06evanand have IO#read and such do fiber switching
17:25:28evanthe actual IO itself could happen entirely in a seperate normal ruby thread
17:25:38tarcieriyeah cool
17:25:47evani think erlang does that, doesn't it?
17:25:50evanmanages all IO in one thread
17:25:57tarcieriyeah
17:26:00tarcieriit has a thread pool
17:26:00evanand other threads request IO operations
17:26:13tarcieriwell, there's a thread that does all I/O that can be made asynchronous
17:26:18tarcieriand a thread pool for synchronous operations
17:26:27evanah
17:26:31evanwhat kind of thinsg are sync?
17:26:42tarcierifile I/O, sendfile, stuff like that
17:26:54evandoes it use sysvipc?? :/
17:26:58evanwe did that a previous job
17:27:02evanworst unix API ever.
17:27:02tarcierihaha no idea
17:27:06tarcierilol
17:27:11evancompletely unpollable.
17:27:12tarcieriyeah I tried to play with it at various points
17:27:27evanthere is literally a standard kludge
17:27:46evanyou put something in a mailbox, then you send the process that should read it a signal
17:27:53evanthe signal writes a byte to a pipe
17:27:59evanthe pipe is in your select
17:28:01evanselect group
17:28:13evanwhen you see the pipe become active, you read from your sysvipc mailbox
17:28:19tarcieriheh yeah
17:28:27tarcierirecalls sigio prior to the days of epoll
17:28:33evanyep.
17:30:54tarcieriwith Rails/EventMachine if anything in the entire event loop blocks or consumes too much CPU you starve every other request
17:31:04tarcieriwhich is why it'd really be nice to solve all that at the VM level
17:31:08tarcierirather than through a library
17:31:20evanyeah
17:32:38tarcierioof
17:32:41tarcieri-> meeting :(
17:39:29evanI should halftone this (http://www.flickr.com/photos/oreillyconf/4687365118/in/set-72157624231740192/) and make it my blog header
17:40:24evankstephens: hi kurt! sorry I didn't end up seeing you after that first day
17:41:01imajesi did not realize jdd was at rc
17:41:22evaninteresting.
17:41:27evan|Blaze||: thanks
17:45:16evanseems similar actually.
17:48:49cremesevan: RE: that picture... are you running for office or something? :)
17:48:59evanha!
17:49:07evanthat was my late night TV show look.
17:49:11evani'll run for office later in life.
17:49:13evani'm working up to it.
17:49:13imajeshe should run for office.
17:49:35cremesevan phoenix... kind of sounds like a super hero's "secret" identity
17:50:37evancremes: SSSSSSSHHHH
17:50:57evani'll confuse the fuck out of the establishment
17:51:09evanWith a name like Evan McClendon Webb Phoenix
17:51:14evanand growing up in Montana
17:51:57brixenhmm EMWP... EventMachine'd Web Programming
17:52:07brixensounds like evan predates ilya's scheme
17:52:21imajesEpic Mechanical Webb Plastering
17:52:46evanhah
17:52:48jeremyevansevan: |Blaze||'s code works for me too
17:53:05evanjeremyevans: which code? works how?
17:53:12evanah ah
17:53:13jeremyevansevan: gcc -Wall -Wl,--export-dynamic -o dlsym_test dlsym_test.c; ./dlsym_test
17:53:13evanthat
17:53:29evaninteresting
17:53:30evanok
17:53:37jeremyevansevan: I'll test modifying the rake task to use those opts
17:53:39evanmust not be.
17:53:46evanjeremyevans: ok.
17:53:58evan|Blaze||: there must be some ELF metadata that says what symbols are exported
17:54:01evanand dlsym() respects that.
17:55:20evanwell
17:55:40evanwe need to also fix the stripping problem
17:56:13evanperhaps I should put those functions in an actual .so
17:56:52evanah!
17:56:57evan -rdynamic
17:56:57evan Pass the flag -export-dynamic to the ELF linker, on targets that
17:56:57evan support it. This instructs the linker to add all symbols, not only
17:56:59evan used ones, to the dynamic symbol table. This option is needed for
17:57:01evan some uses of "dlopen" or to allow obtaining backtraces from within
17:57:03evan a program.
17:57:05evanack.
18:05:18brixenevan: did you discuss cac1547ef1e with dbussink ?
18:05:27brixenI'm not sure I like that
18:05:37evanfeel free to revert
18:05:51evanhe made that change after, in the my rubinius talk, i told them to ignore the [0] entries
18:05:54brixenit's something I use to see if I need to do a full graph
18:06:02brixenyeah, I don't want to ignore them though
18:06:22brixenit just means they are not in the top 45
18:06:26evanhow come?
18:06:37evanwell, no [0] means it's not in the top 45 also :)
18:06:46brixenwhy don't I want to ignore them?
18:07:00brixenyes, [0] means there's no entry in the top 45
18:07:15brixenbut that does not mean I don't want to see them when I'm looking at that output
18:07:17evanand no index listing at all means the same thing
18:07:30brixenI disagree
18:07:36evanok, well if you'd like them, how about something other than [0]
18:07:44jeremyevansevan: success
18:07:46evan[-] perhaps
18:07:51brixenit means there's no entry for them, but you still get to see their contribution
18:07:51evanto say "no index"
18:08:05jeremyevansevan: rubinius 1.0.1 (1.8.7 release 2010-06-03 JI) [amd64-unknown-openbsd4.7]
18:08:10brixen[-] is fine, but I want to see them
18:08:11evanjeremyevans: rad!
18:08:19evanbrixen: ok, lets make it [-] then.
18:08:22brixenwithout having to do the full graph
18:08:59brixenand why they are [0] should have been explained in the profile doc anyway
18:09:04brixenbut I'll make sure it is
18:09:26evanwell, why [-] is there now :)
18:09:56boyscoutFirst cut at call_custom support - 14407d5 - Evan Phoenix
18:09:59evanbrixen: btw.. ^^
18:10:13evanhttp://gist.github.com/434836
18:10:18evanthats my test script
18:11:51brixenwoot!
18:12:42evanobviously Rubinius.bind_call should probably delegate the binding to recv's class
18:12:49evanrather than doing it all itself.
18:13:02evansince you probably want to do different things at different call_custom sites
18:13:23evanbut Rubinius.bind_call is the infection point atm.
18:13:57brixennice
18:16:02evanthe one there is the most complicated one i've written thus far
18:16:19evanwhere the else unit is another test
18:18:43brixenI'll start playing with it tonight
18:19:39evank
18:19:51evantarcieri: if you wanna implement reia on rubinius
18:20:02evantarcieri: i've just added the equiv of invokedynamic to rubinius :)
18:22:47evanyou know you're about to have a fun debugging session when you open badnews.rb
18:23:35boyscoutCI: rubinius: 14407d5 successful: 3441 files, 13543 examples, 41064 expectations, 0 failures, 0 errors
18:24:20brixenheh
18:24:35brixenevan: which ticket is that?
18:24:47evanhttp://github.com/evanphx/rubinius/issues/#issue/356
18:24:54evangoing to see if it's easy to fix.
18:25:01brixenahh that one
18:25:01evanit might be.
18:27:07evanwhen I change the 10m to 1000
18:27:18evanand add a total in the subprocess
18:27:24evanto see how many times the HUP is run
18:27:30evanguess how many?
18:27:51evananyone? anyone?
18:28:25evanif you were to say 2, you'd be right.
18:29:14brixenhmm
18:29:22evani know exactly why too
18:29:37evanMRI keeps the "signals that should be run" as a simple array
18:29:47evanwhen it gets HUP, it does signals_to_run[SIGHUP] = 1;
18:29:52evanin otherwords
18:30:04evanno matter how many HUPs it gets before it runs the handler
18:30:09evanit only runs the handler once.
18:30:12brixenahh ok
18:35:05brixenevan: what do you think of leaving [-] off entirely?
18:35:17evanthats what dbussink's patch does :)
18:35:20brixenif there is a [N], there's an entry; otherwise there is not
18:35:30evanthats what dbussink did :)
18:35:35brixenhm, I misunderstood
18:35:41brixendiffs are hard
18:36:06evanif there is no self entry for a line
18:36:12evanthere is no [0] line
18:36:18evanbecause there is nothing to go reference
18:36:25evanthe contributing line is still there though
18:36:33evanit just doesn't reference anything
18:37:08brixenok, updating the docs
18:38:08brixenI think I'll redo this patch actually
18:38:12brixenit's confusing to me
19:10:06boyscoutReworked profiler graph output change. - d420522 - Brian Ford
19:18:14boyscoutCI: rubinius: d420522 successful: 3441 files, 13543 examples, 41064 expectations, 0 failures, 0 errors
19:22:58boyscoutUpdate profiler docs. - 44e70e2 - Brian Ford
19:31:00boyscoutCI: rubinius: 44e70e2 successful: 3441 files, 13543 examples, 41064 expectations, 0 failures, 0 errors
19:31:49tarcierievan: hahaha
19:32:13tarcierievan: Reia kind of depends on lightweight shared nothing processes that are individually garbage collected
19:32:30tarcieriif you implement some way for threads to have their own independently garbage collected heap that could work
19:33:25brixentarcieri: why is the individually garbage collected important?
19:33:39brixenie, what about Ruby Actors that just don't share state with each other?
19:35:13brixentarcieri: also, we would have SLABs when the gil withers as I understand
19:37:12tarcieribrixen: soft realtime, if that's a design goal
19:37:39tarcieribrixen: with Revactor I thought about duping and freezing all objects you message pass between actors
19:37:51tarcierithat'd sort of accomplish the same thing
19:38:49tarcieriwith separate heaps per process there's no locking contentions across multiple CPUs when allocating memory, except when trying to acquire more system memory
19:40:31brixenslabs should give you no contention when allocating objects
19:40:46tarcieriyeah that's how Erlang does it
19:40:48brixenlarge objects, pinned strings, and overflow allocation would have contention
19:40:59tarcierialthough there's still some locking problems preventing SMP scalability
19:41:11tarcierispecific to their memory allocator
19:41:14brixenoverflow allocation is when nursery is full but the GC hasn't run yet
19:41:44brixenevan: what's pe stand for in the CallUnit code?
19:42:48brixenthinks it's wildly cool that evan implemented the analog to invoke dynamic
19:43:29brixenfinds food
19:43:47slava15:41 < brixen> overflow allocation is when nursery is full but the GC hasn't run yet
19:43:57slavaisn't the point when the nursery gets full precisely when you run GC?
19:44:56tarcieriwell anywho, for starters, getting rid of the GIL would make Reia on Rubinius more useful :)
19:45:20tarcieribut even then I'd rather just play around with actor concepts in Ruby, and you'd probably want me to as well
19:45:45tarcierimaybe help MenTaLguY merge some of his work from Omnibus into the current Rubinius Actors
19:46:19brixenslava: gc doesn't run immediately when nursery is full
19:46:30slavawhy not?
19:46:54brixenbecause it runs when everything is in a certain state
19:47:01slavaweird
19:47:08brixenI'm not totally clear on all the details
19:47:14brixenbut evan will enlighten us :)
19:47:27brixenbasically, it says "collect soon"
19:47:41brixenand then that event is processed at a certain point
19:48:10brixentarcieri: I'd really love to get our Actors some love
19:48:26brixenand with Fibers now and possibly M:N, we should be able to do some cool stuff
19:49:13brixentarcieri: also, getting rid of the GIL is reasonably on the roadmap now
19:49:50brixenquits looking at evan's callunit commit and really finds food :)
20:24:07evanback
20:24:19evanthe nursery actually uses a redzone to find out when to collect
20:24:43evani want to change it soon so that Class#allocate can actually run the GC if it wants
20:32:25brixenevan: so, what is the reason for the current setup?
20:33:06evanallows allocations to occur in code that hold references the GC can't see
20:33:15brixenahh ok
20:33:29evanwe could get rid of that requirement by moving to a Handle<> scheme
20:33:46evanbut the current setup keeps things simple
20:33:51evanand it's really no big deal thus far
20:33:55brixenI see
20:34:16evanif i have 2 seperate allocation paths
20:34:30evanan internal one that never GCs, and one used by Class#allocate that can GC
20:34:41evanthat would likely deal with any potential issues with the current setup
20:34:51brixenmakes sense
20:34:54evansince I introduce a redzone into the nursery allocator, it's been fine.
20:35:21brixenare you thinking about attacking the gil soon?
20:35:26brixenor sooner now
20:35:32evani'll probably do some spikes and experiments
20:35:38brixencool
20:35:40evanit's going to take us some time
20:35:45brixenyeah
20:36:45evani've changed a few things in the GC since the last time I played with making allocation thread safe
20:36:50evanthat will simplify it
20:36:55brixennice
20:36:58evanlike removing find_lost_souls
20:37:05brixenwhat does pe stand for in the callunit code?
20:37:08evanthat means that there can be a lock to aquire a chunk of the nursery
20:37:15evanand then a thread can use that chunk/slab unlocked
20:37:20evanand when it's full, ask for a new one
20:37:28brixencool
20:37:42evancouldn't do that before because find_lost_souls required the nursery to be laid out perfectly packed
20:37:49brixenright
20:38:07evani don't recall what pe stands for :)
20:38:12brixenheh
20:38:22brixencool, then I don't feel so bad for not being able to guess it
20:38:26evanha
20:38:49brixenpointer to executeish
20:38:52evani've got part 1 of the signal fix done
20:38:57brixensweet
20:39:03evani'm using the same scheme as MRI
20:39:11evanie, tracking a signal as a 1 or 0 only
20:39:27evanbut i've hit the bug related to waking a thread again.
20:39:28brixenyeah, seems reasonable
20:39:31evanso i have to really fix it now.
20:39:40brixenmm fun
20:39:56evanI might have to use a helper pthread
20:40:48brixenahh yes, when a problem is a blocker, use another level of indirection
20:40:53brixenor in this case, another thread
20:40:57evan:)
20:41:06evanwell, i need to delay doing anything because of the signal
20:41:10evanbut i can't delay it to just anytime
20:41:30evanbecause i need to get the thing that might be about to sleep to wake up
20:41:56evanso i'll use the old pipe + select trick to get another thread to do the actual work outside of the signal handler
20:42:17brixenman, threads are just so crazy
20:42:26evanyep!
20:42:38evansignals + threads == bad news.
20:42:45evanis the big takeaway
20:42:48brixenyeah
20:42:56BrianRice-worknods
20:42:56evanbecause all the prims for working with thread syncronization aren't signal safe.
20:42:57evan:/
20:43:04evanall == all the useful ones.
20:49:40gavinstarkIf I think I've found a behavior difference between MRI 1.8.7 and Rubinius 1.0.1 what is the best way to proceed? Add a spec to RubySpec to demonstrate the difference and then submit a patch to Rubinius?
20:49:57evangavinstark: sure
20:50:01evangavinstark: off hand, whats the behavior?
20:50:21gavinstarkDir.entries(path) seems to call "to_str" for the supplied object while Rubinius does not.
20:50:34evanok
20:50:40evanyeah, rubyspec and rubinius patch
20:50:42gavinstarkFor example: Dir.entries when supplied a Rails path object gives a Dir#open primitive fail.
20:50:44evanthe rubinius patch is one line
20:50:53evanjust add a call to StringValue()
20:52:59gavinstarkevan: Thanks, I think the change should be in Dir#open but I'll do some more testing first.
20:53:09evanok
20:53:15evanlet us know if we can help.
20:53:51gavinstarkevan: also, is there some docs that describe the best way to run the rubyspecs against multiple implementations? I tried following the instructions for the rubyspec gem but when running the "mspec" there with rbx selected from rvm it does nothing.
20:54:17evanwell, i'm not sure about rvm wise
20:54:22evanmspec predates rvm
20:54:25evanwe have our own mechanism
20:54:28evanthe -t option
20:54:41evanwhich specifies either a patch or a canonical name
20:54:54evanlike -tr will run the specs against "ruby", ie, whatever is in your patch
20:54:56evanif you use rvm
20:54:59evanuse -tr
20:55:03evanafter you switch
20:55:22evanit probably did nothing for you because rvm has confused mspec
20:55:30evanby default, mspec looks for rbx to run them against
20:55:38evanbut rvm advertises rubinius as ruby
20:57:19evangavinstark: make sense?
20:57:31gavinstarkevan: I think so.
20:57:39gavinstarkI was trying to follow the README in rubyspec git clone but supplying the path to the rvm installed ruby via -t, but that failed for me.
20:58:06evanshow me
20:58:09gavinstarkWas trying to see how I'd add a spec in the rubyspec repo and see results in MRI, JRuby, rbx, etc.
20:58:15evanwhat command exactly did you use.
20:58:23gavinstarkSo it says first to clone mspec, add it to your path
20:58:29evanyou'll have to tell rvm to switch between interpreters to do that
20:58:33gavinstarkthen I can just run "mspec"
20:58:36evanmspec won't do it automatically
20:58:40evanwhere?
20:58:43evanwhat says this?
20:59:00gavinstarkstandby.
20:59:26gavinstarkhttp://github.com/rubyspec/rubyspec/blob/master/README.markdown
20:59:46gavinstarkUnder "Running RubySpec"
21:00:12evanyou ran mspec under a rubyspec clone, yes?
21:00:17gavinstarkYes.
21:00:19evanok
21:00:24evanshow me what you mean by "nothing happened"
21:00:29wayneeseguinrvm 1.8.7,1.9.2,rbx ruby -S mspec # maybe?
21:00:32wayneeseguinshuts up
21:00:34evanpaste in your terminal output
21:00:47evanwayneeseguin: we'll get to that
21:01:10evanwe're going over the basics first
21:01:36gavinstarkIf I have mri 1.8.7 as my ruby:
21:01:42gavinstark$ mspec
21:01:42gavinstarkruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.3.0]
21:01:42gavinstark............................................................
21:01:50evanlooks fine to me
21:01:59evani assume there are a lot more dots
21:02:00evanalso
21:02:03evanplease use a gist
21:02:34gavinstarkVia rvm use rbx: http://gist.github.com/435050
21:03:44evangavinstark: you're in a rubyspec checkout, yes?
21:03:52gavinstarkevan: Yes
21:04:06evanhonestly don't know
21:04:08evanbrixen will know.
21:04:11gavinstarkWith a path set so that mspec is first in path (mspec is also via git checkout)
21:04:26evanrvm must be confusing mspec somehow.
21:04:37evanwayneeseguin: for irb under rvm btw
21:04:51evanwayneeseguin: you should use rbx -S irb, rather than just rbx
21:04:55evani told you just rbx, but i was wrong
21:05:02evanbecause I forgot that people want to pass options to it
21:05:17evanrbx -S irb will let them pass irb options directly
21:06:53gavinstarkevan: BTW, same result with mspec when rvm has jruby-1.5.0 active.
21:07:19gavinstarkPerhaps I'll go spellunking and see if I can figure this out.
21:07:23evanok, so it happens to work under 1.8.7
21:07:29evanbut everywhere else, mspec is confused.
21:07:33evanplease do.
21:07:37gavinstarkevan: seems that way.
21:08:57evantake a peak
21:09:02evanit's probably something easy.
21:16:22brixengavinstark: mspec is a front script, it invokes another script that does the work
21:16:28gavinstarkevan: Yup, easy, I think.
21:16:41brixengavinstark: if you are going to invoke it directly, you should do ruby -S mspec-run
21:16:48brixenwhere ruby is something rvm has installed
21:16:56gavinstarkbrixen: Yes, it seems mspec in the rubyspec directory, when using rbx from rvm, is expecting a file: rbx.1.8.mspec to setup the environment.
21:17:25brixenI'm not sure that matters
21:17:34brixenare you getting some error?
21:17:52gavinstarkbrixen: no, I'll provide gist.
21:18:01brixenwell, I see the gist
21:18:05brixenit needs some files to run
21:18:11brixenthat's not an error ;)
21:18:19evanbrixen: under 1.8.7, just "mspec" runs the current directory
21:18:24evanbrixen: and the docs say that no arguments is ok
21:18:29evanor rather, they imply that.
21:18:45brixenyeah, I let someone else modify those docs :/
21:18:49brixenI need to rewrite them
21:19:01evanthe confusion comes from 1.8.7 not printing the help
21:19:05evanbut instead running some stuff
21:19:14gavinstarkright.
21:19:15evanunlike the other interps
21:19:31brixenthere is a default for MRI
21:19:39brixenthat is documented as well
21:19:41gavinstarkI can get tests to run if:
21:20:06gavinstarkcp ruby.1.8.mspec rbx.1.8.mspec
21:20:14gavinstarkthen mspec will generate output.
21:20:30evangavinstark: the true use case for mspec is not the no arg one
21:20:34evanyou specify what specs you want to run
21:20:39evanie
21:20:43evanmspec spec/ruby
21:20:55evanthats the way you should be running it anyway
21:21:04evanand will certainly be the way you run it when writing a new spec
21:21:07brixengavinstark: do not copy that file, use -B <config file>
21:21:14brixenit is a default for *MRI*
21:21:40brixenthe way to run the specs is to do mspec -t <target> <files>
21:21:47brixenMRI has a special default
21:21:59brixenthat is not necessarily intended to work with other impl
21:23:01brixengavinstark: http://rubyspec.org/wiki/mspec/Mspec
21:24:57gavinstarkbrixen: OK, I'll give that a try. I guess what I'm trying to figure out is if I think there is a diff the behavior of somethink, like say Dir#open in this case, what is the most sane path to specing that, then running it in the different impls to see which follows what I'd state is the desired result? I thought it would be to put the spec in Rubyspec and run it with the different impls. rvm seems to be a good way to help with tha
21:25:26brixengavinstark: the use case for rubyspec is: write a spec that passes on MRI
21:25:32brixenthat's step 1
21:25:38brixenand rubyspec is set up to do that
21:25:42brixenthat's pretty much it
21:25:50brixeneach impl has their own way of using rubyspecs
21:26:02gavinstarkbrixen: Aha, thats what I think I am missing.
21:26:10brixenin rbx, you clone rubinius and run bin/mspec path/to/spec
21:26:18brixenin jruby, you do something similar
21:26:20evangavinstark: yes, most people don't run the rubyspec repo directly
21:26:27evangavinstark: they run it out of a projects directory
21:26:34brixenhowever, mspec can invoke the worker scripts with a specific target
21:26:35evanwhere the project has customized rubyspec to run it that project
21:26:42brixenspecified with the -t option
21:27:02brixenyou can use that, but you need to specify the options
21:27:12brixenthe defaults in rubyspec are for MRI
21:28:08brixengavinstark: step 2 is to check a particular impl, and (as indicated) how to do that best depends
21:28:29brixenI'd say, ruby -S mspec-run path/to/spec is probably going to be the best with rvm
21:28:43wayneeseguinevan: Noted, thanks.
21:30:50brixengavinstark: in rbx, see doc/howto/write_a_ruby_spec.txt and the 2 files that doc references
21:31:06brixengavinstark: that's the easiest way to do it here
21:31:16brixenjruby, etc probably have their own easiest way
21:31:19evangavinstark: the typical way, thats perfectly fine, to write a spec when working on rubinius is to do it in the rubinius project clone dir
21:31:34evangavinstark: use bin/mspec -tr <spec file> to test it under MRI
21:31:40evanthen remove the -tr to test under rbx
21:31:47gavinstarkevan: ok.
21:31:49evanyour job is pretty much done after that, spec wise.
21:31:52gavinstarkbrixen: ok
21:31:59evanyou've documented a behavior on MRI
21:32:09evanwhether or not other impls do it is their business
21:32:15gavinstarkevan: So if I add the spec to rubinius clone, and submit, you guys will push to rubyspec?
21:32:22evanyes
21:32:32evanbut you must do the commit to the spec/ dir in a seperate commit from anything else
21:32:35evanthat allows us to merge them easier.
21:33:50gavinstarkevan / brixen : Will give it a try. Thanks for the input/patience.
21:33:56evangavinstark: no prob.
21:34:04evanthe process I just told you is the process I use.
21:34:21brixenand is the process documented at doc/howto/write_a_ruby_spec.txt :)
21:34:35evanyes.
21:35:57evanI wonder what it's like getting a test into the JVM
21:36:03brixenthat said, this is quite the cluster cuss: rubini.us has docs, rbx /doc dir, rubyspec README, rubyspec.org...
21:36:14evanyeah
21:36:19evanwe need to put it all in one place.
21:36:39brixenyeah, I need to get rubyspec.org off of redmine and into a git repo
21:38:40gavinstarkbrixen: Yes, agreed about varying docs. Having followed along at the periphery, I kind of assumed that rubyspec would be the diffinitive source of "put your new specs" here. Thats why I tried getting them to run there first. If the theory is that each impl has its own way to run them, perhaps the README there should be patched to say so and provide a link for each known impl to the appropriate project readme?
21:39:20brixengavinstark: well, I'm not going to maintain a list to all the impl, but I'll clarify the docs
21:39:43brixenthe reason rubyspec doesn't have a .mspec file for every impl is that's not its role
21:39:57brixenrubyspec documents "Ruby", which means MRI
21:40:14evanyes
21:40:18evanwhen someone uses the rubyspec repo raw
21:40:28evan99.999% of the time, it's because they want to run it only under MRI
21:40:38evanto flesh out missing specs
21:40:51evanhow/if the other users of rubyspec handle those new specs is their business
21:41:01evanand thats where the business of getting a spec to pass under rbx comes into play
21:41:08evanwhich can be a seperate topic
21:42:14brixenthere is also a growing pain where "ruby" always meant MRI and now, with rvm, it could mean any number of different impls
21:42:28evanyes
21:42:45brixenpeople have to stop thinking and writing scrips that assume invoking "ruby" is invoking MRI
21:43:02brixenexcept that we've made the convention that RUBY_ENGINE == "ruby" means MRI
21:45:49jeremyevansevan: Rubinius passes almost all of Sequel's specs. There's just one type of spec it doesn't pass, due to a bug in Rubinius: http://pastie.org/1001334.txt
21:46:13evan:/
21:46:17evani fucking hate block spalt.
21:46:21evansplat.
21:46:39jeremyevansevan: There are also some warnings when loading the openssl extension: http://pastie.org/1001340.txt
21:47:02evanzoinks btw is that about...
21:47:07evaner. wtf.
21:47:13evanthats not good at all.
21:47:26evanwhat OS are you on?
21:48:12jeremyevansevan: Still on OpenBSD. openssl version gives OpenSSL 0.9.8k 25 Mar 2009
21:48:22evanoh right, der.
21:48:33evani've been dealing with threads and signals all day now
21:48:37evanit's turning my brain to mush.
21:49:43jeremyevansevan: I love the rubinius backtraces, BTW
21:49:46evan:D
21:50:14brixenjeremyevans: that's great to hear, b/c we do too! :)
21:50:19evanjeremyevans: i'll have to get that openbsd vm up and going to figure out whats up with openssl
21:50:35evanperhaps those symbols are only in openssl 1.0+ or something
21:51:02evanthough i've used it with 0.9.8 i think and not seen those
21:51:04evanso i'll have to repro it.
21:54:58evanjeremyevans: that block splat problem is fixable, but man MRI is so fucking inconsistent
21:55:37evanif you do "[[1,2]].each { |b, *c| p [b, c] }"
21:55:42evanyou get something completely different
21:58:25jeremyevansevan: Yeah. Sucks to be a ruby implementer :)
21:58:32brixenhah
21:58:40evansucks to be a ruby user actually
21:58:45brixenimagines jeremyevans playing sad trombone there
21:58:48evanwith random inconsistencies.
21:58:57brixenyes, splat is so wack in 1.8
21:59:17evanthere is no good reason for |b, *c| to mean muliple things.
21:59:50evanpeople say "the block is invoked with [1,2]" as a way to describe the each above, as though thats the same as doing Proc#call
21:59:52evanbut it's not.
21:59:57evanwhich is just silly.
22:00:06evanjeremyevans: why/where did sequel hit this?
22:00:19jeremyevansevan: I agree. [[1,2]].each { |(b, *c)| p [b, c] } should be required if you want the 1.8 behavior
22:00:59jeremyevansevan: removing an object from an association given an array of composite primary keys
22:03:04evanjeremyevans: could you show me the code that failed?
22:03:23jeremyevansevan: OK. Let me pastie the code and the backtrace
22:03:28evanthanks.
22:07:10jeremyevansevan: http://pastie.org/1001365.txt If you need more context, let me know.
22:09:05evanok
22:09:06evanthanks.
22:13:04slavahi evan
22:13:10evanhi slava.
22:13:48slavaevan: I'm changing my VM to support GC roots inside call stack frames
22:14:03evani thought it supported that
22:14:04slavainstead of being forced to spill values to the operand stack between calls
22:14:09evanah
22:14:11slavait does on the C++ side
22:14:11evancool
22:14:15slavawith data_root<>
22:14:25slavajust like your OnStack<>. but this is different, its for compiled code
22:14:33evanyep yep
22:14:43evanyou making a map of stack locations?
22:14:54slavaso one problem with the 'shadow stack' approach to GC roots is you can get a quadratic blowup in the number of virtual registers in your IR
22:15:10slavaif you have 10 live values and 10 call sites, that's 100 load/stores or so potentially right?
22:15:36evanyeah
22:15:44evanthat's worst case
22:17:20slavayes, so now every code block has a return address -> stack locations map
22:17:40wayneeseguinevan: I'm still in family time but, If there is anything I can do to help let me know. I will be making that irb change for sure.
22:17:55evanwayneeseguin: will do
22:18:00evanwayneeseguin: I think thats the only thing
22:18:49slava< evan> allows allocations to occur in code that hold references the GC can't see
22:19:00slavaevan: isn't OnStack<> intended to handle these cases?
22:19:06evanyes
22:19:08slavawhat remaining situations does rbx have where it doesn't know all roots?
22:19:40evanstate->new_object<> isn't a GC point
22:19:53evanso OnStack<> is used when C++ is calling back into ruby only atm.
22:19:58slavaoh I see
22:20:03slavaso you'd have to add OnStack<> in a bunch more places
22:20:10evanbut it's certainly possible to make new_object a GC point and then we'd need to use OnStack<> a lot more places.
22:20:14evanright
22:20:19slavathat's what I do
22:20:27slavalots and lots of gc roots everywhere because of this
22:20:51evanyeah
22:21:09evani'm just using the redzone to deal with mostly
22:21:15slavaI used to have that
22:21:35slavaoriginally the design was that allocations would trigger a GC on the next iteration of the interpreter loop
22:22:45slavaand since each primitive could only allocate a bounded amount, a red zone was sufficient
22:22:58evanyeah
22:22:59slavabut adding a compiler kind of ruined that
22:23:07evanyeah
22:23:14evanalso, it makes the allocation heavier
22:23:22slavayou need a conditional branch in there
22:23:26evanyea
22:23:38slavamy optimizer combines the gc checks for multiple allocations within a single basic block
22:23:53slavaso the allocation itself is just a pointer bump compiled inline
22:25:56slavaevan: I noticed you added fixnum intrinsics recently
22:25:58slavathat's cool
22:26:18evani added them long ago :)
22:26:20evanyou just noticed.
22:26:23slavaoh
22:26:40slavagoing to do floats soon?
22:27:10slavaif you break float operations down as box(op(unbox(in1),unbox(in2))), then LLVM's GVN might be able to optimize unbox(box(x)) into x
22:27:11jeremyevansevan: I've submitted a rubinius 1.0.1 port for inclusion in OpenBSD: http://marc.info/?l=openbsd-ports&m=127629497628997&w=2
22:27:49evanslava: i've done that experiment
22:27:53evani need to do a little bit more
22:27:58evanGVN can't fully do it.
22:28:16slavaI don't have GVN, I do float unboxing in a specialized pass for that purpose
22:28:34evanjeremyevans: wonderful!
22:28:38slavabut it seems like the kind of thing you'd want GVN to do
22:29:10evani'm going to look at the code again this summer
22:29:18evani'll let ya know what I find
22:29:55slavaevan: can LLVM combine multiple reads of an ivar with no interviening writes or subroutine calls into a single read?
22:30:08slavaor is an ivar access too heavyweight at the IR level for it to see that
22:30:28evanatm, ivar access is opaque
22:30:34slavadead load elimination can be used to unbox stuff too
22:30:43evanwhen I have packed ivars, it possible to expose it
22:30:47evanbut that has to be guarded
22:30:53evanbecause the type of self is not fixed.
22:30:53slavalike in the mandelbrot benchmark, your loop will probably be making complex number objects and then taking them apart right away
22:31:29slavabut even if an ivar access is a C function call, I think you can annotate it a certain way so that alias analysis and GVN treats it like a load
22:32:02slavaI'm pretty sure LLVM constant-folds calls to libc functions such as sin() and cos()
22:32:02evanyeah, i likely can.
22:32:12slavaso it can operate on calls like that
22:32:15evanit's not as pure as sin() though
22:32:21evansince it depends on GC semantics
22:32:32evanread_ivar(1); call(..); read_ivar(1);
22:32:35slavaright, so alias analysis has to convince itself that a given transformation is safe
22:32:42evanyeah
22:32:44evani've started to do that
22:32:51evansince i've got a custom AA pass with LLVM
22:32:54slavacall() would need to kill all collected info
22:33:48evanyeah
22:33:51evanthats all possible.
22:34:01evanjust have to annotate and explain to LLVM the right semantics.
22:34:37slavaI like how LLVM is pretty flexible
22:35:19slavaits also interesting how analyses such as def-use and liveness are implemented with data structures that mirror the IR and are always up to date
22:35:26slavainstead of having separate passes that compile this info
22:35:37slavawhich potentially becomes out of date as soon as you change the operands of an instruction
22:35:44evanyeah
22:35:46evanthats really nice.
22:35:57slavaI think any pass can ask GVN if two values are congruent, or ask AA if two values may/must-alias
22:35:59evansince i've written some stuff that does IR replacement
22:36:16evanand it's easy to check the use's of a value to figure out if there is a context you can specialize
22:36:27evanslava: yeah, thats right.
22:36:29slavahotspot has a similar design, all IR manipulation is encapsulated in a set of routines that keep a bunch of related info up to date
22:36:32evanthere is a standard API to AA
22:36:53evanyou can call llvm::DoesAlias() or something
22:36:58evanon 2 Value's
22:37:21evanall right
22:37:27evani'm headed to chicago tonight
22:37:33evangotta grab a few things
22:37:39evansee ya guys.
22:38:40slavalater