<headius>
two new flags but if they're not used they shouldn't fire
<enebo>
lopex: yeah I know if fixes those tests but not what else it does
<headius>
i wouldn't do it day before release anyway
<enebo>
headius: yeah the new stuff is fine since it is not used
<headius>
right
<enebo>
new engine changes to fix look behind regexps somehow worry me :)
<lopex>
look behind is always scary
<GitHub151>
[jruby] headius closed issue #4889: jruby 9.1.15 fails with NameError: cannot load Java class jline.console.ConsoleReader https://git.io/vb83h
claudiuinberlin has joined #jruby
lanceball has joined #jruby
<enebo>
lopex: so I run this runner script which invokes subprocesses to build a rails app
<enebo>
lopex: when at the end I hit C-v then C-c and a warning pops up when the process dies showing that case duplicated range warning
<enebo>
So I think we still have some extra reporting somewhere?
lanceball has quit [Changing host]
lanceball has joined #jruby
<lopex>
enebo: none I can think of
<lopex>
enebo: does the verbosity can change anyhow ?
<lopex>
er, s/can//
<enebo>
I don't know
<enebo>
lopex: I guess is there another expansion which maybe should be utf-8 as well?
<enebo>
I just tried on windows and I want to see this on linux as well
<lopex>
enebo: you mean shouldnt ?
<enebo>
lopex: I thought we did not warn if we made something utf-8
<enebo>
all \X was changed to be utf-8 and the warnign went away right?
<lopex>
enebo: the opposite
<enebo>
oh \X should not be utf-8
<enebo>
I am in a ruby process launching rails server and then hitting non-visible characters
<enebo>
^C ^V
<enebo>
so I half wonder if there is some regexp in a loop in there..
<lopex>
hmm
<lopex>
quoting ?
<enebo>
lopex: do you know of easy way to dump all regexps getting processed
<lopex>
enebo: caache keys ?
<enebo>
I don't know...it would get before processing each time it used it?
<lopex>
enebo: makeRegexp is central
<enebo>
lopex: but is that called every time a regexp is used?
<lopex>
enebo: there's some regexp in RubyNumeric
<lopex>
er util/Numeric
<rtyler>
headius: FYI, I haven't forgot about your request for endless build capacity, it's still on my whiteboard but ran out of waking minutes last weekend for fun hacking :/
<lopex>
enebo: well actually we should display the regexp in question in the warnings
<enebo>
lopex: I agree does MRI?
<lopex>
yes
<enebo>
hahah ok yeah that would be useful
<lopex>
but it should be on runtime side
<enebo>
lopex: so what I know at this point is that puma says hit Ctrl-C to quit
<enebo>
If I hit Ctrl-V I see the warning message (but only after I actually hit Ctrl-C)
<enebo>
that no doubt is just some flushing issue
<lopex>
yeah
<lopex>
no idea
<enebo>
This is on windows so maybe this is us doing some pure Ruby and using a regexp
<enebo>
headius: ^ jog anything
<lopex>
enebo: all ruby regexp warnings got through Ruby.warning
<lopex>
which checks against verbose
<lopex>
does anything spin new runtimes ?
<headius>
enebo: no
<enebo>
lopex: yeah...my script spins new runtimes
<enebo>
but it won't be inproc
<enebo>
so maybe not :) It runs more than one JVM but through Kernel#system
<enebo>
I am close to rage quitting the release today
<enebo>
we could spin special joni release which ignores this warning to move past it
<enebo>
but of course we still need to figure it out at some point
<lopex>
enebo: or just use none warnings anyways
<lopex>
this way we can check if external users trigger that
<enebo>
lopex: well since it is a new class we could just match and just not display that particular warning too :)
<lopex>
new class ?
<enebo>
for the warning type
<enebo>
the new joni callback class for warn()
<lopex>
I thought it's pre joni release
<enebo>
dude you just made the fix
<lopex>
enebo: 16 Jan
<enebo>
I mean the jruby new class which impls the warn method
<enebo>
we can have that noop if it is the duplicated character class warning
<lopex>
can you just switch off the warnings in makeRegexp ?
<enebo>
then we would hack around it but not need to make a special release
<enebo>
lopex: but is turning off all warnings acceptable?
<lopex>
just to make sure external users dont trigger that
<lopex>
just for test
<enebo>
lopex: because you think joni may be issuing that warning through the old code path?
<lopex>
no
<enebo>
lopex: as a test I predict that will get rid of that warning then
<lopex>
because this way we eliminate ruby regexps to make sure
<enebo>
there is no string matching that warning in jruby source
<enebo>
I find it impossible to think a ruby gem has it either
<enebo>
It is just such a specific string
<enebo>
so theory for me is that sub-invokes of a new JVM running JRuby toggles warn on somehow
<enebo>
Or we have some other regexp which is issuing this warning errantly
<headius>
enebo: I found why 9.1 works I think
<enebo>
I don't really see any other scenario and the first scenario is weird to me since we would be back at square one from yesterday
<enebo>
since I doubt MRI does this
<headius>
the logic for "clumping" methods in 9.1 does consider compat version and binds only newest
<enebo>
although I guess I don't know
<enebo>
only newest!
<enebo>
ok interesting
<enebo>
makes sense too
<enebo>
so generating a 1.8 binding makes no sense
<enebo>
err compat on a ruby which has no 1.8
<enebo>
I don't know how precompiling works though
<headius>
I modified the clumper to skip those results which fixes it on master and makes the existing compat checking on 9.1 redundant
<headius>
so 9.1 probably doesn't really need the patch
<enebo>
can you precompile your ext and have 1.7 bindings made from 9.1? Related question is do we care
<headius>
no
<enebo>
leaving it as is my vote in any case
<headius>
you could never generate both 1.8 and 1.9 at the same time either
<enebo>
I guess it does not matter though. Nothing can use them so it is wasted work I guess
<enebo>
but I mean leave as-is for .16
<headius>
yeah ok
<headius>
I agree now that I know why 9.1 works
<enebo>
ok
<enebo>
shoot if .16 was one week away I would say full steam to joni/jcodings and we should get better warn in place to debug this issue easier
<enebo>
as it is I feel like just adding a string compare against that single warning message and ignoring it since it is such a benign warning
<enebo>
needing to know you have more than one char in a set of matches will not affect correctness nor performance
subbu|lunch is now known as subbu
<enebo>
so perhaps we should punt on figuring out this duplicated char with a message match hack, then add proper message to joni to warn on which regexp is broke, the unhack for .17
<enebo>
As ugly as message match is the utility of the actual warning is so little it just seems simplest way to move past this for now