<enebo>
kares: well that sounds like an icky but good find .... just keep me in the loop.
<kares>
enebo: up in a PR already ^^ ... actually just opened
<kares>
was about to ask on how you're planning with 9.1
<enebo>
kares: we talked about one more 9.1.x but of course maybe 2 if something is wrong with 9.1.18.0
<kares>
thought there isn't going to be another release but the 9.1 branch and some comments suggest otherwise
<enebo>
kares: it has always been grudging in the sense that if people move to 9.2 we do not need more point releases
<kares>
enebo: that sounds good ...
<enebo>
kares: but we know we took too long with 9.2.1+
<enebo>
kares: so it is only fair to put in any critical things for another 9.1.x
<enebo>
ultimately 2.6 is out on Xmas so we need to consider when we go for that
<enebo>
none of us want to support three branches
<kares>
yeah
<enebo>
kares: I am requesting headius look at that PR. I will also but fiber impl has been his backyard
<enebo>
kares: he is in your timezone more or less right now too
<headius>
yo
<headius>
zenspider: yo
<headius>
claudiuinberlin: the biggest limiting factor for us using graalvm AOT would be its limited support for method handles
<headius>
there's zero support for invokedynamic, last time I checked, except for the very limited use cases that exist within OpenJDK (lambda initialization, string concatenation)
<headius>
even if we don't use invokedynamic, we use method handles many places in JRuby proper: binding instance variables to the right object slots, caching constants, making Ruby methods callable objects from Java...
<headius>
once they support invokedynamic and method handles fully I don't see any major reason we wouldn't work, though java integration becomes the next tricky bit (lots of unspecified reflection; this affects TR as well)
<headius>
bga57: hey cool, I'll look for the PRs
slyphon has quit [Ping timeout: 246 seconds]
<headius>
bga57: I thought we fixed jruby-launcher to use cc
<headius>
oh you know what, I bet that was jnr-constants
<headius>
it also had a hardcoded gcc, someone added the use of CC env var, and then I discovered most linuxes don't set CC env var :-P
<enebo>
headius: I nuked CC/CCC/CXX from our make files
<enebo>
no system should not have CC/CXX not defined by make
slyphon has joined #jruby
<enebo>
If there is one we should add logic only for that case
<headius>
is that true? I find that surprising but I don't know unix make practices
<headius>
jnr-constants defaults to ENV['CC] || 'cc'
<enebo>
gnu make for sure does
<headius>
after we found that linuxes *do* define a cc alias
<enebo>
but linux and win10 mingw both were fine for me
<kares>
okay good
<headius>
yeah I'm just confused where the make tool gets it if the env doesn't define it
<enebo>
but it is not typically a unix thing but make itself somehow
<headius>
someone has to be setting CC if make can use CC, and if make it setting it it must have a way to determine it
<enebo>
gnu make will define something but in FreeBSD they have some wild versioned scheme and I have no doubt envs do come into play there
<enebo>
So I predict they env[CC] || 'cc' in gnu make itself
<enebo>
non-gnu-make may not default but as I don't have any env which is not gnu make I cannot try that
<enebo>
headius: if you pull does it work for macos?
slyphon has quit [Ping timeout: 268 seconds]
slyphon has joined #jruby
<lopex>
o/
<lopex>
headius: so, immediate 2.6 compat release after mri release ?
slyphon has quit [Read error: Connection reset by peer]
<bga57>
In FreeBSD gnu make sets CC to cc unless it's overridden. I think that's a standard make thing, and the FreeBSD port doesn't change it.
fredmorcos has quit [Remote host closed the connection]
<enebo>
bga57: gnu make on all systems will define it. so only non-gnu would be a concern
<enebo>
bga57: I pre-date gnu make and I swear CC was always defined in BSD make too
<enebo>
bga57: but I happily no longer write C if I can help it
<bga57>
FreeBSD's make is actually incompatible with gnu make, it builds jruby-launcher with gmake.
xardion has quit [Remote host closed the connection]
<bga57>
I think FreeBSD's make may be more compatible with the original AT&T make.
<enebo>
oh was make originally from sysv legacy?
<enebo>
I don't recall
<enebo>
but I am not too surprised that makefile is using gnu make stuff in it
<bga57>
I'm not sure, and I really haven't programmed in C since the 90s.
<enebo>
bga57: yeah I stopped in the 90s largely other than having to use it for stuff like JNI
<bga57>
or early 2000s
<enebo>
C is impossible to totally avoid even if solving basic compiler problems
slyphon_ has joined #jruby
<bga57>
I presume you'll update the jruby-launcher gem by the time you release 9.2.5.0?
xardion has joined #jruby
<headius>
enebo: yes appears to work fine with jruby-launcher HEAD on macos
<headius>
bga57: we can update that any time
<headius>
if this works enebo can push a new gem now
<headius>
lopex: hey, if we can get it all done by then :-)
<headius>
generally we let them sort out their last few months of feature tweaks before we jump in since it's a big leap to pull their tests and start running them
<headius>
less of a leap if we don't have to do it multiple types as they refine new features
<bga57>
I was thinking that if this fails anywhere, it's probably on AIX or Solaris, where you have to pay for a C compiler, and a lot of places might be using gcc.
<headius>
times not types
<lopex>
headius: yeah, so we dont waste time
<headius>
bga57: we did confirm gmake uses CC || 'cc'
<headius>
as long as we're in a makefile CC is probably ok
<headius>
the jnr-constants case was expecting it to be in the non-make env
<bga57>
I also needed the bug fix that enebo merged this morning.
<bga57>
then I can install jruby with rbenv without going through hoops.
<headius>
yup yup
<headius>
we'll get something out quickly for jruby-launcher
<bga57>
Thank you.
<enebo>
lopex: it is not too early to commit to ruby-2.6 though
<enebo>
headius: ^ made that branch yesterday
<headius>
woot
<lopex>
enebo: yeah, String#split will be my first one I guess
slyphon_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
bga57: pushed
<headius>
dinner!
slyphon has joined #jruby
shellac has quit [Ping timeout: 268 seconds]
Eiam has joined #jruby
subbu is now known as subbu|lunch
shellac has joined #jruby
subbu|lunch is now known as subbu
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
slyphon has joined #jruby
shellac has joined #jruby
slyphon has quit [Ping timeout: 268 seconds]
slyphon has joined #jruby
Puffball has quit [Remote host closed the connection]
Puffball has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]