subbu has quit [Quit: Leaving]
subbu has joined #jruby
subbu has quit [Ping timeout: 252 seconds]
subbu has joined #jruby
subbu has quit [Quit: Leaving]
drbobbeaty has quit [Ping timeout: 252 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Ping timeout: 252 seconds]
drbobbeaty has joined #jruby
<headius> Good morning
<headius> I have been calling the herd each time we release
<headius> Culling
<headius> enebo: I'll have a look through the stuff marked for 9.2
<headius> er
<headius> not sure of the context because I confirmed the 1.3.8 native jar is published and contains the same stuff
<enebo[m]> headius: 9.3
<enebo[m]> We still have 17 open issues against 9.3.2.0 but we do we plan on moving all of them to 9.3.3.0
<headius> I haven't gotten to look through them just yet
<enebo[m]> I had my browser off to do some runs against new stftime
<headius> each time I have punted I have detargeted some stuff along the way
<headius> or moved to 9.4 as it made sense
<enebo[m]> ok. I looked a bit and nothing was obvious but with that said I am not sure how many will really be fixed
<headius> there are still a lot of like-to-have in there
<headius> dat native logger 👀
<headius> numbers look great for strftime though
<headius> need a nice bullet for this
<enebo[m]> the native logger is them juist noticing /dev/null and doing nothing
<headius> I wish GH had a mode where I can just "next" my way through an issue list
<enebo[m]> I switched to /dev/null because I thought it would fake it out
<headius> like JIRA does
<headius> hah
<headius> well that's silly
<enebo[m]> I could softlink /dev/null maybe
<headius> I suppose it is useful to someone
<enebo[m]> it is useful to anyone who only turns this stuff on for dev
<headius> benchmarkers
<headius> if you want to go through these issues with me maybe we can make some decisions
<headius> some are clearly bugs that we are just not jumping on fixing
<headius> I have admittedly tended to target user bug reports right away so we try to fix them, but the ones we can't or just don't fix accumulate
<headius> module issue with the new super logic
<headius> should be fixed, won't be soon
<enebo[m]> 2.6 issue can float since it is just a reminder
<headius> right I'll punt that now
<enebo[m]> meaning we bump it until done
<headius> I guess it is mostly the age old problem of how to know what to work on when there's 700 open issues
<headius> I target stuff because it is more recent or old but recently re-reported
<headius> the original issue was with io-console but it has been updated since to have a separate -java gem
<enebo[m]> This is more of an issue once we remove 8 as our flloor so we will hit it naturally once we get to that point (or someone complains)
<headius> the remaining issues in 6174 are documented in a separate bug about some core classes requiring .rb code from the filesystem
<headius> so I will close this
<enebo[m]> oh cool even better
<enebo[m]> I filed this and no one else has chimed in. So this is annoying but let's detarget since we know it is substantial too
<headius> the java 9+ issues should all get batched together because they're mostly the same work
<enebo[m]> We used to work with our wrapper but it broke in the newer m17n and windows not using native io
<headius> I will add a label for modules or something and move this to 9.4
<headius> since we'll definitely have to have those fixed for 9.5
<enebo[m]> ah yeah makes sense. I half wonder if we detarget refinements but also make a module
<enebo[m]> err a label
<headius> yeah that is not a bad idea
<headius> retargeting this for 9.3.3 since it is a PR with a fix but got lost in the noise: https://github.com/jruby/jruby/pull/6789
<headius> it is a minor tweak to bash script but someone needs to just try it in the prescribed environment to tweak the module search
<headius> also will tag with java modules label
<enebo[m]> I think unless you plan on working no this in the next month it is detargetted. I find that unlikely with 3.0 as a priority
<headius> punting this to 9.4 because nobody is responding and we will start using the updated ostruct gem in that version
<enebo[m]> There is a command-line/config workaround
<headius> so hard deadline to fix
<enebo[m]> sure
<headius> I added module label to that super issue
<headius> can detarget if you want, it was a byteit101 report so not from a user yet
<enebo[m]> If byteit101 wants to work on it but he said something a week or so ago about being really busy. He will get pinged so he can retarget if he is willing
<headius> marked with refinements label and detargeted
<headius> it is still broken fwiw
<enebo[m]> I think I am going to retroactively make a feature issue with results for the strftime so it can just be a line item in out issue list
<enebo[m]> yeah I also tried it this morning :)
<headius> ok
<enebo[m]> I was like "oh we changed something recently"
<enebo[m]> this has to do with copying I think
<enebo[m]> so it another form of teporal bug
<headius> oh that's right
<headius> I am copying the refinements rather than referencing them
<headius> I think my impl was based on an earlier version of the logic
<headius> perhaps something we fix along with other hierarchy logic changes in 3.0
<enebo[m]> yeah since there are I think some behavioral changes to refinements in 3.0 too
<enebo[m]> since we have to re-learn a bit it is a good opportunity to maybe fix both branches
<headius> may be an openssl issue since it is failing in a write there, but not many reports of problems
<headius> I can transfer to jruby-openssl and maybe we can figure it out there
<headius> I have not been able to reproduce pushing dummy gems
<headius> cool
<headius> I rebased that a while back but this is your baby
<enebo[m]> I did not until this morning decide to take Time.now out of the benchmark
<enebo[m]> I am willing to close this but I believe you also had another PR you thought would also work
<headius> added label for fibers (plenty of issues in this area) and detargeting Benoit's issue
<enebo[m]> ok and if you hit Fiber#raise (since it is a visible set of failing specs for 3.0) you probably will hit this
<headius> that is a pretty edge-casey issue anyway... fibers running in parallel after being forcibly terminated
<headius> like, as they shut down
<enebo[m]> well you might. #raise has to shut down the fiber
<headius> raise won't be any weirder than what we have now
<enebo[m]> the error messaging also needs to know more than if it is alive...we also need to know if they are born but not yet running
<headius> I already had to account for asynchronous raises in fibers
<headius> pretty sure we are the only impl with thread-based fibers who even tries to handle them right
<enebo[m]> I am going to release and push gem for 9.3.2.0
<enebo[m]> it takes time for maven to propagate
<enebo[m]> I found no issues testing yesterday
<headius> ok
<headius> I'm slowly reviewing issues
<headius> confirmed the version of IRB we ship does not show cause even for Ruby exceptions, so this is an IRB issue
<headius> we can't really make IRB show cause if it doesn't look at cause
<headius> going to check this on M1 quick because newer jffi may load better there now
<headius> heh, yeah that is probably long done... how did you get to that one?
<enebo[m]> I just randomly clicked on a page
<enebo[m]> I am updating website but we still need some release notes
<headius> 6813 does seem to work for me on M1
<headius> yeah you want notes or you want punts bro
<enebo[m]> notes the punts
<headius> 9 left open on 9.3
<enebo[m]> s/the/then
<enebo[m]> the punts stuff is just an ongoing activity too
<enebo[m]> Like looking back at our issues I can see we probably have a few dead issues in there
<enebo[m]> It is almost amusing after all these years we seem to always have ~600 issues open
<headius> load/require/FILE related issues marked with load/require label and detargeted
<headius> we have gobs of dead issues
<headius> I have not done a full triage for many years because it damn near killed me last time
<headius> it's a lot of work
<headius> marked kotlin issues with java integration label and detargeted
<headius> detargeted my not quite working URI glob PR
<headius> this looks like it could be finished if someone did a little footwork: https://github.com/jruby/jruby/pull/6444
<headius> that's the last one
<headius> I will look at notes now
<headius> you don't want a bullet for strftime then?
<enebo[m]> you already wrote up the security bit too
<enebo[m]> I definitely do
<headius> yeah you have my 9.3.1.1 security notes?
<headius> ok
<enebo[m]> I just also thought it should be an issue so it is something to be linked to
<headius> most of these fixes were to get GHA CI working
<headius> there's not much for callouts
<headius> I ain't got much else
<headius> the prepend thing touches several issues but it seems like a pretty small item
<enebo[m]> We maybe want to say something akin to: Short formats like "%Y-%m-%d" are ~5.8x faster while long strings like "%a, %d %b %Y %H:%M:%S.%9N" are ~3.5x faster.
<headius> yeah I figured some flourish would be nicer, go ahead and add whatever you like
<headius> it's your baby
<enebo[m]> Maybe just "(3.5->5.8x improvement)"
<enebo[m]> we have the links with results
<headius> "up to 8x improvement"
<enebo[m]> although the first link shows time including Time.now
<enebo[m]> HAHA add them!
<headius> should I link your gist?
<enebo[m]> naw. I put it into a comment in the feature
<headius> ok
<enebo[m]> I will just add that tiny bit of string into this
<headius> I read wrong and you didn't say 8x so use the right number 😀
<headius> updated that text a bit to say more about interruptible regexp
<headius> so use that
<headius> I will start preparing socials
<enebo[m]> ok
<headius> ready for the URL
<enebo[m]> ok. site and links look ok so I will push site and make GH release
<headius> docker is pushed
<enebo[m]> Site is live. Will do emails after GH is done
enebo has joined #jruby
ChanServ changed the topic of #jruby to: Get 9.3.2.0! http://jruby.org/ | http://wiki.jruby.org | http://logs.jruby.org/jruby/ | http://bugs.jruby.org | Paste at http://gist.github.com
enebo has left #jruby [#jruby]
<enebo[m]> GH release out and emails out
<headius> oh this text should be removed
<headius> This PR is the only functional difference from JRuby 9.3.1.0.
<headius> that was when I thought we were doing a 9.3.1.1
<headius> socials going out
<enebo[m]> fixed on site
<headius> I think we're all set
<headius> socials, docker, ruby installers done
<headius> we should do another release tomorrow, I'm getting the hang of this
<headius> I merged in the ruby-versions update (postmodern added me to repo yesterday) and the others are pending merge
<enebo[m]> haha
<enebo[m]> it could happen
<enebo[m]> I don't release on Friday's but I do want to be off next week
<headius> yeah be honest, you aren't gonna be working tomorrow
<headius> I probably won't either but I want to revisit the kwargs stuff before I start to forget the pieces
<enebo[m]> I do plan on workig on sprintf rewrite rest of week
<enebo[m]> I won't finish but I will get it further
<headius> hey why not, mo faster
<headius> and less eye bleeding when we maintain it later
<enebo[m]> it is already about 1/2 done
<headius> then comes the bytecode JIT
<headius> that ostruct issue is moving forward... Marc-Andre will modify it not to alias evals and such that we warn about
<headius> which will resolve that json warning issue we punted
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<enebo[m]> byteit101: The only one super is allowed in initialize is fine but split-point will not mean anything to anyone other than us
<enebo[m]> So perhaps 'Due to the complexity of deailing whth Java's ability to call super we have limited this feature to a single call. or something like that
<byteit101[m]> should I mention split-point in some other wiki page? I feel like it's an important architectural feature to mention for jruby hackers
<enebo[m]> well you can mention how it works but split point by itself is vague to me
<enebo[m]> I know what it means because I worked on it but I don't think anyone reading would understand that.
<byteit101[m]> * `super()` calls in the constructor (`initialize`, or whichever method is configured with `configure_java_class ctor_name: :your_custom_ctor_method_name`) must integrate with certain JVM features that are complex to expose to Ruby. As such, the Java restriction of exactly 0 or 1 `super` calls (with no conditional `super`s) applies at this time. Similarly, `self.to_java` is unusable before this super call. Ruby code before a super is valid,
<byteit101[m]> but not recommended.
<enebo[m]> byteit101: yeah that's a lot better
<enebo[m]> The basic issue with self.to_java is that it actually needs to access the constructed java object. Anything which has that requirement cannot happen before the super
<enebo[m]> Anything that would require access to what we would refer to as 'this' is not allowed until after the super call
<byteit101[m]> yea, I figured I'd mention that here, even though it isn't directly related to the restrictions
<enebo[m]> 'refer to as 'this' in Java'
<byteit101[m]> if (superCall != null) throw getManager().getRuntime().newRuntimeError("Found multiple supers in Java-calling constructor. See https://github.com/jruby/jruby/wiki/CallingJavaFromJRuby#subclassing-a-java-class");
<enebo[m]> nice!
sagax has quit [Ping timeout: 252 seconds]
<enebo[m]> merged...hopefully no syntax errors :)
<byteit101[m]> TBF I didn't even build or run it :-D
<enebo[m]> uh oh :)
<enebo[m]> It looks fine
<byteit101[m]> I think that was the fastest I've ever gotten a PR merged
<enebo[m]> haha
<headius> Bam