<JasonRogers[m]>
> Without lurking, though, I don't think there's a way
<JasonRogers[m]>
I get emails via Riot Chris Seaton (Gitter) (fwiw)
<headius[m]>
👍
<headius[m]>
broken?
<headius[m]>
odd...that's not related to my PR
<headius[m]>
enebo: I am going to change gears today and see about backporting some of my native-image changes
<headius[m]>
hopefully can clean those up and combine with the AOT bytecode patch soon to at least POC a fully native Ruby script
<rwilliams[m]>
Would it be possible to do a 10 min call for some general JRuby questions?
<rwilliams[m]>
Sometime
<headius[m]>
I don't see why not
<enebo[m]>
headius: yeah I may grab you if I find something we need multiple sets of eyes on but I will play with bits
<headius[m]>
anything quick we can answer now?
<headius[m]>
enebo: ok... release has my 👍 at this point
<headius[m]>
rdubya: I get that chanserv thing too
<headius[m]>
I muted it and marked it low priority
<headius[m]>
🙉
<rwilliams[m]>
Mmm. Basically at what point or for what particular reasons should I swap to jruby or truffle? Most of my projects are really small user bases so I tend to stick to cruby mostly. Right now I keenly follow jruby and truffle but I'm not using it on any projects
<headius[m]>
opinions: I need a flag/property for disabling stuff that GraalVM native compile doesn't support... jruby.native.compile or jruby.graalvm.native.compile?
<rwilliams[m]>
I'm not a Java guy so interop doesn't interest me too much
<headius[m]>
I feel like if I go with native.compile I'll eventually have to change it for different forms of native compile
<rwilliams[m]>
But the power of the jvm and Graal really do
<JasonRogers[m]>
`jruby.graalvm.native.compile` is my vote ... not that it counts much :)
<enebo[m]>
headius: no strong opinion personally
<headius[m]>
for JRuby the two big reasons are java interop and needing to scale up
<rwilliams[m]>
Also I'm a big noob but for what I lack in CS knowledge I'll make up for on doing things very wrong until I learn
<enebo[m]>
I think a third option is demarcating each thing you disable as its own disable but that will lead to lots of options
<rwilliams[m]>
@rdubya:matrix.org: it's because we have the same initials maybe?
<headius[m]>
enebo: yeah this may evolve into that but I'll go with one property for now
<enebo[m]>
Assuming we want to be able to potentially disable some aspects for their own sake
<enebo[m]>
headius: yeah just throwing it out
<headius[m]>
I guess it doesn't matter for POC
<enebo[m]>
I really don't care...specific tech flag means we won't try and shoehorn all of them into a single option
<JasonRogers[m]>
* `jruby.graalvm.native.compile` is my vote ... not that it counts much :) (I'll stop troll'ing now)
<headius[m]>
rwilliams: I'd say the only reason to look at either jruby or truffle will be if they scale your particular use case better or provide features you don't have on CRuby like JVM tools or Java interop
<headius[m]>
we have always considered ourselves complementary to CRuby... i.e. we're here when you need us
<headius[m]>
there are small use cases like data processing where JRuby will usually be much faster than other options, and then any case where concurrency is important will also be a big win
<rwilliams[m]>
Cool. I love messing with it and I want to dive into theine more. But I don't use it as a daily driver atm
<headius[m]>
Jason Rogers: thanks for the input 😀
<headius[m]>
dev is moving very fast lately so I'm hoping we can get folks excited for upcoming 9.3 release
<rdubya[m]>
I feel like I missed something...
<rwilliams[m]>
Haha
<kares[m]>
how far are we from a release?
<kares[m]>
still need to juggle through one last issue in jossl ... hopefully I am close
<enebo[m]>
kares: today or tomorrow
<enebo[m]>
kares: but tell me more about this issue :)
<kares[m]>
oooh definitely won't make it today :)
<kares[m]>
but I mean its not super crucial (but would be nice) to ship latest jossl
<enebo[m]>
kares: yeah what will we get if we include it?
<headius[m]>
kares: yeah as long as it can be updated it doesn't have to go in lock step
<headius[m]>
nice to have though
<kares[m]>
issue relates to cert extension parsing ...
shellac has quit [Read error: Connection reset by peer]
<headius[m]>
man this is lke an hour's work to make it spin up a new JRuby
<enebo[m]>
yeah it is still another if within that but seems fairly doable
<enebo[m]>
we get MVM-like isolation so we really just pay the cost of having the first runtime and honesty we can probably kill that off with a little more work
<headius[m]>
yeah for sure
ur5us has joined #jruby
headius[m] has quit [Quit: killed]
lopex[m] has quit [Quit: killed]
louis[m] has quit [Quit: killed]
ksawery[m] has quit [Quit: killed]
bastilian has quit [Quit: killed]
annette[m] has quit [Quit: killed]
kasaltie[m] has quit [Quit: killed]
harald[m] has quit [Quit: killed]
cshupp[m] has quit [Quit: killed]
claudiuinberlin[ has quit [Quit: killed]
olleolleolle[m] has quit [Quit: killed]
nieve[m] has quit [Quit: killed]
xardion[m] has quit [Quit: killed]
rwilliams[m] has quit [Quit: killed]
kares[m] has quit [Quit: killed]
ChrisSeatonGitte has quit [Quit: killed]
UweKuboschGitter has quit [Quit: killed]
jellymann[m] has quit [Quit: killed]
aemadrid[m] has quit [Quit: killed]
amiracam[m] has quit [Quit: killed]
TimGitter[m]1 has quit [Quit: killed]
fzakaria[m] has quit [Quit: killed]
chrisseaton[m] has quit [Quit: killed]
KarolBucekGitter has quit [Quit: killed]
sandio[m] has quit [Quit: killed]
rtyler1 has quit [Quit: killed]
JasonRogers[m] has quit [Read error: Connection reset by peer]
rdubya[m] has quit [Read error: Connection reset by peer]