<enebo[m]>
9.3 strscan does not support regexps in scan calls as one difference
<enebo[m]>
but I am not sure anyone would mind that they work
<headius>
We don't have to update it...could just fix it to work with new Region API
<headius>
But I figured it is pretty benign
<enebo[m]>
If that is the only significant difference it ptobably is fine
<enebo[m]>
the only possible scenario is someone writes to JRuby first and still expects MRI 2.6..x to run the same code
<enebo[m]>
2.6 has been EOL for a while so I do not see that happening
<enebo[m]>
(I also wonder if you can gem install on older 2.6 and pick up newer strscan on MRI (in which case this difference really doesn't matter)
<headius>
You would have to activate it in a gemfile but it should work then
<headius>
It just isn't a default gem in 2.6
<enebo[m]>
anyways this is not really a real scenario
<enebo[m]>
and so if someone did run into it we would tell them to add strscan to Gemfile and update to same version (assuming it will install on 2.6.x
<enebo[m]>
I am hoping in 9.4.2.0 to be able to eliminate marking keywords for methods which ar supposed to forward the kwywordness of the args they are passing
<enebo[m]>
The issue is RubyClass.new will forward what it receives and preserve keyword state
<enebo[m]>
in the case of Java Integration this is probably generated on the fly so it fails somehow
<enebo[m]>
I have a branch which is going to hopefully eliminate needing to manage this state (in the context of ruby calling native code which may call ruby code -- crossing those boundaries)
<enebo[m]>
jimtng: if you remove the new does this work?
<headius>
it installs for me locally and doesn't fetch jruby-openssl because I already have it
<jimtng[m]>
enebo[m]: Just tried removing new, same error
<enebo[m]>
jimtng: I was going to say use **{foo: nil} but because internally we split that into two potential calls it hits the Java can only have one super (and we add two as an artifact)
<enebo[m]>
I definitely wonder what cause this because I can see it call A.new -> B.init -> blow up trying to call A.init with the kwarg not being marked as suck
<enebo[m]>
If I replace ArrayList with a Ruby class we do not see it so I am guessing we losing callInfo (how we mark kwargs) in setting up the super
<enebo[m]>
that is something I would not expect to have changed but we do manipulate the IR we make for that initialize due to it being a subclass of a Java type
<jimtng[m]>
I removed new in the issue
<enebo[m]>
I bet this is not even strictly a keyword change which broke this
<enebo[m]>
I am reloading my IDE but I think we translate that super into a regular call and in the process of doing that we are not propagating the flags associated with the call
<enebo[m]>
but why that would have broken in the last point I am unsure
<jimtng[m]>
out of curiosity, where's this stuff located?
<enebo[m]>
good question 😀
<enebo[m]>
I did the splitting or IR stuff but did not work on the rest of the feature so I need to find it again
<jimtng[m]>
what is "IR" ?
<enebo[m]>
oh sorry. IR means internal representation
<enebo[m]>
We translate Ruby code into a series of made up virtual instructions
<enebo[m]>
so foo will become %result = call(%self, "foo") as an instr
<enebo[m]>
if you want to see a lot of noise you can do "jruby -S ast -iir -e "def foo; puts :1; end"
<enebo[m]>
err -S ast --ir
<enebo[m]>
You will see tons of output. The -e will have two sets of graphs of instrs showing what we do on each compilation pass we run over the initial instructions we make
<headius>
There were some super fixes in this release too
<enebo[m]>
yeah but we split on super and do something else in this case
<jimtng[m]>
puts :1 I assume that was a syntax error
<enebo[m]>
we are likely just dropping callInfo at that point which is why the kwargs appears to be a normal hash
<enebo[m]>
heh yeah 1 works...use any valid Ruby syntax
<enebo[m]>
put just -e "puts 1"
<enebo[m]>
My example will output one set of IR for the method and a second for the script body
<jimtng[m]>
ok got it
<enebo[m]>
I think the method is a little more interesting especially once you start adding parameters because you can see how we process args
<enebo[m]>
variables will look like my_var(0: 1) but you will see %v_1 which is a temporary variable (or register if you want to think about it that way)
<enebo[m]>
The 0:1 is 0 scopes down and index 1 of that scope
<enebo[m]>
too much info perhaps but it is fun stuff
<jimtng[m]>
this is way above my current pay grade :D First time seeing this or even delved into AST. Thanks for the explanation and pointers though, I appreciate it.
<enebo[m]>
sure. The gist of the problem when I find it is that we take those instructions and look for super and we will execute everything up to the super ... then call something in place of the super (normally this would be a Java method but in your case still a Ruby one) ... then execute the rest of the instrs after the super
<enebo[m]>
That middle bit is losing the flags which point out it is passing keyword arguments
<enebo[m]>
you get 0 for 1 because it thinks it is just normal hash parameter
<enebo[m]>
so if you changed your subclass initialize to accept a hash you would be fine again
<enebo[m]>
You can probably do something like this to workaround this until it is fixed
<jimtng[m]>
yup, workarounds can be implemented but in the mean time I'll stick with 9.4.0.0 until this is fixed
<enebo[m]>
ok. yeah I am going to fix this now but it will be some time for .2
<jimtng[m]>
thank you!
<enebo[m]>
Hopefully not 2 months like last release but likely 1 month unless something really pressing happens
<enebo[m]>
It could be quicker though.
<headius>
I'm game for quicker
<headius>
Couple weeks at least though
<jimtng[m]>
I can try the snapshot / nightly builds once it's fixed
<enebo[m]>
headius: yeah if we get 10 issues reported today or we see a lot of fast response we should reply in kind
<enebo[m]>
jimtng: yeah that would be great
<enebo[m]>
The more people we can get trying before release obviously the better
<headius>
We also had the holiday in there
<jimtng[m]>
what holiday?
<jimtng[m]>
oh xmas, ny, cny ?
<enebo[m]>
yeah. 2 month stride I think is ok
<enebo[m]>
we had xmas break so we did not work from before xmas through to jan 4? or something like that
<enebo[m]>
Also I think thanksgiving was in this period too which is another day
<enebo[m]>
subtract those out and I think it was 2 months
<headius>
I should probably work on the 3.2 branch a little more so it at least builds and tests right
<jimtng[m]>
Strange. I refactored my affected code (because it needed refactoring anyway) and I cannot reproduce the problem, despite the refactored version still using kwargs. Yet my test code as reported in the github issue still triggered the error.