<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>
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>
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>
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
<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
<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
<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
<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?