<enebo>
olle: so if a shell expansion it will return nothing as last arg because shell globbing will return nothing
lanceball_ has joined #jruby
<olle>
enebo: Perhaps then I can't run this right when in the "debug job" mode
<enebo>
olle: do you make that pattern argument directly?
<enebo>
olle: I would remove \* and just make * but put within single quotes
etehtsea has joined #jruby
<olle>
enebo: The expression comes from RSpec's rake task
<olle>
enebo: It's me trying to integggggrate with some tools in place.
<enebo>
olle: ah if you put a puts in there and there is no last argument then I predict something is expanding the escapes once before being called a second time
<enebo>
olle: that will end up having shell try and use those stars and then it will expand to nothing since shell is not as sophisticated
<enebo>
olle: at least that is my guess
<olle>
enebo: Ya. Sadly, in this interactive mode, it ain't the same.
<olle>
enebo: It does different things.
lanceball_ is now known as lanceball
lanceball has quit [Changing host]
lanceball has joined #jruby
<olle>
enebo: Oh, I was able to.
<olle>
enebo: Now I have the "bundle exec rake" running, with the failure I was pining to see.
<enebo>
olle: locally?
<olle>
enebo: No, in the Travis interactive debug environment.
<olle>
enebo: It's a ssh session with a "build server"
<enebo>
olle: ok well I will let you debug the debug
<olle>
enebo: Grand.
<olle>
Poking around, thanks for the push to Know Things.
<enebo>
olle: if it is us then maybe it is calling something in a new way that 1.7 (or 1.9) does differently
<enebo>
olle: but I predict my theory is still correct…the only question is it us or them
<olle>
enebo: arg is nil, argv is []
<enebo>
olle: if you know it works on 9k it would point more towards us
<olle>
enebo: I should add a jruby-9.1.6.0 build target, yeah
<olle>
enebo: In 1.7, in the earlier step, `OptParser#parse!` the argv is ["--pattern"] (# Same as #parse, but removes switches destructively.)
<enebo>
olle: yeah so something is shell globbing and killing the last arg
<enebo>
olle: which could be travis or it could be how we invoke commands in 1.7.x
<enebo>
olle: or just a 2.xish leaked in later rspec?
<enebo>
olle: actually a foouth option as well we could be not cwd and globbing it to nothing but I would not expect that before parse
<olle>
Oh, drinks and dinner is awaiting beyond this rain. Gotta bike!
<olle>
Thank you for caring about my petite problems.
<enebo>
olle: ok let me know how this turns out
<olle>
enebo: Sure!
<olle>
enebo: haha, I got much more mad 9K errors when I was able to run the tests on Travis with 9K.
<olle>
enebo: This kind: expected no Exception, got java.lang.RuntimeException: org.jruby.runtime.scopes.DynamicScope1 only supports scopes with 1 variables with backtrace:
<olle>
enebo: I'll report back. Ciao!
<enebo>
olle: ok report that too when you get back
donV has quit [Quit: donV]
lanceball is now known as lance|afk
raeoks has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<GitHub24>
[jruby] tobymurray-nanometrics opened issue #4304: Singleton on non-persistent Java type Java::JavaLang::NullPointerException https://git.io/vXS4g
vtunka has quit [Quit: Leaving]
donV has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
thedarkone2 has joined #jruby
Puffball has quit [Quit: No Ping reply in 180 seconds.]
Puffball has joined #jruby
camlow325 has quit [Quit: WeeChat 1.5]
donV has quit [Quit: donV]
donV has joined #jruby
donV has quit [Client Quit]
claudiuinberlin has joined #jruby
lance|afk is now known as lanceball
akp has joined #jruby
maclover7 has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
maclover7 has quit [Client Quit]
nicoulaj has joined #jruby
subbu is now known as subbu|lunch
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
pawnbox has joined #jruby
TheWhip has joined #jruby
maclover7 has joined #jruby
claudiuinberlin has quit []
kirs has joined #jruby
<kirs>
hey!
<kirs>
so I cloned jruby/jruby, bootstrapped the local setup and when I'm running the tests I get quite a lot of failures:
TheWhip has quit [Remote host closed the connection]
kirs has quit [Ping timeout: 260 seconds]
olle_ has joined #jruby
pawnbox has quit [Remote host closed the connection]
mosodede has joined #jruby
mosodede has quit [Client Quit]
TheWhip has joined #jruby
<olle_>
enebo: Back from great dinner. My issue with argv being misunderstood/weird on 1.7, it went away when I removed -J-Djruby.launch.inproc=true
<enebo>
aha
TheWhip has quit [Ping timeout: 265 seconds]
<enebo>
olle_: yeah that property is to not restart a new JVM if you are reinvoking ruby itself but the problem it can have is we did not perfectly emulate shell processing of argument logic
<olle_>
enebo: Is this a fixable thing, or is it more “sharing with inproc=true makes it important for you not to consume args when parsing them“
<enebo>
olle_: so your pattern arg probably got bungled by it
<enebo>
olle_: well it undoubtedly exposes a problem with how we process arguments when we re-invoke Ruby
<olle_>
enebo: I mean is it merely documentable?
<enebo>
olle_: well not without knowing what is broken no
<olle_>
enebo: Eh, hehe. Right.
<enebo>
olle_: I mean we could say do not use inproc if you are using any glob-like syntax but I do think it works with a bunch
<enebo>
olle_: if you can figure out a smaller case where it eats the string when it shouldn’t then we might fix it so it works
<olle_>
enebo: I could start trying a ruby-only case, which does not need tons of deps.
<enebo>
olle_: yeah I think it would be something like calling system (or whichever method was pushing that subinvoke) and simplifying that pattern string til it works then add that last thing back
<enebo>
olle_: not a ton of people use inproc=true now but it can really speed up sub-inokes by not restarting JVM
<olle_>
I see.
<enebo>
olle_: although for features like this I wonder how well we maintain them since they are not on much
<enebo>
olle_: and in CI they require a JVM/proc start to test them
<olle_>
enebo: Can it even be a security misfeature?
<enebo>
olle_: I don’t know. You are invoking a ruby subprocess if not. If you do not trust it in same JVM do you trust executing a process as same user?
<enebo>
olle_: certainly it opens up different interesting security questions but both would be dangerous if you did not trust your code
<olle_>
enebo: I was thinking along the lines of “running the right commands” more than about trust.
<olle_>
enebo: But I’ll get on trying to get a reduced case.
<enebo>
olle_: well I think main one would be you want to run MRI as a subprocess but we say, nope we will run you
<cprice404>
howdy all, I notice there is a new release of jruby-openssl available; is there any chance that there will be a new release of jruby 1.7/jruby-stdlib 1.7 that contains the new 0.9.18 version of jruby-openssl?
<headius>
olle: definitely need that DynamicScope one reported
<headius>
that would be interpreter getting a generated scope and trying to access outside its size
<headius>
cprice404: yeah we should have at least one more 1.7 release before end of year
<cprice404>
headius: awesome, i will work up a PR for y'all unless someone is already doing that. also, are you feeling like you are on target for 1.7.x EOL at end of 2016 or might that slip out a bit further?
<headius>
I don't know of anyone doing that for 1.7
<headius>
end of 2016 is kinda whenever 9.2 is done...that's intended to advance to ruby 2.4 compat and resolve remaining migration issues
nicoulaj has quit [Remote host closed the connection]
<headius>
9.2 will probably not quite be done at the end of 2016 :-)
TheWhip has joined #jruby
<cprice404>
so the plan is to EOL 1.7 at the same time the 9.2 release drops?
<enebo>
cprice404: I think it could be but it might extend another point release. I think we need to see
TheWhip has quit [Ping timeout: 248 seconds]
<cprice404>
k, thx. we're hoping to carve out some time to try to upgrade again soon :/
<GitHub125>
[jruby] olleolleolle opened issue #4305: JRuby 1.7: Argument list not fully preserved when inproc=true https://git.io/vX9ke
<headius>
cprice404: unofficially there might be a little overlap, but that's what I'm hoping for
<enebo>
olle_: this is not a real repro and I do not think you should command-line reduce this as it make string escaping really weird
<enebo>
olle_: but something where the script displays ARGV it receives you should see your funky spec pattern in inproc false and nothing when true
<enebo>
olle_: I also don’t know which method rspec uses to invoke the subprocess. That could be a major thing so you should try and figure out how it does it
<olle_>
system([])
<enebo>
olle_: great so you know that already
<olle_>
that’s how - they build a system() call which is a []
<olle_>
enebo: The #spec_command method builds the command
<enebo>
olle_: I think just their pattern string added as last arg in what I gave above but put into a script should show a difference between inproc true and false
<olle_>
riiiight, it’s the _shape_ of the pattern arg that also matters.
<enebo>
olle_: once you see that difference I think you can start whittling that arg smaller and smaller too
<olle_>
enebo: I got to the difference.
<GitHub118>
[jruby] cprice404 opened pull request #4307: JRuby 1.7: update jruby openssl to 0.9.18 (jruby-1_7...jruby-1_7-update-jruby-openssl-to-0.9.18) https://git.io/vX9qY