<headius[m]>
we settled the static int part of this
<headius[m]>
new/initialize I think is also settled?
<byteit101[m]>
Is the current class I put it in ok? I felt like it was out of place in that class, but wasn't sure a good place to keep the @ivar names
<headius[m]>
looking
<byteit101[m]>
(I pushed ThreadLocal changes to the PR)
<headius[m]>
yes I think that is fine
<headius[m]>
it won't be a visible change if we decide to refactor it to a util class somewhere but anywhere we put it is pretty synthetic
<byteit101[m]>
yes
<byteit101[m]>
And I should just set the Ivars like that, or is there some helper class already?
<headius[m]>
that seems fine
<headius[m]>
ok last one I marked to discuss
<headius[m]>
> Are any of the mixin exclusions needed to be ported?
<headius[m]>
I feel like I should remember what this was about
<byteit101[m]>
Enumerable, etc mixins. Do I need to worry about excluding generating each, etc? (for :all methods)
<byteit101[m]>
or, on the flip side, generating .next? (just though of that side now)
<headius[m]>
ahhh
<headius[m]>
so right now it sees all methods up hierarchy and will generate a Java endpoint for them
<headius[m]>
and you are wondering if it should be filtering things from mixins
<byteit101[m]>
correct
<headius[m]>
I guess it would be surprising if it did not generate them, no?
<headius[m]>
like user might have a mixin of common behavior they expect to see generated
<headius[m]>
mabye this relates to your question about searching only this class for methods
<byteit101[m]>
See JavaProxyClass.EXCLUDE_MODULES
<byteit101[m]>
used on old JavaProxyClass line 681
<headius[m]>
ok looking
<headius[m]>
I have to wrap up shortly
<headius[m]>
aha yes
<headius[m]>
well for this set of modules perhaps we should restore the exclusion
<headius[m]>
Enumerable is debateable but the other three would be very weird to see generated
<headius[m]>
mostly because users aren't typically opting into them... they are already there
<headius[m]>
Enumerable you opt into so that is why it is debateable to me
<byteit101[m]>
Ok, can do
<byteit101[m]>
Also, I don't see a response on AbstractIRMethod/Subclasses
<byteit101[m]>
Oh, right, ok, nvm
<headius[m]>
it seems sorta arbitrary that Enumerable was put in this exclude list
<headius[m]>
Enumerable but not Comparable?
<headius[m]>
etc
<byteit101[m]>
Cool, I'll work on that hopefully this weekend so a more full code review can happen next week
<byteit101[m]>
Are there eclipse style format files?
<headius[m]>
I did not add to that last one because you said enebo answered that we can refactor later
<byteit101[m]>
Yes, I saw that, hence the nvm
<headius[m]>
ok cool]
<headius[m]>
we used to have eclipse .project but probably long gone
<headius[m]>
if you want to add something back that would be fine, it just won't be maintained by those of us using idea
<headius[m]>
whatever makes it easier for you to manage
<Freaky>
hmm
<Freaky>
I think RJGit leaks
<Freaky>
it uses AutoCloseable classes but doesn't seem to make any effort to close()
_whitelogger has joined #jruby
drbobbeaty has joined #jruby
quadz has quit [Ping timeout: 265 seconds]
quadz has joined #jruby
<Freaky>
and after 12 hours it's grown by about 100MB instead of over a gigabyte, yup