<lopex[m]> numbers everywhere
<headius> should fix the indy dispatch issue
<headius> need to get java calls patched back in there but this is fine for now
<headius> needs a test
<headius> I should probably make these indy call sites dispatch through the handle they create so we know on the first go whether the binding worked right
<headius> ah I remember why I didn't... the call site only implements invoke logic for args[] and does the rest with handles... hard to dispatch from generic code into a specialized handle
<headius> not sure the best way to test this
<headius> bleh
<headius> The fix should be good but I know we need to make this more consistent for testing purposes
<headius> I will try to find a way to bind the optimized path immediately so we don't have to run tests twice
<headius> Yeah my fix is okay with the caveat that you can no longer query $! from the Java side
<headius> Because it is cleared upon returning out of the container to the Java client
<headius> So this other issue, like I said my fix seems to be fine and solves the issue and I can add a test for this specific case but the better fix is to make it always use the optimized path so we don't have to run tests twice. I have some code in progress to do that but it worries me a little bit to drop in right before the release
<headius> If it was just simple as invoking the handle it wouldn't be a problem but I have to adapt the handle and tweak it so I can call with varargs and I have most things working but each new command I run finds another small problem
<headius> enebo: I think the safest thing to do is to just test this specific case and open an issue for the future release to eliminate the unoptimized dispatch from the Indy site
<enebo[m]> headius: sounds good to me
<enebo[m]> So I will merge both PRs and perhaps you can open the follow up issue
<headius> Ok
<headius> It still needs a test but it will be basically the small reproduction from the issue
<enebo[m]> There is one PR open kares made for ObjectSpace
<enebo[m]> This is not marked for 9.3.5.0 but it is made so we should consider it
<headius> Yeah was there a bug this is fixing?
<enebo[m]> Nothing is referenced so I don't know
<headius> I looked it over and it didn't seem bad but I'm not sure what this is for really. His point about it being dangerous makes me kind of want to just skip it because nobody's ever reported that this doesn't work and we don't really need to give people a way to reconstitute finalizing objects
<enebo[m]> I suspect this comes from something kares was looking at. Perhaps he can say why he worked on it
<enebo[m]> We should get an issue made regardless perhaps
<headius> Yeah I'd like this too be fixing something rather than just nice to have because I'd rather not expose more id2ref cases of we don't have to
<enebo[m]> There are 2 open 9.2 issues but one is dead on freebsd thing out of our control (enough so I may detarget on Monday)
<enebo[m]> This is the other one
<enebo[m]> Will you be home on Monday?
<headius> Yes
<enebo[m]> ok so I don't think this issue I just posted needs to happen. If so then 9.2 and 9.3 should be good to go codewise
<headius> I can certainly take a look at 9.2 stuff tonight and tomorrow
<enebo[m]> the other issue is freebsd launching and it is hung up on jvmwrapper project
<enebo[m]> ffi I don't care unless this is fixing something significant
<enebo[m]> after all 9.2 should not really get more than it really needs at this point
<headius> Yeah for sure