13:19 <puritylake[m]> I’ve never understood how jits work

13:30 <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

15:26 <headius> basshelal: yo have you seen this: https://github.com/jnr/jnr-constants/pull/106

15:26 <headius> good morning

15:27 <headius> seems like this person might be interested in helping us set up cross-platform (linux, at least) JNR builds and testing

15:33 <headius> enebo: you around?

15:33 <headius> your E seems to be keeping up

15:34 <enebo[m]> I am here but I also happen to have this as my current browser thread

15:34 <enebo[m]> so it would have looked that way regardless

15:34 <headius> https://github.com/jruby/jruby/pull/7022

15:34 <headius> so mrnoname did this one for us but he also has managed to port the entire thing to sh

15:35 <headius> he's finishing up a second pass to reduce the amount of eval needed but it already passes CI

15:35 <headius> I believe he even tested it with dash to make sure it doesn't accidentally use any bash features

15:36 <enebo[m]> how do we ignore whitespace on gh again

15:36 <headius> ?w=1

15:36 <headius> I think

15:37 <headius> he was very annoyed by varying indentation throughout

15:37 <enebo[m]> hmm yeah I did not use w=1

15:37 <headius> which is fair

15:37 <enebo[m]> There is a UI for I found

15:38 <headius> yeah you can get to it from diff settings button I thkn

15:38 <headius> I thicken

15:39 <headius> I don't see any reason not to merge the cleanup since it's mostly standardizing formatting and cleaning up some bashy things

15:40 <enebo[m]> most of this is not really even significant changes but styling or removing unneeded bracket + ""

15:40 <headius> yeah

15:40 <enebo[m]> but I am fine with this either way

15:40 <enebo[m]> and I can see there are substantive changes

15:40 <headius> I think he needed to do this mostly to clean up things before attempting the posix sh version

15:41 <enebo[m]> yeah getting pure sh support would be nice

15:41 <headius> he has that PR ready to go as well but it continues from this point

15:41 <headius> so if you are cool merging this then I will handle that and have him submit the second PR

15:42 <headius> should we keep this on master or move to 9.3? I'm leaning toward master

15:42 <enebo[m]> I think so. master is much safer and gives us more time to tease out anything

15:42 <headius> yeah at least give it some bake time

15:42 <headius> we have some bleeding edge users that will give it a go as well

15:42 <enebo[m]> if we get to releasing 9.4 and it is solid we can backport at that point

15:42 <enebo[m]> but it should give us some time

15:43 <headius> ok I will merge this and have him push the sh PR

15:46 <headius> enebo: ok I just noticed this PR is against 9.3

15:46 <headius> but maybe merging cleanup to 9.3 is fine and sh version to master

15:46 <headius> this cleanup should be zero-sum so I think it's ok

15:47 <headius> hell, cleanup could merge to 9.2 really

15:49 <enebo[m]> I guess. As long as we are sure nothing will break

15:49 <headius> running the CI gauntlet is pretty good

15:49 <headius> I can have him retarget master for now if you are worried about merging the cleanup into release versions

15:51 <enebo[m]> well if this was addressing something concerning it would be simpler to see the need

15:51 <enebo[m]> being able to run in pure sh is a nice feature but something we have not supported for almost 20 years

15:51 <headius> that's fair

15:52 <headius> yeah I agree the new sh version should only be master for now

15:52 <enebo[m]> but we can always backport it later and that would mean less possibility of something we did not expect breaking

15:52 <enebo[m]> yeah and I know you said only cleanup but cleanup is not really all that important for 9.2 perhaps ever

15:52 <enebo[m]> but I do like the idea of having the same script for all of them

15:52 <headius> we do have limited tests specifically for the launcher, mostly just command line specs and tests that aren't too rigorous

15:53 <headius> that was my thinking

15:53 <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

15:53 <enebo[m]> I guess we can reach that point after we gain confidence on master and hopefully people using us on master

15:53 <headius> or maybe not harder because we are doing 9.2 changes separately now anyway

15:54 <headius> it is pretty stable

15:54 <headius> nothing to be fixed in existing bash script will be more than one-liner changes

15:55 <headius> I'll have him retarget master and we'll let the cleanup bake while the sh version is under construction

15:55 <enebo[m]> ok (and I think you can just pulldown to master and merge too)

15:56 <headius> hmm yeah that might work

16:34 <basshelal[m]> headius: Just saw what you sent me

16:34 <basshelal[m]> That is interesting, would it be possibly used to build jffi

16:34 <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

16:34 <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

16:35 <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

16:35 <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

16:36 <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

16:36 <headius> I have just never hooked it up

16:36 <basshelal[m]> I was just about to mention Solaris and AIX, especially AIX

16:36 <headius> it builds for x86, arm64, ppc64, and s/390 I believe

16:37 <headius> linux only of course

16:37 <headius> I linked it in that jnr-constants PR

16:43 <basshelal[m]> Does docker not run on AIX and Solaris?

16:45 <basshelal[m]> I'm thinking of the same type script that runs on those OSes

16:45 <headius> well I don't even know if docker can host other OSes

16:46 <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

16:46 <headius> doesn't look like it, or at least it can't do it well

16:46 <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

16:47 <headius> VMs would be fine but other than full emulation like qemu we can't VM host anything other than the host CPU

16:47 <basshelal[m]> ahh

16:47 <headius> yeah looks like the not great freebsd support for docker has to be run within freebsd

16:47 <headius> so it isn't really a solution for cross-testing all CPU+OS combinations from Linux

16:48 <basshelal[m]> why are there so many CPU archs!

16:48 <headius> hah soon it will all be ARM

16:48 <basshelal[m]> and qemu isn't on those OSes I'm guessing

16:49 <basshelal[m]> Not before RISC-V comes too, things move so quickly in this goddamn industry

16:52 <basshelal[m]> Ah this is a whole rabbit-hole

16:53 <headius> qemu probably can run anywhere as it is full emulation

16:54 <basshelal[m]> How bad do we need something like this, what would be the benefit?

16:55 <headius> There are a number of improvements we could make in the JFFI binary if only we could quickly rebuild for all supported platforms

16:55 <headius> For example there is an outstanding PR to add dlsym to the JNI binding so you can query for library symbols from Java

16:56 <headius> We can't start publishing that feature unless we can rebuild the other binaries to support it

16:58 <basshelal[m]> So we cannot move unless we have a system in place that can build for all supported platforms at once?

16:58 <basshelal[m]> move as in like update jffi

17:00 <headius> for the most part yes

17:00 <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

17:01 <headius> making the Java part keep working across different revs of the binary would be really hard given some of these possible changes

17:01 <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

17:01 <headius> we won't be so lucky for future changes

17:03 <basshelal[m]> Damn, ok good we are on the same page then, I was hoping my assumptions were wrong

17:04 <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

17:05 <basshelal[m]> I'll keep you updated, might create an issue on jffi to archive and log progress and notes etc

17:06 <basshelal[m]> I think it's probably doable with some strange hackery, but god help me with the strange challenges that'll pop up

17:06 <headius> ok sure... I'm hoping this contrib really does want to expand this work so we'll see how it goes

17:07 <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

21:33 <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

21:34 <headius> Oh sure I didn't realize you were waiting on input. I'll have a look this evening

21:34 <byteit101[m]> Just if the high level approach was good or not

22:04 <headius> ok