<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
<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...