Index

Show enters and exits. Hide enters and exits.

00:17:50postmodernbrixen, so i deleted rubinius and recloned it
00:18:00postmodernbrixen, im still getting failures wrt Process.wait2
00:18:13brixenpostmodern: yep, I repro'd them yesterday
00:18:20brixenbut you were already gone
00:18:27brixenI'll take a look at them
00:18:43postmodernbrixen, dbussink had be run the script manually in gdb
00:19:01postmodernbrixen, looks like some destructor failure
07:03:47dbussinkmorning :)
13:30:22goyox86dbussink: morning!
13:33:03dbussinkgoyox86: morning
13:33:30goyox86dbussink: how are you man?
13:33:43goyox86dbussink: working on hydra?
13:36:16dbussinkgoyox86: nope, doing payed work atm :p
13:36:58goyox86dbussink: :)
13:37:50dbussinkgoyox86: one has to make some money too :)
13:37:59dbussinknot that i don't like it btw
13:38:12goyox86dbussink: agree :)
13:42:01dbussinkgoyox86: so what do you do?
13:43:28goyox86dbussink: I'm a web developer, (working RoR), but i love programming languages, vm's so that's why i became interested in rbx :]
13:45:45goyox86dbussink: I'm based in Venezuela (South America)
13:47:09dbussinkgoyox86: already thought so because of the hostname ;)
15:31:28goyox86is there some one working on porting rbx to windows?
15:31:49goyox86i know this is not priority, just asking
15:37:58krrrronossomebody forked rubinius for that, I don't remeber who it was
15:38:18krrrronos*remember
15:38:53goyox86krrrronos: i see
15:48:19boyscoutCI: rubinius: 725c432 successful: 3511 files, 15076 examples, 42901 expectations, 0 failures, 0 errors
17:21:31tarcieriwell, here's my whole rant on why threads are good: http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is-generally-better.html
17:23:02brixentarcieri: woot woot woot
17:23:06brixenreads now...
17:23:35tarcieriheh
17:33:46tarcieribrixen: what ya think?
17:34:43brixentarcieri: sorry, fixing an rbx thing for carllerche
17:34:54tarcieriheh ok
17:35:10carllerchei'm needy
17:35:13brixenit's very complicated, involves booting linux
17:35:20tarcierihaha
17:36:26carllerchesaying "threads are bad when they share data" is like saying "memory is bad when you leak it" (maybe not the best analogy, but something like that)
17:37:08brixenthat's pretty good actually
17:37:29carllerchesharing data for highly concurrent apps is bad no matter how you do it
17:38:08brixenwell, shared data does not make threads bad, any more than your crappy program makes memory bad
17:38:38cremestarcieri: good article; i need to think on it before sharing any feedback
17:39:43carllerchewhen you write async apps, either you share data and can only use 1 core, or you don't share data, in which case, you could write the same logic using threads
17:39:49carllercheand it would be easier to follow
17:39:50carllerche(imo)
17:39:52tarciericremes: cool, thanks
17:40:16brixenall things in moderation
17:40:17carllerchebut yes, threads make perfect sense for an HTTP request
17:40:25brixenyou will share some data no matter what
17:40:29tarcieribrixen: yeah, it's more that when threads don't share state, they don't have the potential for thread synchronization errors
17:40:47brixentarcieri: indeed
17:49:07cremestarcieri: first bit of feedback... code examples always make things clearer (for me)
17:49:27cremessome examples of inversion of control versus synchronous would make the article clearer
17:49:39cremesalso a quick example of reia would be neat
17:49:41tarciericremes: aah, yeah good point
17:49:55tarcierithere's an example of Reia on wiki.reia-lang.org, heh
17:50:19cremessure, but embed it in the article so folks don't have to chase links all over (if they don't want to)
17:50:43tarcieriyeah
17:51:03cremesi haven't looked at reia in a long time (at least a year) so this is a good time for me to take another peek
17:51:37tarcieriit was coming along well, then I got all crazy busy again
17:51:57brixentarcieri: I 2nd the code samples feedback
17:52:22tarcierihrmm, wonder if I can really quick sneak some in :)
17:52:27brixentarcieri: excellent overview I think
17:52:32BrianRice-workrosetta code might be a good source for examples. I used it for Slate
17:52:39tarcierithanks
17:52:46brixentarcieri: I'd consider the post a work in progress, since it's more like a paper
17:52:55brixentarcieri: feel free to revise it
17:53:03nicksiegerI wonder if em-synchrony is basically a threading library on top of events. haven't looked at it yet
17:53:04tarcieriwtf blogger inaccessible?
17:53:22tarcierinicksieger: well, cooperative "threading"
17:53:22tarcieriheh
17:53:47tarcierioh I see, office DNS down...
17:53:54tarcieriswitch to Google ohnoez!
17:54:53nicksiegertarcieri: yeah, i'm referring to a something I read about a guy who was working in an async model but didn't like the callbacks so he wrote a library to manage the state for the state machine and when he was done, he basically found he had implemented a threading library
17:55:08tarcierinicksieger: sounds like what I went through :)
17:55:22BrianRice-workI see
18:04:22tarcieriall right, well I added a small code example
18:04:23tarcieriheh
18:04:31tarcierinot much, could probably use more, but it's better than nothing
18:05:20boyscoutRemoved unneeded ncurses dep in readline ext. - 9260460 - Brian Ford
18:07:18jakedouglastarcieri: not that i really care about EM anymore, but you know the write completion thing you keep talking about is like a 5 line patch right? :p
18:07:46tarcierijakedouglas: I tried to add it one time and got tired of spelunking around the C++ code
18:07:52tarcieribut that was like 4 years ago
18:08:00jakedouglasheh. i promise its *really* easy
18:08:11tarcieriwhy hasn't it ever been added then?
18:08:21jakedouglasand the proxying case that you mention is handled by something else
18:08:30jakedouglasand thats kind of the only case where it's really a problem
18:08:35tarcieriyes, use-case specific solutions instead of a general one
18:09:04jakedouglasshrug. i've never seen anyone complain about it over 2-3 years exception for the proxy case
18:10:07jakedouglass/exception/except
18:10:28tarcieriwell, point still stands without it you can't implement a "blocking" write with Fibers
18:10:32jakedouglasyea, it's never been added because no one has ever asked for it until you
18:10:37jakedouglasheh
18:11:01tarcieriI do know people who've run into it in the proxy case
18:11:02jakedouglasyea i dont really care anymore about the general conversation, i just wanted to nitpick over that minor detail
18:11:03jakedouglas:p
18:11:06tarcierihaha
18:11:32tarcierievery time I've tried to patch EventMachine it's just been an exercise in frustration, but maybe it's been refactored quite a bit since
18:11:59tarcieriFrancis had a very... shall we say non-idiomatic style to his Ruby
18:12:00jakedouglasim sure its been worked on, that probably doesn't mean it's any easier to understand.
18:12:04tarcieriheh
18:12:47jakedouglasi just happen to know where the 5 lines would need to go, that's all :p
18:12:50tarcierinice
18:13:26tarcieriI've thought about trying to port Revactor to EventMachine
18:13:27jakedouglasyea, EM is and always has been a huge mess though. i dont blame you for giving up on patching it.
18:13:31tarcierior at least let it support both Rev and EventMachine
18:13:39tarcieribut yeah, that's the missing piece
18:14:36jakedouglasits just not even worth working on, i dont really believe in it enough to write it properly heh
18:15:16tarcieridon't stop believin'
18:15:19tarcieriand why?
18:15:19tarcieriheh
18:15:28jakedouglasin general i would not choose to write a network server in EM anymore
18:15:41tarcieriyeah same here
18:15:46jakedouglasi duno, why do you think? its just a mess
18:15:55tarcieriyeah
18:15:59jakedouglasi would almost rather it didnt scale than dealing with all that shit heh
18:16:12tarcieriit'd be interesting to port Rev to libevent's buffered I/O
18:16:31jakedouglasi used to think it was really cool but i've seen the light and realized its just a bitch for creating real products with
18:17:22tarcieriyeah
18:17:31tarcierimaybe I'll do a talk on Rev and Revactor at RubyConf :)
18:17:32brixenfunny how 10 lines of a demo look completely different in another context
18:17:47jakedouglasif i had something that was honestly appropriate for that kind of thing and i couldnt use erlang, i would probably use node just because it's actually maintained unlike the ruby tools
18:17:57brixenmethods generally do not give you enough context to understand where they are appropriate
18:18:01brixenyou find that out the hard way
18:18:03poetdoes the standard library attempt to track Ruby's or are there Rubinius specific extensions?
18:18:17brixenpoet: come again?
18:18:36poetbrixen: are there parts of Rubinius' standard library that are not in MRI ?
18:18:47brixenpoet: hm, some yes
18:18:55tarcierijakedouglas: it seems for a lot of those use cases there's off-the-shelf stuff written in C
18:19:06poethow are contributions of that nature treated ?
18:19:13brixenpoet: lib/rubinius lib/debugger
18:19:21jakedouglasi would rather build stuff on a platform thats maintained, has libs actively being built, and written by someone who can actually write clean C/C++
18:19:22brixenpoet: contributions to rubinius?
18:20:09poetbrixen: say for example someone wrote a Net::VNC (or whatever) implementation. Is that something that Rubinius would include?
18:20:26brixenpoet: depends, it's certainly possible
18:20:33brixenpoet: you'd just have to make a case for it to evan
18:20:38poetVNC is a bad example, but some fundemental protocol that makes sense to have in a standard library
18:20:42brixenpoet: for example, we include an Actor lib
18:20:48poetah, ok
18:21:03brixenpoet: we'd probably prefer it be a gem
18:21:15brixenin general, we thing stdlib should be gems in the first place
18:21:23brixener think also
18:21:47brixenpoet: is there a reason gem doesn't work for your case?
18:21:51poetbrixen: how to the TLS extensions to FTB and Telnet fit in?
18:21:55poet*FTP
18:21:59poetthat you are working on?
18:22:20brixenI'm not aware of any TLS extensions
18:22:26brixenis that a RSoC?
18:22:30poethttp://github.com/evanphx/rubinius/blob/master/lib/net/ftptls.rb
18:22:34poetit's pretty old
18:22:42poetand not implemented
18:22:52brixenheh, no idea on that
18:23:13poetok
18:23:21poetI like the idea of moving stdlib to gems ^_^
18:33:53boyscoutCI: rubinius: 9260460 successful: 3511 files, 15076 examples, 42901 expectations, 0 failures, 0 errors
19:35:07tarcieriyeah same here
19:35:19tarcieriRuby stdlib has so much unmaintained junk in it
19:44:55eluxhey guys
19:45:04eluxi hear that rubinius is working on removing the GIL .. that is amazing
19:45:18eluxi was wondering if rubinius is working on supporting 1.9?
19:45:26eluxa lot of my code base has shifted to 1.9 at this point ..
19:56:32kronos_vanoelux, As I know rubinius team doesn't work on supporting 1.9. Here is a more important things.
19:58:47dbussinkelux: kronos_vano: actually brixen recently talked on getting the syntax changes in
19:58:55dbussinkelux: what kind of features do you use?
19:59:01eluxi would imagine it wouldnt be that difficult to add to rubinius
19:59:05dbussinki've found it pretty easy to support both actually
19:59:06eluxdbussink: Process.spawn .. and Fibers
19:59:20dbussinkelux: there's already a fiber implementation in rbx
19:59:25dbussinkelux: you could try if that works
19:59:36eluxdoes rubinius have a debugger?
19:59:49eluxlike ruby-debug .. and how comparable is its performance to 1.9.2 ?
19:59:52dbussinkelux: a work in progress one yeah
20:00:02dbussinkbut off to play another sc2 game :P
20:00:05eluxnice.
20:00:12eluxi play too
20:00:40eluxdbussink: ..another 1.9 thing i need are all the encoding support
20:02:01brixenelux: 1.9 support is coming soon
20:02:08eluxthat is amazing
20:02:15eluxvery impressive turn around
20:02:56brixenthe difference in rbx between 1.8 and 1.9 is pretty much just hash syntax, splats, and encoding support
20:03:04brixenmost of the rest is already in 1.8.7
20:03:15eluxyea.. i realize its not that much. the encoding is big for me
20:03:24eluxplus some of my code assumes ordered hashes
20:03:31eluxi could work around it
20:03:49brixenheh, order hashes *eyeroll*
20:03:56brixenthat's actually really easy to add
20:03:58elux:P
20:04:04brixenelux: Hash is all in Ruby
20:04:07eluxjust saying.. it requires work for me
20:04:10brixenyou could take a shot at adding it
20:05:29eluxbtw.. hows the working coming on removing the GIL and having truly native threads? that sounds amazing to me ..
20:05:38eluxat that point .. would there be a real need for MVM?
20:06:04brixenMVM and truly concurrent threads are different use cases IMO
20:06:16eluxwhat is the advantage of MVM?
20:06:17brixenyou can see the work on removing the GIL in the hydra branch
20:08:01eluxcool
20:08:42brixenmvm could be used to have process type separation behind an actor message passing scheme
20:08:52brixenprocess-like because each vm gets its own heap
20:09:19eluxi see.. would you see use for mvm+native threads ..
20:09:24eluxfor better concurrency ..
20:09:30eluxand making it efficient
20:10:02brixenmvm is implemented with native threads, yes
20:10:20brixenefficiency is not necessarily a function of concurrency ;)
20:10:31brixenso that assumption is confusing
20:10:36eluxis there an mvm branch for rubinius?
20:10:50brixenthere is no mvm branch, the code is in mainline but it's old
20:11:02brixenit needs to be fixed up some
20:11:21brixen|Blaze|: not much more than an additional process
20:11:24eluxbrixen: i meant more overall efficiency of distributing the work to the entire system .. cpu, disk i/o, network i/o
20:11:31brixenit's a full vm in a separate os thread
20:11:44brixenelux: again, that depends
20:12:12brixenwith truly concurrent threading in rbx, you should be able to saturate a system with one vm instance
20:14:50eluxi see
20:24:13evanafternoon.
20:25:27brixenhello hello
20:26:02evani'm debugging a weird situation where a object seems to loose it's lock.
20:26:23evanlose, rather.
20:28:06dbussinkevan: the hang in sysread?
20:28:11evannope
20:28:26dbussinkevan: ah, got that fixed?
20:28:26evanbut it's mildly related.
20:28:28evannope.
20:28:36evantrying to fix it
20:28:39evanand now getting another problem.
20:29:03evani think i've found it.
20:29:04dbussinkevan: ah, down the rabbit hole
20:29:07evanyep.
20:29:20evani'll be back in LA tomorrow afternoon btw.
20:29:25evanfor those who are stalking me.
20:29:37dbussinkevan: you get that feeling from me ;)
20:30:24evanno, but i'll bet you get it from me when you mention stoopwaffles.
20:30:43evanok, i think i found the lock issue.
20:30:46evanyay.
20:31:17evanand the per-object-locks seem to be working well.
20:31:39dbussinkevan: i suspect you having a keyword alert on that one ;)
20:31:44evan:D
20:32:49evanthin locks weren't surviving past GC.
20:32:59brixenahh I was wondering
20:33:07evanbecause they're bits in the header
20:33:10brixenwhen you said an object appeared to lose it's lock
20:33:11brixenyep
20:33:22brixen-'
20:33:23evani'm going to improve how we move an object
20:33:27evanthe code is all over the place.
20:38:22evanyou guys think about synchronized ivar references any more?
20:38:42brixenI read about java memory model
20:38:53evank, thats a great start.
20:38:54evanthoughts?
20:39:02brixenthe approach you suggested sounds good
20:39:11brixenI mean, we absolutely need a memory model
20:39:27brixenI don't see a real need to make a particular ivar synchronized
20:39:28evanwell, we'll HAVE a memory model whether we define it in english or not :)
20:39:43brixenit's ad hoc unless it's formalized
20:39:47evanyep.
20:39:57evanyou mean it makes sense to have all ivars in a class be synch
20:40:01evanrather than just one ivar
20:40:05evanor rather, defined per ivar.
20:40:09brixenyeah, I think that seems fine
20:40:19brixenthe class approach
20:40:35brixenif it becomes a real problem, we could refine it
20:40:40brixenit's a good balance to start
20:41:08brixenI think the most important thing I've heard about concurrency recently was your chat with mental about STM
20:41:28brixenhe said that the concurrency facilities should be focused and limited
20:41:37brixennot something that affects everything
20:41:43evanright
20:41:50evanwhich was my big confusion with STM all these years
20:41:51brixenI think that's something that is missing from many folks mental model
20:41:57brixenyeah, me too
20:42:41evannow that I see that STM explicit rather than implicit, it's much clearer.
20:42:55brixenthis, btw, is also the advice in The Art of Concurrency book I'm reading
20:43:10brixenie, you carefully design the concurrent parts
20:43:25brixenyou don't just whiz bang add some sauce and everything is concurrent
20:43:52brixenhe also strongly recommends always starting with a tuned serial implementation and then design concurrency into it
20:43:56evannow even "special sauce" ?! (it's ketchup and mayo mixed)
20:44:00evans/now/not/
20:44:04brixenwhich is pretty much the path you've taken here
20:44:15evanrad.
20:44:17brixenheh, maybe there's an exception for special sauce
20:44:22evansounds like I need to get that book.
20:44:38brixenit's really good so far, but basically an introduction
20:44:44brixenyou may not learn a lot from it
20:44:45evanlets see if it's on kindle.
20:44:58evan(I wonder if my kindle works here)
20:45:20evanwell to the great american deadzone
20:45:23evanwelcome, rather.
20:45:33evantyping is failing me today.
20:45:57evanoh, there we go.
20:45:58evanyay.
20:46:00brixenI'm so close to getting an iPad
20:46:12brixenbut a lot of the books I want are not on kindle yet
20:46:36brixenoh, btw, Genius Scan iphone app is the shit
20:46:38brixenand free
20:46:54evanoh, whats that?
20:47:14brixenalso, apparently canon has a 20 ppm 2-side scanner that saves the image with transparent OCR'd text over it
20:47:30brixenso my book scanning project may have to commence soon
20:47:55evanhuzzah!
20:47:57brixengenius scan uses the camera to take a pic and ocr it, so you can send it as a pdf
20:47:59evanit's on kindle.
20:48:02brixensweet!
20:48:08evanand only $28
20:48:15brixennot too bad
20:48:25brixenstill pretty frustrated with the cost of ebooks
20:48:34evanyou like it thus far?
20:48:45brixenthe concurrency book?
20:48:48evanyeah
20:48:54brixenI think it's a good primer, yeah
20:49:01evank
20:49:05brixenI've done some parallel programming before
20:49:12brixenso I'm not unfamiliar with concurrency
20:49:32brixenhe explains differences between parallel and concurrent programming
20:49:44brixenthe book is about multi-thread concurrent programming though
20:49:44evangotcha
20:49:49evani downloaded the sample
20:51:25brixenso, apparently google has patented a bunch of shit for book scanning
20:51:47brixenlike projecting an infrared grid on the page and taking high res pics from multiple angles
20:51:58brixenthen transforming the image flat and doing ocr
20:52:04evangoogle's new motto needs to be "Building Brian's ire daily."
20:52:09brixenheh
20:52:13brixennah, this is just tech
20:52:22brixenI'm not opposed to some patents
20:52:28brixenjust not software ones
20:52:38brixenbut the NN thing really upsets me
20:52:54brixengoogle maps will be the hardest to replace
20:53:03brixeneverything else is pretty easy
20:54:17evanbing maps?
20:54:18evanO_o
20:54:19evan:)
20:54:27brixenheh
20:54:30brixenduck duck map
20:56:59evanso, terms out that fastthread introduced the behavior that when a thread exits
20:57:05evanall it's locked mutexes are unlocked
20:57:11evans/terms/turns/
20:57:37evangiven that MentalGuy wrote that logic, I understand why.
20:58:21evanwe never actually supported that.
20:59:41evanman, I forgot how cool the weather is here
20:59:56evanafternoon rainshower for 15 minutes, then the sun is back out
21:00:49brixenhmm, morning rain shower for 15 and still no sun to speak of :)
21:01:10evanthats the great part about the mountains
21:01:11evanso much sun.
21:01:21evanthe clouds move so fast
21:01:50brixensounds nice
21:02:01brixensupposedly mid 90's here later this week
21:02:40evani can just hear the pesimism in your voice
21:03:22brixenheh, mid 90's is pretty warm
21:03:32brixenif i were near a lake...
21:05:24jakedouglasmost dreary nw summer i've ever seen
21:06:15BrianRice-workyeah, this is not the mood-enhancer we usually get
21:10:43jakedouglasyea. i dont actually mind that much, i am generally pretty tired of it being hot by the time it cools down in the fall
21:11:17jakedouglashowever, i am afraid of committing suicide during the winter holidays if i dont experience a proper summer
21:13:24evanyou guys should head up into the mountains for a week
21:13:38evansummer in the mountains is idealic.
21:17:14sbryantAny particular mountain?
21:17:19sbryantJust a mountain?
21:17:29evananything about 5k feet.
21:17:37evanthat excludes most of the east cosat
21:17:38evancoast.
21:17:46evanabove.
21:20:00sbryantwell, damn.
21:20:21boyscoutAdd more object lock operations, fix thin locks on GC. - 63e2855 - Evan Phoenix (hydra)
21:20:21boyscoutFix spec title - 922ffad - Evan Phoenix (hydra)
21:20:21boyscoutReimplement Mutex using object locks - c0dbd36 - Evan Phoenix (hydra)
21:21:18evanfor those curious
21:21:25evanyou can check out lib/thread.rb in hydra
21:21:32evanfor me using the new object locking operations
21:21:50evanMutex is now just a API wrapper around it
21:25:26jakedouglasi have been in the mountains. indeed its nice
21:27:37evanif anyone in here would like a challenge, i have one for them.
21:27:44evancould be quite fun
21:27:52jakedouglassounds hard
21:28:10evanit might be, but it will be fun. :)
21:28:33evani'd love to see someone getting our pathname.rb faster than 1.9's pathname.c
21:28:51evanperformance(rbx+pathname.rb) > performance(1.9+pathname.c)
21:28:53evanin other words.
21:29:25sbryantis our pathname slow?
21:29:43evannot necessarily
21:29:48evanit's the same one as 1.8 though
21:30:04evanand they're rewriting pathname into C in 1.9 because i'm assuming they feel like pathname.rb is slow and unfixable.
21:30:12evani'd love to prove them wrong on rbx
21:33:04brixen1.9 has a sad and unfortunate predilection for rewriting in C :(
21:36:57sbryant^
21:40:17brixenhowever, we have options in rbx
21:40:34brixenbut we are in need of folks learning how to do this
21:41:03brixenby this, I mean solid perf testing and identifying bottlenecks with GC or code
23:11:34boyscoutCleanup moving an object - 1ec1fce - Evan Phoenix (hydra)
23:46:16kronos_vanoHi guys! Is there still a plan for improving "String#%" via ragel?
23:55:49brixenkronos_vano: not sure how that'd work
23:55:55brixendo you have a PoC?
23:56:03kronos_vanoPoC?
23:56:24brixenproof of concept
23:58:41kronos_vanohm... I haven't.
23:59:59brixenI suppose it's conceivable