lucasb has quit [Quit: Connection closed for inactivity]
cpuguy83 has quit [Remote host closed the connection]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest80811
Guest80811 has quit [Ping timeout: 244 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest54619
Guest54619 has quit [Ping timeout: 245 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest66985
Guest66985 has quit [Ping timeout: 244 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest9549
_whitelogger has joined #jruby
Guest9549 has quit [Ping timeout: 245 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest93222
Guest93222 has quit [Ping timeout: 258 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest72969
Guest72969 has quit [Ping timeout: 258 seconds]
sagax has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest21025
shellac has joined #jruby
Guest21025 has quit [Ping timeout: 244 seconds]
shellac has quit [Quit: Computer has gone to sleep.]
whitingjr has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest88094
drbobbeaty has joined #jruby
Guest88094 has quit [Ping timeout: 258 seconds]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rusk has joined #jruby
_whitelogger has joined #jruby
whitingjr has quit [Ping timeout: 272 seconds]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest42964
Guest42964 has quit [Ping timeout: 248 seconds]
whitingjr has joined #jruby
drbobbeaty has joined #jruby
shellac has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest29092
whitingjr has quit [Ping timeout: 245 seconds]
Guest29092 has quit [Ping timeout: 258 seconds]
whitingjr has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest48377
shellac has quit [Quit: Computer has gone to sleep.]
Guest48377 has quit [Ping timeout: 258 seconds]
shellac has joined #jruby
lucasb has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest68344
Guest68344 has quit [Ping timeout: 258 seconds]
rusk has quit [Remote host closed the connection]
sagax has quit [Remote host closed the connection]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest9160
byteit101 has quit [Remote host closed the connection]
shellac has quit [Ping timeout: 250 seconds]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
whitingjr has quit [Ping timeout: 245 seconds]
Guest9160 has quit [Remote host closed the connection]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest17619
Guest17619 has quit [Remote host closed the connection]
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest10360
<headius[m]>
g'day
Guest10360 has quit [Ping timeout: 264 seconds]
sagax has joined #jruby
cpuguy83 has joined #jruby
cpuguy83 is now known as Guest95415
<headius[m]>
So I have a conundrum
<headius[m]>
still can't figure out a better way to detect scala classes other than scanning annotations
<headius[m]>
which means we have to scan annotations for every class we want to bind in Ruby
<headius[m]>
most of the time there will be zero classes from Scala so this is wasting a lot of time at boot of anything JI-heavy
<enebo[m]>
require 'scala'
<headius[m]>
opt-in is certainly an option
<enebo[m]>
Maybe 9.3 API change but if you want scala integration you opt in to pay that price
<headius[m]>
require 'jruby/scala_support'
<headius[m]>
that's better than adding a flag
<enebo[m]>
yeah whichever mechanism
<headius[m]>
I just don't know if anyone uses this
<headius[m]>
it's also only used for Scala singleton objects
<headius[m]>
to make the proxied class look like the singleton
<headius[m]>
there's some swallowed exceptions that might be triggering for all Scala classes that aren't singletons
<enebo[m]>
maybe there is a more obvious simpler check for singletons in scala itself beyond annotation or is annotations how it is specified
<headius[m]>
if it finds a scala annotation it proceeds to try to reflect out the singleton bits
<headius[m]>
blindly
<headius[m]>
because I have no other ways of detecting it
<headius[m]>
I just spent 30 minutes poring over bytecode output from scalac and this annotation search seems to be the only way
<headius[m]>
--dev --disable-gems -e 1 is under 1s on my system now with recent JI tweaks
<headius[m]>
it may be lower than that with the --dev improvements on the other branch
<enebo[m]>
I wondered about a Method database but then we run into all the problems of holding a lot of data which won't be needed over time
whitingjr has joined #jruby
<enebo[m]>
I also wondered something about Java itself
<enebo[m]>
Are these Method instances constructed on the fly by the JVM. I assume so but it made me wonder
<headius[m]>
yeah working on speeding this up I have renewed interest in a serialized form
<headius[m]>
I still feel like there's a better algorithm possible here for binding classes
<headius[m]>
I need to fully document what it's doing so maybe we can see a better path. Biggest challenge to streamlining it is that it needs to search up class hierarchy to choose the highest implementer, and it needs to do this before proceeding to bind methods
<headius[m]>
it might work better if it searched from the top down
<enebo[m]>
and those binds still happen on each leaf right?
<headius[m]>
the logic I've optimized fires once per class you actually need to reference from Ruby, at the point at which the Java object needs to enter Ruby
<headius[m]>
so if you have Foo < Bar < Baz and you only reference Foo, it will only do this for Foo
<headius[m]>
the logic I added does cache some of the intermediate reflection results for Bar and Baz now though
<enebo[m]>
but all Foo and Bar methods have defs on Baz right?
<enebo[m]>
err which ever way those < go :P
<headius[m]>
each class ends up with a collapsed view of methods from all superclasses
<headius[m]>
there's definitely overlap that's hard to suss out
<enebo[m]>
I was thinking about a case like Swing where nearly all leaves will be the same subtypes bindings plus whatever they specifically have
<headius[m]>
hmm I do have an idea now
<headius[m]>
all we really need to do at initial binding is figure out the names
<headius[m]>
so basically any public method names -> go straight to binding
<headius[m]>
then defer the actual calculation of overloads and superclass to dispatch from on first call
<headius[m]>
this is doing all that work up front and when it finally binds the method it has a perfect set of overloads
<enebo[m]>
There are two kinds of laziness possible here and both depend on how things will be used
<enebo[m]>
One is assume almost nothing is actually called. One is assume common subsets will be used again by other types
<enebo[m]>
They are not orthogonal but they are definitely mildly at odds
<enebo[m]>
I would assume if you use JFrame you probably use JButton so both fo those will have same sub-type at some point so calculation of bindings up to that subtype would be helpful....however...
<enebo[m]>
if you look at sheer amount of methods on JButton or JFrame you will not call 95% of those
<enebo[m]>
so both laziness approaches have some merit
<enebo[m]>
This is indepdendent of you calculating which methods exist without resolving which impl to call
<enebo[m]>
Fastest possible resolution of the name subsets would helpful but I can even improve this resolution
<enebo[m]>
We know the JVM version and if you can calculate just the names a type must respond to we can just save per JVM version somewhere
<headius[m]>
Yeah a first scan using getMethods (gets all public methods from all hierarchy) would get the public names
<enebo[m]>
It would have wrinkles but it would be very fast
<enebo[m]>
In fact you could almost AOT that
<headius[m]>
Definitely could speed this up with a database of all classes and methods in a given Java level
<headius[m]>
The set of public methods should not change for a whole major Java level
<enebo[m]>
yeah so I think getMethods() as first pass then evaluate persistence using JVM versioning as key to see if it is much faster
<enebo[m]>
but I think what I was saying above will be true...most Java methods will not be called
<enebo[m]>
although if you call 10 methods on one type it may be nice to have some saved metadata after method 1 is called
<enebo[m]>
which in a sense is where the second caching strategy I mention could be helpful (on paper)
<enebo[m]>
in practice my uses of JI have been single libraries
<enebo[m]>
those are always rooted in common interfaces and sub types
<enebo[m]>
when I said laziness above I mean laziness and caching respectively
<enebo[m]>
not calling most methods is the laziness and sub-type resolutions is caching
<headius[m]>
Yeah the laziness seems like it can definitely work
<headius[m]>
even just partitioning methods by name as a first pass and deferring the calculation of overloads until first call would save a lot
<enebo[m]>
I think the laziness will definitely pay off because most methods will not be called for nearly all types
<headius[m]>
and it should be idempotent on any JVM without agents messing with stuff
<enebo[m]>
but calculating all overloads is likely not worth it
<enebo[m]>
for a type
<enebo[m]>
though in that case a cache becomes more appealing for what has been calculated
<headius[m]>
yeah it has to search anyway on call so might as well defer the collapsing of overloads until needed
<enebo[m]>
so just one method at a time as called then?
<headius[m]>
well we ball up all overloads from all classes in the hierarchy for a given name
<headius[m]>
currently we also sort out what the highest public implementer is for each signature
<headius[m]>
that calculation prevents pipelining the method aggregation
<headius[m]>
basically doing that calculation in advance forces us to create a perfect view of that method before proceeding to the next step where we figure out which names we want to bind (i.e. some are protected like initialize)
<headius[m]>
so step 1, create a big Map with a bunch of List of methods
<headius[m]>
step 2, tear that map down and make another collection of MethodInstallers with their own List of methods
<headius[m]>
I think I can pipeline all methods grouped by name into the second step and do the step 1 calculation on a deferred basis
<headius[m]>
this will also let us bind a special handler for methods that aren't visible so we can report module suggestions
<headius[m]>
so basically we will just bind all names that have any public or protected method on any class in heirarchy
<headius[m]>
at call time, we'll sort out the proper set of signatures and supertype to dispatch with, or report an error saying "no public signatures and class is not open, do this..."
<headius[m]>
I'm not sure if this helps my original scala problem but making that opt-in is a good solution
<enebo[m]>
so just one method resolution at a time or the whole type?
<headius[m]>
one method at a time as needed
<headius[m]>
but ahead of time I would gather all of them
<enebo[m]>
ok yeah it makes the most sense
<headius[m]>
so basically cached retrieval of all methods from classes up the hierarchy, no more than once per class in the system ever
<headius[m]>
and then on a bound-method basis, defer the calculation of public/protected, overloaded signatures, etc
<enebo[m]>
oh so one retrieval of all methods per type but the actual resolution per specific attempted call will then walk all those cached methods for resolution at that point
<enebo[m]>
I was thinking you would just subtype getPublicMethods for just name retrieval and then lazy-grab Method per types on first time that resolution actually occurs
<enebo[m]>
I guess saving them off would also make sense as a cache for laziness not being as expensive to calculate
Guest95415 has quit [Remote host closed the connection]
<headius[m]>
yeah I need protected too though
<headius[m]>
mainly for super calls from child classes...I suppose there's a way to defer that until needed
<headius[m]>
but historically we have bound all public and protected methods so people have code expecting that
<headius[m]>
getMethods only returns public...so we do a walk of all classes calling getDeclaredMethods