<edipofederle[m]>
I lost my self a bit with the IRC, so not sure if my last message arrives; in any case, about build failing, One of the 2 errors was fixed here: https://github.com/jruby/jruby/pull/6907, at least looks like.
<headius>
edipo.federle ah ok, I will look into that today
<headius>
Oops my string dedup patch had some regressions I didn't notice
<headius>
well that's weird... I can't get it to fail locally
<edipofederle[m]>
yep, It also works fine for me locally
<headius>
I will fix the ones that I can repro but all the String specs seem to pass
<edipofederle[m]>
Is something that will fixes the "The command "tool/maven-ci-script.sh" exited with 1." issue?
<headius>
which issue is that?
<headius>
the other failed job in travis, "check-versions"?
<edipofederle[m]>
I see that issue in several builds
<edipofederle[m]>
headius: yes, the check-versions
<headius>
edipo.federle: ah I believe that is because we updated the asm library and did not update jnr-ffi which depends on an older version of asm
<headius>
I will fix that today as well hopefully but it is just verifying all dependencies are aligned
<edipofederle[m]>
I see, is something I can help here?
<headius>
a PR to jnr/jnr-ffi to update to the same ASM 9.1 would move it along 😀
<edipofederle[m]>
I will check it,
<headius>
I pushed a fix for the Hash#[]= regression so we will see how the other ones I can't repro look
<edipofederle[m]>
headius: cannto we update the asm version on Jruby from 9.1 to 9.2 (the one used in jnr-ffi)
<edipofederle[m]>
s//?/
<headius>
ah yeah I am not sure which versions are which but we basically just need them all to match
<headius>
upgrading whereever is fine, it is a minor move
<enebo[m]>
headius: the jruby-jars error in check-version is from misaligned artifacts?
<enebo[m]>
I was looking at this a little earlier today and it appears we never end up running jruby-jars (this is my guess) do to maybe the base/core switch. I can see that lib/jruby-jars/version.rb never seems to update which is my clue it is not running
<headius>
well it has loads of warnings about the misaligned deps in the output
<headius>
it does say something about artifacts not being present but I think that is because of the other errors
<headius>
but I don't know when this broke... it wasn't my string changes
<headius>
aha these only repro this way with objectspace enabled
<enebo[m]>
I could see it being deps having looked at commits
<enebo[m]>
It seemingly starts when I landed PR from 9.3.0.0-SNAPSHOT to 9.3.0.0 as the executable to run stuff
<enebo[m]>
Things are always a little murkier when we change version numbers as well
<headius>
ok these string changes are not really broken, but the way I am checking for instance vars also sees our synthetic object_id and objectspace each_object tracking variables
<headius>
the change was to avoid interning a string that has instance variables... I don't think there's any reason to avoid interning it if it has been assigned an object_id or registered with objectspace
annabackiyam[m] has joined #jruby
<headius>
hmm this is a bit sticky to solve
<headius>
we do not have a clear separation of Ruby instance vars from internal vars we use for object_id, FFI pointer reference, and ObjectSpace tracking list
<headius>
this only fails in a full core/string run with objectspace enabled, because one spec sets an instance var on a string which causes future string's ivar tables (even for just objectspace) to have an extra slot
<headius>
a limitation of our instance variable manager being per-type and not more localized
<headius>
ok this is a little gross but should only impact interning strings when at least one string ivar has been set... I have to scan the ivar array for non-null entries unrelated to object_id etc
<headius>
normal strings in normal execution won't go through this nor will strings that only have the extended variables
<headius>
enebo: I pushed a fix for this regression that you should review
<enebo[m]>
ok
<headius>
this brings back all the issues with our current ivar table, like if one piece of code assigns an ivar or requests an object_id from a String, all future Strings will try to allocate a wider ivar table
<headius>
if you never assign an ivar or use object_id on those future objects they won't create any table, but this just shows the problem with having only one shape for a given type
<headius>
JRuby X will need to support a shape per object so we can localize one-off object_id or ivar usage better
<headius>
(and so we can efficiently allocate objects without always allocating all the possibly needed space
<enebo[m]>
edipo.federle: I will try and find something...
<edipofederle[m]>
I am looking at the PopenExecutor.popen(
<enebo[m]>
ShellLauncher.popen seems like a starting point
<enebo[m]>
That is called by methods in RubyIO so you can see how those parameters are set up
<edipofederle[m]>
nice, I will check
<enebo[m]>
And as a first swipe you may even be able to jusr call RubyIO.popen
<enebo[m]>
It should work exactly as documented by Ruby APIs
<edipofederle[m]>
nice
<enebo[m]>
you just have to manually build your argument array
<edipofederle[m]>
yep
<edipofederle[m]>
I will try
<enebo[m]>
I would possibly suggest doing it a little lower level but in this case it is literally to exit without usage output
<enebo[m]>
So Ithink this may be the least amount of code to support it
<edipofederle[m]>
right,
<edipofederle[m]>
thanks for now
<enebo[m]>
np
<edipofederle[m]>
enebo: not sure I can use it, since these methods are dependent of runtime, which is a thing not available at this point, or I'm missing something here?
<enebo[m]>
edipo.federle: yeah. hmm. I mean one possibility would be to load a runtime to call it but perhaps we just need a nice example of Java code piping to a process
<enebo[m]>
edipo.federle: So ProcessBuilder may be the route but you need to be able to provide its stdin and feed the strings