<GitHub116>
jruby/master f1f2c72 Jarkko Miettinen: Don't hack the internals of java.util.zip.CRC32 as we can use com.jcraft.jzlib.JZlib
<GitHub116>
jruby/master dcf3fb3 Jarkko Miettinen: Don't force the input value to an int. It's supposed to be long as that's the way to simulate 32-bit unsigned ints in the JVM
<GitHub23>
[jruby] kares closed pull request #5088: Use com.jcraft.jzlib.JZlib instead of hacking the internals of java.util.zip.CRC32 (master...jarkko-4834) https://git.io/vxq5b
shellac has joined #jruby
damnski has joined #jruby
bbrowning_away is now known as bbrowning
dipnlik has joined #jruby
yosafbridge has quit [Quit: Leaving]
yosafbridge has joined #jruby
shellac has quit [Quit: Leaving]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
dipnlik has quit [Quit: Connection closed for inactivity]
<GitHub81>
jruby/master 4b1279e Thomas E. Enebo: Yay. Ruby made some errors statically fail. For next,break,redo:...
<GitHub81>
jruby/master e3d52ba Thomas E. Enebo: Removal of old isSingleton counter for isInClass.
<GitHub81>
jruby/master e445827 Thomas E. Enebo: Fix a couple of syntax errors in parser.
<headius>
yay
<headius>
enebo: so like...remember how we've had issues with making super calls and whatnot, because we have to search for the impl class all the time?
<headius>
and sometimes that breaks, like if you get a hierarchy with a module in it twice
<enebo>
our impl is not correct and is too clever
<headius>
MRI handles super by storing the class at which level the method was found in the cache entry
<enebo>
we save all closures and walk up when it is unresolved but MRI does not do that
<headius>
so when you look up a method, you get a cache entry that has the method and the impl class
<enebo>
but I am maybe talking of a different case
<enebo>
(which is define_method one)
<enebo>
so probably different topic
<headius>
yeah it's related
<enebo>
we should not be doing that
<headius>
but this is more about finding where in hierarchy to start supering
<enebo>
we made what MRI could have done but said it was too hard (thanks subbu!)
<headius>
I just managed to add host module to CacheEntry
<headius>
that should make it possible to eliminate the implementer search
<enebo>
ok yeah I think I am mixing two things because whether it is def or define_method what you are talking about still applies
<enebo>
but we do eliminate the frame searching for name in most cases and then those are ordinary calls
<enebo>
for unresolved I guess we still do it I think
<enebo>
I need to review the code to even remember
<headius>
unresolved yeah
<headius>
which is also used for super in module methods
<enebo>
but I could see callsite cache for unresolved keep the search result with a guard?
<enebo>
so those last commits are very interesting to change the subject for a second
<headius>
yeah the tricky bit is that you need to have that host class at the point you super, so the body would need to be able to see the cache entry that called it
<enebo>
they do static compile errors for some conditions which used to be LJEs
<headius>
right
<headius>
they've done that more and more over the years
<enebo>
if nothing in the type system changes you can assume it is the same
<enebo>
well there are not that many
<enebo>
but definitely at least 9
<enebo>
so I can solve this issue by eagerly IRBuilding def/defs in cases I know it contains something
<enebo>
but in order to do that we need cheap detection without walking every tree
<enebo>
so AST will need to notice interesting nodes
<headius>
MRI does it by compiling everything eagerly?
<enebo>
I do not think this is a today sort of thing to fix but it is bothersome to think about
<enebo>
well I believe they compile to iseqs all the time
<headius>
is it not possible to detect at parse time?
<enebo>
def foo; break; end
<headius>
i.e. see a break, know we're not in a loop or closure, syntax error
<enebo>
well they don't do it that way but we may be able to
<enebo>
I mean we can for sure
<enebo>
but I am not sure if that is as appealing
<headius>
but they don't
<enebo>
no they do it building iseqs
<enebo>
basically our IRBuild
<headius>
well, it would be the most efficient way wouldn't it?
<enebo>
and it is very easy to add all those too
<enebo>
yeah but it requires some semantic knowledge to be baked more into AST vs it just being dumb organized storage
<enebo>
MRI does actually have some state for this stuff
<enebo>
like in_def or in_class
<enebo>
but nothing beyond those two
<enebo>
so now you need either bidirectional walk up AST (which would be sweet) or more states like in_closure, in_eval
<enebo>
but it is possible obviously
<enebo>
even my original desire of just knowing something should be eager or lazy by marking something in defnode would still need to know you are actually in a method
<enebo>
but we do have that state
<enebo>
truth be told we are discussing someone doing something which is not valid ruby
<enebo>
so the liklihood of this being an issue anyone even notices is small already
<headius>
so the issue with not doing it is that there's no error until it is encountered, or perhaps until it is first compiled?
<headius>
which would be first call to a method
<enebo>
yeah
<enebo>
so I excluded :)
<enebo>
if there was ever a nice case for rubyspec over test/unit I think it is how many people will jam more asserts into a test method than an it
<enebo>
the methods excluded test 4 different syntaxes for the same error and we pass all but the lazy one now
<headius>
ok
<headius>
I have a few more excludes coming
<headius>
the remaining failures don't seem to be very crucial ones, but I got sidetracked a bit playing with this cache entry thing
<headius>
enebo: so I pushed this host class into entry, and started using that cached host in all of our IR-based methods
<headius>
rather than dynamicMethod.getImplementationClass
<headius>
everything in test:jruby still passes the same
<headius>
this basically is now using that cached host class as the frame klazz
<enebo>
headius: well we will so how it goes
<headius>
but here's the better part...we might be able to nuke both the frame class and the impl search now
<headius>
since the host class the method is being called against is exactly the right place to start supering
<headius>
frame class needs to be there still for Java methods that super, but there's only a handful of them and I think we can modify the invoker logic to support passing host class to them too
<headius>
if we also push name through, as in IR methods, then there's no need for frame name either
<headius>
I'm trying a spec run with just this change, will see how it goes
<headius>
wow, specs ran green too
<headius>
I don't believe it
<headius>
let's see if we can remove the impl class search too