nilsding has quit [*.net *.split]
Freaky has quit [*.net *.split]
jimtng[m] has quit [*.net *.split]
Freaky has joined #jruby
jimtng[m] has joined #jruby
nilsding has joined #jruby
<headius> Nice
jimtng[m] has quit [Quit: You have been kicked for being idle]
subbu has joined #jruby
subbu has quit [Client Quit]
subbu has joined #jruby
<enebo[m]> puritylake no problem. if you want to consider working on another part of sprintf or even work on some of our 3.1 spec failures then that is cool
<puritylake[m]> Been working on some spec failures, believe I have fixed some in array, namely the failures relating to expecting FrozenErrors. The problem was that inside a block passed to delete_if or reject! the array was changed to frozen but the code itself never checks for a change to this so I added a check if the block yields true
<puritylake[m]> I am wondering now if I should still add a check even if the Array isn't being modified?
<enebo[m]> puritylake: this is a case where you can run C Ruby and see what they do
<enebo[m]> Ruby 3.1 is what we are going for
<enebo[m]> Also you may have seen we a convenience method checkFrozen for the actual raising bit
<enebo[m]> The other thign is modify() will also check frozen status too
<puritylake[m]> modifyCheck seems to do raise also
<enebo[m]> puritylake: yeah modify calls modifyCheck
<puritylake[m]> Ah, might be best then to call modify so
<puritylake[m]> Hmm, by the `isShared` properity, does it mean by another thread or?
<enebo[m]> oh isShared in Array is us using COW (Copy On Write). We may share the same backed data in multiple Ruby Array instances
<enebo[m]> modify will toggle that state so we don't modify some other array sharing the same data
<puritylake[m]> Ok, was just making sure
<puritylake[m]> Well that method is called at the top of the `rejectBang` method so I feel it makes more sense reading wise at least to just call `modifyCheck`. Unless can the array regain the isShared property during that block?
<puritylake[m]> * regain the `isShared, * isShared` property
<enebo[m]> yeah any array operation which works on the same instance has to have that shared logic so modify is better
<enebo[m]> I think there might be an argument that we are throwing too quickly for frozen (although I don't know if that is true or not) if MRI only raises frozen error if something is actually deleted
<enebo[m]> MRI = C Ruby
<enebo[m]> force of habit. Matz Ruby Interpreter
<puritylake[m]> Just about test it out
<enebo[m]> Which it hasn't been in more than a decade but habits die hard
<enebo[m]> I did not look at any of those failures either
<enebo[m]> It all seems to be about subclasses of Array and not Array instances themselves
<enebo[m]> One big change in Ruby 3+ was non-modifying methods (e.g. not !-ending ones) would return new instances of Array and not of the particular subclass of array it was being made from
<enebo[m]> MyArray < Array. If it called grep it would not return a new instance of MyArray but of Array
<enebo[m]> I would not think this would be part of the failures UNLESS we did not change that behavior and the testsuite itself is doing something odd using the non-destructive methods
<puritylake[m]> Well my fix seems to affect the subclass tests
<enebo[m]> ah cool
<puritylake[m]> Oh well delete_if isn't a bang method but it calls a bang method
<enebo[m]> yeah that is interesting...It is one of those methods which is not banged
<enebo[m]> This also happens for << but of course that cannot be banged
<enebo[m]> rejectBang does have modify() at the top
<enebo[m]> oh but that is non-block form
<puritylake[m]> non-block form?
<enebo[m]> I meant the opposite of that...there are two code paths one for when a block is passed and one when you want to return an enumerator
<puritylake[m]> Ah yes, I saw that `enumeratorizeWithSize`
<enebo[m]> I just looked at the actual failing test. I should have just looked at it rather than make up random theories
<enebo[m]> you are right above checkFrozen is all you need in the loop
<enebo[m]> but with that said your other question is a good one
<enebo[m]> if that was a.freeze\nfalse would it complain?
<puritylake[m]> I'll check now in a second
<puritylake[m]> Just installing 3.1.0 on my WSL
<enebo[m]> ah windows
<enebo[m]> are you doing JRuby work in or out of WSL?
<puritylake[m]> In WSL
<enebo[m]> ok
<enebo[m]> We have lots of possible Windows support issues
<puritylake[m]> I'd be happy to help with that if you want
<enebo[m]> It is one of our weaker areas. We can run Rails and stuff but our CI situation on windows is pretty bad
<enebo[m]> puritylake: if you have the interest it is a high value area just because it has been historically so poor
<puritylake[m]> I am not an expert with windows (or linux but have a bit more experience) but I am sure I can help
<enebo[m]> So jruby-9.3 does run that particular job
<enebo[m]> The issue of that not starting I would lay money is changes to our stdlib
<enebo[m]> I think you should finish this delete_if stuff which will help give you more experience poking around individual methods
<enebo[m]> Most of windows support will be wondering why a method is a little different
<puritylake[m]> Also to answer the "should it throw if made frozen mid run" it doesn't in 3.1.0
<enebo[m]> So it will be spending a lot of time around a particular Ruby method impl
<enebo[m]> If you are interested I will try and make some effort this week to actually figure out that fiddle error killing bundle install
<enebo[m]> puritylake: but only if all false results
<enebo[m]> Yeah so we are calling safeArraySet and that point likely should have a checkFrozen above it
<puritylake[m]> Nope even if all are true
<enebo[m]> Those tests I thought were from 3.1
<puritylake[m]> oh wait, for some reason my ruby version didn't activate proerply
<puritylake[m]> s/proerply/properly/
<puritylake[m]> Was still testing on pre 3
<enebo[m]> mri31 -e 'a = [1,2,3]; a.delete_if { |e| a.freeze; true }'
<enebo[m]> But false will not hit it
<enebo[m]> mri31 -e 'a = [1,2,3]; a.delete_if { |e| a.freeze; false }'
<enebo[m]> So more or less this means only the actual set operation to shift the values will do the frozen check
<enebo[m]> err safeArraySet
<enebo[m]> I don't see a method which is safeArraySet and checkFrozen
<enebo[m]> so I guess just a checkFrozen inside if above that call
<enebo[m]> I need to be on a call for a bit so I will afk
<puritylake[m]> No problem
<byteit101[m]> > byteit101: I'll coordinate with enebo to get it posted this week
<byteit101[m]> headius: which definition of "week" are you using?
<byteit101[m]> :-D
subbu has quit [Ping timeout: 256 seconds]
<headius> Yes sorry, I've been desperately trying to get as much work done as possible before I take a trip this week
<headius> We're hoping to have Rails 7 working, if not working well, by RailsConf in about 2 weeks
<byteit101[m]> Ah, makes sense!
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<puritylake[m]> enebo: When create a PR for test fixes, should I set to merge to jruby's master branch?
<puritylake[m]> s/create/creating/
<enebo[m]> puritylake: for our next big release 9.4 master. If you were fixing a bug for an existing series like 9.3.x then you would use jruby-9.3 (or possible jruby-9.2)
<enebo[m]> Once 9.4 is released we wait some amount of time since there are bound to be some quicker point releases then we make a maintenance branch (which will be jruby-9.4).
<enebo[m]> So master is right for this stuff
subbu has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
<puritylake[m]> Also think there may be an issue with the `eval` method
<puritylake[m]> `eval([{},{},{},**{}]).size` should be 3 but jruby returns 4
<enebo[m]> that eval contents should be a string right?
<enebo[m]> I happen to be working on keyword args and even though this is not strictly that it is the same code
<puritylake[m]> Yes, sorry the backticks threw me off
<enebo[m]> well I crash so that is something
<enebo[m]> jruby --dev -e 'p(eval("[{},{},{},**{}]"))'
<enebo[m]> Unhandled Java exception: java.lang.ClassCastException: class cannot be cast to class org.jruby.RubyBasicObject
<enebo[m]> I added the code for this on Friday so thanks for finding this issue
<enebo[m]> I will fix it
<enebo[m]> puritylake: and technically this is just ```[{}, **{}]```
<enebo[m]> puritylake: That is the AST and the instrs generated
<enebo[m]> or at least the instrs which come out of IRBuilder
<enebo[m]> That MERGE_KWARGS if it sees both are empty hashes it returns UNDEFINED as a special value
<enebo[m]> That allows me to determine it is an empty kwargs vs an empty hash and then remove it from a call
<enebo[m]> but this is making a LITERAL hash so this should just be making the empty hash
<enebo[m]> This is potentially worse than just not handling UNDEFINED since this MERGE_KWARGS should not be occuring (since it will not only merge two hashes together but also set the hash to have flags specifying it is a keyword arg)
<enebo[m]> puritylake: Just showing you a bit since you originally said you were interested in IR
<puritylake[m]> I appreciate it, there is quite so much about the internals I don't know but want to know
<enebo[m]> Err I diagnosed this a bit wrong. Array itself needs to see this as UNDEFINED and not add it as an element just like a normal call
<puritylake[m]> s/quite//
<enebo[m]> This sort of sucks since it means having to emit the equivalent of an if/else in IR. So far that has seemed a reasonable way to solve this issue since ** is not that common to overall calls
<enebo[m]> but I am wondering if this leads to much weirder behavior: [**{}, **{}, {}, **{}]
<enebo[m]> ah hmm maybe it doesn't allow this
<enebo[m]> you can do it as call arguments but maybe not as a literal array element
<puritylake[m]> `./bin/jruby --dev -e 'p(eval("[**{},**{}]").size)'` returns 1
<enebo[m]> that is wrong but the same bug
<enebo[m]> I notice I can add any number of ** onto the end just not earlier
<puritylake[m]> Ya it results in syntax error
<enebo[m]> Those will keep merging together so the if/else will only have to worry about whether it needs to add an extra last argument. It also will not need to emit that if/else logic unless there is a **
<enebo[m]> I see a class cast exception
<puritylake[m]> `./bin/jruby --dev -e 'p(eval("[**{},{},**{}]").size)'`
<enebo[m]> jruby --dev -e 'p([**{}, **{}])'
<enebo[m]> oh yeah ** allowed on front for array literals I guess
<enebo[m]> in a call you can foo({{a}, {b: 1}, **d})
<enebo[m]> heh well there was a ** on front of that
<puritylake[m]> Also you can stop it crashing add `.size`
<enebo[m]> actually two of them
<enebo[m]> yeah the eval is covering this up
<enebo[m]> The eval is not needed
<puritylake[m]> Fair point, I was still in the mindset of the test I was trying to fix
<enebo[m]> jruby --dev -e 'p([**{}, **{}].size)'
<enebo[m]> Yeah that is interesting....size on the end of it does change how the arguments are processed
<enebo[m]> wow that is really weird
<enebo[m]> hahah
<enebo[m]> So UNDEFINED is an IRubyObject but it is not usable. If you try and print it or act on it bad things happen
<enebo[m]> but we can still stuff it into a Ruby Array so long as we never try and use the value
<enebo[m]> Array#size only calculates its size
<enebo[m]> So it knows 1 thing is in there and works
<enebo[m]> dinner time
subbu has joined #jruby
subbu has quit [Ping timeout: 276 seconds]