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
<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
<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]>
Unhandled Java exception: java.lang.ClassCastException: class org.jruby.ir.operands.UndefinedValue 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
<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 **