<RobertNicholas[m>
👋 hey yall thought I'd poke my head in here. I'm in the process of reviving a JRuby implementation for minecraft forge modding. I already had success and got it working with a recent version (1.12.2 - see above pic for a simple 'block' mod)
<RobertNicholas[m>
besides the past two days the code wasn't touched for about 6 years from the original author so forgive me if you look through it, it's still in quite a messy state and I'm working on refactoring some of it. I'm new to jruby as of two days ago so am still learning how it all works. On that note if someone has a good recommendation for improvements they see that can be made, or on what IDE you use that'd be great :)
<RobertNicholas[m>
intellj doesn't seem to like the class / method overloading and thinks there are things that are undefined
<RobertNicholas[m>
* besides the past two days the code wasn't touched for about 6 years from the original author so forgive me if you look through it, it's still in quite a messy state and I'm working on refactoring some of it. I'm new to jruby (but not to ruby itself) as of two days ago so am still learning how it all works. On that note if someone has a good recommendation for improvements they see that can be made, or on what IDE
<RobertNicholas[m>
you use that'd be great :) intellj doesn't seem to like the class / method overloading and thinks there are things that are undefined
michael_mbp has joined #jruby
<RobertNicholas[m>
Also here is a gist of what the example mod looks like in ruby
ur5us has quit [Read error: Connection reset by peer]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 258 seconds]
sagax has quit [Ping timeout: 265 seconds]
lanceball has joined #jruby
snickers has quit [Ping timeout: 260 seconds]
<headius[m]>
Good morning!
<headius[m]>
Robert Nicholas: hey that's cool! You should chat with enebo about this, he made the "purugin" JRuby mod library that wraps bukkit if I remember right
<enebo[m]>
Robert Nicholas: https://github.com/enebo/Purugin ... It now uses Spigot and I cannot remember now how Bukkit and Spigot are related
<enebo[m]>
I believe spigot still supports the API?
<headius[m]>
enebo I will be punting modules to 9.4
<headius[m]>
It's nearly all there but you have to build with Java 17 because of that javac bug. I could rig it to generate the module info on Java 8 but it wouldn't be validating anything
<enebo[m]>
I wonder if that will ever get backported to earlier Java versions
<headius[m]>
That would give us a chance to move the remaining ant bits to a separate library as well and fully modularize everything
<headius[m]>
Yeah I am not sure the situation there. I asked for a workaround but have not heard back
<enebo[m]>
we will hand build a javac with a patch back to 9 :)
<headius[m]>
I don't know how we keep being the first to find these issues. So there is no other module out there that has a class and package named the same thing?
<enebo[m]>
yeah that one does seem really strange to me
<headius[m]>
Maybe that tells us how few people are doing modules
<headius[m]>
It works with automatic module name but if you use module info it does more validation
<enebo[m]>
but this means there will be a reckoning at some point if lots of projects are just ignoring it until they can't
<headius[m]>
Yeah I am not anti-module but they really have dropped the ball on supporting users
<enebo[m]>
for me I am sympathetic that module world can open possibilities but at this point the carrot is much smaller than the stick
<headius[m]>
the really bad cases are already fixed but this is still open to decide whether any of these softer cases need help
<enebo[m]>
JarResource is just data from the jar right? We don't put a runtime in it do we?
<headius[m]>
right, just a cache of jar entries
<enebo[m]>
all of these comments seem reasonable that as far as your original list we probably do not have any internal leak/pinning
<headius[m]>
yeah the remaining static fields are all soft or weak and reference classloader-level resources anyway
<enebo[m]>
but you do mention one comment which I am not sure we can necessarily address. If we have n runtimes and we generate Java wrappers or byteit101 enriched stuff we may pass it to somewhere else
<enebo[m]>
I am not sure this is really part of this issue at all either
<headius[m]>
somehow I skipped this one: IR Profiler uses static collections for much of its data gathering.
<headius[m]>
clearly not a risk since it is not a supported feature yet but that is out there
<enebo[m]>
well it doesn't even work right now since before our fosdem trip
<enebo[m]>
so I am punting on reenabling until 9.4ish
<headius[m]>
ok then I think I can call this one resolved
<byteit101[m]>
(aww, I saw a notification and was hoping it was my pr being reviewed... carry on)
<enebo[m]>
byteit101: I thought about saying Patrick to not ping you :)
<headius[m]>
haha
<enebo[m]>
but then I was unsure if headius knew your first name
<headius[m]>
you woke the kraken
<enebo[m]>
actually maybe I don't know it :P
<byteit101[m]>
I started the work for jrubyfx like the 2nd week of my lockdown, and I'd love to get it merged before I am fully vaccinated in 3 weeks
<enebo[m]>
HAHA
<byteit101[m]>
Patrick is correct
<headius[m]>
there's a good milestone
<enebo[m]>
ship it!
<enebo[m]>
fwiw I will just say Profiler has multiple Runtime pins in the data it saves
<enebo[m]>
both in saving *Method and IRScope -> IRManager
<headius[m]>
99 issues+PRs open for 9.3 now
<enebo[m]>
take one down and pass it around
<headius[m]>
so another kinda large group of issues...
<headius[m]>
the new IRB is still a little problematic on JRuby
<headius[m]>
we have been dragging a bunch of IRB-related issues along for years but they may get punted again
<headius[m]>
I will update the PR I have for reline + irb but I'm pretty sure it doesn't work on Windows and still has issues on Darwin