03:49 <fzakaria[m]> Are there any nice slides or some writeup on the history of JRuby ?

03:49 <fzakaria[m]> i'm in a reading mood :)

09:04 <headius[m]> fzakaria: oh hmmm

09:04 <headius[m]> I did a talk soe years back that was mostly history

09:04 <headius[m]> maybe Euruko Budapest?

09:06 <headius[m]> video is here: https://www.youtube.com/watch?v=sPS7F-ITqK4&list=PLCrwBqiOtwpINmaC2eBX8QHuLYngECD19&index=2&t=0s

09:07 <headius[m]> doesn't look like I ever uploaded slides

09:12 <headius[m]> ok just for you: https://speakerdeck.com/headius/the-story-of-jruby

19:20 <travis-ci> jruby/jruby (master:a43742a by Thomas E. Enebo): The build was fixed. https://travis-ci.org/jruby/jruby/builds/664982277 [174 min 29 sec]

20:52 <msp-greg[m]> Hello all,

20:52 <msp-greg[m]> A JRuby neophyte question re Windows. Looking at the JRuby head build used in Actions, and the JDK 11, the two are built using different msvc runtime versions. I looked at jruby.dll in JRuby. Normally, one doesn't combine the two, and it can cause issues...

20:53 <headius[m]> We currently only ship a 32-bit binary so it may not be a problem right now... when we can't load libjvm we fall back on spawning a subprocess

20:53 <headius[m]> Are you seeing a problem?

20:58 <msp-greg[m]> I really haven't tried much with JRuby. With the mention of ffi & OpenSSL, I looked at the msvc versions to see what matched up with JRuby. For instance, with Ruby MRI, the mingw & mswin builds use different compilers, so mixing their dll's is not a good idea...

20:58 <msp-greg[m]> I also didn't look at jruby.dll, so I don't know if it's really doing anything.

20:59 <headius[m]> ok, it's probably not a issue in practice but I know we can't combine different versions of the C library

21:00 <headius[m]> any problems you'd see would most likely fail very fast and probably not start up JRuby properly at all

21:10 <msp-greg[m]> Actually, I know a company that embeds MinGW Ruby in a Windows application built with recent Visual Studio tools, and the issues they had were not related to startup. I think it was more memory management, like one runtime would free memory that the other needed? Never got into any serious discussions, as I'm not really a c type.

21:11 <headius[m]> Ok we'll keep that in mind. Might be worth opening a bug on jruby/jruby-launcher so we keep it in mind going forward

21:13 <msp-greg[m]> Ok. I'll look more this weekend, as it could be built on Actions with a matching version... Same version used for the mswin build.

21:21 <headius[m]> the launcher is on its last legs these days and we seek to replace it with something easier to maintain, so this might all be moot soon

21:34 <headius[m]> enebo: https://github.com/jruby/jruby-launcher/issues/31

21:35 <headius[m]> one more wrinkle... most Linux environments don't set JAVA_HOME and link to `java` from /usr/bin/java, so can't as easily determine JAVA_HOME

21:48 <enebo[m]> headius: if you find that wrinkle let's table it for this launcher instead of putting hours more work into fixing it

21:48 <enebo[m]> add it as an issue though so we can fix it

21:48 <enebo[m]> if it is in fact a problem

21:49 <lopex> wrt wrinkle, what can the scripts do anyways

21:49 <enebo[m]> the complicated thing with that launcher is like an octopus it tries multiple ways of getting its answer so we almost need a matrix of what we think should or shouldn't work

21:49 <headius[m]> yeah

21:50 <headius[m]> enebo: the workaround of setting JAVA_HOME is a trivial ask

21:51 <headius[m]> at this point I'm starting to wonder if anything short of actually starting up java will be a reliable indicator of what JDK we're running on

21:51 <lopex> like debian alts ?

21:52 <headius[m]> that's a hell of a bitter pill to add to our already poor startup

21:52 <headius[m]> lopex: yeah

21:52 <lopex[m]> hm

21:52 <enebo[m]> headius: is /usr/bin/java actually not just a soft or hard link?

21:52 <enebo[m]> I guess that may nto help the script but the launcher can do the magic

21:52 <headius[m]> I don't have it in front of me... what is it for you?

21:53 <headius[m]> on fedora

21:53 <enebo[m]> I will see

21:53 <headius[m]> I thought they were typically soft links but I don't know if they all do it that way

21:53 <enebo[m]> although I don't use system java

21:53 <enebo[m]> HAHAH 0 lrwxrwxrwx. 1 root root 22 Dec 26 16:47 /usr/bin/java -> /etc/alternatives/java*

21:53 <headius[m]> for a soft link in theory it should resolve to JAVA_HOME/bin/java so it's a matter of canoncalizing it then (however one does that in C)

21:53 <headius[m]> hah great

21:53 <enebo[m]> 4 lrwxrwxrwx. 1 root root 72 Dec 26 16:47 /etc/alternatives/java -> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64/jre/bin/java*

21:53 <enebo[m]> so yeah round and round we go

21:54 <enebo[m]> but resolving to non-soft link will work on linux

21:54 <headius[m]> and that java/../.. would work but it's two links away

21:54 <enebo[m]> yeah so it needs to get real canonicalized file

21:54 <headius[m]> that might not be a terrible amount of work but I don't know the C to do it

21:54 <enebo[m]> well I won't even be doing it in C :)

21:55 <headius[m]> readlink I guess

21:55 <enebo[m]> but I have little fear of doing this...I am sure this is built in to fs

21:55 <headius[m]> heh yeah well I assume "not C" will have a way to resolve links

21:55 <headius[m]> readlink in C is POSIX

21:55 <enebo[m]> the good news is it isn't C I guess

21:55 <enebo[m]> the other good news is this is probably not OS specific code either

21:56 <headius[m]> so while file.is_link; file = readlink(file)

21:57 <headius[m]> now this is assuming my jmods trick is the best way to detect modules

21:57 <headius[m]> might be that detecting a sibling command is just as good

21:57 <headius[m]> like if you have `jlink` you're probably on Java 9+

21:57 <headius[m]> but I don't know if jlink is standard

21:57 <enebo[m]> ```

21:58 <enebo[m]> ``` let p = PathBuf::from("/usr/bin/java");

21:58 <enebo[m]> println!("FS: {:?}", fs::canonicalize(p).unwrap());

21:58 <headius[m]> neat

21:58 <enebo[m]> ok I did not apparently learn to paste but is is the right answer

21:59 <enebo[m]> FS: "/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64/jre/bin/java"

21:59 <headius[m]> nice

22:01 <lopex[m]> rustenebo

22:02 <enebo[m]> lopex: I have ~98k binary vs linux 78k but on windows I am 97k vs 1M(exe) + 1M(dll)

22:02 <enebo[m]> and these compress to low 30s k with gzip

22:03 <enebo[m]> so I think we can just bundle binaries of all common platforms and it will still be a small gem