skade has quit [Quit: Computer has gone to sleep.]
enebo has joined #jruby
benlovel1 has joined #jruby
benlovell has quit [Ping timeout: 252 seconds]
bbrowning_ has joined #jruby
bbrowning has quit [Ping timeout: 245 seconds]
bbrowning_ has quit [Ping timeout: 265 seconds]
corbt has joined #jruby
<corbt>
hey everybody, I'm hoping to switch my rails app to jruby (for performance and easier clojure integration down the line)
bbrowning has joined #jruby
<corbt>
I'm just wondering what the general consensus is for jruby 9k stability -- should I target that, or stick to 1.7?
mje113__ has joined #jruby
<corbt>
I have some ruby 2.0+ syntax in my app, so it would be kind of a pain to downgrade
<corbt>
but if jruby 9k isn't recommended for production use, I can sort it out
<corbt>
any suggestions?
<enebo>
corbt: well largely 9kpre1 has not had a lot of serious problems and we plan on addressing most for pre2 but it is still a pre-release
<enebo>
corbt: If it works it works though so perhaps give it a spin and see if you encounter any issues first
<corbt>
ok, that's what I was figuring on doing anyway
<corbt>
enebo: any kind of timeline for when 9k will be officially released?
<enebo>
corbt: largely for a major release with so much changed I was surprised how few problems ended up coming back from pre1
<enebo>
corbt: we sort of need it released before the 2.2 requirement for Rails and we would like it quite a bit in advance of that
nateberkopec has joined #jruby
bbrowning_ has joined #jruby
<corbt>
enebo: ok great. I'll try it out and report back if I hit any bugs
mister_solo has joined #jruby
<enebo>
corbt: out of curiousity which 2.0+ features are you using?
slyphon has joined #jruby
bbrowning has quit [Ping timeout: 246 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/test-on-travis b568200 Christian Meier: debug on travis
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] mkristian created test-on-travis (+1 new commit): http://git.io/NUvW
<corbt>
enebo: just keyword arguments, to the best of my recollection
<corbt>
not refinements or any metaprogramming stuff
<enebo>
corbt: ok. pre2 should be better since we had a couple of bugs with kwargs but kwargs largely work in pre1
<corbt>
enebo: ok. When will pre2 be released?
<enebo>
corbt: main issue with kwargs for pre1 was we were destructive on the hash which stored kwargs so if you pass a hash for kwargs and want the hash after the call then you may have an issue
<enebo>
corbt: hopefully in a week or two
<enebo>
corbt: If you run into an issue it would be great to know so we can fix it for pre2 as well :)
bbrowning_ is now known as bbrowning
<corbt>
enebo: ok good to know. I'll look through my code but I don't think we do anything like that.
<corbt>
enebo: yeah I'll open an issue if anything breaks
<enebo>
corbt: great
<corbt>
enebo: thanks for the help, I'll be back here if I run into trouble
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
pglombardo has joined #jruby
slyphon has joined #jruby
slyphon has quit [Read error: Connection reset by peer]
slyphon_ has joined #jruby
<nirvdrum>
lopex: What's the best encoding-aware way to get a character from a ByteList at a provided offset?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/NUAs
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 92e4062 Thomas E. Enebo: NONLOCAL return in bodies
tenderlove has quit [Read error: Connection reset by peer]
tenderlove has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
cren_ has joined #jruby
cren_ has quit [Client Quit]
elia has joined #jruby
elia has quit [Client Quit]
elia has joined #jruby
<chrisseaton>
englishm: what does 2 interpreters mean?
<chrisseaton>
sorry, enebo ^^
<enebo>
chrisseaton: we select different bytecode interpreters based on scope
<enebo>
IR bytecode that is
<enebo>
chrisseaton: Sorry I started this as more of an experiement and did a poorer job than usual in my commit comments
<chrisseaton>
how do they differ?
<enebo>
chrisseaton: One interpreters scripts/evals/moule/class/metaclass bodies the other is for methods and closures
<enebo>
chrisseaton: venn the instrs used between the two and they have a lot of non-overlap
<chrisseaton>
so it's faster to have a simple interpreter for the first set of situations?
<enebo>
chrisseaton: profiling in hotspot imrpoved a little for methods since it was never seeing some instrs hit anymore
elia has quit [Quit: Computer has gone to sleep.]
<enebo>
chrisseaton: It unfortunately did not have much impact on startup time but seems to have improved perf for longer running interpreted runs
<enebo>
chrisseaton: but the reason I landed this with multple interps is I want to experiment with tiny interpreters for methods which contain very few instrs
<enebo>
chrisseaton: I also want to make a meta instr based on single use-def expression chains
<enebo>
chrisseaton: so we can see can try and eliminate the artificial load/stores
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 6 new commits to master: http://git.io/NTmz
<JRubyGithub>
jruby/master 3d59f20 Benoit Daloze: [Truffle] Looks like we are good now!
<JRubyGithub>
jruby/master 76e9453 Benoit Daloze: [Truffle] Report that we are in a block in backtraces similar to what MRI does.
JRubyGithub has left #jruby [#jruby]
elia has joined #jruby
<chrisseaton>
enebo: does it all come down to the size of the big switch?
<enebo>
chrisseaton: being able to replace the engines simply will make it easier to play
<enebo>
chrisseaton: it seems to have boiled down to that without a more radical change
Hobogrammer has joined #jruby
<enebo>
chrisseaton: AST interp I think does better because a) we are not emulating a machine with the ipc stuff in a loop and b) it naturally chains exprs from executing a node and just consuming the returned result
<enebo>
chrisseaton: fwiw our interp speed is not that important as long as we JIT the hot cold past startup perf
<chrisseaton>
enebo: i wonder if it would be worth quickly emitting custom interpreters for a given set of instructions as a first tier before actual jitting
<enebo>
chrisseaton: yeah we talked about that. I guess hotspot generates interpreters on the fly right?
baroquebobcat has joined #jruby
<chrisseaton>
I don't think so - in fact I don't think I've ever seen it done
mister_solo has quit [Ping timeout: 246 seconds]
<chrisseaton>
might be an interesting research project!
<chrisseaton>
for each method you jit an interpreter with just the instructions you need
<chrisseaton>
coupled with byte code quickening so you can get a small set of highly tuned instructions
<chrisseaton>
if you aren't inlining (probably aren't in an interpreter) might get good results for things like attr_readers
<enebo>
chrisseaton: and if you make enough they all inline through each other
koichiro_zzz has quit [Quit: Quit Nadoka 0.8.1+git]
pitr-ch has quit [Quit: Leaving]
<enebo>
chrisseaton: I thought about attr_* and just making Java versions for them
<enebo>
but with inlining we would want IR version
<enebo>
for IR inlining
<chrisseaton>
one advantage if you were using native code might be that it's more verifiable - a single set of machine code you emit, just in different combinations
<enebo>
chrisseaton: yeah. it seems pretty reasonable
koichiro_zzz has joined #jruby
<enebo>
chrisseaton: I guess startup time means probably not making all permutations but a small number of generated ones
<chrisseaton>
yeah if you did an empirical study you might find n combinations that are extremely common
mister_solo has joined #jruby
<enebo>
chrisseaton: I was post processing ir debug output and trying to figure that out a bit
dinfuehr_ has joined #jruby
dinfuehr_ has quit [Remote host closed the connection]
<subbu>
chrisseaton, we talked about this several times over the past couple years, but I think I may discouraged enebo a bit because this feels like "almost jit" .. i.e. why spend the time generating a custom interp, etc, if you can jit it instead?
<enebo>
chrisseaton: knowing of n scopes I am examing I can use a small set of instrs for some of them is great but I discovered those are not neccesarily the hot ones
<subbu>
i.e. where does this technique lie in the continuum of interp --> interp+jit-hot-code?
<enebo>
with that said if I can determine the hottest scopes in Rails event loop I can make special interps to run those better
<subbu>
interp -> interp+jit -> always jit ...
<enebo>
subbu: agreed. It is simple to lose sight of the goal
<lopex>
nirvdrum: index of that char in array or a codepoint ?
<enebo>
subbu: if JIT is for hot code then who cares if interp can run hot code well
<chrisseaton>
precompiled subset interpreters might work well for Ruboto
<subbu>
but, based on chrisseaton is saying .. maybe a good GSoC project or research project for sure ...
dinfuehr has quit [Ping timeout: 244 seconds]
<donV>
Huh?
<enebo>
chrisseaton: yeah definitely a reason why this might be worth doing eventually
<chrisseaton>
donV: you'll have to read all the way back :)
<enebo>
donV: *bonk*
<donV>
:)
<enebo>
donV: discussing IR interpretation
<enebo>
donV: Ruboto is a benefactor to that running well
<donV>
Very important for non-jitting environments!
<enebo>
Who: I remember you started looking at this and it had something to do with needing to change Signature or Arity or something like that?
dling has joined #jruby
<Who>
enebo: so there two examples, do you mean the #2015 example?
<nirvdrum>
lopex: Yeah.
<nirvdrum>
I know how to check for single byte optimization in the encoding.
<nirvdrum>
I'll look at the StringSupport methods you pointed at.
slyphon_ is now known as slyphon
<enebo>
Who: I meant the .arity part being wrong
yfeldblum has joined #jruby
<Who>
enebo: I think I looked at the 2nd one, the Signature/Arity one was a different issue IIRC (I sent a PR for that I think) but I can also fix this
<lopex>
nirvdrum: preciseLength is the equivalent of Encoding::precise_mbclen
<Who>
since I dealt with Arity/Singature issue before
<lopex>
nirvdrum: that name "find_character" is a bit misleading imho
<Who>
enebo: It’s fixed already, I tried on master
<Who>
enebo: I am getting this error, NameError: missing class or uppercase package name (`org.jruby.ext.openssl.OpenSSL'), caused by (NameError) cannot load Java class org.jruby.ext.openssl.OpenSSL
<Who>
when I try run specs
<Who>
but its not failing on travis
djellemah has joined #jruby
<mkristian>
Who, sounds like 'mvn clean install' should get openssl in place
<dfr|work>
mkristian, and if there's a match with decoded version, probably would need to decode entryPath too
<mkristian>
ah even further inside - ok
<dfr|work>
mkristian, that's the only place where the code checks for existence of the jar :)
<mkristian>
:)
<chrisseaton>
JRuby has an annotation processor so that core methods don't have to be added by reflection, right? Is it correct that I'm seeing the Object class's method being loaded by reflection then?
mitchellhenke has quit [Quit: Computer has gone to sleep.]
baroquebobcat has joined #jruby
gaustin has quit [Quit: gaustin]
<dfr|work>
Hey folks. I'm trying to do the following: allow ruby to define an on_change callback for osme ruby code to be invoked once stuff changes. The trick is that changing events are processed in a different thread
<dfr|work>
do I understand correctly that I shouldn't re-used the context that the on_change was invoked with for evaluating the block, right?
shellac has joined #jruby
viking has quit [Remote host closed the connection]
kith has quit [Ping timeout: 264 seconds]
<dfr|work>
seems like runtime.getCurrentContext is actually useful in that context :D