_whitelogger has joined #jruby
apaokin[m] has quit [Quit: You have been kicked for being idle]
<byteit101[m]> Headius: what's the best way to make a fake bidirectional IO object? MRI has the @tied_io_for_writing I posed the other day, and trying to override new and instance on a custom IO class just doesn't seem to work right on JRuby.
<byteit101[m]> "fake" here means I have two separate fd's for each direction, not one fd for both directions
<byteit101[m]> Ideally I'd like something that works on all ruby impls
<byteit101[m]> I had considered `class << instance` but you said that was very slow?
<byteit101[m]> that method would let me tack the writes over the existing read IO
<headius> yeah creating a subclass once would be faster than a singleton class every time
<headius> we do the same tied_io_for_writing thing internally, perhaps we just need to expose that through some JRuby API
<byteit101[m]> Rubinious did " Rubinius::Unsafe.set_class pa_read, IO::BidirectionalPipe"
<byteit101[m]> but that's not appicale to anything else
<byteit101[m]> re tied_io_for_writing: Can it bet set on an existing IO?
<byteit101[m]> I would have to make a C extension to set t_i_f_w for cruby
<headius> enebo: review plz: https://github.com/jruby/jruby/pull/7739
<headius> byteit101: this is the field
<headius> it is set in a couple places in IO logic
<headius> including here where it gets set for popen:
<headius> I'm not sure how you could set this from Ruby code in CRuby or JRuby without adding some extension to do it
<headius> (or in JRuby, using JI to set it)
<byteit101[m]> Time to add more gems?!
<headius> yeah unless we can figure out some way to trick CRuby into setting this
<headius> it would be something like JRuby.ref(io).open_file.tied_io_for_writing = io2
<headius> using JI
<headius> enebo: I considered adding the same test to other core types tested in that spec but not sure how far I should permute this
<enebo[m]> headius: your PR seems fine to me
<enebo[m]> I am not sure you really need to test more since the code will exclude serializable and your test somewhat proves it
<headius> yeah only reason I thought to do more is because there were a several places with custom marshaling that I had to update
<headius> I'll just leave it with the one spec fo rnow
<enebo[m]> ah yeah well I am not sure how you would feel safe in that case
<enebo[m]> unless you test every custom type but then how many can even have a Serializable
<headius> Serializable was accidentally the right choice because BasicObject implements it and any Java objects in the graph need Serializable to dump
<headius> there may be other types of internal state that's serializable but should not be marshaled but I did not dig into that
<enebo[m]> The other solution if this is a concern would be to verify it is valid and any object passed would skip serializing so it wouldn't matter how you acquire the object
<enebo[m]> I didn't read how the lists are processed from that point so that may be a lot more lifting
<byteit101[m]> can ruby code create thread/fiber-local globals like $?/$CHILD_STATUS
<headius> No