<enebo[m]>
headius: I do not see anything wrong with that PR. Having real ruby threads directly seems right to me but I do wonder if you see the same flakiness without this PR
<enebo[m]>
If it is flaky before and after then I guess there is just something else to be figured out (on our side or theirs)
<headius[m]>
enebo: see commit on master also please
<headius[m]>
the PR should be totally fine but I get this weird failure in concurrent-ruby
<headius[m]>
doesn't seem like it should be related
<headius[m]>
so the PR is still open and the commit on master is a simpler fix
<enebo[m]>
but do you see the failure without the fix on ruby-concurrent
<enebo[m]>
ever
<headius[m]>
I don't consistently see it with the fix
<headius[m]>
it almost seems like a too-short timeout on join but when I return to working on the PR I'll try to get it to fail without
<headius[m]>
there are new features obviously but lots of this is just deprecation
<headius[m]>
blockless `proc` and `Proc.new` are finally deprecated
<headius[m]>
flip-flop is undeprecated
<headius[m]>
that stupid syntax...I have a feeling we're going to be forced to implement it
<enebo[m]>
I doubt it :)
<enebo[m]>
fwiw it seems one person in Japan uses it for command-line -e scripts
<headius[m]>
but mame will never use JRuby if we don't
<enebo[m]>
hahahahaha
<enebo[m]>
but yeah it is obviously possible to re-add it as a syntax
<headius[m]>
it's just a matter of us adding IR compile, yeah?
<enebo[m]>
I still feel priority-wise it is wiser to work on nearly anything else
<headius[m]>
all the parser and AST bits are there
<enebo[m]>
well the original IR was actually adding new vars to staticscope
<enebo[m]>
or it seemed like it
<enebo[m]>
but we do add something during flip flop detection in AST from what I remember
<enebo[m]>
but it is all immaterial...I am not going to chase this unless it actually becomes an issue and it hasn't been an issue for as long as it has been removed which is like 6 years
ur5us has joined #jruby
<headius[m]>
it's probably easier to implement with improvements we've made to IR since then
<headius[m]>
but I thinkn the main sticking point was that the hidden variable needs to work across block scopes too
<headius[m]>
anyway yeah... nobody's ever filed a bug about it being missing except other implementers
<headius[m]>
I'm happy to leave it that way
<enebo[m]>
I am working towards not doing any new variable logic in IR since we in theory can do it from staticscope data
<enebo[m]>
the main issue when I last worked on it was we adjust all references to any variables in for loops
<enebo[m]>
Once that is working it will reduce overhead of loading code and this will be more noticeable in persistence
<enebo[m]>
but it does a lot of simple logic constantly when just doing IR building
<headius[m]>
yeah sounds great
<headius[m]>
man I want to finish this 2.6 stuff so I can take a performance break
<enebo[m]>
for looops in serialization and inliner callsites still need to be readded too
<headius[m]>
down to 110 fails on 2.6 specs
<headius[m]>
enebo: where is logic for parsing constants?
<headius[m]>
Module#const_set is still rejecting unicode caps
<enebo[m]>
in RubyLexer under main identifier method
<enebo[m]>
there are only two with identifier in the name
<headius[m]>
got it
<headius[m]>
enebo: aha I see the problem
<headius[m]>
deep inside RubyModule.storeConstant it does an assert on IdUtil.isConstant, but passes in the ID string
<enebo[m]>
b4cc0c0 was last commit for it
<headius[m]>
in the example that's failing, the ID string has been mangled from `ἍBB` and the mangled ASCII result has a leading lower-case char
<enebo[m]>
ah ok so lexer is probably ok it is just the util methods we had needed changing for their new capitalization
<enebo[m]>
which is weirdly permissive
<headius[m]>
I'm not positive about the right way to fix...debating just removing these deeper checks
<headius[m]>
we have checks elsewhere in this sequence that do sym.validateConstantName
<headius[m]>
the ones that work against the ID string are likely to be wrong in all cases now and without knowing original encoding they can't be made right
<headius[m]>
I suppose this logic could pass through the properly encoded String for verification also
<headius[m]>
see RubyModule.storeConstant
<enebo[m]>
nothing should use ID string for this
<enebo[m]>
not as a statement of how it is now but just a statement
<headius[m]>
storeConstant is almost the last method before it goes into constant table
<headius[m]>
so all it has at that point is the id string
<headius[m]>
at least along this path
<enebo[m]>
so there are two paths even if it is one method
<headius[m]>
yeah lots of places call this
<enebo[m]>
one is what we get which really is an id string and that should not be doing this (at least using id)
<enebo[m]>
the second is embed/internal use when we know it is more or less a clean UTF-8/ASCII Java string
<headius[m]>
some are probably passing properly decoded string (which would be wrong for this table if there's unicode chars) and some are passing ID string (which is right for this table but wrong for the verification)
<enebo[m]>
yeah pretty much what I just said so we are on same page
<enebo[m]>
without making MOAR methods I think we have to remove the assert
<headius[m]>
really this check should be confirming that the incoming string is of ID string form, and contains no characters outside ISO-8859-1 range
<headius[m]>
yeah I will remove it... but what about adding an assert for ID string?
<headius[m]>
I suppose I could add a hard error first and see what fails
<headius[m]>
this method should never get anything but ID strings
<enebo[m]>
yeah I mean tbh I don't know how much in embedding is wrong in some way like 223
<enebo[m]>
that assert will likely maybe figure that out
<enebo[m]>
I doubt our internal tests are that comprehensive
<headius[m]>
heh
<enebo[m]>
but you are correct inasmuch as our current impl really wants 8859_1 data with a symbol table entry as well
<enebo[m]>
so if we do trip on this then the 223 impl (or whatever) should be doing some more work that it currently isn't
<headius[m]>
I am auditing other calls to IdUtil.isConstant and replacing them with RubySymbol.validConstantName
<headius[m]>
where appropriate
<headius[m]>
IdUtil.isConstant should never receive ID strings
<enebo[m]>
ok
<headius[m]>
ick, there's a lot of these paths
<headius[m]>
almost all used from JRuby are passing through ASCII strings though
<headius[m]>
well all I've seen are
<headius[m]>
enebo: any reason that RubySymbol couldn't cache the proper decoded Java string for toString?