<kares[m]>
my 2c: imports are best to be scoped - we learned the hard-way.
<kares[m]>
altought for a specific application it's usually okay to have the constants all in Object (global) scope.
<headius>
yeah scoping them is always a good idea to keep global namespaces clean
<headius>
If they are scoped in an easy to use namespace almost nothing needs to be global
<headius>
enebo: might be a evaluation order issue on master? This line of code fails with a NoMethodError for `ignored=` on nil, but that shouldn't be possible.
<headius>
`@spec.ignored = @ignored if @spec`
<headius>
not it is working... this might be concurrency related?
<headius>
s/not/now/
<headius>
the good news is that with custom net-http and strscan gems preinstalled locally, `Successfully installed rails-7.0.2.3`
<headius>
app almost generates correctly except that a call to `delegate` fails with what looks like probably a kwarg issue:
<enebo[m]>
Can you try with --dev to see if it still fails
<enebo[m]>
I just realized this case is not working in JIT but I am surprised I did not fix that
<headius>
It's unlikely this is getting jit compiled but I can give it a try
<headius>
I'm not sure how heavily this method is hit though so it's possible it does compile
<enebo[m]>
if anything passing it is jitted it might not be marking as key args
<enebo[m]>
anything passing arguments to it could also not be marking the value and it then thinks it is a normal arg
<enebo[m]>
So actual caller could be the bug too
<headius>
Oh that's a good point
<headius>
There's basically two or three levels where this might be a bug, in the collar, in the target method's delegation, or in the target method passing those delegated arguments onward
<enebo[m]>
I was fairly certain I marked kwargs in JIT when I did this work but the forwarding was a later fix
<headius>
Caller not collar
<enebo[m]>
HAHA collar really reads fun though
<enebo[m]>
If I was not in the know it sounds legit
<headius>
Bug in the collar
<enebo[m]>
I had some intermediate bugs after first working on this where I would forget to unmark a kwargs hash no longer a hash and it would decide it was not a normal argument
<headius>
FWIW, if you want to try this you just need to rake build the net-http gem from kares branch and the strscan gem from my branch
<headius>
By this I mean getting rails running
<headius>
Building and installing those gems should allow the main rails install to complete
<enebo[m]>
Attach your gems as a comment in a fist
<enebo[m]>
fist in the collar
<headius>
✊
<enebo[m]>
HAHA
<enebo[m]>
I should mention my personal hell of ripper since I have been silent a while
<headius>
This is pretty promising in any case
<enebo[m]>
It nearly works but there is some weird state management in def's that I need to work through
<headius>
The app fails a couple final rake tasks but mostly generates and bundles okay. It might actually start up and work, I didn't try it after it errored
<headius>
Light at the end of the tunnel eh?
<enebo[m]>
Once that works I have no idea but I decided I would rather solidify other problems and come back at that frech
<enebo[m]>
I think I am wearing myself down trying to force it to completion
<enebo[m]>
I fixed about 15 specs in last two days
<enebo[m]>
LOAD_PATH.resolve_feature_path
<enebo[m]>
I implemented this yesterday afternoon and we only have one strange thing where builtins will say the load is 'r' but then it will have no file associated with it
<headius>
Oh nice, I was hoping that would be easy to hook up since our logic is similar
<headius>
enebo: same error with --dev in JRUBY_OPTS
<byteit101[m]>
enebo: oh you are back! have you seen my messages regarding jrubyfx? was going to release it, but had questions and then you went MIA
<enebo[m]>
byteit101: heya
<enebo[m]>
I was desparately trying to finish a tough thing
<byteit101[m]>
enebo: yes, that's what I gathered
<byteit101[m]>
did you see the messages Ipinged you on or do you want a recap?
<enebo[m]>
I don't think it could be evaluation order since I never changed it yet
<enebo[m]>
and that is for masgn largely
<enebo[m]>
I saw the last one about putting constants into its own namespace
<enebo[m]>
which I agree with the others it will just eliminate a possible bug down the road
<enebo[m]>
I don't know the ramifications of how this works as an end-user though
<enebo[m]>
add-opens is a good idea but I don't recall how we do it for gems
<enebo[m]>
headius: If I install a gem how do I allow it to add add-opens? I remember the property file had some system to it
<headius>
There is nothing in place for that currently but the simplest way would be to update the module opts file in bin
<enebo[m]>
headius: ok
<enebo[m]>
byteit101: It would be nice to add-opens but it would be ad-hoc modification of bin/.jruby.java_opts
<enebo[m]>
headius: a blue sky idea would be to allow @{gem_name}:{version}/.jruby.java_opts and noop it it cannot fine it
<enebo[m]>
err wait I am not saying this right
<enebo[m]>
Actually I rescind this idea entirely because it requires loading gemsspecs to work
<enebo[m]>
byteit101: I think perhaps just instructions in readme or maybe even an echo on install saying "put the following crap in file bin/.jruby.java_opts"
<enebo[m]>
It would not be the only gem ever made which prints something out on installation
<enebo[m]>
but without a system to include/manage a section of that file from gems I am not sure it is worth the effort of writing something to magically do it
<enebo[m]>
That feels like something we should provide
<enebo[m]>
All of this is very soft since multiple gems may want to open the same module and we can probably duplicate those options but if you install n versions of the same gem do you just get this every increasing list of garbage
<enebo[m]>
The other thing before I run off 😃 We could also just add these modules as default opens like a few other packages we need. This is a bit of a slippery slope but we should consider it
<headius>
We could have a subdirectory of JVM option files and just tack them all onto the command line
<headius>
They just end up being @filename in the command line on 9+
<headius>
It has been on my list to investigate whether we can use module APIs at runtime to open additional things up. It may be possible if we give something in JRuby extra privileges
<headius>
The options directory might be easiest though
<headius>
It could even be an enhancement to the existing support that either sources the file or if it is a directory sources all the files within it
<enebo[m]>
but if you have 10 versions of jrubyfx installed do they all run?
<enebo[m]>
or do we just remove the versions
<enebo[m]>
and have one per gem
<byteit101[m]>
enebo: cool, I was initially thinking a wrapper script that just re-invokes jruby with the same args, but also add-opens
<byteit101[m]>
enebo: the includes are mostly for compatibility, as they are already in JRubyFX::Includes::BLAH
<byteit101[m]>
FXCollections was one of the errors when I removed that
<enebo[m]>
most people will just do it once and forget about it
<byteit101[m]>
hence why I felt like it could be the only one to stay
<enebo[m]>
we will think about how to make this a bit better in the future though
<enebo[m]>
java modules are not going away and other gems will have needs
<byteit101[m]>
yes, I was pondering that, but I'm busy with other things in the short term (beyond releasing jrubyfx 2.0, would like to get that out asap after we decide what to do about Fxcollections)
<enebo[m]>
Looks a bit ugly if you have to know to type that
<byteit101[m]>
could also use javafx.whateverpackage.Fxcollections
<enebo[m]>
All these included types are what exactly? Not all Jcomponents?
<enebo[m]>
jrubyfx.FxCollections
<enebo[m]>
def jrubyfx; module_which_includes; end
<enebo[m]>
then include jrubyfx could also work
<byteit101[m]>
that's swing, fxcollections mirrors collections but with observable. fxcolelctions.observablelist() etc
<enebo[m]>
So if you include JRubyFx it will provide this for your code
<enebo[m]>
since it will extend those as part of that
<byteit101[m]>
yes, this only affects demos and stuff outside classes like that collections demo
<enebo[m]>
So I am not sure this discussion needs more than telling people they should include JRubyFx into their own module if they do not want to risk a collision with another gem in the future
<enebo[m]>
And I don't know how likely that even is but I think conventrionally putting your code into a namespace is just a good generic Ruby practice
<enebo[m]>
We do this for JRuby's Java support itself since Ruby core and Java stdlib has some of the same names
<byteit101[m]>
Sounds good, I'll mention that in compatibility with 1.x then
<enebo[m]>
(java.lang.String vs String)
<enebo[m]>
ok cool. This sounds good. And some message on gem install for adding the add-opens
<byteit101[m]>
yes, my concern here was compatibility with previous versions, though obviously less pressing as 2.0
<enebo[m]>
yeah I agree
<enebo[m]>
going to start working on some dinner but it looks like these were the two questions
<byteit101[m]>
Yup. Hopefully I can release by this weekend