<byteit101[m]>
Yay, free time! Ok, so you disagree with my reasoning and prefer just "instance_variable"? (sorry, having a hard time following the conversation from earlier)
<byteit101[m]>
> headius: there may be a better example as part of jrubyfx
<byteit101[m]>
Nope, jrubyfx (will) use this as part of the fxmlloader, which is write-only, and happens once. so it currently says ` java_field "@javafx.fxml.FXML java.lang.Object #{value}", bind_variable: true` (old syntax)
<byteit101[m]>
and if users want to reassign their ivars, it will save the wrapped IRO instead of unwrapipng and re-wrapping
<byteit101[m]>
so no conversion necessary
<byteit101[m]>
If javafx needed to read those variables again, then I would need to convert there
<byteit101[m]>
but this way keeps the most ruby semantics
<byteit101[m]>
I should be free to discuss this more all afternoon tomorrow
dangerousdave has joined #jruby
dangerousdave has quit [Client Quit]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
<enebo[m]>
byteit101: I added a comment to the issue which I hope will make this discussion easier
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
<headius>
I do prefer just instance_variable for naming the binding bar. No strong opinion on convert: because it's doing a couple things
<headius>
it actually kills the whole spec run so the break is losing its target
<enebo[m]>
Probably not cloning hasBreakInstructions
<enebo[m]>
I am guessing none of this state is preserved in clone constructors and it was an oversight
<headius>
hmmm ok
<enebo[m]>
The IRScope constructor saying it is for cloning does not seem to do anything
<headius>
I can probably get this to a small example that I can manually diff the IR
<headius>
oh wait
<headius>
there's no define_method here so I am not cloning
<enebo[m]>
hah yeah
<enebo[m]>
So you may want to make these are even running before your changes
<headius>
I made some changes to how supers are built so more of them would resolve
<headius>
yeah I will look into the other changes I have locally
<enebo[m]>
Maybe we have some test walk off the edge of some source and now you caused it to start working or something like that
<headius>
this might be due to the way I changed builder to detect if a super happens in a method within a class or module
<enebo[m]>
anyways...we are not cloning all those booleans
<enebo[m]>
I think that should happen since they are largely only setup during IRBuild at this point and are intended to always be true about the scope
<enebo[m]>
as it stands the clone will contain them and everything will be false
<headius>
I do force a full build before I clone
<enebo[m]>
This does make me wonder though. If you are removing super then usesSuper may become false (this flag also examines the contained lexical closures so it is not trivial)
<headius>
not sure if that bypasses some of the logic that needs the flags but it is at least full structure and protocol
<enebo[m]>
full build will probably not affect there booleans at all
<enebo[m]>
or not many of them
<headius>
ok I see
<headius>
I converted this super into a ModuleSuper from UnresolvedSuper, but UnresolvedSuper has additional logic for when it receives a literal block
<headius>
I need to restore that
<enebo[m]>
If you build full before you clone we may not care about the flags at that point and it might just work but if that new code JITs it may try to run more passes and then it will not have access to those flags
<headius>
yeah unsure
<enebo[m]>
prepareFull does less than prepareForCompilation so I think there is a good chance things will go south
<enebo[m]>
but in any case if we clone something we should make sure we update those flags
<headius>
ok duh this was an easy fix
<headius>
if the super has a literal block it needs to call through the "iter" logic that marks the block as escaped after the super returns
<enebo[m]>
The only second thing on top of that is that we maybe can untoggle something like usesZSuper if we make sure nothing is doing zsuper any more
<enebo[m]>
but I would guess we clone all flag fields and the modify that state off right after we construct
<headius>
I got confused about the literal block and thought it referred to the container of the super, not the block passed to the super
<headius>
I have one failure due to not using "class super" logic for a define_method in a singleton, and another that appears to be using the wrong name and not getting rewritten properly
<headius>
oh I see the problem there... I'm not recursing through all nested closures
<headius>
so those are straightforward fixes
<headius>
this should mean that all supers are now using a static name, except for ones that would not be valid anyway (super in a block at toplevel or in a class body, etc)
<headius>
I don't feel great about how I'm doing the rewriting
<headius>
it is obviously heavy but also feels like I'm poking around the guts of IR/BB too much
<enebo[m]>
When you get things working we can examine what we can do to make it simpler
subbu has joined #jruby
<byteit101[m]>
enebo: so the last example jcomponent to jbutton isn't useful unless it hits the last point of my condition (ruby2java doing something extra) which I don't think is the case for that
<enebo[m]>
byteit101: so I guess I am trying to understand if this can just be true/false or we need an option to specify what type. If so then we figure out the issues (if any) with that
<byteit101[m]>
see the issues with j.l.Object + the need for to_java to take a type parameter for why it can't just be true/false
<byteit101[m]>
I want to store any json type=> java has no union/product types
<byteit101[m]>
ergo Object as the storage
<enebo[m]>
So you have a field where from Ruby you know it will always be a type but from Java side you don't know?
<byteit101[m]>
correct
<enebo[m]>
Will the java side ever write to that field?
<byteit101[m]>
A summary of when convert: is useful:
<byteit101[m]>
When Java is reading the field after Ruby writes, and
<enebo[m]>
If I write a specific type to Object and the thing which uses it from java is Object it still work
<byteit101[m]>
Ok here's the alternative: we don't have a convert argument and store the IRO directly in object
<byteit101[m]>
then java can't read Object, only subclasses appropriately converted
<byteit101[m]>
yes
<byteit101[m]>
If we don't ever store IRO's, then we don't need convert, but then you can't put ruby classes in the fields
<enebo[m]>
IRO means IRubyObejct?
<byteit101[m]>
yes
<enebo[m]>
I don't mind the convert. I see the value in it
<enebo[m]>
I am just confused about the field declaration needing to be different from the convert type
<enebo[m]>
Any ruby -> java will unconditionally make it a specific type. Any writes from Java can write anything to that field so the convert on the way out will only work if it is the specific type
<enebo[m]>
unless convert is only for writing the field
<enebo[m]>
but any specific type is still all the general types so having a more speciifc field would still work on any API wanting the more general thing
<byteit101[m]>
convert is only for ruby writing the field, not reading
<enebo[m]>
oh
<enebo[m]>
headius: did you know that convert was only for writing to the field?
<enebo[m]>
byteit101: it makes a bit more sense to me for writing since some Ruby types potentially can be made into different Java types
<enebo[m]>
but that would not be an argument for more specific or less specific values but that they may be totally different
<byteit101[m]>
(called toJava)
<byteit101[m]>
tyhe getter only has "basetype" witch is the type of the field, not the convert argument "toJava"
<byteit101[m]>
*the getter (line 166)
<enebo[m]>
I was mostly hung up on not getting how this fit in because I thought it was bi-directional
<byteit101[m]>
nope
<enebo[m]>
Ok. So then I think my next question is whether there would ever be a need to specify how to convert the stored Java value back to a Ruby value
<byteit101[m]>
see the getter code, it calls javaUtil.convertJavaToUsableRubyObject(javaobj) or javaUtil.convertJavaToUsableRubyObject(rubyobj.unwrap())
<enebo[m]>
yeah I am just trying to understand semantics. Reading code will not make this discussion go quicker (at least I don't think so :) )
<byteit101[m]>
fair
<enebo[m]>
I mostly am just trying to make sure we do not realize we should have changed the design but then we sort of get stuck with the decision we make. Iknow you are also concerned about that from the issue comments
<byteit101[m]>
I think there is a nicitiey to have the same object back that you set, but I wasn't sure how to implement that nicely, so now @foo.equals?(@foo) being false for some types (ex: j.l.String)
<byteit101[m]>
Yes, that's good
<enebo[m]>
yeah
<enebo[m]>
So we have 4 theoretical cases
<byteit101[m]>
why I said "this isn't bikeshedding" when I implemented this to headius's comments about a nicer name
<enebo[m]>
no conversion in or out (convert: false)
<enebo[m]>
convert in and out (bidirectional)
<enebo[m]>
convert in only
<enebo[m]>
convert out only
<enebo[m]>
These may not be useful
<byteit101[m]>
I'm... not sure that's the best framing
<enebo[m]>
of these we are really only specifying no conversion and conversion in
<byteit101[m]>
My framing has been: object instance is {ruby, raw java, wrapped java} {matching,not matching} field type accepting {compatible, incompatible, conversion-necessary} types
<byteit101[m]>
ex: object is ruby not matching field type accepting compatible (IRubyObject) types. "convert; false"
<byteit101[m]>
ex: object is wrapped java not matching field type accepting compatible (Numeric) types. "convert; int, etc"
<enebo[m]>
and you only mean for writing although you could look at this for reading perhaps
<byteit101[m]>
Ruby field writing
<byteit101[m]>
correct
<byteit101[m]>
that's roughtly how I've been framing this as I implemented it
<enebo[m]>
So you have a particular real use case and you pretty much only need to write to the Java field and then a Java API will consume that field
<enebo[m]>
But do you also ever read it again?
<enebo[m]>
Is it just a wrapped java at that point
<byteit101[m]>
wrapped java = IRO holding a java object
<enebo[m]>
yeah I think so
<enebo[m]>
what do you get in the current impl if you convert and then read from the ivar?
<byteit101[m]>
a new IRO wrapping things again (probably)
<enebo[m]>
ok yeah that's what I would have thought. You have a java object and you call javaToRuby or whatever
<enebo[m]>
So if I make a field with j.l.String and convert to the Java String we sort of luck out in that because Java String is special we will actually get a Ruby String back
<enebo[m]>
but if I wrote Date and it converts to one of the Java Date/DateTime or whatever when it comes out it will be wrapped Java instance
<enebo[m]>
As you have said this is an advanced feature that will not probably be commonly used but I am wondering if we want ability to convert both directions (or not so much we implement both but we name it so we can have both eventually)
<enebo[m]>
I don't like to yak shave on something we will never do but it seems like something someone might want (convert on reading the ivar)
<byteit101[m]>
that was one reason I proposed to_java initially, then store_as
<enebo[m]>
yeah
<enebo[m]>
yeah I think something like 'write_as'
<enebo[m]>
read_as
<enebo[m]>
read/write load/store
<enebo[m]>
field 'java.lang.Obejct address', instance_variable: true, store_as: java.lang.String
<enebo[m]>
maybe we implement load_as or maybe we don't
<enebo[m]>
I did not review the code but what happens when the two java signatures do not match
<byteit101[m]>
I'll update the messages when we finialize the config names
<enebo[m]>
So it will raise when the field is being processed with that error. Ok. It is likely also just a type Error when you try and write to the ivar?
<enebo[m]>
So those two types agree but then you pass something which does not agree
<byteit101[m]>
TypeError (could not coerce Integer to class java.lang.String)
<byteit101[m]>
from the to_java methods
<byteit101[m]>
(or whatever your types are)
<enebo[m]>
yeah so this is just a normal rubyToJava sort of error so consistent with what we would expect
<byteit101[m]>
1: from org/jruby/java/addons/KernelJavaAddons.java:34:in `to_java'
<byteit101[m]>
yes
<enebo[m]>
well my preference is to use store_as or write_as to imply direction to be future proof
<enebo[m]>
we can decide if we want the dual (e.g. load_as) at a later date
<enebo[m]>
My vague thought is wondering how much of what we do as Java native extensions could leverage this
<enebo[m]>
more than you are doing I should say
<byteit101[m]>
ok, I'll change it to store_as this evening
<enebo[m]>
in most cases native extensions want to avoid any conversion if possible but it may just make it ship with no java in it
<enebo[m]>
which is useful
<enebo[m]>
cool. and headius will chime in if he has an issue but I think if I was a consumer of this API I may get confused without some notion of direction
subbu has quit [Quit: Leaving]
<enebo[m]>
Also if you consider store_as could take the same Ruby object but make different potentially unrelated Java objects then I think you could also see load_as also having that potential
<byteit101[m]>
enebo: what's your verb/no-verb opinion?
<byteit101[m]>
(main config)
<enebo[m]>
you mean for instance_variable?
<enebo[m]>
I think these are all adjectives now of the field and declarative so I see no verbs
<enebo[m]>
store_as maybe is a bit verbish but I see a type and not an action
<byteit101[m]>
cool, will update PR this evening
<enebo[m]>
byteit101: this is pretty cool and we will even get a new jrubyfx release out pretty soon
<headius>
I'll be back in office shortly
<headius>
Will review but I think we're on the same page
<byteit101[m]>
yes, though... should this go in 9.3 or 9.4? 9.3 = sooner jrubyfx release
<byteit101[m]>
(I presume)
<enebo[m]>
I guess we will discuss this but we are pretty early and this is essentiall new syntax
<byteit101[m]>
This is so minimally disruptive I could see either being valid
<enebo[m]>
For me risk is not very high for 9.3 and I doubt anyone has written this exact code (which would be something totally unrelated to this) so I think we will not trample over another method
<enebo[m]>
I think 9.3 is still early and this is additive so that is my stance but we will talk through this before merging
<headius>
Agree
<enebo[m]>
ok and it is targetted for jruby-9.3 so that's easy too
<enebo[m]>
oh I guess it is master
<byteit101[m]>
yea, I didn't think about that before starting on master
<enebo[m]>
byteit101: retarget for jruby-9.3
<enebo[m]>
you can do it at top of PR
<byteit101[m]>
will re-merge this evening
<enebo[m]>
I don't expect it will be hard. I don't recall having to touch JI at all yet
<enebo[m]>
We did change some IRRuntimeHelpers
<enebo[m]>
but I doubt any you would hit
<byteit101[m]>
plus this is a very small PR compared to the previous PR
<headius>
retarget might try to pull all of master in so it may have to be a rebase
<headius>
in office now, catching up
<headius>
> convert is only for ruby writing the field, not reading
<headius>
that makes sense
<headius>
I assumed at least the writing side, for when we want to coerce as a specific type but the field is a more generic one... numerics was the main example for me too, but maybe something like a Serializable field and we have a Time object in hand
<headius>
> I'll change it to store_as this evening
<headius>
hey in keeping with existing names, what about `to_java:`?
<headius>
since that is what you would call to convert it directly
<headius>
And I am on board with adding this to 9.3 since it doesn't alter much existing behavior
<headius>
byteit101 enebo: that's it from me then
<headius>
so the default to_java is just the field type, and you can turn it off with to_java: false, or specify a type
<headius>
I like that synchronicity
<byteit101[m]>
headius commented 9 days ago:
<byteit101[m]>
> One problem with "to_java" to me is that it's really bi-directional, so it's both "to_java" and "to_ruby" depending on whether you set or get.
<byteit101[m]>
^ changed your mind?
<headius>
yeah now that we are clear it is just writing
<headius>
if we decide we need to change how the value comes from field into Ruby we can have a to_ruby later or something
<byteit101[m]>
enebo good with to_java too versus store_as ?
<byteit101[m]>
headius: oh did you ever get around to ensuring this stuff was inlined properly? IIRC you said you wanted to check that?
<headius>
I have not, got into other quagmires... it doesn't have to happen for this PR though and it may already work as is
<headius>
field-based instance vars do inline fine so I suspect it will just work
<byteit101[m]>
cool. I just remembered you said that and was curious
<byteit101[m]>
and I suspect so too
<headius>
I am eager to get back to perf and then we will look into all this stuff
<headius>
gotta get 9.4 done first
<headius>
enebo: one issue with the way I am cloning and rewriting is that I'm rewriting UnresolvedSuper to one of the other types that does not need frame name, but there's no re-optimization based on that
<headius>
if we can get this to also use a more static place for the frame klass then we will want to reopt to remove the protocol
<headius>
so then that makes me wonder if I should instead be cloning the simple IR
<enebo[m]>
headius: ah
<enebo[m]>
You know if you do this transformation pre-full you could get around this
<headius>
I have expanded the rewriting a bit so it now will turn UnresolvedSuper into Instance, Class, or ModuleSuper depending on where it is doing define_method
<headius>
I had to add a definingModule variable to Unresolved so we can rewrite it later
<enebo[m]>
byteit101: headius I am fine with to_java
<headius>
it is not used for Unresolved, but then again Unresolved will very soon just become InvalidSuperInstr
<headius>
because that will be the only cases left
<enebo[m]>
you mean it throws?
<headius>
yeah
<enebo[m]>
that can just be instr(s) which throw. We do not need an instr for that
<headius>
it already does in a roundabout way when there's no frame name to super
<headius>
I need to know it is for a super though to rewrite it
<headius>
it becomes valid if the super is now in a define_method method
<headius>
I'm open to other ideas
<enebo[m]>
So you make an InvalidSuperInstr but if it is a define_method yuo make it into a real call?
<headius>
I can go back to simple IR for this, sure... the lifecycle of this stuff is still very confusing
<headius>
yes
<enebo[m]>
ok
<headius>
it becomes a specific type of super with a static name (and hopefully direct class access in the future)
<headius>
it could remain UnresolvedSuper but at this point the only cases that will go through it are invalid supers
<headius>
(probably)
<enebo[m]>
yeah I think in this case we are always at startup so it may be simpler since you just will have simple lists of instrs to swap
<headius>
yeah ok
<headius>
does clone work on simple though?
<enebo[m]>
Then when you are done it will at some point become full or JIT and then ACP will be right
<headius>
yes
<enebo[m]>
I will have to check but it should
<enebo[m]>
hmm this is weird
<enebo[m]>
ok I think this will not work as it stands but it should be made to work
<enebo[m]>
I guess this was designed around happening from a CFG and from inlining which also has CFG/full at that point so I must have realized we would never go back to interpreterContext and nulled it out
<enebo[m]>
but I think this could be IRScope#IRSCope @line 142 (for cloning) to do
<enebo[m]>
if (this.fulleInterpreterContext != null) this.interpreterContext = null;
<headius>
yeah that's why I went straight to full
<enebo[m]>
At the point you are doing this you know you have just interpreterContext
<headius>
if I could hook into building I could change the way supers get compiled out of def, but I was scare by all the def = null clearing
<headius>
this has to always work
<enebo[m]>
how would this work from a main script?
<enebo[m]>
we immediately full compile
<enebo[m]>
err even more I guess
<headius>
JIT still serializes simple IR
<headius>
into the generated bytecode class
<headius>
so it will have to stand it up again
<enebo[m]>
I mean main script we JIT immediately
<enebo[m]>
not AOT
<headius>
it's not much of a distinction for the target script
<headius>
JIT always serializes IR into the class
<headius>
so we can return to it if necessary
<headius>
we just don't
<enebo[m]>
I am just saying if it JITs we will make fullinterpretercontext which means in the case of main script we will not assume interpretercontext can still exist
<enebo[m]>
and main script is one case where it happens right away
<headius>
ah, sure
<headius>
well I could rewrite both ways but obviously it's getting messy
<enebo[m]>
So doing it with startup is not great in that case
<headius>
if I do both then we don't have to worry about parent method being full and new closure being simple
<headius>
so that is a bit of a question
<enebo[m]>
If this is a more of a pass it could just determine if it still needs framing and removes that if it is not needed but as you noticed manipulating instrs is some work
<headius>
e.g. a script like cls = Class.new { def self.do_it; define_method(:foo) { super }; end }
<headius>
compiled at command line do_it will go full and then JVM
<enebo[m]>
The best way to do this though is not to change the instrs but to mark them as dead
<headius>
if we then revert the define_method block to simple it will act weird
<enebo[m]>
that should noop them
<headius>
hmmm ok
<enebo[m]>
I am looking at ACP atm
<enebo[m]>
so fic.needsFrame could go away if super was the only reason for it
<enebo[m]>
This is quite weird
<enebo[m]>
I do not see usesSuper() only usesZSuper()
<headius>
hmm
<enebo[m]>
That is because we don't need the name?
<headius>
before this work only UnresolvedSuper needs frame, which is the supertype for ZSuper
<headius>
now there is ModuleSuper which needs frame only for the klass
<enebo[m]>
So we should figure out what flag makes a super in a define_method forces a frame
<enebo[m]>
there are things like canCaptureBinding() or binding has escaped
<headius>
it is just the two frame fields, name and class
<headius>
Unresolved reports that it needs them; ModuleSuper only requests class
<enebo[m]>
/ For now, we always require frame for closures
<enebo[m]>
I think ACP unconditionally frames all IRClosures
<enebo[m]>
So needsFrame is not the cause of the frame but a second check on closure
<enebo[m]>
At the time we run ACP we don't know how the closure is used
<enebo[m]>
ACP could be smarter about this perhaps but even if it was then we would need to see if it usesSuper (which it appears we do not)
<enebo[m]>
then we would still be in the same position that we need to see if we still need a frame or not
<headius>
we do
<headius>
need frame always for closures
<headius>
yeah it is odd it does not check that because a super in a module method does need frame
<enebo[m]>
except in this case?
<headius>
a super in a block might not but the block will always have the frame anyway
<enebo[m]>
so define_method { super() } will always be framed
<enebo[m]>
Did I fall off track here?
<headius>
well it might not with this rewrite
<enebo[m]>
ok
<headius>
if it is define_method in a normal class that super will turn into an InstanceSuper that does not request frame
<headius>
I have to rewrite all super instructions to the correct type during this so they will not have to do unresolved stuff if not necessary
<enebo[m]>
so there is a lot of logic here deciding that for non-closures and all of that needs to be reexamined and the needsFrame instrs added in ACP should be marked dead if they are not needed
<headius>
or they will do it if necessary (like if we wrongly detected it as an InstanceSuper but the define_method call is actually in a module)
<enebo[m]>
ala instr.markDead()
<headius>
yeah
<enebo[m]>
but since you are looking at this I can say I think there are things to look at
<enebo[m]>
usesSuper does not mean we need a frame but it does in some cases right?
<enebo[m]>
so needsFrame() in FIC probably needs some extra logic to encapsulate that
<enebo[m]>
heh...I don't see how the visitor excludes dead instrs
<enebo[m]>
now I am thinking markDead is not a good way to go
<enebo[m]>
I am a bit baffled why visitor does not skip dead instrs since they are not alive but I don't know if we should push forward or just BB.instrs.remove(instr)
<headius>
well usesSuper is a bit too overloaded
<headius>
it should be just looking for specific frame things
<enebo[m]>
That is much more direct than marking. I just figured marking is simpler because you are iterating over the list you would remove from
<headius>
super needs access to frame sometimes, zsuper needs access to raw args
<headius>
but other supers may not need anything special and are just a call on superclass
<enebo[m]>
well I use super specially to know if a scope has super for constructor splitting
<enebo[m]>
if something is put to needs_name or something like that we really want to know why in case we remove what specified that
<enebo[m]>
but usesSuper would appear to be too broad here
<enebo[m]>
also we do have those flags
<headius>
right
<headius>
I think it is just old
fidothe has quit [Read error: Connection reset by peer]
<headius>
when we did not have the plumbing in place to piece apart the actual needs
<enebo[m]>
flags still exist for values which are determined specific to the IC they live in where in IRScope those are meant to be truisms about the scope
<enebo[m]>
So frame info in FIC is based on those truisms and other info but the scope booleans are meant to always be true (until they are unconditionally not)
<headius>
I have to run to pool but I will push what I have... all super instrs are being rewritten to appropriate type now at define_method time
fidothe has joined #jruby
<headius>
not everything passes but this is the right direction
<enebo[m]>
In this case if you remove super then we can toggle usesSuper to false
<headius>
the rewriting can change without much effort here
<enebo[m]>
ok I will look in the morning
<enebo[m]>
I am really interested in the rewriting aspect here since this will also fit into speculative opt of removign frame
<headius>
so we will be at a point where there's no unresolved supers in the system soon, and the only frame requirement is when it's in a module
<headius>
which we should be able to get from Java stack or from an as-yet-undefined place in the binding
<enebo[m]>
I was thinking about this and the full deopt is not really needed to do frame elision with deopt
<enebo[m]>
there are so few instrs we can special case what we need to dump and even make space for any temps we need for framing
<headius>
all super instrs extends a new abstract SuperInstr for simplicity
<headius>
but we will want to make this more mutable... change thyself into this kind of super
<enebo[m]>
It would be nice to be generic but I think we can special case this just for removing framing for things like $_
<headius>
it might be one instr once this all boils out
<enebo[m]>
that would be great
<enebo[m]>
anyways I will look at your stuff tomorrow and see what pain points exist
<headius>
yeah it is not passing everything but I'm getting there
<enebo[m]>
hopefully we can make modifying this stuff simpler
<headius>
mostly issues with define_method in weird cases like singleton class
<headius>
oh and still not rewriting child closures
<headius>
I was not sure if that gets cloned or I have to do additional cloning
<headius>
the cloning and simple/full/jit lifecycle is the main confusion for me right now
<enebo[m]>
I would have to look but I think it should if it doesn't since those closures may have the actual super
<headius>
yeah I just need the whole tree cloned and I can rewrite the nested supers