AndyMaleh[m] has quit [Quit: You have been kicked for being idle]
pboling[m] has quit [Quit: You have been kicked for being idle]
<headius>
enebo: jcodings 1.0.56 finally released
<headius>
joni needs release also, on it
<headius>
hey lopex ahorek enebo and anyone else that wants to help... there's a backlog of issues in joni including one that claims we are much slower than calling out to onig via JNI and slower than some other port of onig (but mostly because they cache last result)... some PRs from 2015 that got missed and other issues
<headius>
anyone want to reevaluate issues and PRs that would be a great help
<lopex[m]>
I wonder if there's been major perf regression across versions
<lopex[m]>
I think it would help to check
<headius>
only major thing we've done in the past few years is interruption and we measured that as having only a small impact
<headius>
but we have not tracked perf over time
<lopex[m]>
they also claim java.util.regex is faster too
<lopex[m]>
but that's two moving targets
<headius>
yeah
<headius>
enebo: all merged and mostly green... couple jobs still using cached failure to find joni 2.1.42
<enebo[m]>
ok so we can spin this up. I see two ripper bugs posted since yesterday. I am just going to look at them quick in case they are super trivial
<enebo[m]>
I fixed this but in looking at it I probably have more work to do later. This seems reasonably safe since just assuming all identifiers get a null encoding is pretty wrong :)
<headius>
ÖöÖ
<enebo[m]>
I put a 7bit ident and it still will pass it as a utf-8 symbol so I guess this is an interesting difference in how ripper differs from parser
<headius>
Ok
<enebo[m]>
I am pretty sure a clean 7bit iident will be US-ASCII even if marked with difference coding
<headius>
~Ö~
<enebo[m]>
The second ripper issue is weirder. It is adding an error element in the sexp but in looking at it this seems to only be because it thinks we are in a method definition (narrator: we are not)
<enebo[m]>
I would have no confidence in a 5 minute fix for that
<headius>
We can toss another release out next month with some additional fixes
<enebo[m]>
So I wanted to pass off a goal and see how you feel
<headius>
Especially if we can tidy up some of these Joni issues
<enebo[m]>
I would like to get maintenance releases on a strict schedule
<enebo[m]>
we put out a release once every two months on closest monday
<headius>
Sounds great
<enebo[m]>
security releases being an exception
<enebo[m]>
Then if we get into that groove people will just know when we plan on getting the next round of fixes
<enebo[m]>
For 9.4 or any early release dev cycle this will not be held to the same standard for first couple of point releases depending on how many issues come in
<enebo[m]>
But even in that case it can be our intention to have a 2 month release cycle
<headius>
9.3 releases have been about two months between
<headius>
Give or take
<enebo[m]>
yeah I think it is close
<headius>
This one is just a few days over and January's 9.3.3 was a bit under
<enebo[m]>
but I think we may also have some more motivation to get items/issues finished sooner knowing we plan on releasing on a particular date
<headius>
But we knew there was a minor security issue and a regression so we did that soon after the holiday
<headius>
Yeah I'm on board
<enebo[m]>
ok cool
<headius>
9.3.5 would be just after railsconf at two months
<headius>
So we can concentrate on getting 9.4 out
<enebo[m]>
yeah
<enebo[m]>
I am really really really hoping to have ripper done this week
<headius>
there's another dozen or so fixes for minor things that didn't seem to warrant notes
<enebo[m]>
sure looks good
<byteit101[m]>
ivar release note phrasing is very good
<byteit101[m]>
I may steal that phrasing for the blog post
<byteit101[m]>
oh right, blog post. enebo: did you think of any other less-contrived examples of using java libraries than the ones in the draft you had issues with?
<headius>
be my guest
<headius>
I don't know if anyone actually uses javabeans anymore but the bean inspector could be used to make an example
<byteit101[m]>
(or anyone else)
<enebo[m]>
byteit101: sorry I didn't but I also forgot to think about it
<headius>
or would that require get/set methods?
<headius>
I forget, it was like 25 years ago I did anything with javabeans
<enebo[m]>
This was just that you extends java.lang.Object as an example of concrete extension right?
<byteit101[m]>
bean inspector? get/set is fine, the json example has get/sets
<byteit101[m]>
yes
<headius>
any data binding libraries maybe?
<byteit101[m]>
I have jackson for JSON, spring for construction, and jackson for annotations
<headius>
that all seems good to me
<headius>
spring dependency injection into fields that are then used as ivars from Ruby?
<byteit101[m]>
*jackson for fields
<byteit101[m]>
no, spring is just for newInstance construction, but I like that idea
<headius>
that would be hot but dunno if it is straightforward
<byteit101[m]>
would need to introduce a classloader
<enebo[m]>
Maybe MyComponent < javax.swing.JComponent or something along those lines
<headius>
ah true
<enebo[m]>
It is merely meant to be illustrative.
<headius>
yeah if it is too complicated I would skip it
<enebo[m]>
java.lang.Object as an example just is a bit lacklustre since it gets that extension by default
<headius>
jaxb used to be a thing but dunno anymore
<headius>
probably would also need classloader wrestliinig
<byteit101[m]>
I can't see using swing stuff except for the construction example, Fields and annotations I don't know how to use it
<headius>
yeah don't think it would really use those
<byteit101[m]>
I did consider jaxb, but used jackson instead
<headius>
that's just fine
<headius>
my 90s Java brain is pulling out all the hits
<enebo[m]>
So the extension also needs to be relevant to having fields but when are fields important for any Java API?
<enebo[m]>
It is just a pretty uncommon public exposure
<byteit101[m]>
class HammerTime ... :-D
<headius>
AOP? 🤮
<byteit101[m]>
the only thing I could think of was jackson/JSON/other serialization libraries
<enebo[m]>
I would say if there is not a good extension example then just remove the j.l.Object from your examples because it looks strange
<byteit101[m]>
or initialization librariers like spring, etc
<enebo[m]>
no Java programmer would ever do it and I think they will think you need to or something after seeing it
<byteit101[m]>
Ah, but jackson without j.l.O causes an infinite loop exception as it tries to serialize the RubyObject fields that are cyclical
<enebo[m]>
Oh!
<enebo[m]>
Is that a bug?
<byteit101[m]>
No, jackson catches it and tells you the fields
<headius>
oh
<headius>
interesting
<headius>
metaClass should probably be transient
<byteit101[m]>
^that;'s the one iirc
<headius>
that is an easy change
<enebo[m]>
Is that only an issue for jackson or is this a generic issue
<byteit101[m]>
anything that looks at all fields will encounter that
<byteit101[m]>
if it wants to do serialization
<enebo[m]>
so any reflection
<headius>
Java serialization can handle cycles because it is not dumping a hierarchical format
<headius>
so I theorize anyway
<byteit101[m]>
I looked at a few json libraries and realized it was just easier to use j.l.O to avoid excess fields
<byteit101[m]>
I bet yaml might work too, but that's not very java--y :-)
<byteit101[m]>
It's a very strange way to look at libraries asking: do you access fields? I wonder if there is any matrix of maven libraries and what java features they use
<headius>
it used to be done a lot more but modern libraries are more sanitary
<headius>
Tim Bray pointed out Android
<headius>
I wouldn't know how to set that up though... might be able to get some help from @donv
<headius>
"Spotless" code formatter mentioned but I don't see how that would work
<enebo[m]>
headius: I pushed all bits and maven seems to be visible
<enebo[m]>
I can push website as it is updated locally
<headius>
sweet
<enebo[m]>
I am going to push website then send out emails
<JasonLunn[m]>
Basically, the base class of all JRuby protobuf messages today implements method_missing in Java,
<JasonLunn[m]>
but doesn't override responds_to?
<JasonLunn[m]>
I thought it would be easy
<JasonLunn[m]>
But in my tests, sometimes my customized responds_to? method gets invoked
<JasonLunn[m]>
and sometimes it gets skipped
<JasonLunn[m]>
I looked at the JRuby codebase to check that I was using @JRubyMethod correctly
<JasonLunn[m]>
and I see that in some places, it uses frame=true
<JasonLunn[m]>
But it isn't clear from reading the description of that attribute when to turn it on
<JasonLunn[m]>
It's one of these situations where I wish we already had #6844
<JasonLunn[m]>
jumping back and forth between the ruby debugger and the Java debugger is not a good workflow
<headius>
I don't think frame should be necessary
<headius>
Implementing it alongside method_missing should do it
<headius>
I'll have a quick look
<JasonLunn[m]>
What's zany is that I'm finding that I can repeatedly construct objects that respond identically to my customized method_missing,
<JasonLunn[m]>
so I know that even though they're different classes that they're both getting their method_missing from my base class,
<JasonLunn[m]>
but I get differential behavior for their responds_to?
<headius>
Yeah that should work just adding respond_to? In roughly the same way as method_missing
<JasonLunn[m]>
Also observed - I get different implementations of responds_to? based on how many arguments I pass it
<JasonLunn[m]>
The single argument is the one I can't seem to override,
<headius>
Can you show me an example of how you are binding it?
<JasonLunn[m]>
but if i pass the optional second parameter, I get the one i've added
<headius>
Oh, perhaps you are not using the annotation?
<headius>
I think it has a couple overloads so you can override all overloads in Java or use the annotation and it will replace the superclass method defined in Ruby
<JasonLunn[m]>
public IRubyObject methodMissing(ThreadContext context, IRubyObject[] args) {
<JasonLunn[m]>
Do I need to use rest = true even though responds_to? only takes two args?
<headius>
This stuff has gotten complicated over the years and there's a different form now called respond_to_missing? but I would need to review if that is the correct thing to do
<headius>
No you could just have two arguments
<headius>
It will dispatch to the one argument or two argument form for one required and one optional
<headius>
It doesn't hurt anything but there's no three argument form