subbu has quit [Quit: Leaving]
andreimaxim[m] has quit [Quit: Client limit exceeded: 20000]
<puritylake[m]> I’ve never understood how jits work
<headius> It's pretty basic at its core. Compile the code to something faster but do it after you run it slow for a while to learn what needs to be optimized
<headius> basshelal: yo have you seen this: https://github.com/jnr/jnr-constants/pull/106
<headius> good morning
<headius> seems like this person might be interested in helping us set up cross-platform (linux, at least) JNR builds and testing
<headius> enebo: you around?
<headius> your E seems to be keeping up
<enebo[m]> I am here but I also happen to have this as my current browser thread
<enebo[m]> so it would have looked that way regardless
<headius> so mrnoname did this one for us but he also has managed to port the entire thing to sh
<headius> he's finishing up a second pass to reduce the amount of eval needed but it already passes CI
<headius> I believe he even tested it with dash to make sure it doesn't accidentally use any bash features
<enebo[m]> how do we ignore whitespace on gh again
<headius> ?w=1
<headius> I think
<headius> he was very annoyed by varying indentation throughout
<enebo[m]> hmm yeah I did not use w=1
<headius> which is fair
<enebo[m]> There is a UI for I found
<headius> yeah you can get to it from diff settings button I thkn
<headius> I thicken
<headius> I don't see any reason not to merge the cleanup since it's mostly standardizing formatting and cleaning up some bashy things
<enebo[m]> most of this is not really even significant changes but styling or removing unneeded bracket + ""
<headius> yeah
<enebo[m]> but I am fine with this either way
<enebo[m]> and I can see there are substantive changes
<headius> I think he needed to do this mostly to clean up things before attempting the posix sh version
<enebo[m]> yeah getting pure sh support would be nice
<headius> he has that PR ready to go as well but it continues from this point
<headius> so if you are cool merging this then I will handle that and have him submit the second PR
<headius> should we keep this on master or move to 9.3? I'm leaning toward master
<enebo[m]> I think so. master is much safer and gives us more time to tease out anything
<headius> yeah at least give it some bake time
<headius> we have some bleeding edge users that will give it a go as well
<enebo[m]> if we get to releasing 9.4 and it is solid we can backport at that point
<enebo[m]> but it should give us some time
<headius> ok I will merge this and have him push the sh PR
<headius> enebo: ok I just noticed this PR is against 9.3
<headius> but maybe merging cleanup to 9.3 is fine and sh version to master
<headius> this cleanup should be zero-sum so I think it's ok
<headius> hell, cleanup could merge to 9.2 really
<enebo[m]> I guess. As long as we are sure nothing will break
subbu has joined #jruby
<headius> running the CI gauntlet is pretty good
<headius> I can have him retarget master for now if you are worried about merging the cleanup into release versions
<enebo[m]> well if this was addressing something concerning it would be simpler to see the need
<enebo[m]> being able to run in pure sh is a nice feature but something we have not supported for almost 20 years
<headius> that's fair
<headius> yeah I agree the new sh version should only be master for now
<enebo[m]> but we can always backport it later and that would mean less possibility of something we did not expect breaking
<enebo[m]> yeah and I know you said only cleanup but cleanup is not really all that important for 9.2 perhaps ever
<enebo[m]> but I do like the idea of having the same script for all of them
<headius> we do have limited tests specifically for the launcher, mostly just command line specs and tests that aren't too rigorous
<headius> that was my thinking
<headius> if we have bash fixes in the future they should go to 9.2 if it is still maintained, which would be harder if it has not had cleanup PR
<enebo[m]> I guess we can reach that point after we gain confidence on master and hopefully people using us on master
<headius> or maybe not harder because we are doing 9.2 changes separately now anyway
<headius> it is pretty stable
<headius> nothing to be fixed in existing bash script will be more than one-liner changes
<headius> I'll have him retarget master and we'll let the cleanup bake while the sh version is under construction
<enebo[m]> ok (and I think you can just pulldown to master and merge too)
<headius> hmm yeah that might work
<basshelal[m]> headius: Just saw what you sent me
<basshelal[m]> That is interesting, would it be possibly used to build jffi
<basshelal[m]> I have exactly 0 knowledge of Docker other than it is essentially miniVMs but if what I'm saying is possible, this could be pretty awesome, the niche OSes will be a problem though
<basshelal[m]> I wonder if the same process can be used to build for the other OSes too, even if we need a physical (or Virtual but not Docker) instance of it, for example for FreeBSD
<headius> the base idea could be used for any number of platforms... the tricky part is getting something we can run in qemu for those platforms
<headius> BSDs would be a good next step since it's still OSS but e.g. Solaris or AIX we have no way to run for free with or without qemu
<headius> we do have a build based on qemu + docker running in jffi CI right now but it is not used to produce any artifacts currently
<headius> I have just never hooked it up
<basshelal[m]> I was just about to mention Solaris and AIX, especially AIX
<headius> it builds for x86, arm64, ppc64, and s/390 I believe
<headius> linux only of course
<headius> I linked it in that jnr-constants PR
<basshelal[m]> Does docker not run on AIX and Solaris?
<basshelal[m]> I'm thinking of the same type script that runs on those OSes
<headius> well I don't even know if docker can host other OSes
<basshelal[m]> Even if we need VMs for them, so it's not strictly automatable (not good for a CI) but good enough that we can get full builds in like 30 minutes manually
<headius> doesn't look like it, or at least it can't do it well
<basshelal[m]> No need for host, do it manually, I'm fairly certain docker is limited to the OS it runs on, though again I'm not very aware
<headius> VMs would be fine but other than full emulation like qemu we can't VM host anything other than the host CPU
<basshelal[m]> ahh
<headius> yeah looks like the not great freebsd support for docker has to be run within freebsd
<headius> so it isn't really a solution for cross-testing all CPU+OS combinations from Linux
<basshelal[m]> why are there so many CPU archs!
<headius> hah soon it will all be ARM
<basshelal[m]> and qemu isn't on those OSes I'm guessing
<basshelal[m]> Not before RISC-V comes too, things move so quickly in this goddamn industry
<basshelal[m]> Ah this is a whole rabbit-hole
<headius> qemu probably can run anywhere as it is full emulation
<basshelal[m]> How bad do we need something like this, what would be the benefit?
<headius> There are a number of improvements we could make in the JFFI binary if only we could quickly rebuild for all supported platforms
<headius> For example there is an outstanding PR to add dlsym to the JNI binding so you can query for library symbols from Java
<headius> We can't start publishing that feature unless we can rebuild the other binaries to support it
<basshelal[m]> So we cannot move unless we have a system in place that can build for all supported platforms at once?
<basshelal[m]> move as in like update jffi
<headius> for the most part yes
<headius> we can leave weird platforms behind until users can contribute a new build, but they'll have to do that before it works again
<headius> making the Java part keep working across different revs of the binary would be really hard given some of these possible changes
<headius> I was able to fake it for M1 because I could just pack some extra bits into an int and the older binaries ignore those bits
<headius> we won't be so lucky for future changes
<basshelal[m]> Damn, ok good we are on the same page then, I was hoping my assumptions were wrong
<basshelal[m]> I'll look into it and see what I can do about it, looks insanely complicated but a fun challenge and worth the pain
<basshelal[m]> I'll keep you updated, might create an issue on jffi to archive and log progress and notes etc
<basshelal[m]> I think it's probably doable with some strange hackery, but god help me with the strange challenges that'll pop up
<headius> ok sure... I'm hoping this contrib really does want to expand this work so we'll see how it goes
<basshelal[m]> Yeah that would definitely be of help, but it would be better if we knew the process ourselves and clearly documented it for the future
klobuczek[m] has joined #jruby
yosafbridge` has quit [Quit: Leaving]
yosafbridge has joined #jruby
<byteit101[m]> headius: Reminder that if you aren't too busy, I 'd appreciate a cursory glance at the @ivar PR concept before the weekend to see if I should continue down that path (MethodHandle/Binder) or if a different path would be a better approach
<headius> Oh sure I didn't realize you were waiting on input. I'll have a look this evening
<byteit101[m]> Just if the high level approach was good or not
<headius> ok
sagax has joined #jruby