<byteit101[m]> how do I require jar-dependencies jars? lib/foo_jars.rb isn't being generated with lock_jars
<byteit101[m]> egads, using jar-dependencies with 9.3.3 gives 9.1.2 errors!
<headius> byteit101: yeah it is still using an old JRuby... need to get that updated
<byteit101[m]> Interesting, seems to be afffected by which java I'm using. System java: modern one, non-system (using path+java_home env vars) uses old jruby
<byteit101[m]> Both 11
<headius> well that's unexpected
<byteit101[m]> yea, I encountered issues with jbundler after upgrading a project from 9.2.? to 9.3.3, so moved to jar-dependencies, but I've had so many issues
<byteit101[m]> right now none of my gems are being required
<headius> hmm
<headius> I am not familiar with the guts of those libraries since they were mostly maintained by mkristian
<headius> he has not been available as much so they have started to rot a bit
<byteit101[m]> oh if you are around, what's a good exception (or exception wrapper) for binder errors (re my ivar pr)?
<headius> binder errors?
<byteit101[m]> MethodHandles/Binder
<headius> ah I see
<headius> and below
<headius> we should not see these in normal use so I would throw a Ruby RuntimeError wrapping them
<headius> with some appropriate "this is a bug" text
<byteit101[m]> yes, those
<byteit101[m]> Ok, thanks!
<headius> we control this class and the field so these should not happen
<byteit101[m]> Did bundler 2 stop requiring files automatically? using jbundler+bundler1 I didn't need to do anything to get my gems
<byteit101[m]> Are there module reasons we can't generate a class in arbitrary packages?
<byteit101[m]> ex to generate a subclass that calls a package-private constructor?
<headius> module reasons, yes
<headius> Not sure about bundler, show me an example of what you mean?
<byteit101[m]> Previously, using jbundler+bundler1:
<byteit101[m]> require "bundler/setup"
<byteit101[m]> require "jbundler"
<byteit101[m]> # now all jars & gems have been required
<byteit101[m]> Now, uisng jar-dependencies+bundler2:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9e6e1a14a1bebd4703c33ed09f473fba665a9d40)
<headius> ah isn't the autorequire optional now?
<headius> gem "blah", require: true
<byteit101[m]> Ah! I use bundler so infrequently I don't know, I'll try that
<byteit101[m]> Wait, how would that work in the gemspec?
<headius> hmm though I mostly see require: false so maybe that was just added to turn it off
<headius> oh if getting them from gemspec, hmm
<byteit101[m]> I saw 'Bundler.require(:default, :development)' is a thing, but that didn't do anything for me
<headius> first answer makes it sound like you are expected to require the things you set as dependencies
<headius> this may have changed in bundler 2
<byteit101[m]> Ah drat, ok
<byteit101[m]> explains why
<byteit101[m]> It's wierd I never use bundler, always directly requiring, then I saw this old project didn't do that, and worked until I upgraded. Oh well
<headius> yeah I guess it makes sense, if you have it as a dependency you should probably require it where you use it
<byteit101[m]> Oh, are you aware the jruby wiki isn't generally googleable?
<headius> the one on github?
<headius> what makes it not googleable?
<byteit101[m]> I'd been seeing what I thought was seo spam recently
<byteit101[m]> but it's not
<headius> I admit I do not see any hits in the first pages
<byteit101[m]> I kept getting resutls from https://github-wiki-see.page/ thought it was spam, but it's actually, well read it
<headius> yeah I just found that too
<byteit101[m]> It would explain why I always have difficulty googling jruby problems
<headius> there's some text in the issue linked there that restricting it to contributor edits only would make it indexable
<headius> they allow pages sites to be indexed but of course those are not publicly editable
<headius> this is probably the restriction we would have to live with and getting this to index would be very nice
<byteit101[m]> I have no idea the feasability of this, but you could also do what gh-wiki-see does and proxy it from jruby.org
<headius> yeah possibly, or clone the wiki repo and republish
<headius> periodically pull
<headius> or just make a wiki collaborator group and restrict it
<headius> I'm going to restrict it for now since we don't get many external contribs
<headius> I'll add whoever wants to the list
<headius> oh wat
<headius> "Restrict editing to users in teams with push access only"
<headius> so you have to be able to push to the repo to edit the wiki with this setting
<headius> that's absurd
<headius> I switched it and I'm in google search console to request it be indexed
<headius> according to the tool it can be indexed now so fingers crossed
<headius> it had the other pages indexed but blocked by robots.txt, and does not say that now for the top level page I requested to be indexed
<byteit101[m]> Cool
<headius> ok I updated all gems in the 3.1 issue with checks or links to the issue blocking us from using them
<headius> we now copy only a handful of files out of our cruby stdlib fork so I'm thinking this is the time to stop using the fork and consider the ones in JRuby repo canonical, until we can incorporate them in the appropriate gems
<headius> Monitor needs a native port: https://github.com/jruby/jruby/issues/7041
<headius> enebo: you went through the 3.0 and 3.1 issues marking completed items, could you do that for 2.7 as well?
<headius> There's some overlap because patterns were there but experimental, argument changes were starting to happen, etc
<byteit101[m]> headius: https://github.com/jruby/jruby/pull/6534 Is that not what 7041 is about?
<headius> Wow
<headius> Yup I did it a year ago
<headius> Guess I got overzealous looking at unchecked features in those lists
<byteit101[m]> :-D
<headius> In 9.3 even 😁
<headius> Maybe that means it's time to sleep
<headius> Ttfn
nilsding has quit [Quit: Client limit exceeded: 20000]
adam120 has joined #jruby
adam120 is now known as adam12
adam12 has quit [Ping timeout: 256 seconds]
<enebo[m]> headius That day I did do 2.7 but I have fixed stuff since then. Let me see if I can mark it off
<enebo[m]> yeah in fact I had already marked pattern matching as done on that issue
<enebo[m]> I didn't do the kwarg checkboxes because at the time I didn't spend the time to figure out what is transitional and done but I will review those now
<headius> Yeah those were ones that stood out for me
<enebo[m]> Almost done. Main issue is most of them fail for us but they also fail for 3.0/3.1 so I have to make sure we fail succeed same way
<enebo[m]> almost done though
<enebo[m]> ok we are cool as far as complaining on 2.7 args the same way as 3+
<enebo[m]> heh it basically says we are 1/2 done on 2.7 but nearly everything unmarked is from stdlib updates and internal VM features
<enebo[m]> we probably should remove checkboxes on RubyVM and internals updates since we obviously will never be doing that stuff
<headius> yeah I will review today and remove things that are clearly not going to happen
<headius> or just remove checkboxes anyway
<headius> most of master stdlib is updated... just the few things we copy from our fork left
<headius> there's few enough now I'm not sure maintaining the fork is useful... I will consider that but most of the remaining items are going to come from gems once we get jruby support merged over
<headius> quick stab at foo(&)
<headius> I did not see any specs for this
<enebo[m]> Yeah I am not sure how I would have added that
<headius> it was failing because it was a blockpass with an argument node, something we have never had before
<headius> so I just check for that case and reload the incoming block
<enebo[m]> That I think is fine but it is a little unsatisfying because the intent is weird...ArgumentNode just happens to only be '&'
<enebo[m]> I already knew why it was not working but was not too into doing it this way but I think this is literally the only way this would show up (& is the only ArgumentNdoe we can get)
<headius> yeah that's what I was hoping
<headius> it's clearly not something the builder has had to deal with before so this is a new case
<enebo[m]> yeah. So perhaps just put a comment on that if saying this is for '&' and it is the only case where it happens
<enebo[m]> I did not do this fix because I figured I would fix this in the AST but that can be done later
<enebo[m]> when I say figured I mean I am not sure how much work that is and it tired me out thinking about it :)
<headius> I will narrow it to just the '&' case so we get proper errors if something else sneaks in there later
<enebo[m]> ah great idea
<headius> guess we don't have enough smarts to skip the %v_0 but it's fine
<headius> enebo: you given any thought to the masgn order of operations change?
<enebo[m]> headius: I have looked at it but I have not started on it
<enebo[m]> Our masgn code is isolated so this is largely just walking our builds in the same order
<enebo[m]> This is an issue I plan on visiting once we get most errors down because I do not see a lot of people noticing this and there are not many tests for it
<enebo[m]> It is also largely going to be a one or two method change in builder
<headius> this Kernel.load module thing will be a larger change for us
<headius> we propagate the wrap boolean all the way into the Library interface
<headius> I started to attempt it but then I hit
<headius> library.load(runtime, wrap)
<enebo[m]> yeah yuck
<headius> I pushed a couple more minor 3.1 things
<headius> going back to stdlib and test updating now
<headius> project for someone: https://github.com/jruby/jruby/issues/7045
<headius> enebo: ok, stdlib and tests are updated from 3.1
<enebo[m]> ah nice
<headius> several files we had diffs for are now completely gone from CRuby repo so I have removed them from our sync tool
<headius> unicode_normalize only has some unicode table sources left in CRuby (see above issue) but I filed a bug to get that moved out to a gem
<headius> remaining diffs against 3.1 are here: https://gist.github.com/headius/2e3928e8a96c1a86cd887e37da78b844
<headius> jruby-ruby_3_1_0 branch pushed to our fork but we are close to dumping it altogether
<headius> kares: I proposed a simpler option for getting the openssl gem to install on JRuby: https://github.com/ruby/openssl/issues/20#issuecomment-1022872855
<headius> if you and enebo agree with that we could move forward adding a -java version of the openssl gem that just depends on jruby-openssl
<enebo[m]> headius: I wrote a comment and I think that is a good idea
<enebo[m]> byteit101: I installed zulu with JDK FX and I see the same problem as reported
<byteit101[m]> oh "good"
<enebo[m]> byteit101: I can see the .mods for jrubyfx in modules dir in the distro
<enebo[m]> haha
<byteit101[m]> must be a windows issue then
<enebo[m]> I could maybe try a simple JavaFx Java program and see if that works
<enebo[m]> I notice in the zulu downloads it says 2012r2 for platform version. I am on windows 10
<enebo[m]> but I saw no other versions and the java part of this works so I am just throwing it out as something which made me wonder
<enebo[m]> Did modules get more mandatory in Java 17?
<enebo[m]> it appears they are recommending making a module-info.java to use javafx module
<byteit101[m]> I disnt have to --add-opens in my testibg on 17 with those two samples
<byteit101[m]> I do with the fxml sample though
<enebo[m]> byteit101: ok new news
<enebo[m]> I managed to run rake reflect on master and using that I can run analog_clock
<enebo[m]> The gem itself does not work and we just get the no fx loaded error
<byteit101[m]> hmm
<enebo[m]> If I were to manage a guess I would say we are loading something generated that is not there or something like that and we are blanket catching some exception
<byteit101[m]> so to confirm -> rake gem & gem install = fail, but just rake reflect works?
<enebo[m]> byteit101: I just did a gem install
<enebo[m]> I did not build the gem from the repo
<byteit101[m]> Oh gem install gives you 1.x
<byteit101[m]> he was using master (2.x dev)
<enebo[m]> HAHA ok
<enebo[m]> When will 2.x be released?
<enebo[m]> I thought a release eventually get out. It has been 6 years between releases
<byteit101[m]> after ivar is implemented
<byteit101[m]> because otherwise we have to break api, then revert the api break
<byteit101[m]> ruby fxmlloader uses ivars, java fxmlloader uses fields, so hence the ivar exposing push :-)
<enebo[m]> I can will try making the gem and making sure that is working
<byteit101[m]> I have some modifications staged for ivar stuff, but nothing too big
<byteit101[m]> (not pushed)
<enebo[m]> So gem does work but rdoc complains during install
<enebo[m]> (which does not actually prevent the gem from installing but it is not desirable)
<byteit101[m]> that's funky
<enebo[m]> I did end up install zulu twice and I swore I got JDK FX on first try but nope
<enebo[m]> So maybe the reporter is not running the FX build since there is a non-FX build
<enebo[m]> Perhaps ask java --list-modules to make sure it is right one
<byteit101[m]> comment your findings (and ask if they are sure they are on 2.0/master with rake reflect)
<enebo[m]> ok
<byteit101[m]> because "I did end up install zulu twice and I swore I got JDK FX on first try but nope" is interesting
<enebo[m]> byteit101: yeah I would have bet money I got JDK FX the first time but I definitely got the wrong one
<byteit101[m]> cool
<byteit101[m]> thanks, though don't you need rake [build/gem] ? rake reflect only generates the dsl helpers
<enebo[m]> That did not compute
<enebo[m]> what didn't I need to do?
<enebo[m]> if I would have did gem it would have implicitly did the reflect?
<byteit101[m]> Yes, rake gem depends on reflect, but reflect only doesn't build the gem
<byteit101[m]> not something that you didn't need to do, but in the instructions you should probably change rake reflect to rake gem (or build I always forget)
<enebo[m]> byteit101: I only specified that because that is what I did. Once I ran reflect I ran the clock without installing the gem
<enebo[m]> then I isntalled the gem after that. So I figured I could skip the reflect but I didn't
<byteit101[m]> enebo: Does that sequence of commands in a fresh checkout work? I don't think so
<byteit101[m]> I could be wrong though
<byteit101[m]> my only reason for mentioning this is it may cause confusion to the user if it idn't
<byteit101[m]> *it isn't
<enebo[m]> Sure it works
<enebo[m]> you can rake reflect on an empty project
<enebo[m]> then just use -Ilib and you can run stuff
<byteit101[m]> Yes, which is what I do, but your comment on the issue mixes those two modes and may be confusing
<byteit101[m]> if you run rake reflect, I think the gem install will fail as no gem was build, and that may confuse people
<enebo[m]> I can remove the rake reflect line if you want
<byteit101[m]> (people looking at the issue)
<enebo[m]> I made a gem after running that
<enebo[m]> I literally did what I typed
<byteit101[m]> well, either replace it with rake gem as step one
<enebo[m]> why would rake gem fail if you ran rake reflect?
<byteit101[m]> or remove gem install and add -I on step 3
<byteit101[m]> > jruby -S gem install pkg/jrubyfx*.gem (rdoc error did occur but it did not prevent the gem from installing)
<byteit101[m]> that's not rake gem
<byteit101[m]> rake gem wouldn't fail, but gem install would
<enebo[m]> why?
<enebo[m]> Is it because rake reflect happens on install or something like tat?
<enebo[m]> you didn't run rake gem?
<byteit101[m]> correct!
<enebo[m]> but I did
<byteit101[m]> Sure, but you didn't mention it in the comment
<enebo[m]> ah ok now the confusion is over
<byteit101[m]> my whole point was your comment didn't mention that fact, which may be confusing to someone who is "completly new to jruby"
<enebo[m]> I missed putting a step down
<enebo[m]> fwiw my instructions were just as confusing by deleting the rake reflect
<byteit101[m]> Yes, they were more confusing
<enebo[m]> since there was no istruction to build the gem
<enebo[m]> so I had a confusing set of 3 steps
<enebo[m]> then edited out rake reflect making it more confusing
<byteit101[m]> Yay, thanks!
<enebo[m]> then added the missing line
<byteit101[m]> that confusion took too long to clear up :-P
<enebo[m]> much too long but we got there :)
<headius> Java 17 prohibits illegal accesses
<headius> i.e. --illegal-access flag goes away and you have to add-opens for everything