ur5us__ has quit [Ping timeout: 258 seconds]
ur5us__ has joined #jruby
_whitelogger has joined #jruby
_whitelogger has joined #jruby
ur5us__ has quit [Ping timeout: 258 seconds]
ahorek[m] has quit [Ping timeout: 245 seconds]
ahorek[m] has joined #jruby
lopex has quit [Ping timeout: 276 seconds]
c355e3b has quit [Ping timeout: 245 seconds]
lopex has joined #jruby
c355e3b has joined #jruby
ur5us__ has joined #jruby
ur5us__ has quit [Ping timeout: 245 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 252 seconds]
c355e3b has quit []
enebo has joined #jruby
enebo has left #jruby [#jruby]
subbu has quit [Remote host closed the connection]
subbu has joined #jruby
<headius[m]> yaml 4.0 was too drastic a change so I am looking to just update psych to whereever 2.6 left off
<headius[m]> enebo: not sure what psych to use
<headius[m]> Ruby 2.6.7 released earlier this month still uses 3.1.0, based on my rvm install
<headius[m]> we are running 3.2.0
<headius[m]> 3.2.1 is latest in that line, 3.3.2 is out there, and 4.0.0 as well but that changes some larger things and is intended for Ruby 3.1
<headius[m]> my original PR was to update to 3.3.1 but there were new failures in psych tests
_whitelogger has joined #jruby
_whitelogger has joined #jruby
<enebo[m]> hmm
<enebo[m]> yeah I guess it depends on what failures you can observe
<enebo[m]> other than big changes like safe mode I would think most changes are largely bug fixes
<headius[m]> enebo: changing gears for a second, I am looking at my full modularity branch
<headius[m]> of course we stumbled on a compiler bug that means we can't build it except on Java 17 b20 or higher
<headius[m]> but I am using that now to try to finish the branch so it is ready if they provide a workaround
<headius[m]> dirgra is one remaining library with no module
<enebo[m]> I thought I had added it
<enebo[m]> perhaps I just did not release it
<headius[m]> oh let me check then... what module name did you use?
<headius[m]> I had it set to just look for "dirgra" because of the default module name stuff
<enebo[m]> module org.jruby.dirgra {
<headius[m]> ok
<enebo[m]> 0.4
<headius[m]> and that is in what release?
<enebo[m]> 0.4
<headius[m]> I see 0.4 latest
<headius[m]> march
<headius[m]> cool I will update then
<enebo[m]> yeah I only made 0.4 for this but if I remember right I realized I needed to massive updates to make it pass specs
<headius[m]> to make it pass our specs?
<enebo[m]> I don't remember why they stopped but it is weird to write Ruby specs against a library which is part of jruby itself
<enebo[m]> dirgra has its own specs
<headius[m]> ok
<enebo[m]> 1700 lines of them...
<enebo[m]> err half that
<enebo[m]> I see these show up in target :)
<headius[m]> ypu that is working
<headius[m]> boo, my automatic module stuff in jffi was configured wrong
<headius[m]> jffi module naming is fixed and released in 1.3.4
<headius[m]> jitescript 0.4.2 released with module name
<headius[m]> ok so it is close
<headius[m]> there are two libraries remaining: ant and jzlib
<headius[m]> even the most recent ant jar does not appear to have any module info
<headius[m]> jzlib has not had an update in many years and may be difficult to push forward
<headius[m]> we can't really get rid of either... jzlib is an integral part of zlib ext and ant extensions in JRuby are used in our rake builds
<enebo[m]> FFI
<headius[m]> FFI!
<enebo[m]> not really being serious
<headius[m]> what about it
<enebo[m]> ffi to zlib
<headius[m]> hah
<enebo[m]> requiring native and also having to fit into stream I know
<headius[m]> there might even be a Ruby FFI zlib wrapper already
<headius[m]> or maybe I am thinking of libzip or something
<enebo[m]> so we could fork jzlib if it is just missing module info
<enebo[m]> I mean if it already is not getting updated the cost of taking it as a forked project is not going to cost anything
<enebo[m]> HAHAHAH last released in 2013
<headius[m]> yeah that is an option
<headius[m]> just push under org.jruby.jzlib
<enebo[m]> makes me wonder what was patched for that release
<headius[m]> so that is just sticking jzlib and ant into jars so that the default name they get matches
<enebo[m]> modules are grand
<headius[m]> but that is fully modularized JRuby
<enebo[m]> https://github.com/ymnk/jzlib/issues interesting how few issues there are for this library
<enebo[m]> including 'wifi access'
<headius[m]> $ jlink --module-path lib/modules/:lib/jzlib.jar:lib/ant.jar --launcher jruby=org.jruby.base/org.jruby.Main --add-modules org.jruby.base --output linked-jruby
<headius[m]> Error: automatic module cannot be used with jlink: org.hamcrest.hamcrest.core from file:///Users/headius/projects/jruby/lib/modules/org.hamcrest.hamcrest-core-1.3.jar
<headius[m]> aww so close
<headius[m]> actually I don't think I need that one for runtime
<headius[m]> ant and jzlib kill it next though
<headius[m]> no automatic modules (based on jar name) can go into jlink
<headius[m]> yeah I have tried to get in contact with ymnk and he is just gone
<enebo[m]> yeah jcraft site shows 2012 as last update
<enebo[m]> so last jzlib is 2013 I am guessing this did not work out
<headius[m]> seems like forking is probably the only path forward
<enebo[m]> yeah I think forking is pretty reasonable here
<enebo[m]> no response no release in forever. the library is mostly just working so not much maintenance
<headius[m]> email I sent to info@jcraft in early March went unanswered
<headius[m]> I guess it is dead
<enebo[m]> the benefit is we can actually put out a release if we find a problem which is a big improvement over current situation
<headius[m]> yeah and there are definitely things we could fix
<enebo[m]> all lambda impl
<headius[m]> I will fork it to jruby/
<enebo[m]> we can rewrite it in ceylon
<headius[m]> rewrite in ruby
<headius[m]> jrzlib
<headius[m]> jerzeylib
<headius[m]> I don't know how this was ever released... there's no release plugin or parent pom
<headius[m]> depending on how closely he followed zlib code it may be easy to update it
<headius[m]> I will try to set it up for sonatype release under jruby group
<headius[m]> oh right
<enebo[m]> library builds with sbt so perhaps the deploy is there too somehow?
<headius[m]> oh just for testing
<headius[m]> as far as I can tell
<enebo[m]> ah ok
<headius[m]> the tests are in Scala
<enebo[m]> there are some directories which could just get nuked too if we care enough to bother
<enebo[m]> MindTerm patch
<enebo[m]> just keep src and example
<headius[m]> this pom looks different than the one in the repo
<enebo[m]> does repo have -src.jar?
<enebo[m]> source is probably the important bit for comparison...perhaps we can diff and then apply anything newer if it actually is different
<headius[m]> hmm
<enebo[m]> how did he make this anyways :)
<headius[m]> yeah
<headius[m]> the 1.1.3 tag appears to live on dev branch
<headius[m]> ahh no that is a merge commit on both
<enebo[m]> ah so master/head is just not the latest
<headius[m]> seems that way
<headius[m]> there are unreleased fixes after 1.1.3
<enebo[m]> still nothing in pom to do this release as far as I can tell
<headius[m]> yeah
<headius[m]> according to maven search is it using the same sonatype oss-parent we use in some projects
<enebo[m]> oh maybe a lot of inherited stuff
<headius[m]> release:prepare seems to run 🤔
<enebo[m]> if so nice
<headius[m]> yeah it must be inheriting it somehow
<enebo[m]> makes you wonder about our poms now
<headius[m]> yeah
<headius[m]> should I just change it to our group ID and try to release?
<headius[m]> once I add the module name anywa
<enebo[m]> yeah I would do a local build with jruby too
<enebo[m]> but sure.
<headius[m]> deploy is working with an oss-parent update
<headius[m]> dunno if I should do any weird version numbering but I don'
<headius[m]> don't think it is necessary'
<enebo[m]> hmm
<enebo[m]> I wonder if we should rename the packages
<headius[m]> we should before we add a module-info but I think with automatic name we can dodge it for now
<headius[m]> automatic name will just export everything as public
<enebo[m]> ah this is just to make sure it is still working
<headius[m]> I think automatic name will be enough to get us to linking
<headius[m]> I think
<headius[m]> methinks jdeps should be normalizing hash order
ur5us has joined #jruby
sagax has quit [Ping timeout: 240 seconds]
<headius[m]> enebo: forked jzlib seems to work fine... no package naming but it has module name and whatver fixes were on master but unreleased
ur5us has quit [Remote host closed the connection]
<headius[m]> enebo: this is the PR on our fork that would get it ready for release with a module name: https://github.com/jruby/jzlib/pull/1
ur5us has joined #jruby