Successus has quit []
Guimauve has joined #jruby
<Guimauve> ...any chance modern jruby can run on an ancient JDK, such as that available for windows xp? (yes, you heard that right. the department of education operating within a local prison has an entire room of machines running windows xp and ZERO chance of changing them in any way)
razetime has joined #jruby
razetime has quit [Ping timeout: 268 seconds]
Guimauve has quit [Quit: Client closed]
razetime has joined #jruby
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
AndyMaleh[m] has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
razetime[m] has quit [Quit: Bridge terminating on SIGTERM]
duane21[m] has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
nilsding has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has joined #jruby
razetime[m] has joined #jruby
kares[m] has joined #jruby
ahorek[m] has joined #jruby
byteit101[m] has joined #jruby
duane21[m] has joined #jruby
AndyMaleh[m] has joined #jruby
JasonMiller[m] has joined #jruby
nilsding has joined #jruby
headius has joined #jruby
lopex[m] has joined #jruby
<enebo[m]> razetime: there is a couple of error not ironed out but most of pattern matching is working. Something with hash patterns in the IR we generate. It is probably a small transcription error
<razetime> hmm, I see.
<enebo[m]> razetime: I used the ruby pseudo code as a reference from MRI compile.c in their comments
<razetime[m]> I see
<enebo[m]> but our IR is not Ruby so I messed something up
<razetime[m]> Were there any lexer changes that were of note?
<enebo[m]> for pattern matching?
<razetime[m]> yes
<enebo[m]> I don't remember. I made them a long time ago now but I doubt it is much since the parser is where the bulk of the pattern matching changes occurred
<razetime[m]> hm, I see.
<enebo[m]> since it is matching different productions I would not think the lexer needs to do much differently
<enebo[m]> usually it is when productions highly overlap where they add a new lex_ctxt state or something to disambiguate
<razetime[m]> ok, make sense. I was wondering whether there was a relation between the only errors being on symbols in my fork (^ and }) so i thought there would be some change thee
<razetime[m]> what is strange is truffleruby is very much similar and there is little to be found in a diff
<enebo[m]> oh yeah?
<enebo[m]> The .y includes all the pattern matching productions now?
<razetime[m]> yes, I've ported all the pattern matching productions from jruby in a fork
<enebo[m]> cool
<enebo[m]> $$ = new BeginNode(lexer.tokline, $3);
<enebo[m]> }
<enebo[m]> p_expr_ref : '^' tLPAREN expr_value ')' {
<enebo[m]> I mean I would think '^' here could only really get confused if it saw the generic '^' as the operator but that I would suspect would just be something wrong with the grammar
<enebo[m]> Examining JRuby AST against MRIs AST would resolve if something like that is happening (we have -S ast to dump some code)
<razetime[m]> oh, there was a tool recently added to truffleruby to dump AST
<razetime[m]> I will check the mri ast as well
<enebo[m]> razetime: yeah. Let me know if something is mismatched in AST since we will have same problem
<razetime[m]> well the thing is my port throws a syntax error and jruby runs fine
<razetime[m]> even produces correct behaviour
<enebo[m]> ah
<enebo[m]> ok. I see why you are asking about lexer although parser could also be the issue (like tCARET vs '^') or something like that
<enebo[m]> This last set of changes also went a bit further in match MRI more
<enebo[m]> Those changes should have happened in an earlier JRuby but some of these source changes are so low payoff for effort I tend to realign in larger parser updates (which I know makes it more difficult to pick up these changes)
<razetime[m]> cool, will check the commits, mr golimaar
<razetime[m]> but first let me see if i missed any lexer changes
<enebo[m]> hahah
<enebo[m]> yeah feel free to ask questions if you something does not make sense
razetime has quit [Ping timeout: 265 seconds]
razetime_ has joined #jruby
razetime_ has quit [Remote host closed the connection]
<headius> enebo: where did we land on 9.2 after the jruby-complete jar realization? Still going to wait and see if anyone needs it?
<headius> 9.2 and the psych DOS thing
<enebo[m]> headius: yeah I think we wait and see
<headius> fine by me
<headius> enebo: ok I reviewed 9.3.8 stuff
<headius> two issues and two PRs are for handling of alias and visibility wrappers, related to supering up those wrappers... those both look good to me other than a lot of rogue whitespace changes
<headius> one is the Time.at issue you wanted to get cherry-picked into 9.3
<headius> and the last is the SnakeYAML thing, with some discussion about the new "DoS" issues
<headius> I'm on the fence about waiting for a PR to fix or workaround those other DoS items because Andrey does not believe they are DoSes but at least one of them could be avoided with configuration
<enebo[m]> I do not think that Time.at is fixed on master but it might be
<enebo[m]> k7chi basically reverted it to fix some regressions although he may have also fix it
<enebo[m]> I will try the time.at thing on master and see
<enebo[m]> (which may not be a simple cherry-pick since it might also include 3.{x} fixes
<enebo[m]> ah yeah master is broken again for this. I will see if I can quickly solve this
<enebo[m]> I am not really sure what the right thing for snakeyaml is but I do not want to release 2 days later so we should have some confidence on our decision
<enebo[m]> 2 days later == 9.3.8.1
<headius> oh I see
<headius> well fix or not fix it seems somewhat low priority if we have to push 9.3.8 this week
<headius> the inheritance chain wrapper stuff was accompanied by tests and seems logical (it was picking the wrong super method in the wrapper, so just an issue of not delegating right)
<headius> I am 86.3% confident in those changes
<enebo[m]> 3 repeating of course
<headius> of course
<enebo[m]> omg. I kept trying to connect to debugger and I had switched to 9.4 intellij window
<headius> good job
<headius> I've got to fix this polyglot maven element ordering thing... constantly have dirty XML in my diffs
<headius> hmm could we be on an old version? I think this was fixed
<headius> well we are using one before the change... oh happy day
<headius> only affects the latest two polyglot releases... I'm going to upgrade 9.3 to use 0.4.7 which seems to have consistent element ordering now (after committing the new ordering)
<headius> woot it works
<headius> enebo: you can pull this branch and confirm building works and does not reorder anything in XML
<headius> ok those are my tasks for the day... I'm going to shift gears and see if I can figure out why this MRI suite is hanging on master
<enebo[m]> headius: mri is hanging?
<enebo[m]> headius: I am on update_polyglot and see two .xml files as changed building with Java 8 core and lib pom.xml
<headius> hmm
<headius> test:mri:core:int hung in most recent master build
<headius> and kiichi reported that it has been really slow
<enebo[m]> hmm there was only one PR from this weekend
<headius> enebo: that was on a clean checkout?
<headius> I build with 8 and 11 here and it did not reorder after I committed the changes
<headius> if it is reordering for you perhaps it is something else different between us
<enebo[m]> oh heh and my Kernel#clone fix
<enebo[m]> It was not on a clean checkout
<enebo[m]> ah 5 hours
<headius> 5 hours!
<enebo[m]> I will say I did do one thing which had a perf issue
<enebo[m]> clone is convoluted and they remake the option hash for frozen and use a C module variable so it only makes one
<headius> it could be it just was extra slow and got killed this time
<enebo[m]> We make it every time
<headius> but the slowness should be investigated anyway
<enebo[m]> I assumed that would have an extra cost but not this one :)
<enebo[m]> We cannot assume we can just reuse a single instance of a hash because threads+
<enebo[m]> The proper solution is to not use their logic and push that option along through the intermediate methods so init_copy can just use the same hash that was sent
<enebo[m]> That would be mildly semantically different if some makes a super-faked-out hash but not really and notices it is accessed twice
<headius> could use a thread-local hash but that may be going too far
<enebo[m]> I mean the truth is if we had a formal way of passing keywords natively we could just pass it another way and not make a RubyHash
<enebo[m]> I am assuming we will solve it that way when we get there
<headius> yeah it's coming soon
sagax has quit [Read error: Connection reset by peer]