<puritylake[m]> headius: what is the best way to adjust parsing? Is it the RubyParser.y? It doesn't seem to affect anything when editted, does it need to be manually updated?
<puritylake[m]> s/updated/processed/
razetime has joined #jruby
razetime has quit [Ping timeout: 260 seconds]
<anewbhav_1[m]> Merry Christmas Folks.
<anewbhav_1[m]> So it is branch that comes out of main and is long lived in jruby/jruby and all PRs for 3.2 are merged with
razetime has joined #jruby
razetime has quit [Ping timeout: 272 seconds]
razetime has joined #jruby
razetime has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<JrmeCharaoui[m]> Hello, I'm seeing a lot of failures in spec:ruby:fast on 32-bit arches: i386, armel and armhf -- wondering if these failures are expected or not? https://pastebin.com/ZiVnFsCD
<JrmeCharaoui[m]> This is with 9.3.9.0 on Debian (Java 17)
JrmeCharaoui[m] is now known as lavamind[m]
razetime has joined #jruby
razetime has quit [Ping timeout: 260 seconds]
<lavamind[m]> Gah, pastebin removed it, here it is again http://sprunge.us/Q7zY2h
<lavamind[m]> The errors all seem related to #pack and #unpack in format 'j' or 'J' (pointer)
<lavamind[m]> Oh I'm wondering if I'm seeing this because these tests are running on 64-bit hardware ? The results seem to match what is expected when the tests run on 64-bit
<enebo[m]> puritylake headius There is a branch ruby-3.2 already
<enebo[m]> puritylake: ./tool/generate_parser will generate ruby and ripper parser from the RubyParser.y file
<enebo[m]> This is a "recharge" week for us so we will be more spotty than normal in responding to stuff but I will pop over and help when I can
razetime has joined #jruby
<puritylake[m]> Thanks enebo, hope you have a good time recharging
<enebo[m]> puritylake: thanks! happy holidays
<puritylake[m]> And to you
razetime has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sagax has quit [Read error: Connection reset by peer]