<headius[m]>
enebo: is that consistently failing? I thought it was intermittent
<headius[m]>
which is maybe worse
<headius[m]>
enebo: I caught up with your chat transcript on the byteit101 PR
<headius[m]>
did you discuss the more aggressive option of generating the initialize directly into the Java constructor, using the JIT?
<headius[m]>
based on your description of IR work needed I am not sure which would be the easier path at this point
<headius[m]>
basically the other idea was generating the Ruby initialize directly into the Java subclass constructor so that it can call the Java super at the right place... it would require several adjustments to the bytecode compiler, but I think it is doable. Zero work done down that path so far, though, so the AST/IR manipulation is already much further along
<headius[m]>
ok so mostly you just said we are not pursuing it
<byteit101[m]>
yea. I was under the impression from my chat with you that we weren't, so relayed as much to him
<headius[m]>
I think there may have been some confusion in this discussion over the jit compilation of your modified AST/IR versus modifying the jit to create a hybrid constructor on the subclass
<byteit101[m]>
yes, that's why I tried to clarify early
<headius[m]>
enebo seems to be out of the office today but I will pull him aside when I get a chance to make sure we are on the same page about the promise and peril of that other option, but I am still with you both on doing this as a code tranformation
<byteit101[m]>
The only strong opinion on that I have is that it reduces dynamism. Otherwise, it might be a good idea
<headius[m]>
yeah no dynamism for initialize but is the transform solution better there?
<headius[m]>
when does the transform happen?
<byteit101[m]>
yes, you can retransform on each call if you want
<headius[m]>
aha ok, so if it gets redefined we just transform the new one
<byteit101[m]>
right now it's once and then cached as I don't know how to detect modifications. previously it was each call
<headius[m]>
god forbid people are doing that but ok
<headius[m]>
all method objects have a serial number
<headius[m]>
Dyan
<headius[m]>
DynamicMethod objects
<byteit101[m]>
sure, but I wasn't sure a good place to store it
<headius[m]>
ah ok
<headius[m]>
(hmm why isn't serial number final 🤔
<byteit101[m]>
at least it is better than doing this: `def new(*args); obj = alloc; object.send object.methods.sample, *args; object; end`
<headius[m]>
ick... it's so we can mark the jit compiled version with the same serial as the IR version
<headius[m]>
I should fix that
<byteit101[m]>
I've slowly been whittling down failing tests. 8 less the ant tests left
<byteit101[m]>
*8 plus the
<headius[m]>
wow that's great
<headius[m]>
I was not clear from discussion, did enebo think this is fine to ship with or did he want to do the IR version of it before release?
<headius[m]>
he mentions it is fine for PR/POC but I was not clear if that meant we still needed the IR version
<byteit101[m]>
Potholes galore right now. the AST transform is fine for simple things, but getting slightly complex (ie a rescue around a super) is broken, and I'm not entirely sure. I would personally wait for an IR version, unless you and enebo are with with the potholes (I'll doc them once I get all tests passing)
<headius[m]>
hmm ok
<byteit101[m]>
*are fine with the
<headius[m]>
and to be clear super at end or beginning of method requires no transforming?
<headius[m]>
just wondering if we can encourage people to use a simpler pattern
<byteit101[m]>
right now they are transformed, but that transformation is bullet proof*. Could simply the "at end" case
<headius[m]>
odd that we don't have an AST duplicator already
<byteit101[m]>
I was surprised too!
<headius[m]>
you could run this through a test of a large file and just compare the tree again
<headius[m]>
I guess that would just be another visitor where you give it expected AST and then have it walk actual AST and confirm they have at least the same leaf values and child node types or something
<headius[m]>
at a glance yeah it is tedious but probably fine
<byteit101[m]>
I wrote a generator for 3/4 of it
<headius[m]>
nice
<byteit101[m]>
the 3/4 that had only one ctor
<headius[m]>
I usually write these visitors in Ruby so I can use method_missing tricks to generify some of the more tedious ones
<headius[m]>
for testing that would be reasonable to do
<headius[m]>
I will also give this a read through
<headius[m]>
actually I will pull the branch... only bugs I could imagine is if you chose a constructor that did not propagate all params
<headius[m]>
the AST is pretty dumb
<byteit101[m]>
lists are like that
<byteit101[m]>
and colon2node
<headius[m]>
Ok
<byteit101[m]>
should I pull the duplicator out as a generic thing?