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
<headius> I am releasing as-is today
<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
<headius> ok
<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
<enebo[m]> It nearly will compile only to not run
<headius> ok I am back online
<headius> going to look at release notes
<headius> there's not a lot of big tickets here
<headius> obviously the java field stuff
<headius> I think that's the important ones
<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
<enebo[m]> I will also do github release
<headius> tweet's ready
<enebo[m]> sites live emails going out
<headius> looks good
<headius> tweet's live
<headius> awful link
<enebo[m]> github release is out
<headius> markdown seems to work better now on reddit so I put the release page in the post
<headius> I think that's everything
<headius> bgoetz suggested Velocity... amazing if that is still in use
<headius> byteit101: ^ as an example of reflective field access
<headius> perhaps not so relevant these days
<headius> enebo: two issues didn't get links in my notes for some reason: (#6831, #6963)
<headius> I must have spaced it out
<headius> fixed but it occurs to me we could use the same link list if you generated it like mine
<headius> Hibernate suggested as another field example
<byteit101[m]> Ah nice, I'll look at that twitter thread after work today
<headius> hmm it would be interesting to make this work with rack:
<headius> oh wat, it only does HEAD and GET?
<headius> ok nevermind
<headius> enebo: I see a bunch of low-hanging fruit in WIP specs
<enebo[m]> yeah especially in the smaller items like Method#to_s/inspect
<enebo[m]> It is mostly just adding some new missing output
<enebo[m]> I have backed off on some of those just because people like k7chii was doing a few each weekend
<headius> Encoding.list
<headius> - includes CESU-8 encoding
<headius> works with jcodings update thanks to ahorek
<enebo[m]> that is just jcodings being updates
<enebo[m]> hopefully that is fixed with that jar updated
<headius> TCPSocket#initialize spec hangs which is probably what gets killed on GHA
<enebo[m]> There are a lot more encoding errors in MRI from lack of udpate
<headius> TCPSocket#initialize with a running server connects to a server when passed connect_timeout argument
<headius> Example took longer than the configured timeout of 120.0s
<enebo[m]> some of those new keywords are a bit more work
<enebo[m]> but all the timeouts feel like they may also touch io scheduler too at some level
<headius> maybe
<headius> one of these versions added some DNS timeout stuff to connections
<headius> this may just be some timeout logic we are missing (if we can support it on JDK sockets at all)
<enebo[m]> yeah and quite a bit of refactoring to push it down
<enebo[m]> I did look briefly at tcpsocket timeout
<headius> I will try to have a look at this so we can do a full run of WIP
<headius> at least get it to fail rather than timeout and kill the run
<enebo[m]> before WIP we were seeing full runs
<enebo[m]> It would give results
<enebo[m]> So perhaps not running everything but it was at least producing a summary
<headius> not sure we included stdlib in that
<enebo[m]> we definitely had some stdlib
<enebo[m]> but not all of it but TCPSocket was in there for example
<headius> oh hmm
<headius> maybe this was tagged as hangs?
<enebo[m]> Maybe? It is definitely possible we are running more now or we just updated something which made things progress in the same spec file
<headius> hmm I only see the wip tag
<headius> wiplers
<enebo[m]> I got a case of the wiplers
<headius> 184)
<headius> TCPSocket#initialize with a running server connects to a server when passed connect_timeout argument ERROR
<headius> TypeError: no implicit conversion of Hash into String
<headius> partial impl lets it run now but the timeout is not honored
<headius> so it times out
<headius> this is from the last run before wip
<headius> post wip it now accepts the Hash but then does nothing with the timeout
<headius> so we can re-break it or finish it I guess
<enebo[m]> yeah
JasonLunn[m] has joined #jruby
<JasonLunn[m]> Is there any good reading to be had on overriding responds_to? from Java?
<headius> From Java? Can you elaborate?
<JasonLunn[m]> Sure -
<JasonLunn[m]> I'm working on fixing
<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]> @JRubyMethod(name="respond_to?", required = 1, optional = 1)
<JasonLunn[m]> public IRubyObject respondTo(ThreadContext context, IRubyObject [] args) {...}
<headius> Hmm that looks fine
<JasonLunn[m]> and then I tried explicitly adding:
<headius> It should bind a new respond_to? and dispatch one or two arguments to it
<JasonLunn[m]> @JRubyMethod(name="respond_to?", required = 1)
<JasonLunn[m]> public IRubyObject respondTo(ThreadContext context, IRubyObject name) {...}
<JasonLunn[m]> to try to get the single argument version
<headius> Does the method_missing work?
<JasonLunn[m]> The method missing works like a champ
<JasonLunn[m]> @JRubyMethod(name = "method_missing", rest = true)
<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
<byteit101[m]> is irb ctrl-c weirdless known?
<byteit101[m]> *weirdness
<byteit101[m]> (since at least 9.1, the oldest jruby I have installed)
<byteit101[m]> Ah, the footgun of the setter transformation only happening if the return type is void strikes again
<JasonLunn[m]> Is there a good `.java` reference to base off of for the purpose of a minimum repeatable failcase?
<JasonLunn[m]> I want to open an issue that is decoupled from the protobuf codebase
<JasonLunn[m]> But I'm snarled in trying to figure out how BasicLibraryService works.
<byteit101[m]> looking over the twitter answers, it looks like jackson is the best option with the least setup
<headius> Jason Lunn: there are a few gems that are good examples like psych I can try to find something and help more when I'm at my desk tomorrow
<JasonLunn[m]> I think I have it working finally. I must have messed something up in the naming scheme
<JasonLunn[m]> Opening the issue now
<byteit101[m]> I suppose this means I can release JRubyFX 2.0 now that is out (oh, the matrix header still says btw)
<headius> Oops