RageLtMan has quit [Ping timeout: 255 seconds]
RageLtMan has joined #rubinius
RageLtMan has quit [Ping timeout: 255 seconds]
houhoulis has joined #rubinius
nirvdrum has quit [Ping timeout: 255 seconds]
RageLtMan has joined #rubinius
GitHub26 has joined #rubinius
<GitHub26> [rubinius] chuckremes pushed 1 new commit to ffi-io: http://git.io/vcz4U
<GitHub26> rubinius/ffi-io 2b90e73 Chuck Remes: Passes all but one select spec which is related to thread sleeping...
GitHub26 has left #rubinius [#rubinius]
meh` has quit [Ping timeout: 264 seconds]
houhoulis has quit [Remote host closed the connection]
amclain has quit [Quit: Leaving]
|jemc| has quit [Ping timeout: 240 seconds]
tenderlo_ has joined #rubinius
tenderlove has quit [Ping timeout: 246 seconds]
stass has joined #rubinius
ssedov has quit [Ping timeout: 250 seconds]
RealMarc has joined #rubinius
DireFog has quit [Remote host closed the connection]
DireFog has joined #rubinius
DireFog_ has joined #rubinius
DireFog has quit [Read error: No route to host]
<cremes> I hope all of the IRC lurkers are seeing the good momentum I’ve got going with the ffi-io branch
<cremes> Just finished #select, so now I’m on to fixing readpartial, read_nonblock, and write_nonblock
<cremes> A few more weeks and there will be very little C++ left to handle rbx IO
<cremes> And then the real fun begins as I try to move File IO over to using memory-mapped files and reducing the amount of
<cremes> string creation and copying; the hope is that this will speed up rbx IO 2x (or more)
<cremes> I’d appreciate any help people can offer even if it’s just bug reports against the ffi-io branch
<cremes> along with an example of the code that broke it
nirvdrum has joined #rubinius
cremes has quit [Quit: cremes]
cremes has joined #rubinius
|jemc| has joined #rubinius
DireFog_ is now known as DireFog
mustmodify_ has joined #rubinius
mustmodify_ has left #rubinius [#rubinius]
meh` has joined #rubinius
cremes has quit [Quit: cremes]
bb010g has joined #rubinius
cypher23 has quit [Read error: Connection reset by peer]
cypher23 has joined #rubinius
cremes has joined #rubinius
amclain has joined #rubinius
amclain_ has joined #rubinius
amclain has quit [Read error: Connection reset by peer]
amclain__ has joined #rubinius
amclain_ has quit [Ping timeout: 246 seconds]
cremes has quit [Ping timeout: 246 seconds]
cremes has joined #rubinius
cremes has quit [Ping timeout: 244 seconds]
cremes has joined #rubinius
<digitalextremist> cremes: thank you Very Much for all your hard work. I will gladly beat the crap out of your code via ffi-rzmq soon, with pleasure!
<cremes> digitalextremist: ha ha, please beat it up
<cremes> and thank you for the kind words
<digitalextremist> liked your anecdotal Rubinius blog post too -- seems like you've been very active lately
<cremes> yeah, i’ve had a few things at work circle back around to Ruby land, so i’m programming again. haven’t had much time for it lately.
<digitalextremist> Ruby land missed you deeply :)
<digitalextremist> hey since you're here, did you see that ffi-rzmq issue I posted earlier?
<cremes> i’m not so sure about that
<cremes> when did you post it? today?
<digitalextremist> yeah, it's the only open ticket
<cremes> let me take a look
<cremes> ah, ffi-rzmq-core has a new issue. let me examine the code and see what y’all are talking about.
<digitalextremist> yeah, sorry, I ought to have just copied the link for you
<cremes> digitalextremist: I don’t understand the ticket. Nowhere does ffi-rzmq-core touch the zmq_msg_t structure.
<digitalextremist> I'm not entirely clear on the issue's specifics myself, mostly aggregating what Asmod4n is saying: https://github.com/celluloid/celluloid-zmq/issues/56#issuecomment-144314972
<cremes> Yeah, I read that thread. Asmod4n doesn’t point to the code, so I don’t believe them now. :)
<digitalextremist> Right on, I'll poke him for evidence and start testing 4.x myself
<cremes> Need more information from them on what they think is wrong.
<digitalextremist> Thanks for the peek
<cremes> np
<cremes> Just keep making celluloid kick-ass and I’ll be happy to help with some zeromq stuff!
<digitalextremist> I'm happy to hear that, thanks - I will, and the reciprocal of that assurance backatcha
<cremes> digitalextremist: i also hope you can test celluloid against my ffi-io branch on rubinius at some point. It isn’t quite ready yet, but soon.
<digitalextremist> is there any reference info or any diffs of what's changed I could skim?
<cremes> no, no notes yet. but i’ve pretty much ripped out all of the C++ from the IO class and rewritten it in ruby with some FFI to bind system functions.
<cremes> i’m passing most of the specs now, so it’s getting pretty solid.
<cremes> the IO api should be exactly the same. what’s happening under the covers is a bit different but hopefully still correct.
<digitalextremist> oooo so this is on ::IO itself? I hoped that's what you implied but life may have made me less of an optimist and maybe I should resume
<cremes> yep, all new IO
<cremes> same shitty Ruby IO API :(
<cremes> whoever designed that class and its hierarchy really didn’t understand OOP
<digitalextremist> then I ought to have no problem at all beating the crap out of that with gusto.. I've been migrating over to rbx nearly completely for more and more IO
<cremes> cool, good to hear
<cremes> is the fiber implementation in rbx holding up ok?
<digitalextremist> amazingly, yes
<cremes> great!
<digitalextremist> I am trying to cook up *actual* benchmark comparisons between rubies, including/especially that
<cremes> i’ll be interested to see that.
<digitalextremist> per brixen's talking about Rubinus as a language platform, I've also been looking at a slight/serious fork of the ruby language to go a more Specialized Programming route, so maybe your ::IO pain points can be worked through without being encumbered by the Design Process -- without "leaving ruby"
<digitalextremist> I call it Phyr ... short for Sapphire... Ruby without the Sap
<cremes> I like it.
<cremes> I have a vague future plan to completely redo Ruby IO and make it sane. Maybe that could be part of Phyr.
<digitalextremist> I would be extremely happy if it would be. The specialization intended is actually prompted as much by you as by brixen
<digitalextremist> I pass so much over 0MQ with your bindings that I've hit a point where my bottlenecks are pure IO and over complication of Object / BasicObject in the case of just plain data
<digitalextremist> you know the talk I'm referring to? http://www.infoq.com/presentations/rubinius-cynefin
<cremes> yes, I’ve seen it
<cremes> digitalextremist: when i was first starting to use zeromq, i was very interested in finding out if rbx could “ping” a bytearray in memory
<cremes> so that i could rapidly share it among zeromq sockets
<cremes> having to marshal/unmarshal ruby data over zeromq sockets is a giant pain and huge performance penalty
<cremes> if the runtime could pin an object in memory and send a reference over a socket, that would be really cool
<digitalextremist> I think Bjarne Stroustrup was talking about something like this recently and I wondered something in the neighbor or at least the same city as what you're thinking
<digitalextremist> Are you talking about inproc:// type connections mostly?
<cremes> digitalextremist: yes
<cremes> it only makes sense for inproc. any other kind of socket could be talking to a different process that doesn’t have access to the originator’s memory.
<digitalextremist> I think this could be worked around using a document store or DB, but that'd be a lot less awesome
<digitalextremist> Right
<cremes> just fixed all failing specs for read_nonblock
<digitalextremist> ( my work around implies different machines )
<cremes> next!
<cremes> now to fix readpartial
<digitalextremist> WOOT! Well I'll just fade into the background for a bit while you rock out. I am always here for the most part, btw. I'll be in touch more often
<digitalextremist> I am about to omnirepo the celluverse
<cremes> ooh, that sounds complicated
<cremes> though i’ve been using git for a few years now, i am still very much a n00b
<digitalextremist> very much so -- I've got a gem about done that can do it for any family of repositories though... easier than actually just doing it once manually. I'm in the same boat with you RE: Git. I've learned a ton having to solve this problem. Managing 8-12 repositories just to release one series of gems is just too much of a downer
<cremes> yeah, celluloid has a complicated gem structure
<digitalextremist> I think it's in the "got worse before it got better" phase, with the solution coming in 0.18.0
<cremes> cool
<cremes> any change on the jruby front? that is, are they getting coroutines anytime soon or is each fiber still backed by a thread?
<cremes> oh good, only one failing/hanging readpartial spec
<digitalextremist> I've not seen a change in RE: Coroutines yet. Still threaded fibers from what I've seen. Haven't gotten too far into 9k+ yet, but I actually have been watching for that
bb010g has quit [Quit: Connection closed for inactivity]
digitalextremist is now known as celluloid
celluloid is now known as digitalextremist
GitHub192 has joined #rubinius
<GitHub192> [rubinius] chuckremes pushed 4 new commits to ffi-io: http://git.io/vcwJj
<GitHub192> rubinius/ffi-io d17f9e0 Chuck Remes: modify this ugly hack a little to put struct in proper namespace
<GitHub192> rubinius/ffi-io 4ce1738 Chuck Remes: add helper methods for raising EAGAIN and EAGAINWaitWritable
<GitHub192> rubinius/ffi-io 99735d7 Chuck Remes: disable the C++ version of #readpartial
GitHub192 has left #rubinius [#rubinius]
GitHub178 has joined #rubinius
<GitHub178> [rubinius] chuckremes pushed 2 new commits to ffi-io: http://git.io/vcwZX
<GitHub178> rubinius/ffi-io bd20526 Chuck Remes: disable the C++ code for write_nonblock
<GitHub178> rubinius/ffi-io ced0230 Chuck Remes: write the code to support write_nonblock and clean up some style issues
GitHub178 has left #rubinius [#rubinius]
GitHub5 has joined #rubinius
<GitHub5> [rubinius] chuckremes pushed 1 new commit to ffi-io: http://git.io/vcwWC
<GitHub5> rubinius/ffi-io a8ececb Chuck Remes: comment out all primitives that are no longer in use
GitHub5 has left #rubinius [#rubinius]
GitHub26 has joined #rubinius
<GitHub26> [rubinius] chuckremes pushed 2 new commits to ffi-io: http://git.io/vcwza
<GitHub26> rubinius/ffi-io f4bd9c7 Chuck Remes: when reopening a FD flush buffer and seek to other FDs location; fix typo
<GitHub26> rubinius/ffi-io 31b3df9 Chuck Remes: stub out a call to #pos for 2 specs
GitHub26 has left #rubinius [#rubinius]
nirvdrum has quit [Ping timeout: 246 seconds]
GitHub189 has joined #rubinius
<GitHub189> [rubinius] chuckremes pushed 1 new commit to ffi-io: http://git.io/vcwpA
<GitHub189> rubinius/ffi-io 4072455 Chuck Remes: Support File#truncate and File#ftruncate correctly...
GitHub189 has left #rubinius [#rubinius]