<puritylake[m]>
It's marked as WIP so I can use that PR for the rest of the commits
<byteit101[m]>
Ah, I needed to call it "@name", not just "name"! Ok I have a prototype:
<byteit101[m]>
@var = 12, then java reads: 12
andrea[m] has joined #jruby
<byteit101[m]>
Hmm, should I make this be a part of FieldVariableAccessor, a subclass, or a MethodHandle/Binder thing?
<puritylake[m]>
-_- it was working fine now the error is back lol
<puritylake[m]>
Scratch that, I downloaded the main repo not my fork lol
<byteit101[m]>
Hah! java.lang.ClassCastException: Cannot cast org.jruby.RubyNil to java.lang.String
<byteit101[m]>
what should the property to configure ivar backing store in reified classes be called? `ivar_field_storage` sounds correct but too wierd
<headius>
Something weird and conspicuous so we will remember to change it before release 😀
<byteit101[m]>
surprised how easy methodhandler made this implementation, mostly
<byteit101[m]>
Still needs proper testing and some cleanup, but I opened a PR with a working implementation of storing ivars in raw reified fields: https://github.com/jruby/jruby/pull/7012
<kares[m]>
interesting, concept to treat `@ivar` with a java field backend - wonder about the Java<->Ruby conversion
<kares[m]>
seems like this is lowe leve stuff and I would pbly not want to do the auto conversion while reading a field - like in your example a Java string?
<enebo[m]>
kares: This also feels like it would be nice to choose somehow
<enebo[m]>
kares: optimize for how the data will be accessed most
<headius>
Good morning
<basshelal[m]>
headius: Any chance you can take a look at this and the PRs I reference in it.
<basshelal[m]>
I don't need you to pull anything, just need to know if its the right approach and if it's worth pursuing, I have so much more planned and will be working on it all for the forseeable future (months maybe) so I want to know now if I can do things better
<basshelal[m]>
Just need the assurance is all since it's a lot of time and work
<headius>
yeah definitely... just been heads down on 9.3.3 but I think the work for that is done
<basshelal[m]>
Awesome! I would really appreciate it, I know you're bogged down with JRuby stuff
<headius>
basshelal: wow great list
<headius>
if we turn that into a checklist can you still update it?
<headius>
some of these cases may exist in the various examples sprinkled around so we could adapt those as tests
<headius>
this is a good initiative though, and good tests will serve as good examples
<basshelal[m]>
I am updating it as I add PRs for each item, and as I go through I might add or remove items, I haven't planned it well super far ahead so it'll morph with time
<basshelal[m]>
Im more interested in the tests being a good spec
<basshelal[m]>
At the very end after everything is merged, I'll end up doing a cleanup for code reuse because I suspect I'll end up repeating some code because of splitting each item into a PR
<basshelal[m]>
But I have the OK then?
<headius>
yeah go for it and I will help where i can
<basshelal[m]>
Awesome! Thanks, really appreciate it, and I'll definitely nag when I need you 😁
<headius>
yeah and thank you, this needed to happen both for docs and for sanity-checking changes going forward
<basshelal[m]>
Absolutely! Glad to help
<headius>
enebo: so how are we looking
<enebo[m]>
headius: fine
<enebo[m]>
I haven't actually done any testing but I am unsure what we changed which will break anything. I will do that this afternoon
<puritylake[m]>
enebo: is the width part of a float specifier supposed to do anything>? I've tried it on regular ruby and it doesn't pad left or right
<puritylake[m]>
Even with a java example it didn't but it seems to say in C it should
<puritylake[m]>
Oh wait forgot width means the full string, sorry
<enebo[m]>
puritylake: also remember beyond just width of the value it also affects padding
<enebo[m]>
I was looking at sprintf this morning and I realized it is impossible for the Locale to ever be anything other than US
<enebo[m]>
It is in our codebase and the couple of things I looked in MRI appear to also just be US
<puritylake[m]>
Possible to fix that?
<enebo[m]>
puritylake: yeah. I just remove passing it around and storing a field for it
<enebo[m]>
puritylake: our code is just more generic I guess. When this was written I am asuming they figured Ruby provided some way to use your locale to display the '.' and whatever another locale wants the precision delimeter
<enebo[m]>
which I guess I have only seen ','
<enebo[m]>
Probably not from Ruby though :)
<puritylake[m]>
Getting close to finishing %f specifier also
<enebo[m]>
oh great!
<enebo[m]>
but %f is like in two parts right?
<enebo[m]>
if it can get num/den it will work but then it falls down in the bigger section for e,f,g,a
<puritylake[m]>
There is a g and a?
<puritylake[m]>
%e is for exponential representation
<enebo[m]>
a is not implemented in JRuby (yet)
<puritylake[m]>
%f has to handle Bignum too
<enebo[m]>
right below 'f' section is cases for 'eEgG' and commented out 'aA' but you will see if den/num in 'f' is not a value it falls through to that section (there is no break)
<enebo[m]>
So I am thinkign you almost finished this for Integer and Rational but not for Floats
<puritylake[m]>
Just for floats, my brain had "float" in my head so forgot those but an easy enough add
<puritylake[m]>
Testing would have messed up anyway
<enebo[m]>
I am excited for the various floating point formatting since we have not implemented a/A in years this will be a big reduction in failures in the main test suites
<puritylake[m]>
Ya, I'll get to them as soon as I cna
<puritylake[m]>
s/cna/can/
<enebo[m]>
yeah cool
<puritylake[m]>
I'm kinda excited to see my code being run by everyone who uses JRuby7
<headius>
guy trying to migrate to 9.3, the snapshots got him past M1 issues but some signatures you removed (deprecated for some time) are still in use by the "fishwife" extension
<headius>
well, just one signature we know of
<headius>
see my replies there, it was from your arity-killing PR
<enebo[m]>
yeah I tried to not kill public signatures
<enebo[m]>
that was poor phrasing...I tried not to eliminate anything with Arity that I thought anyone would use
<headius>
these were all deprecated for quite some time
<enebo[m]>
I actually remember doing it
<headius>
aha fishwife is a form of mizuno, a jetty wrapper for JRuby
<enebo[m]>
And I thought I left most public methods as deprecated
<headius>
fork not form
<enebo[m]>
"most"
<enebo[m]>
ok so maybe we can see what fishwife is missing and add them back if it is reasonable
<byteit101[m]>
> I would pbly not want to do the auto conversion while reading a field
<byteit101[m]>
yes, that's the tricky bit. I do have to make it be an IRubyObject, but is there a better way to marshall it through an IRO? (Planning on making it a bit more configurable)
<byteit101[m]>
kares: ^
<byteit101[m]>
I'm more concerned with the auto conversion on write, why are you more concerned about the reads?
kovyrin[m] has joined #jruby
<kovyrin[m]>
Hi, everyone! Wanted to bring this to your attention (seems like some internal API removed/changed some time between 9.2.16.0 and 9.3.3.0): https://github.com/dekellum/fishwife/issues/23.
<headius>
kovyrin: hello there!
<headius>
I have a PR that fixes the line in question but fishwife has a lot of old JRuby references in it
<headius>
the pom.xml for building the Java code uses JRuby 1.6.6 as a dependency
<headius>
I've got a patch compiling but building and testing fishwife needs updates to work
<enebo[m]>
So this does not hurt us in any way and we have so many deprecated methods. So I put in a note above it and when someone updates fishwife they can solve it
<kovyrin[m]>
I can update our vendored version of fishwife directly to use the new version of the method, so no rush there.
<enebo[m]>
I did not actually make sure fishwife works but this particular case should not be broken as arity for one arg is really simple and it will convert to proper signature
<kovyrin[m]>
Going to apply the patch and see if our app works. Will report in a few minutes.
<headius>
the Signature version of this API should go back pretty far, and the Arity version has been deprecated for almost as long I think
<enebo[m]>
kovyrin you may also try just try head of jruby-9.3 since I added back the deprecated method
<enebo[m]>
I think headius did the right thing in updating that gem but if you were using a released version of this gem I think it is likely to still work
<headius>
yeah doesn't seem like the gem has been updated in some time, which I guess is why you vendor it
<kovyrin[m]>
In our case we could not use the released version since we only use the servlet class from it and not the whole thing. So it is more like forking than vendoring.
<enebo[m]>
This is such a simple native extension
<enebo[m]>
I can see other problems on the horizon with createNativeRaiseException but those should still work
<enebo[m]>
oh I see
<headius>
I also got those on my compile
<headius>
[WARNING] /Users/headius/projects/fishwife/src/main/java/fishwife/IOUtil.java:[115,8] [deprecation] RuntimeHelpers in org.jruby.javasupport.util has been deprecated
<headius>
[WARNING] /Users/headius/projects/fishwife/src/main/java/fishwife/IOUtil.java:[204,18] [deprecation] createNativeRaiseException(Ruby,Throwable) in RaiseException has been deprecated
<headius>
[WARNING] /Users/headius/projects/fishwife/src/main/java/fishwife/IOUtil.java:[133,16] [deprecation] createNativeRaiseException(Ruby,Throwable) in RaiseException has been deprecated
<enebo[m]>
yeah I saw those when I was compiling
<enebo[m]>
The Java part of this is pretty small
<enebo[m]>
The Ruby part is smaller than I would expect but I can see how converting some of this to Java would be a help
<headius>
I can put together a PR for the gem just so it's out there but I can't get a full rake test to work due to some old http maven URLs somewhere in the support libraries
<headius>
rjack-whatever seems to be trying to use an http URL for maven but they force https now
<enebo[m]>
So in one direction we added back a deprecated method and in the other we are udpating the gem to have more modern artifacts and non-deprecated methods
<kovyrin[m]>
No problem, replaced it with `kind_of?` and it seems to work as expected (all specs pass). Trying out the final set of tests before declaring it all done.
<headius>
thanks so much for running through this with us
<kovyrin[m]>
No problem, thank you guys for all your efforts on Jruby and the recent M1 push in particular. I've been following it from afar and I know it wasn't fun.
<kovyrin[m]>
Ok, finished all my tests and everything seems to work perfectly! Hugest thanks to all of you for making it so easy. Now we'll be able to upgrade to the latest version and continue our development on M1 macs.
<headius>
Excellent! Ship it!
<byteit101[m]>
headius: When you get a chance, could you make sure the approach I took with the MethodHandle/Binder in the @ivar PR is workable before I spend time polishing that up?
<headius>
yeah cool, looking like we are in great shape for 9.3.3 so I will have a look through this tomorrow
<headius>
enebo: there are a number of PRs for 3.0/3.1 stuff, have you looked over them at all?
<headius>
I'm going to merge in the trivial ones as I look through them
<headius>
ok they were all trivial
<headius>
kovyrin: closing the loop on that missing method... we will have the signature restored, but still want to eliminate it at some point; you have it patched locally so no worries on your end; PR is submitted but who knows if it will ever get merged