Index

Show enters and exits. Hide enters and exits.

00:21:31evanDefiler: "It's fast! Finalyfast.com!"
00:23:51brixenevan: where are we using libltdl?
00:23:58evanwe're not.
00:24:04brixencan I remove it?
00:24:05evanreferences to it are wrong.
00:24:14brixenI could find no use of it
00:24:16evanis it still in external_libs?
00:24:19brixenyep
00:24:21evannuke it.
00:24:23brixenk
00:28:23boyscoutRemove unused libltdl. - 24691cb - Brian Ford
00:36:42Defilerfinallyfast has detected the presence of 'libtldl'
00:37:09brixenDefiler: ha ha :)
00:37:46boyscoutCI: rubinius: 24691cb successful: 3511 files, 15076 examples, 42901 expectations, 0 failures, 0 errors
00:38:56DefilerI got myself a cool colo server and I'm waiting for it to get installed aaah
00:38:58Defileragonizing
00:42:44brixenDefiler: you should have just gone with 10TB, I hear they are great :)
00:43:04DefilerI did actually heh
00:43:09brixenhah
00:43:28brixenyou saw zed's ticket?
00:43:35Defilernope
00:43:58brixenhttp://twitter.com/zedshaw/status/20663785704
00:44:16brixenfollowed not long after with http://twitter.com/zedshaw/status/20667124260
00:44:34Defilerhaha
00:44:46Defilerwell, I went with the dedicated option so hopefully it will go better
00:44:50DefilerI don't intend to use their software
00:45:26brixenalso, this is pretty interesting http://twitter.com/acangiano/status/20656752154
00:45:45Defilerhaha that is a sick title page
00:46:17DefilerIt should have a little legend showing the scale of 'my balls' and 'the earth'
00:46:28brixenhaha
07:24:46boyscoutRemove references to libldtl in build process - 1856e25 - Dirkjan Bussink
07:24:51dbussinkbrixen: ;)
07:34:08boyscoutCI: rubinius: 1856e25 successful: 3511 files, 15076 examples, 42901 expectations, 0 failures, 0 errors
07:54:42dbussinkpostmodern: do you still have that process kill spec issue? because i had it too but properly cleaning fixed it
07:55:04postmoderndbussink, let me check
07:55:11postmoderndbussink, saw some commits on Process
07:55:39dbussinkpostmodern: yeah, they are because the error was handled incorrectly
07:55:47dbussinkbut the error itself should have been fixed some time ago
07:57:29postmodernmake: *** No rule to make target `ruby.h', needed by `ossl_x509crl.o'. Stop.
07:57:35postmodernum, i might have foobared my system?
08:01:59dbussinkpostmodern: do you still have an rvm ruby active?
08:02:54postmoderndbussink, yeah i still have 1.9.2-rc2 installed, i just installed 1.9.2-head
08:03:00postmoderndbussink, not sure what happened
08:03:10dbussinkpostmodern: please do an rvm use system before trying to build rbx
08:03:21dbussinkbecause otherwise GEM_PATH's can mix up things and point to the wrong gems etc.
08:04:27postmoderndbussink, i don't have a system ruby :P
08:04:52dbussinkpostmodern: hmm, that would be tricky
08:04:52postmoderndbussink, let me start with a clean shell
08:05:16dbussinksince rvm versions setup stuff like GEM_PATH which rubinius of course picks up
08:07:52postmoderndbussink, ok re-configured rubinius and now it's compiling
08:10:27postmoderndbussink, ah yeah idk, something is messed up
08:36:34dbussinkpostmodern: does it work now?
08:37:02postmodernit's failing in /home/hal/src/misc/rubinius/lib/ext/nkf
08:38:01postmoderndbussink, im guessing because i did a rvm update --head, something broke
08:38:13postmoderndbussink, and rubinius cannot find the include directory for ruby.h
08:39:32dbussinkpostmodern: well, building rbx always breaks for me if i have an rvm ruby active
08:39:46dbussinkpostmodern: i always make sure i do an rvm use system before
08:39:46postmoderndbussink, interesting
08:39:55postmoderndbussink, i've been building rbx under 1.9.2 for a while now
08:40:11dbussinkpostmodern: well, 1.9.2 is fine, but an rvm version active is what's problematic
08:40:16krainboltgreeneAhoy.
08:41:30dbussinkkrainboltgreene: morning
08:47:34dbussinkpostmodern: just tried building with an rvm version active, it segfaulted pretty hard
08:48:05krainboltgreeneMorning.
08:49:08dbussinkpostmodern: because it compiled the melbourne extensions against my system ruby and tries to load that extension in the MRI version
08:49:13dbussinkrvm version i mean
09:08:04postmoderndbussink, ok successfully rebuild
09:08:06postmodern*rebuilt
09:08:20postmoderndbussink, and now 11 failures on Process.wait related methods
09:08:31dbussinkpostmodern: can you gist them?
09:09:31postmoderndbussink, http://pastebin.com/DQaBm3Su
09:10:03dbussinkpostmodern: could you try running this script in gdb? https://gist.github.com/c1373c1f0d4911e3ac71
09:11:29postmoderndbussink, http://pastebin.com/Pu20hQHK
09:11:52krainboltgreeneThis is bullcrap. Conan The Destroy is on Instant Netflix, but not Conan The Barbarian? Someone will pay.
09:11:53dbussinkpostmodern: not in irb, in gdb :)
09:12:03postmoderndbussink, that was gdb bin/rbx
09:12:30dbussinkpostmodern: well, i see irb prompts there, could you try with just running it as a script?
09:12:39dbussinkpostmodern: gdb --args ./bin/rbx script.rb
09:16:48postmoderndbussink, http://pastebin.com/UVdhXiW1
09:17:10dbussinkpostmodern: can you also include the backtrace?
09:17:57postmoderndbussink, http://pastebin.com/PsJWGeNq
09:18:17dbussinkpostmodern: looks like libffi wasn't rebuilt properly
09:18:22dbussinkin vm/external_libs/libffi
09:18:34postmodernrake distclean ?
09:18:37dbussinkyeah
09:18:43dbussinkor perhaps try a new clone?
09:20:04dbussinkkrainboltgreene: apparently they don't want you to pay ;)
09:20:27dbussinkpostmodern: i had this exact same issue, was fixed with a distclean
09:22:09krainboltgreeneI donno, Conan just punched a horse in the face. I'm pretty placated.
09:25:19postmodernpoor horse!
09:28:39krainboltgreeneThat horse was a dick. You could see it in the eyes.
09:29:50krainboltgreeneAnd now he punched a camel. Jesus.
09:41:37postmoderndbussink, hmm looks like i need a new clone
09:50:17postmodernok done for the night
13:46:53kronos_vanoVery intresting http://www.hokstad.com/compiler :)
16:49:22evanmorning boys.
16:56:38brixenmorning
16:57:36blowmagehowdy
16:58:55dbussinkmorning
17:00:16evanso, one thing i've started pondering is the Rubinius Memory Model
17:00:34evanbasically, if we're truely concurrent, we're going to have to define some rules for how changes are seen by other threads
17:01:20evanone thing i'm considering adding as the ability to say that all ivars in a class are volatile
17:02:34evancalling it volatile isn't probably the best word, but thats what java 5 calls it
17:02:38evanand it's the same semantics
17:02:55evanbasically, when you read or write to a volatile ivar, the system will introduce a memory barrier
17:03:06evanwhich makes sure that the data is flushed from the cpu's cache to main memory
17:03:08brixenyeah, can we define volatile?
17:03:16brixenI'm looking at http://www.javamex.com/tutorials/synchronization_volatile.shtml
17:03:17JamesKiltonC++ already has volitile
17:03:21JamesKiltonvolatile*
17:03:24evanJamesKilton: COMPLETELY different.
17:03:26evan100% different.
17:03:29JamesKiltonYeah I realize
17:03:30dbussinkbrixen: hehe, me too :)
17:03:31JamesKiltonbut it could be confusing
17:03:34evanyeah
17:03:49evani'm not going to use the word volatile, just establishing the cannon.
17:04:08brixenwho else uses a word that means what we want it to mean?
17:04:16brixenwe definitely need a word
17:04:23evansynchronized ivars
17:04:26JamesKiltonso write-barrier protected ivars
17:04:26brixenok
17:04:40evanactually, synchronized references is a better term.
17:04:41brixenwrite-barrier doesn't sound right
17:04:43brixenyes
17:04:43dbussinkevan: where do you want to use theM
17:04:56evanbecause it defines that the thing being controlled is the reference, not the thing referenced.
17:05:19evandbussink: well, you'd do
17:05:35evanclass Thing; Rubinius.synchronized_ivars(self); ...; end
17:05:41evanor something like that.
17:05:55evanall instances of Thing would would have syncronized references then.
17:06:35dbussinkevan: do you already have a use case right now in hydra for example?
17:06:39evan|Blaze|: lets talk about that later.
17:06:51evan|Blaze|: short answer: more on startup, less over time.
17:07:00evandbussink: yes, the Mutex class.
17:07:12evani want the @owner ivar to be volatile/synchronized
17:07:41dbussink|Blaze|: this has some rought numbers that might give you an idea: http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/
17:08:34dbussinkevan: ah ok, so that being transfered is not missed
17:10:36evanyeah, so
17:10:55evanthe memory model should be defined
17:11:35brixenevan: so, explicitly marking ivars as synchronized is required? or it will be the default?
17:11:42brixenfor ivars
17:11:45evanbut we need to also have something thats easier to understand than explanations that use phrases like "memory barrier"
17:11:54evanwell, thats another good question.
17:12:16evanmaking all ivars synchronized is probably too expensive
17:12:25evanbasically, we'd be fighting the L1 cache.
17:13:10brixenyeah
17:14:14brixenI think "sychronized reference" is good
17:14:15evanthe easier answer is going to be "use locking mechanisms to protect shared references and data"
17:14:20evanMutex, etc.
17:14:32evanthose imply memory barriers (since they're protecting data)
17:15:09evanbut there will be a class of people interested in how the whole model is.
17:15:17brixenyeah
17:16:06brixenso, an "object" has synchronized references? ie, all ivars are synchronized if you tag the object, not a specific ivar?
17:16:56evanyes
17:17:00evanthat seemed easier.
17:17:06evanit's easier to implement too.
17:17:12evaneasier to understand, easier to implement
17:17:13brixenthis is a good example IMO of "synchronized" vs atomic update in a real use case
17:17:16brixenhttp://www.javamex.com/tutorials/synchronization_concurrency_7_atomic_updaters.shtml
17:17:22evanyep.
17:17:25evani read that yesterday
17:17:28brixenok
17:17:35brixenso, this should be fairly easy to explain
17:18:13sbryantmorning
17:18:18brixenhi sbryant
17:18:27evanwe can, and will likely have, an atomic updater also.
17:18:33brixensure
17:18:40evanit's basically just CAS.
17:18:55evanbtw, this all fits in very will with autopacked ivars.
17:19:27evanbecause it's much easier to keep the body of an object syncronized and find the address of an ivar when it's packed than when it's using a LookupTable
17:19:39brixenyeah, that makes sense
17:20:03evanvery well, rather.
17:29:36jrwhey guys, I found a typo in the docs. (contributing.txt) line 15 it says 'it', I think it should say 'is'
17:30:48brixenjrw: yep, thanks
17:32:04boyscoutFixed typo in doc/contributing reported by jrw. - 725c432 - Brian Ford
17:41:32boyscoutCI: rubinius: 725c432 successful: 3511 files, 15076 examples, 42901 expectations, 0 failures, 0 errors
17:45:03evanso, atm, i've got Rubinius.memory_barrie
17:45:07evanmemory_barrier
17:45:22evanto do this whole synchonized references thing manually
17:46:08brixenso, are you adding a header flag for the object?
17:46:43evanto say that ivar references are synchronized? probably just use the class
17:46:47evani'll have a flag there
17:46:50brixenok
17:47:17evanif(self->reference_class()->synchronized_references()) atomic::memory_barrier();
17:47:22evanthats 100% of the functionality.
17:47:28DefilerCool
17:47:44brixenso Rubinius.synchronized_reference(X), where X is a class?
17:48:09evanbrixen: yep, though thats a little confusing because the method doesn't say it effects ivars
17:48:10evanbut yeah.
17:48:15brixenok
18:00:15evanoh, MRI
18:00:17evanmega fail.
18:00:31evanthey introduce fastthread (ie, thread.c) at some point in 1.8.7
18:00:42evanand it's Mutex has slightly different semantics that Mutex in thread.rb
18:00:46evan:/
18:04:13Defilerfastthread was so completely the wrong fix :(
18:05:12dbussinkevan: wouldn't making it references instead of reference indicate that better?
18:05:24dbussinkevan: in the method name that is
18:05:26evanhuh?
18:05:30evanoh
18:05:31evanmmm
18:05:32evanmaybe.
18:05:35evani'll thinking about it
18:05:43evanI just wanted to get you guys thinking :)
18:05:56evanwell, i'm off to lunch.
18:06:08blowmageevan: i understand matz is committed to remove the gil in 2.0. any word on what they are doing for that memory model?
18:06:09brixengreat, now I'm hungry
18:08:57sbryantI just had lunch
18:09:08dbussinki already had dinner
18:09:09evanblowmage: really? where did you hear that?
18:09:16evan(i'm putting my shoes on)
18:09:38blowmagehe gave a presentation at some regional conference ~ a month ago
18:09:48blowmagein his slides he said they were removing he gil for 2.0
18:09:51evani'd heard just the opposite.
18:10:00evani'd love to see those slides
18:10:15blowmagei'll see if i can find it then
18:10:20evank
18:10:28blowmagehave a good lunch
18:10:29evani'm off to lunch, but just paste the url in here.
18:10:29sbryantinconceivable!
18:14:37brixenhi graaff
18:15:03graaffbrixen: hi
18:15:24Defilerblowmage: Is it this one? http://www.slideshare.net/ThoughtWorks0ffshore/matz-3534905
18:15:29brixengraaff: how goes the gentoo packaging? need anything from us?
18:15:40graaffTime? :-0
18:15:45brixenheh
18:15:48brixenman oh man
18:15:56graaffIt seems we already had rubinius in gentoo earlier.
18:16:11brixenyeah, someone was working on it
18:16:14brixencan't remember who
18:16:48brixenwait what? Ruby 2.0 is coming out in 2660?!
18:16:58brixenstarts a twitter rumor
18:17:07graaffbrixen: looks like it was Caleb Tennis?
18:17:17blowmageDefiler: he gave that at mwrc, but i don't know for sure if he mentioned removing the gil there
18:17:27blowmagei'll watch his session and see
18:17:31brixengraaff: hm, not sure
18:18:06graaffhttps://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+rubinius ← these are the two bugs I could find. Seems it got removed because at the time git stopped working.
18:18:38graaffAnd our ruby project was understaffed so there was no effort to put against it
18:22:26graaffIn any case we now have more staff and a much better infrastructure for handling multiple ruby implementations.
18:22:58brixengraaff: awesome
18:23:10dbussinkah, more dutchies in here?
18:23:17graaffwe currently ship MRI, 1.9, REE and jruby.
18:23:33graaffFolks are working on ironruby, so I guess all we need is rubinius
18:23:36graaffdbussink: yes
18:23:55dbussinkevan: do you want hangs in hydra?
18:24:04dbussinkevan: backtraces of them i mean :)
18:24:13dbussinkdbussink: had to be with a name like that :)
18:25:23dbussinkgraaff: i mean ^^
18:25:50graaffdbussink: yeah, people in other countries always seem to mangle it, missing an 'a' or 'f' :_)
18:26:09Defilergrf
18:26:28dbussinki had fun with people trying to pronounce my first name at railsconf :P
18:31:45brixendbussink: it's not pronounced Dirk Jan? :)
18:31:57dbussinkbrixen: somewhat yeah
18:31:58brixenlike Jerk Dan?
18:32:07brixendbussink: I kid, I kid :)
18:32:18dbussinkbrixen: hehe
18:32:52brixenis a phonolophile
18:32:57graaffDurk Jen is probably more close to what they were saying :-)
18:33:20graaffThen again the 'g' in my name is a showstopper for the most part as well.
18:36:52dbussinkgraaff: yeah, those are killing for foreigners :)
18:40:48graaffbrixen: any specific issue that you had with Gentoo, or was your tweet-rant more general?
18:42:22graaffbrixen: you don't have normal versioned tarballs for download?
18:42:55brixengithub has tarballs
18:43:34brixenclick on the download source link or http://github.com/evanphx/rubinius/archives/master
18:44:08brixengraaff: my tweet was simply about all the distros doing the same things differently
18:44:19brixenit's a terrible waste of time to track down user issues
18:44:25graaffbrixen: the download source link links to a symlink, and then it downloads a tarball that also has what looks like a date added to the version number.
18:44:30brixenthere is, IMO, no need for 20 different distros
18:44:56graaffI would be happy to just have rubinius-1.0.1.tarsomething.
18:45:37graaffbrixen: to some extend it can be explained by different distro's having different goals, but that won't go on for 20+ distros, agreed.
18:48:56graaffbrixen: the "latest" link is nice, but do you also have a direct link for download of these archives, or should i go to github to get those?
18:49:11graaffThe latest trick will break our ebuilds if you update them.
18:49:41graaffBecause we manifest files and the our system can't distinguish between one version and the next if they have the same version.
18:52:44brixengraaff: http://asset.rubini.us/rubinius-1.0.1-20100603.tar.gz
18:56:12graaffbrixen: great, thanks.
18:56:18brixenn/p
18:57:21graaffI guess the build system changed since 0.9.0 (that's the last ebuild we had before), I'll have a look
18:58:19brixenhm, 0.9.0 would be about 2.5 years ago I think...
18:58:36dbussinknothing is the same anymore :P
18:58:37brixenyeah, our build system has changed a bit, still basically rake though
18:58:42dbussinkwas that still with shotgun?
18:58:47brixenyeah
18:58:48graaffcould be, I just thought it was easier to start with something rather than nothing.
18:59:15brixenactually, I can't remember when 0.9 was, but it was too long ago to remember clearly :)
19:00:01brixengraaff: I'm thought someone was playing with a gentoo package a couple months ago
19:00:04graaffLast change to the ebuild we had was on 2008-07-20, so release was before that.
19:00:09brixenor was that suse?
19:00:24brixenWHO CAN KEEP TRACK OF THESE THINGS?
19:00:25brixen:)
19:01:14graaffyeah, yeah, we all look alike to you
19:01:37brixenhaha
19:01:48brixenno no, you all look *different*, that's the problem
19:02:00graaffhaa
19:04:00brixenI'm going to engage in lunch-like activities, bbl...
19:40:57graaffHmm, rubinius can only use llvm 2.6? On gentoo we only have 2.7.
19:46:09graaffOk, this is going to be a lot harder than I anticipated. Hopefully I can do some more work on it coming weekend.
19:51:29dbussinkevan: what's the planning btw on using llvm 2.7?
20:25:32evanactually, i've got a branch using 2.7
20:25:40evani didn't push it because i wanted to update all the prebuids first
20:25:46evan2.6 => 2.7 was pretty easy
20:25:48evanone minor API change.
20:25:53evanwas needed for us.
20:26:42dbussinkevan: ah ok, i can build a linux 64 bit if you want
20:30:24evank
20:31:25dbussinkevan: what's the easiest way to do that?
20:32:01evanwell, i'd like llvm to be build with certain flags
20:32:08evanlet me refactor that into a shell script people can run
21:41:07dbussinkevan: btw, i have a hang in hydra in gdb if you're interested
21:41:16evanyep
21:41:19evani'm interested.
21:41:24evani've found one in sysread
21:41:28evanthat i'm looking into now.
21:41:37evanit appears to be running the net/http specs
21:45:01dbussinkevan: ah, i have one there too
21:45:07dbussinkbut that's an infinite busy waiting
21:45:14evank
21:45:20evanwell, i'm interested!
21:45:32dbussinkevan: https://gist.github.com/e68fc76efa31d0031196
21:45:50evandbussink: could you get a ruby backtrace too?
21:46:25dbussinkevan: i added it to the gist
21:47:30evank
21:47:42evanok, yep
21:47:46evanthis is the same one i've got.
21:48:09dbussinkevan: ah ok, different manifestation?
21:48:19evanno, same.
21:48:21evanthats in net/http
21:49:16dbussinkevan: ah ok, because you were talking about sysread
21:49:23evanwell, check another thread
21:49:29evani'll bet you'll see a thread in read()
21:49:43evangist "thread apply all bt 20"
21:55:09dbussinkevan: hmm, not seeing that
21:55:27dbussinkevan: https://gist.github.com/ae899b373d819b6814e4
21:58:47evanoh oh
21:58:48evani fixed this one
21:58:51evandidn't push it yet
21:58:52evansorry!
21:59:11evanwe need to be checkpointing in check_interrupts as well
21:59:20evani'll push it
21:59:37dbussinkevan: but i did see the sysread one another time
21:59:42dbussinkevan: so it does ring a bell :)
22:01:30boyscoutCheckpoint where we check interrupts - 0a13ba5 - Evan Phoenix (hydra)
22:01:31boyscoutFix running the VM tests - 4a1f0ad - Evan Phoenix (hydra)
22:01:38evanthere ya go.
22:07:46dbussinkevan: w00t
22:07:53dbussinkbut i'm going to get some sleep
22:07:59evan:)
22:07:59evannite!
22:11:27dbussinkevan: having a sysread hang too yeah now
22:11:32evanyep
22:11:45dbussinkbut other than that it already gets pretty far
22:12:16evanyep
22:12:20evanseems to run the core specs pretty well.
22:12:28evannet/http is a good Thread test
22:12:31evanit uses them a bunch.
22:16:39dbussinkbut now really time for bed!
22:35:42blowmageevan: can't find the mention of removing the gil
22:35:45blowmagemaybe i thought that because matz mentioned using stm at euruko
22:35:47blowmage~38:00 here: http://www.vimeo.com/12674501
22:36:09evanstm? wow, his head is really in the clouds. :)
22:36:24blowmagewell, it was just an idea
22:36:29evanwhy the fuck can't you fast forward in vimeo.
22:37:06evanoh, there we go.
22:37:08blowmagei don't know if that is where i thought i heard they wanted to remove gil from ruby2 though
22:37:57evanblowmage: well, keep an ear out
22:38:03evani've heard exactly the opposite from them before
22:38:41brixenno one thought my joke about Ruby 2.0 being released in 2660 was funny :(
22:39:01blowmagethey think having multiple vms in a process is preferable to removing the gil?
22:39:16brixenblowmage: that's what I got from the slides
22:39:31evanblowmage: yeah, thats what i've heard
22:39:33brixenI will be *very* surprized to see the GIL removed in the current codebase
22:39:44evancourse, i heard that they weren't considering a JIT for a while
22:39:46evanand that changed
22:39:46brixener surprised also
22:39:47evanso who knows.
22:40:21blowmagein the q&a he mentions they considered using llvm as the backend in 1.9, but decided against doing that work
22:40:47blowmageand they were hopeful that they could get that done with the macruby team, but it didn't end up going that way
22:40:56evanyep.
22:42:04evanbrixen: 2660?
22:42:21blowmagewhat is the main issues preventing the gil being removed in the current 1.9 code?
22:42:49evanbasically the whole code base.
22:43:01blowmagenone of the c code is threadsafe?
22:43:02evanthey have so much C code
22:43:06evanand 100% of it isn't thread safe.
22:43:07evanyeah.
22:43:46blowmageand making RArray threadsafe would slow it down too much?
22:44:26blowmageand it would make ruby2 basically be a fully new implementation?
22:44:59evanit's looking that way
22:45:28evanusing locks for all access to RArary would be slow, yes.
22:47:58brixenevan: matz's slides refer to a novel that happens in 2660
22:48:41evani guess i missed that.
22:49:37brixenhttp://www.slideshare.net/ThoughtWorks0ffshore/matz-3534905
22:49:42brixenthe first few slides
22:53:27evanbrixen: aaah
22:53:27evanhehe.
22:53:34evanok, i'm going for an overdue jog.
22:53:42brixenok
23:02:22tarcieribrixen: heh, the novel whose author the Hugo is named after?
23:02:24tarcierihttp://en.wikipedia.org/wiki/Ralph_124C_41%2B
23:03:08tarcierilol I see Matz screenshotted the Wikipedia page in his presentation
23:03:19tarcierialong with tons of other tabs
23:05:09tarcierithese Matz presentations always confuse me
23:05:23brixenheh
23:05:24tarcierihe goes on and on about multicore CPUs
23:05:30tarcierithen doesn't talk about how to address them with Ruby
23:05:35tarcierione slide mentions "multiple VM"
23:05:35brixenmvm
23:05:36tarcierithat's it
23:05:38tarcieriyeah
23:05:39brixenyeah
23:05:58brixenI wonder if Ruby 2.0 will be our Perl 6
23:06:03tarcierilike natively multithreaded Ruby isn't even on his radar
23:06:06tarcieribrixen: probably
23:06:16brixendude, Perl 6 is amazing
23:06:21brixenperiod
23:07:04tarcieriamazing how?
23:07:16brixenwow, just waw amazing
23:07:48brixenI'll probably be tending a small vegetable patch before I program in Perl 6
23:10:54tarcieriheh
23:11:26tarcieriit seems PHP might be pragmatic to maintain and incrementally improve their ball of shit instead of trying to fix it
23:12:13tarcierithey're always adding new nifty features, like goto!
23:12:51brixengoto is underrated
23:12:56tarcieriit really is!
23:13:21tarcierivery useful for goto-driven FSMs! :)
23:13:39brixenalso, php is eminently pragmatic... 50% of the population is below average
23:13:49tarcieriheh
23:14:40tarcieribrixen: but seriously, wonder why Matz is all "OMG MULTICORE!" and doesn't give a crap about native multithreading
23:14:58brixenI think he probably cares about it
23:15:08brixenmvm would use threads probably, not processes
23:15:16brixen:)
23:15:19tarcierilol
23:15:27tarcieriwell I mean Thread mapping to native threads
23:15:49brixentarcieri: not everyone is like you, this you have to realize
23:16:05tarcieriheh whut?
23:16:08brixenhaha
23:16:13brixen:D
23:16:32brixenall I know is, rbx will be natively threaded concurrently
23:16:34tarcierithreads are immediately useful to anyone with a Rails app they want to scale across multiple CPU cores with a single VM image
23:16:38tarcieriyay!
23:17:06tarcieriI have a whole blog post on multithreading in Ruby I intend to put up here in a bit
23:17:18brixensweet, looking forward to it
23:17:20tarcierimentions "Rubinius soon!" on the native multithreading front :)
23:17:25brixenjust remember what I said about the 50% J)
23:17:29brixener :)
23:17:30tarcieriheh
23:17:41tarcierithreads that don't share state aren't scary!
23:17:44brixenJ) isn't a half-bad emoticon
23:18:14tarcierireminds me of a bull's nose or something
23:18:18tarcieri):J)
23:18:23brixenheh
23:18:56brixentarcieri: you need to wrap that into a sound bite: threads that don't share state are like bdsm with a safeword
23:19:00brixensomething like that
23:19:07brixencapture the imagination
23:19:09tarcierihahaha
23:19:33tarcierithat's awesome
23:20:17brixendon't be scared, you can play too
23:20:22tarcierihehe
23:20:32brixenI dunno, probably something you can work with there
23:20:41BrianRice-workor "threads that share state are like bdsm without a safeword" of course
23:20:47tarcierilol yeah
23:20:49brixenBrianRice-work: heh
23:21:06brixenBrianRice-work: I'm trying to evoke a positive image
23:21:15brixenpeople are already scared
23:21:47BrianRice-workthat metaphor will need work, then
23:22:07brixenyeah, kinda pulled it out of my hat there
23:22:35tarcierialready threw it on Twitter :)
23:22:51brixenheh
23:23:58brixentarcieri: hah, great, now we're going to get all kinds of crazies
23:24:03tarcieriheh
23:24:19brixensome guy was trying to run his php script in rbx because the topic mentioned JSON
23:24:26brixenand he was having trouble with json in his app
23:24:33tarcierihahaha