drbobbeaty has quit [Read error: Connection reset by peer]
prasun has quit [Ping timeout: 246 seconds]
drbobbeaty has joined #jruby
guyboertje has joined #jruby
prasun has joined #jruby
<guyboertje>
If I hold a reference to a RubyString in a Java JRuby extension, is there a way to tell if the RubyString was mutated since I saved the reference? IOW is there a modification counter or similar I can ad-hoc check?
<guyboertje>
@chrisseaton - thanks, I did not think so but wanted to check.
vtunka has quit [Ping timeout: 260 seconds]
bbrowning_away is now known as bbrowning
vtunka has joined #jruby
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
shellac has joined #jruby
<kares>
guyboertje: you could check its hash - whether it changed, but of course you won't know for sure
<guyboertje>
@kares - which hash would that be?
<guyboertje>
I mean, is it a ready made hash or would I need to compute it?
<kares>
guyboertje: I meant ... str.hash
<enebo>
guyboertje: well RubyString can compute it via hashCode (or hash the ruby method)
<kares>
yy ... if you're on Java side RubyString#hashCode
<enebo>
The hash is not saved internally though so it is computer per call
<guyboertje>
That may work, thanks.
prasun has quit [Quit: Leaving]
<kares>
enebo: hey! have a question - seems the RuntimeCache is only used on one place - dispatching dynamic calls in Java for built-in types, isn't it a relic from the past or does it still make sense to stick around?
<kares>
(esp. with all the Java call-sites now getting all over places)
<enebo>
kares: yeah it likely has slowly been consumed by making callsites bound with invokedynamic
<enebo>
kares: but I do wonder if we still use this in ruboto?
<kares>
definitely seems so ...
<enebo>
kares: do we still use the scope cache?
<kares>
not that I have seen
<enebo>
yeah I would bet that is dead
<kares>
but I will re-check just to be sure :)
<enebo>
kares: well a first pass might be to mark all dead code @Deprecated
<kares>
so do you think it can eventually go deprecated and runtime.cache be null ?
<kares>
yy that would be the plan - not sure whether to keep it around - instanciated, probably to be safe
<enebo>
kares: I am fairly sure it can be but I always wonder about how much we use indy and warmup
vtunka has quit [Quit: Leaving]
<kares>
my worries are if anyone outside core is using it - although that would make no sense
<enebo>
kares: so I have wondered if we get profiling working well enough we may cut back on which sites we use with indy and which we use a less optimal but easier on hotspot mechanism
<enebo>
kares: but we can obviously add things back and as you just said it is hard to believe someone is using this cache outside core (never say never though)
<enebo>
kares: I am doing something potentially much more complainable
<kares>
interesting but does that also apply for those hand-crafter call-sitea around Java code?
<enebo>
kares: I am changing identifiers to use live Rubysymbol everywhere
<kares>
I have seen the beast :)
<enebo>
once I get into IR I have no simple access to runtime to make a symbol from a string
<enebo>
so for IR I am going to take the complaint hit and we will say 2.4 is a major release
<kares>
najs!
<enebo>
which is not really too far from the truth since 2.4 has breaking changes at Ruby level
<enebo>
with that said I am trying to fully deprecate
<kares>
oh does it? thought it to be an easy release
<enebo>
well mainly just Bignum == Fixnum == Integer
<enebo>
but that does break code
<kares>
ah right
<kares>
never really got the benefit of it but so be it :)
<enebo>
kares: that is another reason we did not push very hard on 2.4 support until recently too
<kares>
was also deprecating a lot (of simple legacy) along the way of getting Java numbers play nicely with Ruby's auto magic conversions on places
<kares>
wish I had more time to get more JI stuff ... my todo list has grown and keeps growing :)
<enebo>
heh yeah me too
vtunka has joined #jruby
<kares>
ah so the RuntimeCache is still used with generated code - mostly for Ruby interface impls
guyboertje has left #jruby [#jruby]
madrob has joined #jruby
<madrob>
Hi folks! I'm running into an issue with jruby 9.1.10.0 and rubylex
<madrob>
I don't see any issues opened for this, wanted to check if there was an easy workaround before filing a new one.
vtunka has quit [Quit: Leaving]
<GitHub9>
[jruby] madrob opened issue #4719: NoMethodError in RubyLex https://git.io/vQNsG
<enebo>
madrob: wow interesting find
jeremyevans has quit [Ping timeout: 240 seconds]
<enebo>
madrob: although this is also broken using MRI
<madrob>
... How are we the first people to try reading from stdin using ruby-lex
<madrob>
Or use ruby-lex at all, I guess? Like, I'm shocked there's not unit test coverage here.
<enebo>
madrob: perhaps people only use StringIO or String which have an encoding method but not actual IO
<enebo>
the scope or irb/ruby-lex is probably pretty limited to how irb uses it
<enebo>
OTOH some classes just do not have much coverage :|
shellac has quit [Quit: Leaving]
swills has quit [Remote host closed the connection]
<madrob>
@enebo maybe it's worth discussing our use case for a bit to see if there is a different preferred approach?
<madrob>
We have a custom REPL build on JIRB+bunch of custom commands. But we also want to allow users to send args on stdin in a batch mode.
<enebo>
madrob: does it need to be an unbounded stream?
<madrob>
Currently we create a RubyLex and pass all of the statements on STDIN to IRB::WorkSpace::evaluate
<madrob>
what do you mean by unbounded? We don't know a priori how much data will be on stdin
<enebo>
madrob: yeah I just meant does it need to process before encountering EOF
swills has joined #jruby
swills has joined #jruby
<madrob>
I'm not sure. Probably needs to process as a stream, not read everything and then process, yes.
<madrob>
Although maybe we can change that if there's a compelling reason from the ruby side
<enebo>
madrob: minimal work I think would be to re-open $stdin and just add an encoding which just calls default_external on the same object (well it can be an alias)
<enebo>
madrob: possibly there will be other issues but if you are actually integrating with IRB itself then you probably want to use their lexer and not go down ruby-parser or ripper routes
<enebo>
looking in ruby-lex the only three methods is .gets .eof? and .encoding
<madrob>
FWIW this worked before in JRuby 1.6
<madrob>
But that's not a strong position to take
<enebo>
madrob: yeah no doubt this changed when Ruby 1.9 came our since 1.6 was 1.8 only right?
<madrob>
yep
<enebo>
madrob: we use MRI's stdlib so this is m17n additions
<enebo>
ok so I just printed out what IO they use for ordinary irb session
<enebo>
weirdly at first is also prints out stdin (like it initializes twice)
<enebo>
madrob: so I don't know how reusable StdioInputMethod is but that is how they cope with that .encoding call
<enebo>
madrob: ah yeah you probably need to subclass this since they print a prompt on gets
<enebo>
madrob: but I think maybe just extending your own InputMethod class would be better
<enebo>
madrob: and their code for this look broken,... they set up a @stdout but then call a raw 'print' but I do not see any def print in any of those classes
<enebo>
I guess it no doubt works ok for irb since they just dump to stdout but why bother to make a special stdout wrapper if you do not call through it?
<enebo>
madrob: so my recommendation is to make your own InputMethod modelled after StdioInputMethod and pass that into ruby-lexer and things should be ok
<enebo>
madrob: if you wanted to engage MRI you could at least lobby they change 'io' to 'input_method' in ruby-lexer since it clearly will not work as an actual IO
<madrob>
I'm stretched a little to thin right now to be a good open source citizen
<enebo>
madrob: sure. that's fine too. it looks like then just make your own InputMethod type and you will be good to go
<enebo>
haha I don't even think @output is used at all either hmm
<enebo>
madrob: since I think the main issue here is irb using a poor name and not documenting this accepts an InputMethod I will close out our issue on this
<madrob>
That's fair. Can you open an issue with MRI about the naming?
<enebo>
you are not the only one stretched a little thin but I might
<GitHub126>
[jruby] enebo closed issue #4719: NoMethodError in RubyLex https://git.io/vQNsG
subbu is now known as subbu|lunch
<headius>
kares: RuntimeCache could go away in favor of just generating static code to create call sites
<headius>
it was a way to reduce the amount of generated bytecode when we need to have various types of caches for a piece of Ruby code
Osho has quit [Quit: Changing server]
Osho_ has joined #jruby
Osho_ has quit [Client Quit]
Osho has joined #jruby
subbu|lunch is now known as subbu
subbu is now known as subbu|busy
<GitHub48>
[jruby] headius pushed 1 new commit to ruby-2.4: https://git.io/vQNwD
<GitHub48>
jruby/ruby-2.4 03ba517 Charles Oliver Nutter: Fixes for our BigDecimal and our local test for it to match MRI.
<headius>
I'm so tired of working on this branch
jeremyevans has joined #jruby
<enebo>
it was the best of branch and the worst of branch
<headius>
to be fair I'm taking a lot more time to actually impl small 2.4 changes, but I just want this thing merged now