<jeremyevans>
headius[m]: Merged. If there are other standard lib gems you want to work better with JRuby, please send PRs and ping me (I don't follow all stdlib gem repositories, yet).
<headius[m]>
yeah that would be great... as they have been gemified I have been trying to make sure we can switch to them
ur5us_ has joined #jruby
daveg_lookout[m] has quit [Ping timeout: 246 seconds]
KarolBucekGitter has quit [Ping timeout: 246 seconds]
sdlin[m] has quit [Ping timeout: 246 seconds]
sureshbabu[m] has quit [Ping timeout: 246 seconds]
sagax has quit [Ping timeout: 245 seconds]
daveg_lookout[m] has joined #jruby
sureshbabu[m] has joined #jruby
KarolBucekGitter has joined #jruby
sdlin[m] has joined #jruby
snickers has quit [Ping timeout: 260 seconds]
sagax has joined #jruby
kai[m]1 has quit [Ping timeout: 265 seconds]
vortex1111[m] has quit [Ping timeout: 265 seconds]
TimGitter[m] has quit [Ping timeout: 265 seconds]
UweKuboschGitter has quit [Ping timeout: 265 seconds]
RomainManni-Buca has quit [Ping timeout: 265 seconds]
OlleJonssonGitte has quit [Ping timeout: 265 seconds]
sdlin[m] has quit [Ping timeout: 246 seconds]
sureshbabu[m] has quit [Ping timeout: 265 seconds]
JulesIvanicGitte has quit [Ping timeout: 240 seconds]
MattPattersonGit has quit [Ping timeout: 240 seconds]
rdubya[m] has quit [Ping timeout: 240 seconds]
ChrisSeatonGitte has quit [Ping timeout: 240 seconds]
marcheiligers[m] has quit [Ping timeout: 240 seconds]
FlorianDoubletGi has quit [Ping timeout: 240 seconds]
GabrielMazetto[m has quit [Ping timeout: 240 seconds]
jswenson[m] has quit [Ping timeout: 240 seconds]
liamwhiteGitter[ has quit [Ping timeout: 240 seconds]
MarcinMielyskiGi has quit [Ping timeout: 240 seconds]
CharlesOliverNut has quit [Ping timeout: 244 seconds]
souravgoswami[m] has quit [Ping timeout: 244 seconds]
enebo[m]1 has quit [Ping timeout: 244 seconds]
byteit101[m] has quit [Ping timeout: 244 seconds]
headius[m] has quit [Ping timeout: 244 seconds]
JesseChavezGitte has quit [Ping timeout: 244 seconds]
TimGitter[m]1 has quit [Ping timeout: 258 seconds]
kalenp[m] has quit [Ping timeout: 258 seconds]
boc_tothefuture[ has quit [Ping timeout: 258 seconds]
chrisseaton[m] has quit [Ping timeout: 272 seconds]
kares[m] has quit [Ping timeout: 272 seconds]
daveg_lookout[m] has quit [Ping timeout: 244 seconds]
KarolBucekGitter has quit [Ping timeout: 240 seconds]
UweKuboschGitter has joined #jruby
vortex1111[m] has joined #jruby
RomainManni-Buca has joined #jruby
TimGitter[m] has joined #jruby
OlleJonssonGitte has joined #jruby
sdlin[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
GabrielMazetto[m has joined #jruby
JulesIvanicGitte has joined #jruby
FlorianDoubletGi has joined #jruby
liamwhiteGitter[ has joined #jruby
jswenson[m] has joined #jruby
marcheiligers[m] has joined #jruby
sureshbabu[m] has joined #jruby
MattPattersonGit has joined #jruby
kai[m]1 has joined #jruby
FlorianDoubletGi has quit [Ping timeout: 240 seconds]
sdlin[m] has quit [Ping timeout: 240 seconds]
OlleJonssonGitte has quit [Ping timeout: 240 seconds]
<headius[m]>
byteit101: what work remains to get this running green? I can start reviewing and hunting around for TODOs but I am not sure I quite understand what the status is right now
<byteit101[m]>
headius: excellent! I'll change that this weekend
<byteit101[m]>
re green: a few things. For start: windows GHA. I don't know why that fails
<byteit101[m]>
I also don't have a windows machine
<byteit101[m]>
next: 2 fails are due to interface default methods. I don't know how to solve the non-concrete extension (this, but with my changes: https://github.com/jruby/jruby/issues/6479 )
<byteit101[m]>
Other than those + 1 minor edit I just realized I need to make, It should work
<byteit101[m]>
The last 2 fails could probably be marked as failing for the moment, as they never worked before either
<byteit101[m]>
the TODO's in the code are pretty minor otherwise
<headius[m]>
ok
<headius[m]>
if they did not work before they are not a blocker for release... we can mark then as failing and link to that issue
<headius[m]>
of course if we can fix that is better 😀
<byteit101[m]>
tricky thing is super in reification requires `public bridge synthetic __super$methodname(){super.methodname();}` + `this$rubyProxyClass = ...getJavaProxyClass.initMethod("methodname", "()Z", true);`, but non-concrete doesn't have a javaproxyclass
<headius[m]>
what do you mean by super in reification
<byteit101[m]>
super calls from ruby in reified classes (concrete and non-concrete) will infinite recuse unless the super target(?) is set correctly via that code
<byteit101[m]>
*concrete only, non-concrete is fine in general, except inteface default methods
<headius[m]>
I am confused... you say concrete and non-concrete but then say non-concrete is fine
<byteit101[m]>
super calls from ruby in reified classes (concrete only, except non-concrete extending interface default methods) will infinite recuse unless the super target(?) is set correctly via that code
<headius[m]>
ok
<byteit101[m]>
^ correct statement
<headius[m]>
so this is more about the default method issue that was an issue before
<byteit101[m]>
yes
<headius[m]>
concrete can set the super target because there is a JavaProxyClass for it
<byteit101[m]>
yes
<headius[m]>
a hard error in the default method case would be better than stack overflow, if we can detect it
<headius[m]>
until we can support the behavior properly
<headius[m]>
like "super not supported with Java default methods"
<byteit101[m]>
I think it is tricky to detect, but I may be mistaken
<headius[m]>
those two failures illustrate the problem sufficiently?
<headius[m]>
I mean you can't really just super into an interface default method from Java either so an error could show a "right way" if we can provide a right way
<headius[m]>
Interface.super.someMethod() in Java
<byteit101[m]>
yes, see become_java_spec.rb changes
<headius[m]>
ok
<byteit101[m]>
iterator/remove method
<enebo[m]1>
ah I just saw that. so if_mod is not working on that branch
<byteit101[m]>
well, inside split ctors, no
<enebo[m]1>
"@enebo super(..) if cond is not being caught as an error. Is there something I need to tie in to catch that?"
<enebo[m]1>
Is this still an issue?
<enebo[m]1>
I would think it can't be based on how we detect it
<byteit101[m]>
Yes
<byteit101[m]>
let me make a repro real quick
<enebo[m]1>
actually I might see how now
<enebo[m]1>
Or not :)
<enebo[m]1>
That if should occur before the super as BEQ/BNE
<headius[m]>
that is locally running your branch, rake test:jruby, on Java 11
<headius[m]>
on MacOS
<headius[m]>
oh I see you had to step away, will update issue
<enebo[m]1>
ok I think I need to actually fetch this branch now :)
<headius[m]>
dooo ittttt
<headius[m]>
coffee time
<enebo[m]1>
HAHAHAH
<enebo[m]1>
missing throws
<enebo[m]1>
byteit101: I will just let you fix this one: if (!earlyJumps.isEmpty()) getManager().getRuntime().newRuntimeError("forward control flow found around super"); is missing a throws
<enebo[m]1>
which also means we have not really tested an entire class of cases which should not work
<enebo[m]1>
but I think the approach is sound. we just keep track of all unknown jump points encountered before we see super and then when we do see them if they are after the super they will raise because they will not have been removed from the earlyJumps list
<headius[m]>
enebo: might be good for all three of us to pound on this branch and make sure everything is solid next week
<headius[m]>
spend a few days finalizing this whole thing
<headius[m]>
if we can get kares on board so much the better
<enebo[m]1>
sure I mean let's get it in and pound on it
<enebo[m]1>
The above fix has to be run before we land it :) but I think testing on a branch will be less likely to uncover stuff
<headius[m]>
yeah we should throw some apps at it
<headius[m]>
look for some heavy JI stuff
<enebo[m]1>
jrubyfx is probably covered but something with a lot of JI in it
<headius[m]>
maybe we can resurrect donv to try some of his stuff
<enebo[m]1>
image_voodoo and purugin both are consumers
<enebo[m]1>
I can't say image_voodoo will hit very much. It is pretty simple
<headius[m]>
yeah I don't know many that use concrete extension
<headius[m]>
because it was so iffy
<headius[m]>
usually it is only done if you absolutely have to
<enebo[m]1>
Purugin I don't think does
<enebo[m]1>
I remember I had one weird problem (without remembering what it was) where maybe I had to do something
<headius[m]>
oh hey a thought I had the other day, maybe we talked about it
<enebo[m]1>
My tendency is to just write some Java though
<enebo[m]1>
Purugin has 3 java source files in it
<headius[m]>
if we had interface injection we could combine that with default impls in IRubyObject and all objects could just flow
<headius[m]>
I dunno if that would ever be perfect though... we use the concrete classes so much
<enebo[m]1>
I should say byteit101 still have hudson-whatever branch locally
<enebo[m]1>
byteit101: you should remove that branch
<headius[m]>
hah can you share your script?
<headius[m]>
any tag that doesn't start with a number or jruby-ope
<enebo[m]1>
git tag -d hudson-whatever ; git push enebo :hudson-whatever
<headius[m]>
jruby-openssl
<enebo[m]1>
I do not have all of those tags in the script
<headius[m]>
well like I say it is anyu
<headius[m]>
anything not #.#.# or jruby-openssl-#.#
<headius[m]>
those are the only tags we should have published
<headius[m]>
I wonder if there is a github config for this 🤔
<headius[m]>
I am pivoting back to 9.3 audit for the rest of today
<headius[m]>
woo 111 open issues marked for 9.3
<headius[m]>
lots of half-finished headius tasks
<headius[m]>
yay me
<byteit101[m]>
headius: win fails: ah, good, I'll take a look then. I saw missing windows paths and assumed it was a windows thing, didn't actually bother to run tests :-)
<byteit101[m]>
enebo: throws added, works as expected now
<byteit101[m]>
I like the idea of more people giving this branch a good pounding. I'll merge enebo's arg->signature work this evening and let you both know when
<byteit101[m]>
I've been testing heavily with (modified) jrubyfx, which I'll cleanup my debug statements and push soon.
<byteit101[m]>
enebo: hudson branch. Ah, I think I forked my repo ages ago and just occationally push changes. I should clean that up...
<headius[m]>
yeah we can all start to hit it next week since this is one of the main outstanding PRs for 9.3
<byteit101[m]>
how do I mark the two default interface method tests as failing?
<headius[m]>
pend should work
<headius[m]>
well pend works for test/unit
<headius[m]>
I forget the equivalent for rspec
<byteit101[m]>
how? where? (I;;'ve not done that with ruby tests before)
<headius[m]>
I believe the syntax is just `pend "some message about why this is pending"`
<byteit101[m]>
>the main outstanding PRs for 9.3
<byteit101[m]>
Do you want to add it to the milestone on GH? :-)
<headius[m]>
oh is it not marked already?
<byteit101[m]>
No
<byteit101[m]>
(can probably also look at the linked issues in the first comment)
<headius[m]>
marked
<byteit101[m]>
NoMethodError:
<byteit101[m]>
undefined method `pend' for #<RSpec::ExampleGroups::JRubyClassReification:0x30396acf>
<headius[m]>
ok not that then
<headius[m]>
search for rspec pending
<headius[m]>
I think it might be pending(message) { spec here } or similar but don't have it in front of me right now
<byteit101[m]>
does it replace `it` ?
<headius[m]>
or it "blah", pending: true do...
<byteit101[m]>
Ah!
<byteit101[m]>
it "supports reification of java classes with interfaces" do
<byteit101[m]>
pending "GH#6479 + reification not yet hooked up"
<headius[m]>
that works
<headius[m]>
enebo: just thought of another reason to use a branch for any nontrivial work... I am pretty sure bisect will not traverse branches, so broken commits therein won't throw it off
<headius[m]>
bisect should only consider the merge commit I think?
<headius[m]>
byteit101: I was wrong, I was running locally on Java 8
<headius[m]>
dunno if that has anything to do with the failures
<byteit101[m]>
1 & 2 I pending'd, 3 I fixed right now. About to push and then try that before merging
<byteit101[m]>
headius: how do I set up my env to test mvn builds? I keep getting LoadError: bad SnakeYAML version 1.14, required 1.21 or higher; check your CLASSPATH for a conflicting jar
<byteit101[m]>
when I try to run test:jruby
<byteit101[m]>
ah-ha! 13M Feb 13 2016 lib/jruby-truffle.jar
<headius[m]>
byteit101: hmm there should not be any setup
<headius[m]>
oh wow
<headius[m]>
time to clean house
<byteit101[m]>
:-)
<byteit101[m]>
seems to be working now
<headius[m]>
I had that happen recently revisiting an old branch
<headius[m]>
we add all jars in lib to classpath I believe so that is probably why