kares[m] has quit [*.net *.split]
rebelwarrior[m] has quit [*.net *.split]
MarcinMielyskiGi has quit [*.net *.split]
UweKuboschGitter has quit [*.net *.split]
klobuczek[m] has quit [*.net *.split]
MatrixTravelerbo has quit [*.net *.split]
Freaky has quit [*.net *.split]
Freaky has joined #jruby
Freaky has quit [Signing in (Freaky)]
Freaky has joined #jruby
MarcinMielyskiGi has joined #jruby
MatrixTravelerbo has joined #jruby
UweKuboschGitter has joined #jruby
rebelwarrior[m] has joined #jruby
klobuczek[m] has joined #jruby
kares[m] has joined #jruby
<kares[m]> headius: just let the jossl pre sink in for a while - so ppl could try it out.
<kares[m]> no complains so far, going to add a system prop flag to turn off the new logic and I am releasing today.
<kares[m]> will respond on the related issue in the jruby tracker as well ...
<kares[m]> will see how I'll have time - there's a ton of work that I did not complete + one jossl specific cert handling I needed to revert.
<kares[m]> I'd like to at least look into the build issue and some long term test failures.
yosafbridge` has quit [Quit: Leaving]
yosafbridge has joined #jruby
Edipofederle has joined #jruby
<Edipofederle> Hi Guys, I notice some builds with some strange errors, like this one (https://app.travis-ci.com/github/jruby/jruby/jobs/544784300) someone is aware of what is the issue?
<puritylake[m]> <enebo[m]> "puritylake: I updated the branch..." <- I’ll take a look later when I’m home
<Edipofederle> Nice, I've pushed this PR (https://app.travis-ci.com/github/jruby/jruby/builds/240496208) and looks like it fix at least one build failed phase...
<headius> Good morning
edipofederle[m] has joined #jruby
Edipofederle has quit [Quit: Client closed]
<edipofederle[m]> Morning,
<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]> Some examples:
<edipofederle[m]> |
<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 to 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
<headius> lunch, bbl
drbobbeaty has quit [Quit: Textual IRC Client: www.textualapp.com]
<headius> ok that seems to have fixed the string and objectspace failures... my hash fix seems to have regressed something else
drbobbeaty has joined #jruby
<edipofederle[m]> enebo: could you please maybe point me to some example on Jruby code regarding your comment here -> https://github.com/jruby/jruby/pull/6902#discussion_r735888554?
<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
<edipofederle[m]> yep, I will try exactly that.
<edipofederle[m]> currently on the same page :)
<enebo[m]> nice
<edipofederle[m]> I will try and see how it works,
<headius> pushed my last fix for the regressions... should be good on master other than the version check failing
<edipofederle[m]> <headius> "pushed my last fix for the..." <- So, at the moment, the error on version check is 'expected'? (ref: https://github.com/jruby/jruby/commit/823cb5f464bb7cb8d37caf8f1b5273956b02a7c2#r58638618)
<headius> Yeah until we fix those versions