tlarevo_ has quit [Read error: Connection reset by peer]
tlarevo has joined #jruby
mister_solo has joined #jruby
jeremyevans has quit [Ping timeout: 245 seconds]
marr has joined #jruby
josh-k_ has joined #jruby
josh-k has quit [Ping timeout: 245 seconds]
drbobbeaty has joined #jruby
deobalds has joined #jruby
jeremyevans has joined #jruby
Hobogrammer has quit [Ping timeout: 250 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian force-pushed redefine-uri-classloader-meaning from 1bc0673 to 8341e05: http://git.io/cwP5fQ
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 0a34091 Christian Meier: redefine uri:classloader: meaning to be the parent classloader of runtime.getJRubyClassLoader...
<JRubyGithub>
jruby/redefine-uri-classloader-meaning f4c9d41 Christian Meier: added osgi test without inlining the dependencies
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 8341e05 Christian Meier: add testcase for the case where jruby.home is inside a jar but not on the context-classloader
JRubyGithub has left #jruby [#jruby]
calavera has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vyorkin has joined #jruby
vtunka has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
skade has joined #jruby
_whitelogger has quit [Ping timeout: 256 seconds]
_whitelogger has joined #jruby
zorak8 has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
shellac has joined #jruby
tcrawley-away is now known as tcrawley
mister_solo has quit [Ping timeout: 256 seconds]
vtunka has quit [Quit: Leaving]
tlarevo has quit [Remote host closed the connection]
tcrawley is now known as tcrawley-away
zorak8 has quit [Ping timeout: 244 seconds]
tlarevo has joined #jruby
triple_b has joined #jruby
triple_b has quit [Ping timeout: 264 seconds]
statonjr has joined #jruby
zorak8 has joined #jruby
vyorkin has quit [Ping timeout: 265 seconds]
mister_solo has joined #jruby
mike_ has joined #jruby
mike_ is now known as Guest3468
lance|afk is now known as lanceball
_whitelogger has joined #jruby
josh-k has quit [Ping timeout: 244 seconds]
tlarevo_ has joined #jruby
tlarevo_ has quit [Read error: Connection reset by peer]
<headius>
it's crashing in C1, though... can you try to reproduce with Java option -XX:-TieredCompilation please?
<headius>
stupid C1, always raining on our parade
<nirvdrum>
I just realized I was running with: -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-noverify -J-Xmx2G -Xcompile.invokedynamic=false -Xreify.classes=true
<headius>
something about that method
<headius>
nirvdrum: well that's good, actually...I would have had you try that if it weren't obvious it's C1 from the dump
<JRubyGithub>
[jruby] chrisseaton pushed 2 new commits to master: http://git.io/s5D8qQ
<JRubyGithub>
jruby/master dbd0f97 Chris Seaton: [Truffle] Remove a couple of unused nodes.
<JRubyGithub>
jruby/master 0e4c83c Chris Seaton: [Truffle] Annotate some nodes that don't result in any machine code, to better inform the inliner.
JRubyGithub has left #jruby [#jruby]
tcrawley-away is now known as tcrawley
viking has joined #jruby
<nirvdrum>
Well, that's interesting. I have an area of code that does something like: if defined?(::Sequel) do X else do Y. ::Sequel should be defined by virtue of loading the gem. The defined? check is true for a while and then is suddenly false. It works with JIT disabled.
viking has quit [Changing host]
viking has joined #jruby
<nirvdrum>
It appears to be a JIT bug of some sort.
<subbu>
nirvdrum, aha .. that is the same bug that i told enebo about wrt. activesupport 3.0.12 tests
<subbu>
where ::TZInfo goes missing in some scenarios ..
<subbu>
and where if you set JRUBY_OPTS=-X-C and run jruby -S rake .. all is well.
<enebo>
OMGZ
<subbu>
require 'active_support/tzinfo' unless defined?(::TZInfo) is the relevant piece of code there.
<enebo>
nirvdrum: so is this the super bug specifically?
<headius>
phooey
<headius>
are you trying to say my JIT isn't perfect?!
<subbu>
which also goes missing at arbitrary times .. for different values of city names in different runs.
<nirvdrum>
enebo: No. That one seems to have been fixed.
<enebo>
headius: well it is a world better than saying the IR logic is broken :)
<subbu>
nirvdrum, ah, nice short and sweet test case. you are good at it :)
<headius>
so defined?(Const) boils down to lexical + hierarchical search instrs
<enebo>
nirvdrum: chrisseaton noticed IR interp could crash the JVM and he made a patch which prevented his case from happening…perhaps this is a bigger problem
<headius>
Const becomes a single search_const instr
<enebo>
headius: they were split and the merged in one case probably should be all cases
<headius>
I suspect there's a bug in either lexical or hierarchical search that don't get hit except for here
<headius>
I will review them
<chrisseaton>
enebo: we never got to the bottom of that I'm afraid
<enebo>
chrisseaton: yeah but does this crasher look similar?
<subbu>
enebo, nirvdrum seems like the same crasher that chrisseaton encountered.
<headius>
enebo, chrisseaton: probably time we officially got Hotspot folks to look at it
<enebo>
oh of course it is
<headius>
enebo: it would be an incredible coincidence :-)
<enebo>
I just saw the stacktrace :|
<enebo>
Well I guess there are not many JVM crashes outside of JNI usage but he could have hit a bad jr-posix call
<enebo>
but it is crashing in chrisseaton workaround method
<chrisseaton>
certainly looks similar
<headius>
it's crashing in the Java code, compiled by C1
<chrisseaton>
can you try removing my workaround and does the crash look the same?
<chrisseaton>
last time it was crashing inside C2, not inside generated code, I believe
<nirvdrum>
I see scrypt in the mix. That's a JAR I load that appears to have a native component. Not sure how that would really impact things though.
<nirvdrum>
subbu: I'll file an issue for the JIT problem.
<enebo>
nirvdrum: this trace is still with JIT on I think
<nirvdrum>
enebo: Yes. I can try without it.
<enebo>
nirvdrum: Are you sure this happens with JRUBY_OPTS=-X-C?
<enebo>
nirvdrum: I mean it happens in the interp for places we didn’t or haven’t JIT’d yet but I am hoping we can remove some variables
<enebo>
I also suspect running with jnr-posix going native might make JVM engineers more receptive to accepting this as a JVM bug
<headius>
nirvdrum: I assue you did not have invokedynamic enabled
deobalds has quit [Quit: Computer has gone to sleep.]
imperator has joined #jruby
<headius>
nirvdrum: good repro, thanks
<nirvdrum>
enebo: No crash with JIT disabled.
<nirvdrum>
enebo, subbu: And with JIT disabled, all of my specs pass :-)
<headius>
ok, :: version falls into a runtime helper instruction
<headius>
nirvdrum: woohoo!
<enebo>
nirvdrum: wow great to hear
<headius>
pressure's on me now!
<enebo>
headius: or perhaps on MH imlementrers
<enebo>
headius: Java6 invokeer support could maybe take heat off you
<nirvdrum>
headius: Good call. It doesn't fail without the ::
<headius>
I think this is running without indy, right?
<headius>
it fails for me either way, in any case
<nirvdrum>
indy disabled, correct.
<nirvdrum>
The version string doesn't have +indy.
<headius>
subbu: ahhh, this is the one you meant about the JIT fallback failing
<headius>
I can fix the JIT issue...it's a signature mismatch on the helper method (which I will also tag with JIT so people know I'm using it)
<headius>
we also need to fix the fallback interp though
<headius>
some additional interp state that's not getting contextualized
noop has quit [Ping timeout: 256 seconds]
<enebo>
headius: fallback right now just continues using the same interpcontext as before JIT started right?
<enebo>
headius: We are not reset’ign state and calling prepareForInstructions again are we?
<headius>
shouldn't be...if I bail out I do nothing else to the IR
<headius>
my concern is that I'm going to fix this and it's going to be forgotten because we can't easily trigger it
<headius>
perhaps I should add a property that forces JIT to always fail after doing everything it would to run?
<enebo>
headius: ok so then maybe we are missing some state we should be saving into IC
<headius>
we'll be able to stress test a bit then
<headius>
enebo: that's my theory
<headius>
I have no idea what state though :-)
<enebo>
headius: but I am not sure what that could be unless there is some more IRScope.getFlags() happening in an interp impl in an operand or something
<headius>
defined?(::Const) uses IRRuntimeHelpers.isDefinedConstantOrMethod, which is pretty straightforward
<enebo>
headius: but I hope not. Most instrs no longer have IRScope
<headius>
it has to be the incoming receiver getting mucked up or something
<headius>
only thing that's variable there is the operand
<enebo>
subbu: I have wondered this and never asked but I see this in a few places…RuntimeHelperCall.callHelper we pass in currScope but in the method we don’t use it. Instead we asl dynscope for currScope. Are they ever different?
e_dub has joined #jruby
tenderlove has joined #jruby
<enebo>
And my question is not pedantically correct. We do use currScope in places but in other places we use the scope we get from dynscope
<nirvdrum>
Well, at least 9k is consistent. It'll crash both JVM 7 & 8.
<enebo>
headius: is that instr to lookup for ::?
<headius>
appears so
<enebo>
So defined? ::Foo will defined? ‘Object’?
<headius>
man, something in that logic it really doesn't like
<headius>
enebo: this IR is for defined?(::Object)
<enebo>
oh ok
<enebo>
headius: if I remember the IRBuilder logic generates some exception catching stuff around this
<headius>
subbu, enebo: Oh wait, it's not an IR bug
<headius>
enebo: yeah that's exactly it
rsim has joined #jruby
<enebo>
exception region stuff
<headius>
it's catching the JIT's failed call signature (probably NoMethodDefFound) and returning nil
<enebo>
yeah in protectCodeWithRescue
<headius>
so this is too broad
<enebo>
headius: so for IR bugs or impl bugs we should only be catching reasonable errors
<headius>
actually, why does this use isDefinedConstantOrMethod? Can :: be used to invoke a toplevel method?
<subbu>
headius, enebo sorry . i was away for a while .. but, back now. last i see is headius saying this is not an IR bug .. looks like you are hot on the trails of this one.
<enebo>
subbu: well it might be a builder bug
<headius>
you can't do ::foo
<headius>
::Array(1) doesn't work either
<headius>
I don't think this form can resolve to a method
<headius>
so it shouldn't need exception handling
<subbu>
enebo, ok.
<enebo>
headius: so it only hurts because it swallowed JIT bug
<enebo>
headius: I think this exists because const lookup could return a ruby exception
<enebo>
headius: but we should not be calling an exception path for that
<subbu>
enebo, reg. currScop eand dynScope ... good qn. let me take a quick look.
<enebo>
headius: we need an annotation for Ruby exception/important non-checked internal methods
<enebo>
headius: so at a glance we can tell whether something can raise
<headius>
enebo: I think if it boils down to just const lookup, this can't raise
diegoviola has joined #jruby
<headius>
it uses getConstantFromNoConstMissing, which should never trigger an error
<headius>
it will just return null if it's not found
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/WvV3oA
<JRubyGithub>
jruby/master c3b80aa Charles Oliver Nutter: Fix defined?(::Object) logic in JIT. Partial fix for #2090....
JRubyGithub has left #jruby [#jruby]
<headius>
nirvdrum: fix is in for you...we'll continue to sort out what needs to change in IR
<headius>
if it works with default JIT threshold, next step would be to try a run with jit.threshold=0
<enebo>
headius: I would love to get rid of all of the excption handling in defined
<headius>
also, there's different logic for parts of JIT for indy and non, so if you can test indy that would be great too
<headius>
enebo: me too
ludyte has joined #jruby
<headius>
most don't need it if we just do more active lookup rather than "run this and see if it blows up"
<nirvdrum>
headius: So, some is exception is being raised and then swallowed?
<enebo>
headius: I was able to remove from several by leveraging RubyRuntimehelpers
<nirvdrum>
headius: Fix confirmed.
<chrisseaton>
headius enebo: I thought the semantics of defined? specifically included that if any exception was raised it returns nil? so you need to handle normal user exception don't you?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/JqnzVA
<JRubyGithub>
jruby/master a8db1a0 Charles Oliver Nutter: Mark runtime_helper helper methods with JIT annotation.
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: yes, but that only needs to apply when the expression being tested is too complicated to determine without running it
<headius>
method calls don't have to fall under that category if the logic to look them up and not find them is equivalent to the logic to just run the call and let it fail
<headius>
there's some interplay with method_missing, respond_to_missing? here as well...that may complicate some cases
<headius>
nirvdrum: excellent
bbrowning is now known as bbrowning_away
<headius>
nirvdrum: the JVM6 JIT backend has several cases where it does less caching (or no caching) than 1.7, so don't expect perf to be where it should be (for that and other reasons)
<headius>
if you are able to find specific cases that are bad, those should be filed
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 5 new commits to master: http://git.io/SUAMfA
<JRubyGithub>
jruby/master 4cc5aff Benoit Daloze: [Truffle] +@ should be defined on Numeric.
<JRubyGithub>
jruby/master 850d9c8 Benoit Daloze: [Truffle] Move #nonzero? to Numeric.
<JRubyGithub>
jruby/master 35ee548 Benoit Daloze: [Truffle] Move #times to Numeric.
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
JVM6? I've only tested with 7 & 8.
<headius>
sorry, I mean the default JIT mode that doesn't use indy
<headius>
JVM6 versus JVM7 bytecodes
<nirvdrum>
Ahh.
statonjr has quit [Quit: statonjr]
pchalupa has quit [Quit: Leaving]
<nirvdrum>
headius: Well, I run into new problems with indy enabled.
<nirvdrum>
Seems to be either a super or varargs issue: wrong number of arguments (1 for 2)
<headius>
very nice but still requires us to mark up all resumable call paths with checked exceptions
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
skade has quit [Quit: Computer has gone to sleep.]
<headius>
chrisseaton: good lord truffle generates a lot of classes :-)
obs has quit [Quit: Leaving]
<rtyler>
dat permgen
<headius>
1/3 of the total in jruby.jar
<rtyler>
quasar's fiber implementation isn't useful for mapping Ruby fibers into the JVM?
<headius>
rtyler: it would require a very large rework of our codebase unfortunately
<headius>
every method that can potentially call back into Ruby would have to handle this new exception type used by the fiber stuff
baroquebobcat has joined #jruby
<headius>
some of those would propagate up and not have to be directly dealt with, but many of those methods are public APIs and they'd suddenly have a new checked excep tion
<headius>
oif
<headius>
the cloudbees instances are fedora 17
<rtyler>
headius: understood, but based on my understanding of the calling into java from jruby support, I /should/ be able to use this if I'd like right?
<headius>
as long as whatever you call never calls back through APIs that don't know about fibers, sure
<rtyler>
hrm
statonjr has quit [Quit: statonjr]
<headius>
those libraries are extremely limited in what they can do, since every call that you want to be resumed has to be aware of their framework
erikhatcher has joined #jruby
<headius>
I think some of them can do classloader tricks to dynamically modify code that doesn't explicitly know about fibers, but I've never seen it work
<rtyler>
hrm, sounds like similar problems to coroutines in python
<rtyler>
but at least there we had greenlets to do stack swapping and shit
<headius>
chrisseaton: ok if I cancel some of these small commit builds? They won't be green without the commit I just made
<headius>
just making sure you and eregon aren't monitoring them
<nirvdrum>
Let me know if you run out of things to do :-P
<chrisseaton>
headius: yeah
<chrisseaton>
headius: you're always free to cancel Truffle builds if they are in your way - we have a duplicate CI system
Areessell_ has joined #jruby
<headius>
chrisseaton: ok, thanks
<chrisseaton>
headius: the number of classes will hopefully go down as we move more stuff to Ruby - but yeah I know it's not ideal, and not much we can do really at the moment
<chrisseaton>
headius: they shouldn't get loaded unless you use Truffle of course - so for a user who doesn't want anything to do with Truffle the only penalty we're imposing is a compile time dependency on Java 7 and a bigger jar
<headius>
chrisseaton: no worries...we may have to consider an additional jruby maven artifact that has no truffle, or a new artifact that DOES have truffle
yipdw has quit [Quit: No Ping reply in 180 seconds.]
yipdw has joined #jruby
<headius>
there will be folks with maven deps that aren't excited about pulling in some oracle library they're not familiar with, even if it's not used
<chrisseaton>
yeah, we'll work with you on it when you get complaints - maybe nobody will care
<headius>
ok
<headius>
enebo, subbu: nirvdrum's latest is an IR bug
<headius>
check_arity makes calls that eventually depend on context.getCurrentScope just to get StaticScope to look for argument names
<headius>
but it does not load that scope using IR
imperator has quit [Ping timeout: 244 seconds]
<headius>
and it is obviously not something we want to deopt for :-)
<enebo>
headius: ah simple enough but I may take a stab at fixing arity itself
<headius>
it should have a CurrentScope operand
<headius>
I believe
<headius>
enebo: fixing arity itself?
<enebo>
headius: After I vote (and probably) eat I will do cheapest fix and then try and make a reasonable Arity object
<enebo>
headius: we don’t support kwargs in arity which we use Arity for method.arity and others
<enebo>
headius: so we need a richer way to represent arity now
<enebo>
headius: and we might as well calculate it at parse time
imperator has joined #jruby
<enebo>
headius: but I should look at MRI is now doing too
<enebo>
headius: but first step is stuffing arity into IC
vyorkin has quit [Quit: WeeChat 1.0.1]
<headius>
enebo: I can hack JIT to just use current static scope but it means introducing a separate checkArity helper that's mostly the same as the one interp us using
<headius>
this fails in JIT because the scope is optimized away and doesn't match anymore
<enebo>
headius: You can also grab it from DynamicMethod at runtime?
<enebo>
headius: for that matter IR Interpreter could if it actually passed a method ref into Interpreter
<subbu>
wow man .. how many things have had to be fixed even though I got rails booted up, gems installed, rails server running back in 2012 ... of course, we have made many ir design changes as well .. but still ...
<headius>
enebo: actually I may be wrong about this causing nirvdrum's issue, but it's definitely a bug
<headius>
I think the bug I found requires kwargs to be involved
<headius>
let me try to reproduce
<headius>
enebo: all method bodies in JIT get StaticScope passed in now
<headius>
for call protocol, const lookup, refined invocation
<headius>
I can pass that through to anything that needs it and have no DynScope requirement
<enebo>
headius: going to vote…I will be back
<headius>
ok
e_dub has quit [Quit: ZZZzzz…]
BobFunk has quit [Ping timeout: 244 seconds]
tlarevo has joined #jruby
<headius>
subbu: to be fair, most of these are being driven by JIT and optimization...IR minus those things works right
triple_b has joined #jruby
vtunka has quit [Quit: Leaving]
<headius>
huh, this is an interesting one
<headius>
an instance super is getting compiled as a regular call
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
subbu: Did that commit fix the ActiveSupport tests for you?
statonjr has joined #jruby
shellac has quit [Ping timeout: 255 seconds]
<subbu>
nirvdrum, i haven't tested yet .. will play with it later today.
<subbu>
headius, true reg. opts and jit.
skade has joined #jruby
dabradley has joined #jruby
pietr0 has joined #jruby
Hobogrammer has joined #jruby
imperator has quit [Quit: Leaving]
<rtyler>
is there a document with an updated release timeframe for 9000?
<headius>
a document...no, not really
<headius>
plan is preview for rubyconf and final for xmas right now
<rtyler>
will it be called jruby 1.8? :P
<rtyler>
I'm trying to determine what my team's forward looking strategy should be to migrate Lookout internal teams off of 1.7 onto whatever is next
<rtyler>
this is where release timeline and EoL docs are super helpful
<headius>
it will be JRuby 9.0.0.0
mister_solo has quit [Ping timeout: 260 seconds]
<rtyler>
r u j/k?
BobFunk has joined #jruby
<headius>
no, that's what it will be...it's sufficiently high we'll never conflict with MRI and not unreasonable considering the number of major releases JRuby has had
<rtyler>
heh, okay
<headius>
huh...turns out 1.0, 1.1, ... 1.7 is 8 major releases
<headius>
if we'd numbered them like majors we'd be at 9 now anyway
<rtyler>
heh
<nirvdrum>
The java version naming strikes again!
<rtyler>
do you have a timeline for the 1.7 series ceasing to be thereafter?
skade has quit [Quit: Computer has gone to sleep.]
Areessell_ has quit [Quit: (null)]
<headius>
rtyler: I'd guess it will be at least a year, as painful as that might be
<headius>
9k removes 1.8 support and reworks a lot of internals, so there will be some migration time
<rtyler>
thinking 9k will follow the same one month release cadence 1.7 has?
skade has joined #jruby
<headius>
ideally yes
phrinx has joined #jruby
<rtyler>
hrm
<headius>
maybe faster than that initially as reports come in
<rtyler>
I'll have to noddle on what our support cycle is going to be then
<nirvdrum>
Maybe I fat-fingered the args. A second set of eyes would be good.
<headius>
well NPE is not expected in any case
<headius>
oh, -X+C
iamjarvo has joined #jruby
<headius>
that's a bit different than threshold=0... anything that fails to JIT will immediately terminate the system
<subbu>
and on 3.2.13 activesupport, i get 11F/5E (jruby 9k master) vs. 7F/5E (jruby 1.7)
<headius>
that's *forced* JIT, rather than just immediate JIT
<headius>
subbu: oh neato, things to fix!
<subbu>
not sure if it is related to ruby version diffs .. but, not too bad.
<nirvdrum>
headius: Duh. Thanks.
<headius>
nirvdrum: I will look into that NPE anyway
<nirvdrum>
It's time for another coffee.
<headius>
some things are expected to not JIT at the moment, like really large methods
ephemerian has quit [Quit: Leaving.]
<headius>
they will fail with arbitrarily peculiar exceptions under -X+C
<nirvdrum>
Well, that script doesn't have anything really large.
<nirvdrum>
But, understood.
rsim1 has joined #jruby
<nirvdrum>
So, not doing -X+C works. Thanks!
<headius>
cool
<nirvdrum>
+indy crashes the JVM as well, FYI.
<nirvdrum>
(when running my full rake)
rsim has quit [Ping timeout: 265 seconds]
<enebo>
headius: Those chars in persistence was a change so if I looked at the binary I could sort of read what operand was being encoded so there is no restriction. Operand type is a single char
<dfr|work>
*sigh* why is activerecord-jdbc-adapter so frigging complicated? :(
<enebo>
headius: Are you adding a new operand?
<headius>
I needed something for JIT to be a placeholder for aconst_null
triple_b has joined #jruby
<enebo>
headius: at IR level?
<headius>
I had some generic code in JIT that just accepted operands, but for one consumer that particular operand is not available and replaced with null
<headius>
I could pass a flag for it too if adding an operand is not appropriate
<nirvdrum>
dfr|work: Gotta use Sequel.
<dfr|work>
nirvdrum, stickign to AR for now, thank you very much ;)
<dfr|work>
nirvdrum, but am considering rolling my own adapter =/
<enebo>
headius: So this operand will not be put into a CFG or any place like that. You are just replacing a null with a null object pattern?
<headius>
basically
<nirvdrum>
It's amazing how much easier my life got after I moved. Moving was a PITA though.
<enebo>
headius: I wonder if you could use a single instance of Label named NULL :)
<headius>
nirvdrum, dfr|work: I'd pay real money to get someone to switch AR's backend to Sequel
<enebo>
Label is a no value operand
<headius>
it would make our job supporting Rails a million times easier
<nirvdrum>
tenderlove: ^
<headius>
anything to get rid of custom adapters that use C exts
<headius>
ANYTHING
<headius>
I will donate a kidney if it will help
<nirvdrum>
Sequel optimizes incredibly well, too.
<dfr|work>
headius, so that it would be using sequel rather than connection adapter stuffs?
<headius>
enebo: seems weird
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
headius: but it is stateless and can be a singleton?
<headius>
yes
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/2mGBBQ
<JRubyGithub>
jruby/master 74b86d6 Charles Oliver Nutter: Actually implement Null in JIT.
<JRubyGithub>
jruby/master dd69e08 Charles Oliver Nutter: Fix forced-compile loading of files.
JRubyGithub has left #jruby [#jruby]
marr has quit [Ping timeout: 245 seconds]
<enebo>
headius: then you can make Operand NULL = new Operand() { where you pass operand type of label } since it is not really going to enter back into the system
zorak8 has joined #jruby
<headius>
nirvdrum: ^ lets your original example script run with -X+C for me...I forgot to actually implement Null in the JIT
<enebo>
headius: then it will only exist in the JIT and we do not need a bogus type for something not part of IR instr set
postmodern has joined #jruby
<headius>
and the NPE was bad code in the forced-compile load logic
subbu is now known as subbu|lunch
<headius>
enebo: hmm...overloading Label for this purpose still seems wrong
<headius>
are you saying to still have a Null operand but of type Label and only the visitor logic actually gets used?
<headius>
maybe even error on interpret
skade has quit [Quit: Computer has gone to sleep.]
<enebo>
headius: current operandType is only used for two things but I could reduce it to one
<enebo>
headius: actiually new Operand with operandType as null
<enebo>
headius: Then it NPE’s if used in the wrong thing
<enebo>
headius: right now it is used by CFG but that should be made an instanceof
<enebo>
headius: otherwise it is only used by persistence
<headius>
hmm
<enebo>
headius: making an operand so you have appropriate operndtype means having to document this type in operands which has nothing to do with operands
<enebo>
headius: If you do want a Null we can do it but one layers impl artifact it would be nice to keep that exclusively in the JIT layer
<nirvdrum>
headius: Fix confirmed.
<dfr|work>
nirvdrum, any way, I'm not sure switching to sequel will nbe helpful to me, since that's just trading one jdbc abstraction for a different (albeit better) jdbc abstraction =/
<headius>
enebo: I think it sounds easier for me to just pass a flag then
<dfr|work>
but both have features I don't need and I will still have to likely hack things :(
<enebo>
headius: so where is the flag?
<dfr|work>
nirvdrum, right now I need to add support for seamless reconnect to a different mysql server if an existing connection goes down >.<
<nirvdrum>
dfr|work: Might be better off using a proxy.
<dfr|work>
nirvdrum, hmmm?
<nirvdrum>
Since ActiveRecord really doesn't have an API to code against.
<dfr|work>
nirvdrum, tell me more.
oblutak has quit [Quit: Page closed]
skade has joined #jruby
<nirvdrum>
dfr|work: On the postgres side, there are tools like pgpool and pgbouncer that sit between the client and the DB servers. I'd be surprised if there isn't something similar for MySQL.
<dfr|work>
nirvdrum, ah. No, that's extra operational overhead.
<nirvdrum>
I think people have even written HAProxy modules for things like that.
<JRubyGithub>
jruby/master 9a83034 Thomas E. Enebo: Use instanceof for WrappedIRClosure here since next line is a cast to WrappedIRClosure. It also reduces OperandType to be used only for persistence
<headius>
tenderlove: the JDBC adapters have to duplicate a ton of logic
<headius>
every time rails changes something in the provided adapters, ours break
<headius>
because they're all custom written to that database's C ext
Areessell_ has quit [Ping timeout: 264 seconds]
<headius>
Sequel provides a JDBC-like API for both C Ruby and JRuby
<headius>
so it would eliminate the need for us to supply our own handwritten adapters
<headius>
^ by FAR the biggest time sink for us supporting rails
<multibot_>
File "<stdin>", line 1
<multibot_>
by FAR the biggest time sink for us supporting rails
<multibot_>
^
<multibot_>
SyntaxError: invalid syntax
<tenderlove>
adding *another* abstraction between AR and the database sounds like *loads* of fun
mister_solo has joined #jruby
<tenderlove>
:P
<headius>
you'd have less to maintain too
<headius>
ideally a lot of duplicated logic across databases would go away
<headius>
there'd be a single way to establish a connection, execute a statement, walk a result set
<tenderlove>
I'm sure we'd have to maintain db specific quirks
<headius>
of course
<headius>
but you wouldn't have to do what sequel does for every database Rails supports, and databases Rails doesn't support could fall back on default logic...sequel supports more databases
<tenderlove>
idk
<headius>
the fact that AR *isn't* build atop a shared DB library is a travesty, really :-(
<tenderlove>
there's *tons* of knowledge in the adapters we have.
<headius>
mostly as regards building queries
<headius>
that wouldn't change
<tenderlove>
"just replace with sequel" sounds like a pipe dream
<headius>
what would change is that you wouldn't have N different ways to work with a database...you'd have one, and query builders to handle quirks
<headius>
not replace
<headius>
AR would *use* sequel as its access to the actual DB
<headius>
hell, we've proven it's possible because sequel is basically jdbc, and we provide those databases just atop jdbc
<tenderlove>
so send a patch
<tenderlove>
just make sure the tests pass
<headius>
well, that's the problem...there are others with a hell of a lot more experience in AR internals than me :-)
<headius>
I could take a month of from JRuby :-D
<tenderlove>
I too have better things to do.
<headius>
I'm not criticizing in any way...you seem to have taken my intent wrong
<headius>
what's there grew organically out of one database
<tenderlove>
headius: I'm just giving you a hard time ;-)
<headius>
yes, you are
statonjr has quit [Quit: statonjr]
mister_solo has quit [Ping timeout: 240 seconds]
<headius>
tenderlove: and fwiw, I wasn't the one who pinged you about it :-)
zorak8 has quit [Ping timeout: 244 seconds]
<headius>
but once that had passed, might as well dogpile!
<tenderlove>
hahah
<nirvdrum>
tenderlove: 'tis a time when someone suggesting merb merge with rails would have been fed the pipedream line!
<headius>
I'd love to fix this...it's just such a massive time sink for us to maintain all our own adapters that basically do the same thing as standard ones
<headius>
we can't keep up
<tenderlove>
good news: I'm burned out on AR, so I will probably not make many changes
<nirvdrum>
I'd be happy if AR just had an internal API to write against. Anything that claims to be an AR plugin is just a mess of monkeypatching against its internal adapters :-(
<nirvdrum>
But I understand how it's evolved.
<headius>
jeremyevans: didn't someone do a prototype of AR atop Sequel at one point?
<headius>
tenderlove: hopefully you can give us some tender loving guidance if we find someone to attempt it
<nirvdrum>
headius: Trying to talk around how I pinged him?!?!
<headius>
from what I see in the adapters on master, sequel would be easy
<headius>
or at least a straightforward conversion
BobFunk has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
headius: Breaking existing "plugins" would probably cause people to raise hell. You'd have to target it for a major release.
<headius>
your work on ARel should make it a lot easier
statonjr has joined #jruby
<headius>
nirvdrum: that may or may not happen
<nirvdrum>
People getting upset about the plugins?
<nirvdrum>
I'm almost certain it will. Some of the postgres ones are rather popular.
<headius>
no, I mean breaking them
<headius>
I haven't seen much so far that wouldn't be 1:1 in sequel...structure of the adapters would stay mostly the same
tlarevo has quit [Remote host closed the connection]
<nirvdrum>
The problem is most of these plugins are implemented by monkey-patching the underlying adapter. So they don't even work with ARJDBC.
<nirvdrum>
Or need to be substantially changed to support both.
<headius>
another huge reason
<nirvdrum>
Oh, I don't disagree. I'm just saying to fix that means breaking the rest of the ecosystem. Unless you ship both and run in some sort of switched mode configuration.
<nirvdrum>
Thus requiring to be a major release.
<nirvdrum>
Having said that, the Sequel API is pretty nice for plugins. So porting efforts shouldn't be that bad.
<nirvdrum>
This is more of a political problem than a technical one, methinks.
<jeremyevans>
headius: I'm not aware of anyone doing an AR prototype atop of Sequel
<headius>
creating a connection, escaping incoming sql, ping, executing a query, last inserted ID, and query options
<headius>
that's about it
<jeremyevans>
Before it used ARel, there was talk of it using Sequel instead of ARel, but I've heard nothing about it since it decided to go with Arel
<Antiarc>
Is there are project guideline for when to use single class imports vs import-on-demand?
<headius>
jeremyevans: I'm right in thinking all of those actions would be easily supportable atop sequel, right?
<Antiarc>
I ran intellij's "optimize imports" on jruby-core to see if it could clean up unused imports and it ended up collapsing imports where there were 5+ improts from the same package into import-on-demand imports
<Antiarc>
But then I tried it without the collapsing and it expanded a number of import-on-demands into explicit lists :)
<headius>
Antiarc: almost always single class imports
<nirvdrum>
Antiarc: You can disable that in IntelliJ, FYI.
<nirvdrum>
Or bump the threshold.
<Antiarc>
nirvdrum: Yeah, I know, I did for the second run
<headius>
if it's more than 20 we will sometimes do a wildcard
<Antiarc>
Okay, good to know. I'm taking a quick trip through the codebase, trimming out trailing whitespace and cleaning up used imports
iamjarvo has joined #jruby
<headius>
I don't think we have a hard upper limit, but there's few files that import enough from the same location to warrant a wildcard
<Antiarc>
(because, for some reason, that stuff annoys the heck outta me)
zorak8 has joined #jruby
<jeremyevans>
headius: I'm guessing it is possible to write AR on top of Sequel, though I doubt you could get 100% compatibility
<Antiarc>
I'm getting " java.lang.NoClassDefFoundError: Could not initialize class jnr.enxio.channels.Native$SingletonHolder" after pulling your changes now, even after a clean build, hm
<headius>
Antiarc: oh, ugh
rsim has joined #jruby
<headius>
there's a known issue with JVM not finding 64-bit lib on fedora/rhel
<Antiarc>
Odd, why would it just start failing now?
<headius>
I'm not sure
<Antiarc>
I just found the existing issue about it, will poke around
<headius>
it shouldn't have just started failing :-\
<Antiarc>
2efa00133faef1fd22f3c2761f86896b62569175 is the only commit I didn't have locally
<Antiarc>
Which was the update to invokebinder 1.4
<headius>
very strange
<headius>
harumph
<headius>
I'll bring up a fedora instance I guess
<Antiarc>
actually, no, other stuff got merged
<Antiarc>
I'll bisect it, no worries
<dfr|work>
headius, I'm not sure that throwing more abstraction will necessarily help things in terms of activerecord driver support >.<
<headius>
it has been around for some time on master, so if you're able to find a commit that would be huge
<headius>
dfr|work: honestly, I think this abstraction is already there
<dfr|work>
although I do concede that sequel's jdbc code looks at least simpler than activerecord-jdbc-adapter =/
<headius>
they're using N different DB APIs that largely do the same thing
<headius>
this would reduce it to one DB API
<headius>
across MRI and JRuby, even
<dfr|work>
headius, I think then it's essentially replacing abstract_adapter with sequel =/
<dfr|work>
which is reasonable, I suppose.
<headius>
yes, or even lower, making the concrete adapters (Mysql2Adapter, etc) call into sequel rather than directly into C ext
<headius>
either way jruby would work for free then
<headius>
no config changes, no separate gems for adapters
<dfr|work>
headius, I feel that's icky: you'll have: AR -> Arel -> adapter -> sequel -> jdbc, whereas right now it's AR -> Arel -> adapter -> jdbc, although adapter -> jdbc step is very very ugly code.
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dfr|work>
abstract_adapter effectively provides a low-level interface for DB operations, and seems that's exactly what sequel does too =/
<headius>
jeremyevans: how heavy is the abstraction for, say, getting a connection or executing a query?
<headius>
dfr|work: that could be true...but the C ext calls are in the concrete adapters
<headius>
mostly because they're different for every database, which is exactly what this would fix
e_dub has joined #jruby
<Antiarc>
You know what...I installed a bunch of libs to do an Android build this morning.
<jeremyevans>
headius: connection handling in Sequel is transparent to the user, internally it's purely block based, with an ensure that the connection is checked back in
<Antiarc>
I'll betcha that pooched my env and broke jruby.
<jeremyevans>
For executing a query, Sequel has a few different methods, depending on whether you want to return results, get number of affected rows, retrieve the auto incremented primary key value after inserting, etc.
JohnBat26 has joined #jruby
mister_solo has joined #jruby
<jeremyevans>
results in Sequel are always returned as symbol-keyed hashes though, and since AR uses string-keyed hashes (and AR::Result an array or something), using Sequel would probably slow things down
<headius>
jeremyevans: 36 is in, partial fix for 38 is in
<headius>
should be a full fix when I actually make OpenBSDTimeval use the right widths
subbu has quit [Ping timeout: 250 seconds]
<jeremyevans>
headius: Awesome!
<headius>
hmm
<jeremyevans>
Note that on OpenBSD/amd64, suseconds_t is going to be 64-bit, not 32-bit (since long is 64-bit on amd64)
<jeremyevans>
I think that the SignedLong type takes care of that, but I'm not sure
<headius>
yeah I'm not sure either
<headius>
it should
<headius>
jeremyevans: actually if you have freedom to try this out you could do a small PR with the right struct fields
<headius>
I was about to push it with Signed32 for tv_usec but I'd be pushing blind
<jeremyevans>
headius: Sure, if you send me what you have, I can probably test first
<headius>
jeremyevans: it's pushed
<headius>
sorry, it's pushed now
<headius>
anything else that needs timeval will need similar treatment, or an overridable allocTimeval like we have for stat
<jeremyevans>
I don't think this fixes the API issue, though
<headius>
no?
<jeremyevans>
Unless long in Java is always 64-bit?
<headius>
it is
<headius>
long, int are always signed 64, 32-bit
auxbuss has quit [Quit: I'm gone.]
<jeremyevans>
OK. I'll play with it and see if I can get it to work. I think tv_sec needs to be Signed64 just by looking at it, though
<jeremyevans>
SignedLong on OpenBSD/i386 is going to be 32-bit, not 64-bit
<headius>
oh right
<headius>
so it should be forced to full 64 always
<jeremyevans>
correct
<jeremyevans>
the tv_usec can remain SignedLong
skade has joined #jruby
<headius>
I'll let you fiddle with it and watch for PR then
<jeremyevans>
headius: OK. I'll ping you when it is ready
<headius>
Aethenelle/tbuehr was working on getting vagrant instances set up for testing jnr-* but I'm not sure how far he got
<headius>
we really need a way to test across our supported platforms with every commit
<headius>
er, tduehr on github
e_dub has quit [Quit: ZZZzzz…]
diegovio1 has joined #jruby
diegoviola is now known as Guest44162
skade has quit [Ping timeout: 264 seconds]
Guest44162 has quit [Ping timeout: 256 seconds]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Antiarc>
headius: uninstalling glibc.i686 (which got erroneously installed this morning) solved the issue
<Antiarc>
I'm not quite sure where the load paths for jnr-ffi get set, but it looks like it's just taking the first match for the library that it finds, which was the i686 version rather than the x86_64 version
<headius>
Antiarc: ah! that's very helpful!
<headius>
perhaps jffi needs to gain smarts about lib64
<Antiarc>
Would it make sense to find *all* libraries in the search paths that match the requested library, iterate them, and try to load them until it succeeds?
<headius>
that's what I'm thinking
e_dub has joined #jruby
<Antiarc>
That way if it finds i686 first, it can try to load it, fail, then continue on to find the x86_64 version
<headius>
or at least try both 32 and 64 bit paths
<Antiarc>
So I think that Time#localtime in 1.7.16 is actually wrong. The doc says it modifies the receiver, but if you pass an offset it returns a new Time
<headius>
hmm
x1337807x has joined #jruby
<headius>
I wouldn't be surprised
<enebo>
headius: That defined? for colon2/colon3 cannot remove exception unless I split the logic between primary value as lhs and simple constant as lhs
<enebo>
headius: not sure we care enough to add more code for defined? code
<headius>
enebo: doesn't matter a great deal to me as long as the the static scope load is reflected in operands
<enebo>
wha? :)
<headius>
and as long as it is not swallowing Throwable :-)
<enebo>
headius: yeah I think that is the bigger issue
<headius>
oh wait, sorry, I got my stuff mixed up
<headius>
this is fixing the Throwable thing
<headius>
scope load was check_arity
<headius>
still outstanding
<enebo>
I can fix it for simple case but lhs can be any code at all
<headius>
right
<headius>
simple case fixes are the name of the game for optimizing defined
<enebo>
and that code in theory could return any exception
<enebo>
headius: but do we care?
<headius>
we didn't before and eventually I had to start rewriting Ola's defined logic in JIT
<enebo>
I can do it and it will be like 5 more lines of code but I guess I wonder if this is used past prologue crap
<headius>
we did get reports
<headius>
exception handling isn't going to be a big deal perf wise though
<enebo>
hah
<headius>
well, unless you have a defined?(:: Const) that fails every time forever
<headius>
that would be a problem :-)
<enebo>
yeah even Foo::Bar
<enebo>
I think Foo cannot be Foo()
<headius>
ch risseaton: How expensive is it to build a stack trace in the truffle stuff? Have you measured it?
rsim has quit [Quit: Leaving.]
<headius>
with default JVM settings, just acquiring the JVM stack trace takes >1ms for us
<headius>
not to mention the massive amount of garbage created
<subbu>
i think we have bigger perf. fixes to fry, no? (so says a vegetarian :)).
cprice404 has quit [Read error: Connection reset by peer]
<subbu>
*fishes
cprice has joined #jruby
<enebo>
headius: fwiw this will virtually never actually throw
<headius>
subbu: I was going to say...perf fixes are vegan
<subbu>
:)
<enebo>
It still has to potentially throw I guess even though it won’t in the simple cases
<enebo>
I will add a FIXME: That we can optimize and specify which cases
<chrisseaton>
headius: I haven't - it requires a full deopt - but maybe a stack trace in a normal JVM needs that anyway
<chrisseaton>
1ms seems a bit extreme though
mister_solo has joined #jruby
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
Hell with it I can make this line number zero sum
mister_solo has quit [Ping timeout: 265 seconds]
ludyte has quit [Quit: ludyte]
<headius>
chrisseaton: it's really extreme, and I don't think it deopts either...I think the overhead is in mapping JITed frames back to the right stack trace elements
<headius>
if I reduce the number of frames Hotspot provides in backtraces the cost goes down accordingly
<chrisseaton>
that mapping is most of the work of deopt anyway
x1337807x has joined #jruby
<chrisseaton>
have you seen a non-translated Truffle stack trace? it's looooong - it's fairly neat though, just long
<headius>
this will be an area to explore...the majority of cases only need a small number of caller frames
<Antiarc>
Okay, so this is really confusing --
<headius>
I have wanted to prototype a JVM API to just get previous N frames but never got around to it
<Antiarc>
the new stdlib asserts that for a time: 2001-02-02 10:20:30 +0000, #utc? => false
<Antiarc>
The utc_offset is false, but utc? and gmt? are both false and asserted as such
<chrisseaton>
headius: but the problem is it's been generated by the time you get your hands on it isn't it?
<headius>
there may be some stuff coming along in recent 8 and 9 builds but obviously we can't depend on that
<Antiarc>
This makes web-developer-me want to fall over twitching and screaming
<headius>
hahah
<headius>
yeah, I have no explanation for that :-)
josh-k has quit [Remote host closed the connection]
<headius>
I will remain optimistic that there is one
josh-k has joined #jruby
<Antiarc>
If I understand the MRI changeset properly, it's that the RFC says that only times which are explicitly UTC are considered UTC
viking has quit [Remote host closed the connection]
<Antiarc>
Times which happen to be UTC+/- 0 aren't
<headius>
Antiarc: down to 228 locally with some minor fixes and excludes
<Antiarc>
Nice, I'll have another batch of fixes in a couple of minutes
<headius>
ok cool
<headius>
I'm looking for other big wins
<headius>
enebo: bunch of new ripper failures...ok if I just tag them?
<Antiarc>
Just running the full MRI suite before I push
<enebo>
yeah. They are missing parser logic for complex/imaginary
<headius>
mostly yeah
<Antiarc>
LoadError: library not found for class Digest::RMD160 -- digest/rmd160 -- looks like an implementation detail, shouldn't be too hard to wire up. That's a handful of tests
<headius>
enebo, subbu: that enumerable/lambda issue is a whole bunch of failures
<headius>
Antiarc: that's gone...they removed Digest::HMAC and we still had the test and lib in repo
<subbu>
what enumerable/lambda issue? i've not followed all the discussions here.
<Antiarc>
Ooh, okay
<enebo>
Does anyone have the simplest snippet for that?
<Antiarc>
enebo: Sec
<enebo>
I do know it involves stabby
<enebo>
fucking stabby…he’s a nasty fella
<headius>
yeah, argument processing not working with stabby but works with proc
<headius>
looks like arg spreading
<enebo>
yep
<Antiarc>
aww crud
<Antiarc>
I was working on a github issue for it and looks like I closed the tab
<headius>
chrome can recover form content if it's still in history
<Antiarc>
Line 10 there, if you replace the stabby with Proc.new it works
<headius>
Antiarc: perfect
josh-k has quit [Ping timeout: 250 seconds]
<Antiarc>
That's basically taken verbatim from test_enum.rb
<enebo>
I will look into this once I debug why my const opt is not working
<headius>
we can toss that into spec/compiler/general_spec.rb
<enebo>
hopeflly I can figure this out before dinner
<headius>
enebo: there's many ways we can improve defined? with indy too
<headius>
get it enlisted in all the same const-folding and cache-busting that constant and method lookups do
<headius>
in theory I can emulate whatever indy doesin JVM6 too
<enebo>
yeah I added colon3 as own thing which was 3 linies
<headius>
nice ok
<subbu>
headius, enebo is it still worth trying to convert my method-def tests (which i was stripping out rubyclass) into jruby-specific tests since many of them weren't adequately covered in mri / jruby.
<headius>
subbu: more tests is always worthwhile :-)
<enebo>
then I busted out fast path for colon2 where lhs os constnode but that causes something weird
<subbu>
but, we also have so many other suites that i also don't want to add test noise.
<subbu>
ok.
<headius>
subbu: those would be good cases for the general compiler spec
<subbu>
k
<chrisseaton>
headius: I do recall some research on lazily creating stack traces - the trace gets forced for a new frame when you request it or when that frame unwinds so ceases to exist - but can't quite remember the context it was form - might have been deopt in general
<headius>
I'll want to know the JIT can do them too
<enebo>
so I converted build lhs with const node as buildGetDefinition and it seems to work but I might have an extra already defined issue
<headius>
chrisseaton: yeah, that would be doable if instead of a StackTraceElement[] you got back a StackTrace abstraction
<headius>
I don't know how that laziness applies if you leave the frame though
<headius>
applies/would apply
<chrisseaton>
leaving the frame triggers the stack trace element to be fufilled
<headius>
ahh sure
<headius>
so there's a safe point on exit and if that frame has been captured for a trace it needs to fill it up
<headius>
or something along those lines
<chrisseaton>
something like that - I'm sure the specifics will come back to me
<headius>
yeah
<chrisseaton>
do you know work stealing in parallelism? where threads have a list of tasks and if they run out they take tasks from another thread?
<headius>
anything we can do to reduce stack trace overhead will pay dividends...we periodically run into libs using exceptions for flow control
<chrisseaton>
Fork?Join does it
<headius>
yeah sure
<chrisseaton>
there's a paper where you just recurse to create tasks, so just creating new local stack frames, and other threads steal by extracting these frames and reading the task data from them - crazy stuff
<enebo>
That wacky symbol fortran replacement…fortresss is all about work stealing
pietr0 has quit [Ping timeout: 244 seconds]
<headius>
chrisseaton: I like it
<headius>
fortress is dead, right?
<enebo>
only in our hearts
<enebo>
oh and I think the project is dead too
<enebo>
:)
<chrisseaton>
I think the darpa funding went to x10 instead
<enebo>
We need more languages to leverage zapf dingbats
<enebo>
haha
<enebo>
god damned warnings
<headius>
we need a new keyboard with an additional row of symbol keys above the numbers
<enebo>
headius: like 5 more rows
<headius>
and we need a couple decades for it to gain adoption :-D
<enebo>
headius: with oled displays on each key
<enebo>
headius: or one more meta key
<headius>
have you priced those oled keyboards lately?
<enebo>
headius: or chording
<headius>
I hoped they might come down, but yeah... $1000+ for a keyboard is a bit out of my range
<enebo>
headius: unfortunately the big one was sold out like 2-3 years ago
<enebo>
I love the idea of animating rainbows scrolling accross while I work. I need more distractions
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
e_dub has quit [Quit: ZZZzzz…]
<headius>
byteit101: looks much better now
<headius>
that JI failure is an old feature I've removed
<enebo>
headius: I did colon3 as non-exception throwing version
<enebo>
headius: something wacky with a warning as a side-effect trying to remove simple colon2 version
<enebo>
I spent too much time optimizing something unimportant :)
pietr0 has joined #jruby
<headius>
byteit101: looks like you still have my syntax error printStackTrace in there too...might want to rebase
<headius>
it looks fine failure-wise though, so I'l merge and save you the trouble :-)
<Antiarc>
TestFileExhaustive#test_expand_path_memsize => LoadError: no such file to load -- objspace -- should that one just be excluded due to jruby not having objectspace on by default?
<headius>
hmmm
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/82Ipww
<JRubyGithub>
jruby/master b42424d Patrick Plenefisch: Provide better error message when using :: in java_import (fixes #2074)
<JRubyGithub>
jruby/master 1df19df Charles Oliver Nutter: Merge pull request #2075 from byteit101/master...
JRubyGithub has left #jruby [#jruby]
<headius>
Antiarc: yes
<Antiarc>
Where are tests excluded?
<headius>
test/mri/excludes, files are the test class names with :: translated to /
<byteit101>
headius: thanks
<headius>
you'll get the idea pretty quick
<headius>
byteit101: thank you!
zorak8 has quit [Ping timeout: 272 seconds]
<Antiarc>
yup, cleand and easy
multibot_ has quit [Remote host closed the connection]
multibot_ has joined #jruby
<Antiarc>
Down to 240 locally now
<headius>
ok
<byteit101>
headius: actually, do you have any idea about why I have to reference a JNI class from JRuby before jruby can call java classes to call the JNI object? I think It might have to do with jruby's classloaders messing with javacv's classloaders, but am unsure: https://gist.github.com/byteit101/4c0617cf879d99e84c99
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to update_stdlib: http://git.io/z2A3LQ
<JRubyGithub>
jruby/update_stdlib 822abec Charles Oliver Nutter: Merge remote-tracking branch 'origin/master' into update_stdlib
JRubyGithub has left #jruby [#jruby]
<headius>
byteit101: I think there's a JVM bug in some versions that has problems bootstrapping inner classes if you access the inner class before the outer
<Antiarc>
is 9k targeting 2.2 compatibility out of the gate?
<headius>
we had to add some explicit accesses of outer classes in a few places
<headius>
Antiarc: yes
<Antiarc>
awesome :D
<byteit101>
headius: know which versions?
<headius>
this is going to finally be our "caught up" release, at least as far as "expected" compatibility
<headius>
byteit101: it was Java 6 for me some years ago but I haven't played with it recently
<headius>
let me check
<byteit101>
because this was in java 7
<byteit101>
7u72
<headius>
hmm
<headius>
nothing that late
<byteit101>
and I found it very strange that simply referencing the class from jruby fixes it so java works
<byteit101>
so I figured that it must be something that jruby is doing with loading classes somehow
<headius>
yeah, this is probably a similar issue and I've never gotten a good explanation about it
<headius>
when accessed from Ruby, we walk the containing class to reflect its methods, etc
<headius>
that causes it to link when it should
<chrisseaton>
headius: JRuby doesn't have internal or filesystem encodings but MRI does - is that a bug or a JVM thing?
<headius>
JVM seems to only link the inner class and then things blow up because it tries to access outer class for some state
<headius>
chrisseaton: we do have them
<byteit101>
its static inner class
<byteit101>
*its a
<headius>
byteit101: it was for these other cases too
<headius>
trying to remember one of them
<chrisseaton>
headius: they don't seem to be listed in Encoding.name_list on master - could they just be missing from the name list somehow?
<headius>
yeah that's probably all it is
<chrisseaton>
I'll add them in - due the way RubySpec works with encodings, not having them in name_list is costing you literally thousands of expectations
<headius>
I don't think I re-ported that logic when I updated encoding/transcoding this summer
<headius>
oh, nice...go for it
<headius>
there should be accessors for them on either Ruby or EncodingService
<byteit101>
headius: ok, thanks. I love how jruby can fix jvm bugs like that!
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Antiarc>
https://gist.github.com/cheald/f341b2adc1c5926e38e8 - a big chunk of the remaining errors are of this form - NPE when processing a script chunk, it looks like. The issue there is the `script` is nil when it's passed into runScript - parser issue?
<byteit101>
oh, is there a nice api to generate simple ruby code from an ast-like form? currently in jrubyfx I just make strings and hope the parser makes valid strings of jruby code, but I would prefer something less stringy
josh-k has joined #jruby
<headius>
byteit101: there's another possible explanation
<byteit101>
headius: oh?
<headius>
if the parent class and inner class are referenced from different classloaders but come together, that might also cause this error
<headius>
Antiarc: oh, I can fix that
<headius>
I thought I had actually
<byteit101>
hmm, but calling it from jruby fixes it, and the javacv stuff uses its own classloader to load JNI stuff...
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
<headius>
Antiarc: oops...that NPE is my fault, bad fix for something on master
<headius>
that's probably why your numbers went up
<Antiarc>
Hah. Woot.
<Antiarc>
I didn't think I saw those yesterday.
<headius>
yeah neither had I
<headius>
thought maybe we were just geting further
<Antiarc>
enumerable/webrick are the last two big really meaty chunks, it looks like
<Antiarc>
After that it's probably gonna be harder work :)
<Antiarc>
Like, the method currying stuff
josh-k has quit [Read error: Connection reset by peer]
<headius>
that may not be too bad...like, to_proc.curry might be enough
<headius>
unsure how deep the MRI impl goes
<enebo>
Antiarc: I reduced the test case: jruby -e 'a = lambda { |a,b| p a, b}; def foo; yield [1,2]; end; foo &a'
<Antiarc>
enebo: Is it as simple as not splatting yielded values to the stabby or something?
<enebo>
Antiarc: I think specifically this is blockpass &lam should convert its behavior to proc and non-lambda but amazing nothing catches this than an enumerable spec
<enebo>
Antiarc: If you invoke a lambda directly it should arg error like we see in the error
<enebo>
Antiarc: So this is about passing via &foo I think
<headius>
enebo: spec in general_spec will be good
<enebo>
Antiarc: I was going to change some of out logic for lambda and arg passing and I reliazed it is correct