jpsikorra has quit [Remote host closed the connection]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
nirvdrum has joined #jruby
shellac has joined #jruby
xardion has quit [Remote host closed the connection]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xardion has joined #jruby
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Client Quit]
<headius[m]>
hello again
<headius[m]>
jpsikorra: your patch looks fine to me... will chat with kares about it and see about a release
shellac has quit [Quit: Computer has gone to sleep.]
subbu is now known as subbu|lunch
<headius[m]>
enebo: you around?
<enebo[m]>
yes
<headius[m]>
I moved some jobs to github actions yesterday
<headius[m]>
all the Maven-based suites are running there, quite a bit quicker than Travis
<headius[m]>
shouldn't be difficult to expand this and move more jobs over but I wanted to see what you think
<enebo[m]>
yeah I saw that. I did not see how fast they were though
<headius[m]>
well the way it's set up you can run multiple steps against a single build... so it checks out and bootstraps once and then runs all the suites in sequence
<headius[m]>
the suites take under a minute each mostly
<headius[m]>
they are serial and if one fails they stop though so that's a down side
<headius[m]>
if you want parallel execution and no fail-fast you need to make separate builds
<enebo[m]>
from a pure use-case perspective having this tiny region to expand and then have that region take time to do weird rendering with a big CPU spike is not fun
<enebo[m]>
github does definitely iterate on stuff though
subbu is now known as subbu|afk
<headius[m]>
yeah I expect this will evolve quickly
<enebo[m]>
travis was far from perfect but in jobs like this I just smack raw download as I know it will guarantee I can see the bottom of the log
<headius[m]>
yeah
<enebo[m]>
It is not like actions is brand spanking new either but perhaps the number of people with large output jobs has not been a focus yet
<byteit101[m]>
enebo: I've been updating your java_signature_parser code (https://github.com/jruby/jruby/pull/6141) and was wondering why you decided to go with java_signature vs java_annotation? Should there be a difference as there is now? (see latest comment in that PR)
<enebo[m]>
byteit101: I do not really know. I do not recall the lineage of this or whether perhaps java_annotation came much later or not
<enebo[m]>
byteit101: The second syntax seems like it should work in both but annotations I think can work for more than just signatures
<enebo[m]>
Do they in this case? I don't remember
<byteit101[m]>
Fair enough, I see you did that almost a decade ago :-)
<byteit101[m]>
The second syntax errors in jrubyc as it outputs "@Deprecatedpublic void my_method()"
<byteit101[m]>
java_annotation in jrubyc can apply to java_field
<enebo[m]>
byteit101: I somewhat thought the signature parser came last
<byteit101[m]>
but not in become_java
<enebo[m]>
and anything before that was incapable of processing annotations
<enebo[m]>
but as you just pointed out this was done a long time ago so my memory of it may be wrong
<byteit101[m]>
Going forward should both styles work for all cases? or is there one to prefer and one to deprecate?
<enebo[m]>
java_annotation may work with fields?
<byteit101[m]>
with jrubyc it does
<byteit101[m]>
not with become_java though
<byteit101[m]>
(that's what I'm also implementing in that pr)
<enebo[m]>
yeah so I think it would not go away but not be rewuired if we can parse it out of the signature for signatures
<enebo[m]>
so recommended syntax would be the full signature with annotations inlined for both but that java_annotation is used for more than what the signature parser does?
<enebo[m]>
Or do we support field declarations in the parser?
<byteit101[m]>
I added field support
<enebo[m]>
oh ok well at some level then signature parser should work for all things and that seems reasonable to me
<byteit101[m]>
(didn't exist for b_j! before)
<enebo[m]>
but based on how old some consumer code that still works I suspect a very long tail on removing java_annotation
<enebo[m]>
yeah obviously for new behavior we do not want to retrofit anything
<byteit101[m]>
So: java_annotation 'Annotation1'; java_signature '@Annotation2 void mymethod()' should have both annotations in b_j! and jrubyc? And emit/note a warning on the java_annotation usage?
<enebo[m]>
damn...I feel this is a tough one
<enebo[m]>
If people want the same code to potentially compile via jrubyc and also reify via become_java! should the same syntax work
<enebo[m]>
I am just thinking about this mostly from a support aspect
<enebo[m]>
There are only two choices I guess
<enebo[m]>
a) warn b) support it
<byteit101[m]>
Would it be surprising that one way of making java classes has different methods than another way of making java classes?
<enebo[m]>
It would be if you used both features
<enebo[m]>
The warn route would at least give you a heads up that we have a more recommended way
<enebo[m]>
but if it errors but works one way and not the other then I guess they will just change it
<enebo[m]>
and this did not work before so it should not have happened in the past
<enebo[m]>
headius: quite a bit of read back but what do you think
<enebo[m]>
byteit101: I generally am on the side of whatever prevents an incoming issue report
<byteit101[m]>
Currently: java_annotation: jrubyc only. java_signature: become_java full support for arg-less annotations, jrubyc errors on any annotations
<enebo[m]>
there are multiple ways to do that though
<byteit101[m]>
currently: java_annotation+field: jrubyc only
<enebo[m]>
yeah so in theory anyone in the past would not be trying to use the same code for both things
<enebo[m]>
in the future if they do they should just use java_signature
<enebo[m]>
so those two things are truths I guess
<byteit101[m]>
and expand java_field to mirror annotation support for java_signature? (currently doesn't support annotations at all in b_j! case)
<enebo[m]>
yeah that seems reasonable
<enebo[m]>
then we have a consistent 'modern' set of methods
<enebo[m]>
The original notion of this parser was we could just copy+paste from javadocs
<enebo[m]>
It just never was the full all the crazy annotation stuff parser since annotation syntax is surprisingly weird and huge
<enebo[m]>
and also generics
<headius[m]>
I don't know if I consider the jrubyc java compilation to be a supported feature anymore really
<enebo[m]>
At this point I feel java_annotation should just error in a case it has never worked on
<headius[m]>
it was an interesting experiment but the lifecycle of the runtime behind those fakey Java classes makes it limited utility
<enebo[m]>
so we do still support it inasmuch as someone is using it
<enebo[m]>
so if we are going to remove it we should probably add something to jrubyc
<headius[m]>
to the larger question, I think the same syntax should work in both
<headius[m]>
they mostly generate the same sort of thing but there's lifecycle differences
<enebo[m]>
java_signature and java_field being full annotation aware seems fairly obivously right
<enebo[m]>
java_annotation should error where it has never worked is one answer since it already doesn't work
<enebo[m]>
but with a ncie error
<enebo[m]>
There was some pregenerated type I needed for Purugin and jrubyc at that time was a mechanism for making it a .java file
<enebo[m]>
I believe in the end I did not actually need it
<byteit101[m]>
Does jrubyc run the file? if so, I don't think there is a way to check for never working cases safely
<byteit101[m]>
enebo: I don't think I can error, only warn. It's conceivable that someone with jrubyc might have required jruby/core_ext indirectly, and then it would be confusing error messages