<headius[m]>
if you can test that installer is fixed, maybe you could push an unofficial 9.2.13 installer that works
<enebo[m]>
ah a 2fer
<headius[m]>
push somewhere... I don't think we're pushing those artifacts yet
<enebo[m]>
you also fixed the other creation in addition to install4j
<headius[m]>
yes
<enebo[m]>
'yet' but the word 'ever' is apt
<headius[m]>
nobody used them anyway so I'm not worried about removing it in a minor
<enebo[m]>
There was some confusion which ended up giving birth to that
<enebo[m]>
headius: but you can just land that and if by some miracle the install4j bit is wrong we will deal with it. I strongly suspect it will just make a slightly larger isntaller
<headius[m]>
ok
<headius[m]>
folks on that issue seem to be working around it, but it might still be nice to have a working installer
<headius[m]>
just dunno how strict we want to be about the installer coming directly from the tag
<headius[m]>
like you could pull 9.2.13 source, patch just the installer, and push a new one from that
<enebo[m]>
well if we were to do that then I think .14 with just repackaging
<headius[m]>
there are a few small things that could go in .14 when we decide to do it, so if you're not too concerned about .13 I don't care
<enebo[m]>
people can work around it but if we have any need of .14 then we will for sure fix it
<enebo[m]>
or obviously if we continue to get unexpected amounts of complaints
<enebo[m]>
So I am making an internal execution API so I can match MRI in being able to execute a program from within Ruby without it going through eval
<enebo[m]>
I keep switching tests in MRI test suite when eval changes what a warning or syntaxerror should be but that a) makes it a full ruby process spawn b) involves changing the MRI test itself.
<headius[m]>
this PR is against 9.2 so we should be good going forward
<headius[m]>
nobody has complained about pack200 in the installer until now
<headius[m]>
I am guessing that just removed it in 14
<headius[m]>
enebo: so this is some RubyVM thing?
<headius[m]>
I remember seeing RubyVM APIs for running some ruby code directly as a new toplevel
<enebo[m]>
headius: yeah it is something similar but I think we just include it as JRuby thing via jruby/something require
<headius[m]>
seems fine to me
<headius[m]>
we can submit a patch to CRuby test suite that compartmentalizes this better
<enebo[m]>
we already sort of do tangential stuff for jrubyc specs
<enebo[m]>
well they did already
<headius[m]>
all the test references directly to RubyVM ought to be to helper methods that we could override
<headius[m]>
they do for some stuff
<enebo[m]>
it is just we do not have the internal API in their common method
<headius[m]>
ok
<enebo[m]>
so they fall back to eval if you do not have it
<headius[m]>
pretty sure I added the fallback
<enebo[m]>
which works much of the time but not all of it
<enebo[m]>
oh ok well thanks I guess :)
kith is now known as roadkith
<headius[m]>
thanks I guess for sure, I didn't figure on the errors changing
<enebo[m]>
There are not really tons of differences but it does point out how weird that is
<headius[m]>
enebo: I merged it but forgot I wanted to wait until you test it
<headius[m]>
I removed the pack200 attribute from the installer xml completely but just now noticed that for lzma it is there but set to "false"