<byteit101[m]>
headius: Ah! JRubyFX always reports java stack traces with ruby exceptions as the cause due the threading model. That's where I see these
<byteit101[m]>
is there a way that I can catch those and re-convert into ruby stack traces from ruby? do I just need to re-throw the cause?
<headius>
It must be getting that from the Java trace. I only mangle those names for the class bytecode since it has to be something and all I have is the path to the .rb
<headius>
Characters like . Are obviously not allowed in class or package names
<headius>
Though, JRuby exceptions could rewrite the trace and use the unmangled name. By then it's just a string
<byteit101[m]>
right, I shall ignore it then
drbobbeaty has quit [Ping timeout: 252 seconds]
drbobbeaty has joined #jruby
<headius>
enebo: so now that this ArrayDeref optimization is in place there's some failures
<enebo[m]>
yay
<headius>
I fixed the one in CRuby tests, whereby a Hash with compare_by_identity needs to clone incoming strings
<headius>
the other one is in Proc#[] tests... it's checking that a pre-frozen string (like from .freeze or pragma) does not get duplicated
<headius>
and also that a normal string passes through as mutable
<headius>
so I am adding a flag to FrozenString operand to say whether it was pre-frozen
<enebo[m]>
oh heh. weird but I get the reasoning
<headius>
yeah it is a little weird but it lets me know whether this frozen string was created just for the optimization or if it was a "true" frozen string
<headius>
so I can just leave it as is if it is true
<enebo[m]>
yeah
<enebo[m]>
were those tests in MRI?
<headius>
the hash ones were from MRI, the Proc#[] is a spec
<enebo[m]>
I think I fixed the @@cvar used in wrong place in all scenarios but I need to write some specs
<headius>
Bleh this optimization is getting too complex, starting to wonder if I should kill it for now and revisit later
<headius>
I need to see whether MRI does this. It was discussed but then there's these exceptions
<headius>
If you use prefrozen strings it is moot...so this is just the case of caching a frozen strong when we know it's going to a Hash#[]
<headius>
Actually maybe that's the better path. Normal call site unless it is a hash target, then we pass a frozen string we cache at that point
<headius>
In any case the coverage work is paying dividends. I will try to cover all JIT logic
<enebo[m]>
nice
<headius>
Then we will have some confidence that the compiler spec hits all of that code, maybe be able to drop some jobs from CI
<enebo[m]>
I guess so...but it is nice to have some random activiity across code since coverage does not equal completeness
<headius>
Right we'll see
<headius>
As I break things during this process I'm adding cases for those too
<enebo[m]>
One thing is clear you are finding things to fix so that is reward enough but removing some jobs may be good
<enebo[m]>
I could see us not running spec:ruby:fast:jit but running MRI jit covers so many weird edge cases it probably is still worth it
<byteit101[m]>
Yay for the @@cvar fixes!
<enebo[m]>
byteit101: I keep rolling around on this fix
<enebo[m]>
I am on like the 4th solution now
<byteit101[m]>
:-)
<enebo[m]>
but what is currently in the PR I think breaks less than what was there
<byteit101[m]>
That's good
<enebo[m]>
frame records topself as a live value
<enebo[m]>
staticscope records what types of scopes we are in
<enebo[m]>
hmm I realized another detail :)
<byteit101[m]>
Glad I could find such an interesting bug for you :-D
<enebo[m]>
tbh I knew it was not correct and I hate that this check even exists
<enebo[m]>
So I did not do a good job to begin with
<enebo[m]>
Like do people really need to be safeguarded against setting @@cvar on Object if it happens to be done in a non-module/object scope
<enebo[m]>
Was this really causing bugs to occur?
<headius>
Awful feature
<byteit101[m]>
make it even more awful: tie the error to safe levels!
<headius>
Thank goodness they finally agreed with us and got rid of safe and taint
<headius>
I'm glad you never bothered through the implement those completely