<kares[m]>
nice work on deprecating the JODA DateTime APIs, it actually seems "less work than I anticipated"
<kares[m]>
btw. was there ever a discussion about Ruby threads propagating (at least) `java.lang.Error` into the Java thread's uncaught exception handler?
<kares[m]>
propagating out JRuby "internal" exceptions but java.lang.Error is treated just like a RaiseException ...
<headius[m]>
kares: probably should do that propagation since there's generally no way to respond to an Error
<kares[m]>
ðïļ I'll follow up with a PR the only drawback would be users manually raising java.lang.Error instances but I do not see why anyone would do that
mrtommy[m] has joined #jruby
<mrtommy[m]>
Hi!
<headius[m]>
mrtommy: hello!
<mrtommy[m]>
I've a question, what is better for embeding ruby as a scripting language in my project? JRuby or TruffleRuby?
<mrtommy[m]>
I was working with Jruby but I recently heard about Truffle Ruby which claims it has way better performance but I'm not sure, pretty confused, so I'd like to know your thoughts
<headius[m]>
For embedding in a Java application? JRuby would be the clear preference there
<headius[m]>
I am biased of course, but only JRuby runs on all JVMs
<mrtommy[m]>
Oh, so, I can't use Jruby as a maven dependency and set it up in a ready-to-go package?
<headius[m]>
you can do that easily with JRuby
<headius[m]>
org.jruby:jruby-complete would be the all-in-one maven artifact, or you may find jruby-core sufficient if you don't need the Ruby standard library
<mrtommy[m]>
ya, I was using the complete one but I don't really need the ruby stdlibs thx ;)
<mrtommy[m]>
I wouldn't like to go with TruffleRuby cuz, It's with GraalVM and Oracle, and... It's Oracle, that's enough reason imo
<headius[m]>
I think JRuby will work best for you... there are many, many users embedding Ruby into Java apps using JRuby
<headius[m]>
we have plenty of docs on the wiki but let us know if you run into any issues
<headius[m]>
enebo: so this timezone stuff has gone all quagmire on me
<headius[m]>
Ruby specs require handling a vast array of time zone formats without a lot of hard rules
<headius[m]>
java.time zones are all about hard rules
<enebo[m]>
So different hard rules
<enebo[m]>
or a non-verlapping set
<enebo[m]>
partially
<headius[m]>
example: you can specify a time zone as "AST-3:00:00" and it should pick up that it is called AST and has an offset of 3 hours
<headius[m]>
but that does not exist in java.time zones
<headius[m]>
you can have a ZoneOffset that is 3 hours, OR you can have a ZoneId that is AST, whch will then be Anchorage Standard Time at 8 hours
<enebo[m]>
This has always been the Java API curse hasn't it
<headius[m]>
if I use the ZoneOffset, then it loses the AST identifier and other things fail
<headius[m]>
it may not be possible to handle all of Ruby Time using java.time, or at least not without extending java.time stuff a bunch
<headius[m]>
ZoneId is extendible so it is a possibility we could make our own zones that have a specific ID and offset
<enebo[m]>
hmm
<headius[m]>
you said AR uses some DateTimeZone APIs?
<enebo[m]>
I thought the person who did this had an eye for replacing joda
<headius[m]>
it was the same guy as Joda, yes
<headius[m]>
but he removed a lot of the soft edges in Joda
<headius[m]>
like for this, it is basically not possible to fake a timezone anymore in the way you could with joda
<headius[m]>
unless you have your own ZoneInfoProvider or custom ZoneId impls perhaps
<headius[m]>
that is not clear though
<enebo[m]>
11 methods in DateTimeUtils pass it in as an arg and I have not audited more than one
<enebo[m]>
the one only passed zone as null and UTC
<enebo[m]>
ah yeah this is a big complicated thing where it can be anything
<headius[m]>
I can get failures down to under ten but I am flipping back and forth between two sets of failures depending on how I convert the joda zone to the j.t zone
<enebo[m]>
which makes sense
sagax has joined #jruby
<headius[m]>
so there are several possible futures
<headius[m]>
if java.time is insufficient then we have to either extend it or stick with joda
<headius[m]>
if we stick with joda then we would have to undeprecate these APIs again, or not deprecate them in the first place
<headius[m]>
I have not looked at TR code but they use java.time and have to tag off a bunch of time specs
<enebo[m]>
as to datetimezone it just hooks into runtime.getTimezoneCache().get(zoneString)
<enebo[m]>
My immediate reaction to this is we need to boil the ocean and not do this in steps
<enebo[m]>
Since we don't know if we can maintain parity without going the extra mile on seeing if we can get full Ruby date compat
<enebo[m]>
It is worth considering how important this is too? I don't think there are enough TR users for us to say that tagging out the failing cases is acceptable
<enebo[m]>
Although it might be
<headius[m]>
TR has 58 tags in time vs our 36
<headius[m]>
several of the tags are exactly the issues I am struggling with
<enebo[m]>
I guess if we do not have any users with the 22 it will not matter. Perhaps they are all so esoteric they do not matter. OTOH I feel like if we do end up discovering someone needs it we may put ourselves in a position to say we cannot support it
<headius[m]>
I hate to say it but I am leaning toward punting for 9.3 and trying to do this from the inside out for 9.4
<enebo[m]>
yeah I agree. I would like to feel like if we make this move we know we can put in the extra work to make it good
<headius[m]>
then we will know if it is even possible to implement Ruby Time with java.time
<headius[m]>
right
<headius[m]>
I don't want to deprecate this and then halfway through conversion realize we can't do it
<enebo[m]>
yeah exactly
<headius[m]>
OTOH..... joda is dead
<headius[m]>
so this is a messy situation right now
<enebo[m]>
can you email the author of Joda and ask about possibility of supporting missing things?
<headius[m]>
he responded to my complaints on Twitter with mostly a shrug
<enebo[m]>
ok. I am just wondering if he would say it is possible to just extend X to support it or not
<enebo[m]>
If I made joda time (or any date/time library like that) I think I would be pretty jaded and salty.
<enebo[m]>
Dates suck
<headius[m]>
yeah I don't fault him for how java.time was designed but there are missing bits that make a straight joda conversion impossible (or so it seems so far)
<headius[m]>
that said the main issue seems to be time zones which are notoriously messed up, so it may be possible to extend just that part of java.time to support the squishy zones that joda can support
<enebo[m]>
yeah I guess that is the crux for eventual migration then
<headius[m]>
alright... I am going to retarget this PR to 9.4 and we will have to tackle that as a project after 9.3
<enebo[m]>
Just bringing this up. I already nickserv'd enebo and opened a #jruby on libera. Not sure if we officially move soon or not. Just in case those irc users should register their nicks on libera.
enebo has joined #jruby
<headius[m]>
wow
<headius[m]>
I guess it is good we made the move to Matrix
<enebo[m]>
yeah and we can wait and see on libera since we have almost 60 people using irc bridge
<enebo[m]>
kares looked and did not see a libera bridge yet. This is developing and for all we know the takeover thing will collapse
<headius[m]>
Good idea to get the important names registered though
<headius[m]>
We could have both Bridges running once there is a bridge for libera
<enebo[m]>
I have someone who likes my nick so I am trying to land grab quick :)
enebo has left #jruby [#jruby]
headius has joined #jruby
<headius[m]>
enebo: did you see somewhere that libera is the preferred path?
<enebo[m]>
yeah all the freenode staff are running it...I will see if I can see a better link
<headius[m]>
I can't get any of my emails to work right now
<headius[m]>
got it finally
headius has quit [Quit: headius]
<headius[m]>
enebo: I will need to do a round of jnr releases to fix the dependency graph
<headius[m]>
going to push out the preliminary Armple support as is for now
<headius[m]>
it still needs varargs work to be complete
<headius[m]>
ahh, it got off because I did a release of jffi without the other stuff, to add the ability to pick dir and name for the unpacked dll
<headius[m]>
jnr stuff updated on 9.2 and master
<headius[m]>
down to 111 open items on 9.3 ðĪŠ
<kalenp[m]>
just out of curiosity, what's the status of 9.3? I've skimmed those 111 bugs before, and don't expect all of them to actually make the cut, but it's hard to know from the outside if it's "real soon now" or "whoa, we still have a lot of hard work to do"
<headius[m]>
real soon now
<headius[m]>
anything I can't resolve in a day is getting punted at this point and I am retargeting some "wish" issues to 9.4 along the way
<headius[m]>
when I am not triaging new bugs (not many lately) I am working on wrapping up these issues and PRs
<kalenp[m]>
cool. as is usual, our (Looker) CI system is kind of a mess, but I wonder if I could shoehorn a nightly build in to see how it does. any particular incompatibilities to expect?
<headius[m]>
there are a handful of missing 2.6 features that may not be done for release, so that is a possibility... also the load/require subsystem has been replaced so we would want to look out for any issues there, especially relating to concurrent loading
<headius[m]>
other than that this thing has been baking for a long time... hopefully it is pretty stable
<headius[m]>
year delayed
<kalenp[m]>
ðïļ I'll see what I can do. We've definitely found our share of jruby issues, so it would be good if we could get ahead of the release
<headius[m]>
down to 105
fzakaria has joined #jruby
<fzakaria>
I'd appreciate some tips on where to search for whats going on here from anyone whose more familiar with the JDK.
<fzakaria>
I have a patch to the JDK for NixOS to remove the default library path searching to adhere better tot he hermiticity NixOS wants. https://github.com/NixOS/nixpkgs/pull/123708
<fzakaria>
If I run `jruby -ropenssl -e 'OpenSSL::SSL::SSLContext.new.ciphers.each { |c| p c}'` though no ciphers are present (with my patch).
<fzakaria>
I'd assume it's failing to get some library but nothing shows up with `strace -f -e trace=open,openat`
<headius[m]>
fzakaria: ooh neat
<headius[m]>
JRuby's openssl does not use native libopenssl you know right?
<fzakaria>
then I'm even more confused lol
<fzakaria>
I was chasing JOpenSSL -> BouncyCastle but figured that's a culprit since my patch is only tied to changing library path
<headius[m]>
so you're saying it loses its ciphers on your patched JDK?
<fzakaria>
Yea; i'm trying to validate this patch creates a "well behaved enough JDK"
<fzakaria>
All I did was strip /lib, /usr/lib etc.. from the default `java.library.path`
<headius[m]>
yeah I am not sure how that would affect this unless BC is doing something native somewhere (it shouldn't be) or jruby-openssl does something native that no longer works
<headius[m]>
perhaps give some JRuby test runs a try on your modified JDK, since if native stuff is broken a lot of stuff will be broken
<fzakaria>
that's a good idea; just `mvn test` with JAVA_HOME pointing to it ?
<headius[m]>
-Ptest to enable tests, or rake test:jruby is a good smoke test
<fzakaria>
sweet; i actually found a (maybe "the" bug) lol.
<headius[m]>
I was about to fix this to assume the OutputStream.write bytes were encoded like IO's internal encoding but then it occurred to me that maybe the OutputStream you get from RubyIO should be doing syswrite instead of write
<headius[m]>
enebo: this is not used much inside JRuby now so it would mostly change behavior for anyone attempting to turn an IO into an OutputStream
<headius[m]>
the more I think about it the more this seems right, since the "equivalent" getChannel returns the raw channel underneath all the Ruby encoding and buffering stuff.
joast has quit [Quit: Leaving.]
<headius[m]>
hmm probably would want to make the same change on getInStream
<headius[m]>
otherwise one honors encoding and buffers and the other does not
joast has joined #jruby
<enebo[m]>
yeah if outputstram is considered to be as low as syswrite I think that makes sense
<headius[m]>
OutputStream is an unencoded, unbuffered IO abstraction (unless you buffer it yourself) so this feels right to me
<headius[m]>
I will push a PR that attempts this
<enebo[m]>
so akin to reader vs stream
<headius[m]>
yeah
<enebo[m]>
I feel like we long ago had this conversation
<kalenp[m]>
that OutputStream issue is interesting to me. definitely doing some IO <-> Stream juggling in our ruby/kotlin interop layers
<headius[m]>
ah yes
<kalenp[m]>
no real further input on that at the moment, just :eyes
<kalenp[m]>
* no real further input on that at the moment, just :eyes:
<kalenp[m]>
* no real further input on that at the moment, just ð
<headius[m]>
I made some improvements previously to use more direct read paths when converting an IO to an InputStream (zero alloc) so this will be a similar change for write
<kalenp[m]>
actually, auditing that code, looks like it's all `stream.to_io`. feel free to ignore that
<headius[m]>
ahh the other way around
<headius[m]>
enebo: that windows CI error appears to be a regression, likely caused by my ShellLauncher fixes to improve open3 on Windows: https://github.com/jruby/jruby/issues/6678
<headius[m]>
nobody has reported this issue but we will need to look into it before .18 or 9.3
<enebo[m]>
ok
<headius[m]>
enebo: you registered #jruby on libera too right?
<headius[m]>
whitequark is setting up his logger for folks that migrated so I told him we would like that
<enebo[m]>
oh I realized I did not do chanserv so I will do that now since I am op in channel
<headius[m]>
yeah cool
<headius[m]>
add me as an op too
<headius[m]>
boo
ur5us__ has joined #jruby
<headius[m]>
both Marshal and Psych appear to depend on that input stream using the buffered logic
<headius[m]>
I will have to come up with an alternative solution (and probably fix them to not use getInStream so we can be more direct about these reads)