razetime has quit [Remote host closed the connection]
<headius>
Good morning!
razetime has joined #jruby
<headius>
byteit101: hey what's your status on the pty/spawn stuff
<headius>
just want to make sure I'm not blocking anything
<headius>
I'm back in the office now
<byteit101[m]>
Not really. You can review what I have so far, but my plans for this week after work are create PR for new lfp features, build lfp as a gem, get those features into subspawn impl, then figure out how we can package all architectures into jruby/a jar. I only really need your help on the last one
<byteit101[m]>
I will probably be done in under a month for 9.4 for posix, but win32 unlikely to make the cut unless I have help there
<headius>
byteit101: I had thought some about packaging LFP with JRuby... one possibility would be to just include it in jffi directly
<headius>
but there's an open project to do a nicer job of managing native libraries (unpacking, loading, cleanup, platforms, etc) that would encompass both of these
<headius>
at this point I don't see win32 getting the additional native IO stuff it needs, since we really just need 9.4 out the door. Another 2023 priority once we have caught up with 3.1 compatibility in general
<headius>
there are very few Windows users... we still want to support them, but 99% of JRuby users are on unixes
<byteit101[m]>
I had though about jffi, but I'd prefer separate so I can use this lib in mri too
<byteit101[m]>
that's what I assumed regarding windows
<byteit101[m]>
lfp would add roughly ~50k*(number of platforms we support)
<byteit101[m]>
on an unrelated side note: I encountered a java build using makefiles. It was weird. Not even my java classes in school used makefiles
<headius>
byteit101: agreed on keeping it separate... it was just an immediate escape valve I had considered to avoid the complexity of introducing a framework for native library management right now
<headius>
that need is already there and has just been kicked down the road forever
<headius>
I believe this is a good place to invest time, though, given Panama and the strong likelihood that there will be more and more of these native libraries blurring the lines and all need to be managed
<byteit101[m]>
headius: oh speaking of panama, your talk in MA included that yes? are your slides or a recording somewhere?
<headius>
I will post a PDF of the slides but there's not a whole lot more to see than the Panama documentation provides
<headius>
No recording at this conference unfortunately
<ldywicki[m]>
Hey folks, opening communication channel as requested to help with maven stuff: https://github.com/jnr/jffi/issues/85. I actually don't know much about low level stuff you all guys been doing, however I will be able to help with java classloaders, maven and osgi (probably least interest for you but that's what drove me to you).
<ldywicki[m]>
Based on surnames I think that at least some of you are based in EU, myself too but I am working currently with US customer which shifted my working hours around theirs.
Guimauve has joined #jruby
<headius>
ldywicki: hello there!
<headius>
The low level stuff is fine, mostly what we need is getting a grip on how to properly package jffi better for maven and modules
<headius>
I also have wanted to look at the maven native library plug-in that is supposed to make it easy to ship multi-platform native libraries but I never have had a chance
<ldywicki[m]>
My maven c/gcc toolchain fights from 2008 were rather sober making whole build far more complicated, however if you have built binaries produced by something earlier in a chain then it could fly with "classifiers". I recently found out that ie. protobuf compiler is distributed in such way.
<headius>
We're using all of the tools unfortunately. There's an ant build that launches a make build to create the binaries, and then Maven to package up the Maven artifacts
<headius>
This was stitched together by the original maintainer years ago and after he left we never got around to cleaning it up
<ldywicki[m]>
I think I will be able to help with maven itself and classloading. I don't have much experience with java module system, but if something works with osgi it will definitely match constraints forced by jigsaw.
<headius>
That sounds great, let's start there and see what we can come up with
<headius>
I wouldn't say the build is complicated, it's just spread across a lot of different tools
<ldywicki[m]>
if you would be up for experiment with dockcross then I will be able to pull it into maven based on javacan blueprint
Guimauve has quit [Quit: please stop licking my ears ;_;]
<headius>
Dockcross sounds familiar, I'll have a look
<headius>
All right
<headius>
Cross compiling with docker
<headius>
Yeah for sure, there's also some CI GHA stuff for building across platforms using docker right now but if we could do it locally that would be nice to have for sure
<byteit101[m]>
hmmm... where to put the setrlimit on lfp...
<byteit101[m]>
ok, I think I've implemented setrlimit and umask in lfp