headius has quit [*.net *.split]
DylanCamilleri[m has quit [*.net *.split]
lopex[m] has quit [*.net *.split]
genpaku has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
duane21[m] has quit [*.net *.split]
nilsding has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
razetime[m] has quit [*.net *.split]
satyanash has quit [*.net *.split]
sagax has quit [*.net *.split]
bastelfreak has quit [*.net *.split]
AndyMaleh[m] has quit [*.net *.split]
ahorek[m] has quit [*.net *.split]
distant[m] has quit [*.net *.split]
byteit101[m] has quit [*.net *.split]
PT[m]1 has quit [*.net *.split]
bastelfreak has joined #jruby
satyanash has joined #jruby
drbobbeaty has joined #jruby
headius has joined #jruby
DylanCamilleri[m has joined #jruby
lopex[m] has joined #jruby
genpaku has joined #jruby
yosafbridge has joined #jruby
PT[m]1 has joined #jruby
distant[m] has joined #jruby
byteit101[m] has joined #jruby
ahorek[m] has joined #jruby
AndyMaleh[m] has joined #jruby
enebo[m] has joined #jruby
razetime[m] has joined #jruby
sagax has joined #jruby
nilsding has joined #jruby
duane21[m] has joined #jruby
lopex[m] has quit [*.net *.split]
headius has quit [*.net *.split]
DylanCamilleri[m has quit [*.net *.split]
genpaku has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
duane21[m] has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
nilsding has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
razetime[m] has quit [*.net *.split]
satyanash has quit [*.net *.split]
sagax has quit [*.net *.split]
bastelfreak has quit [*.net *.split]
AndyMaleh[m] has quit [*.net *.split]
ahorek[m] has quit [*.net *.split]
distant[m] has quit [*.net *.split]
PT[m]1 has quit [*.net *.split]
byteit101[m] has quit [*.net *.split]
puritylake[m] has quit [Ping timeout: 255 seconds]
JasonMiller[m] has quit [Ping timeout: 255 seconds]
bastelfreak has joined #jruby
satyanash has joined #jruby
drbobbeaty has joined #jruby
yosafbridge has joined #jruby
genpaku has joined #jruby
sagax has joined #jruby
genpaku has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
satyanash has quit [*.net *.split]
sagax has quit [*.net *.split]
bastelfreak has quit [*.net *.split]
sagax has joined #jruby
yosafbridge has joined #jruby
satyanash has joined #jruby
genpaku has joined #jruby
bastelfreak has joined #jruby
drbobbeaty has joined #jruby
enebo[m] has joined #jruby
headius has joined #jruby
byteit101[m] has joined #jruby
JasonMiller[m] has joined #jruby
AndyMaleh[m] has joined #jruby
razetime[m] has joined #jruby
PT[m]1 has joined #jruby
DylanCamilleri[m has joined #jruby
lopex[m] has joined #jruby
ahorek[m] has joined #jruby
distant[m] has joined #jruby
duane21[m] has joined #jruby
puritylake[m] has joined #jruby
Successus has joined #jruby
kares[m] has joined #jruby
<kares[m]> yeah I thought so - just wasn't sure since you mentioned those.
<kares[m]> thanks for the thorough analysis - this is very useful to have some understanding of what's out there ...
<kares[m]> as noted the changed return might be off a concern (not sure whether how much it would matter), the foo= writers are just aliases at this point
nilsding has joined #jruby
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #jruby
razetime has joined #jruby
razetime has quit [Ping timeout: 252 seconds]
razetime has joined #jruby
<headius> good morning
<headius> kares: I think it is so rare that someone uses the method call form we'll be fine, and these are rather different than a simple attribute assignment anyway
<headius> upgraded psych on master for that snakeyaml CVE... a 3.3.x release for JRuby 9.3 will be coming soon
razetime has quit [Ping timeout: 244 seconds]
<razetime[m]> /leave
razetime has joined #jruby
<headius> woot that fiber leak is a fixed bug in CSV
<headius> honestly, using Enumerator#next just to get one line... not only awful for us, but actually inefficient on CRuby too
<headius> enebo: this one is interesting, maybe you have had your fingers in this code recently: https://github.com/jruby/jruby/issues/7344
<headius> when aliasing or changing visibility of a module method from the includee class, we get confused about where the super call is
<enebo[m]> yeah interesting
<enebo[m]> We also need to review https://github.com/jruby/jruby/pull/7343
razetime has quit [Remote host closed the connection]
subbu has joined #jruby
PT[m]1 has left #jruby [#jruby]
<headius> Ah yes
<byteit101[m]> kares: I can also review Boolean isFoo vs boolean isFoo, but I care less about that
<byteit101[m]> javap some.class is really slow, took my 8 core desktop over 24 hours to javap all ~2000 jars in my m2. is there some faster way to extract class method signatures without loading them?
<byteit101[m]> Or some way to scan all of maven central perhaps?
<headius> Where on earth did we ever see Boolean isFoo anyway? Must have been from pre-autoboxing code
<enebo[m]> can you have both?
<headius> No
<enebo[m]> ah I guess not
<enebo[m]> just remembered that
<headius> So it would be pretty weird
<enebo[m]> does it matter?
<enebo[m]> we just java2ruby all this stuff right?
<headius> This came up in the context of attribute assignment for a Java, because we don't recognize the capital b form as a JavaBean property
<enebo[m]> I mean we could add it or not but adding it for boolean and Boolean is just a detail right?
<headius> So it is just another case where we stayed strict to the JB spec and maybe it doesn't matter anymore
<enebo[m]> yeah meh
<headius> Yeah it's just a detail
<enebo[m]> I would say don't add that as it is not relevant and if someone does ever notice it we can add it later
<headius> Nobody's going to call us out for violating the spec, and probably nobody ever would have but it was our justification to reduce the number of bindings we created I think
<enebo[m]> we never signed on to the java bean alliance :)
<headius> Yeah I don't think it was reported by anybody but kares mentioned it
<enebo[m]> but I think we can safely ignore a case no one can find an example of
<headius> I still have my O'Reilly Java Bean book
<enebo[m]> I appreciate the due dilligence of kares on this but we should just pretend he didn't bring it up 🤣
<enebo[m]> headius: impressive. Earlier this year I got rid of like 80% of my tech books
<headius> Hardcore
<enebo[m]> weirdly I still have my stroustrup C++ book from the early 90s
<enebo[m]> That must be strangely useless now
<enebo[m]> Also I kept my college prolog book
<enebo[m]> but that probably has not changed
<headius> I might have that one
<headius> C++
<headius> I know I've got monster waffle's EJB book around here somewhere
<enebo[m]> I am EJB free now
<headius> I have to wonder who's building new apps with Java EE at this point
<headius> Sorry Jakarta EE
<enebo[m]> People who have been for the last few decades I suppose and won't quit
<headius> If only someone had taken EE and put a ruby front end on it
<enebo[m]> If you have a significant investment in it already it is simple to keep using it
<enebo[m]> I mean we have Java doing lots of syntax now (e.g. records) so if they had been more open to syntax back then we could have had a EJB language and not forced people to write zillions of boilerplate
<enebo[m]> but yeah Ruby could have pumped it all out in a simpler syntax
<headius> Torque box was ahead of its time
<enebo[m]> I guess we can blame Bracha a bit here
<byteit101[m]> I ask about the maven scanning as I was more curious about package names for the irb bug on package objects
<byteit101[m]> Quick scan of Boolean isFoo: Yes, lots.
<byteit101[m]> Jar: kubernetes-client has 5 classes with 5 methods (AutoAdaptableKubernetesClient.isAdaptable=>Boolean, BaseClient.isAdaptable=>Boolean, Client.isAdaptable=>Boolean, ExtensionAdapter.isAdaptable=>Boolean, ...)
<byteit101[m]> Those are interesting: Jar: svnkit has 5 classes with 5 methods (SVNJNAUtil.isExecutable=>Boolean, DebugProxyISVNCLibrary.isNull=>String, SVNLinuxUtil.isExecutable=>Boolean, SVNWCDb.isSwitched=>SwitchedInfo)
<byteit101[m]> Lots of asserts do void actually: Jar: shiro-lang has 1 classes with 6 methods (Assert.isTrue=>void)
<byteit101[m]> oh wait this is 1 arg isFoo
<byteit101[m]> but yes, I think I will ignore them for now :-D
<headius> So weird
<enebo[m]> unexpected
<enebo[m]> yeah I agree this is probably one of those things I would like to see if anynoe ever reports it
<headius> We've gotten maybe one report in the past 15 years
<enebo[m]> haha
<enebo[m]> byteit101: I do wish we could have an advanced search in maven to look for methods using some query language
<enebo[m]> I have wanted to do similar searches
<headius> Are we sure such a service doesn't already exist?
<enebo[m]> no :)
<enebo[m]> but I believe I tried looking years ago
<headius> It seems like the intelliJ folks would have set something like that up
<headius> Index the whole of Maven into some graph database so you can query for method signatures, call targets, callees
<enebo[m]> could be. I was doing something with noridoc when?
<enebo[m]> a long time ago I guess
<headius> Yeah exactly
<headius> The data is all there, it's just a matter of writing a front end for it
<enebo[m]> this is what you can do with search.maven.org
<headius> intelliJ has a structural search that I've never quite figured out but it's sort of an OQL query language against the loaded classes and libraries
<headius> Writ large that's what we want
<enebo[m]> yeah it is cool to do it for your stuff but I mean looking through whole repo for method call 'id' or 'hash' and stuff like that
<enebo[m]> Most of my curiousity has been around global considerations. Are people really using a method calls 'instance_methods'
<enebo[m]> our Java packages is a good use case for this type of info
<enebo[m]> perhaps we can not have OS or IRB explode
<headius> You'd index it a few different ways, like simple identifiers, method identifiers with fully qualified types, classes, classes instantiated with particular parameters
<enebo[m]> but you are right...we have this massive corpus where it is already parsed out for things like javadocs
<headius> If you normalize the crap out of it you could do some pretty complex queries but just a few giant tables would cover most searches
<enebo[m]> being able to query it is definitely doable
<enebo[m]> but has someone done this
<headius> There's javadoc.io but I don't think it stores any metadata about the libraries themselves
<headius> And it's on demand, it doesn't eagerly index libraries
<headius> It is one example of such a tool though
<byteit101[m]> Using only my local m2 repo's jars, here are packages and jars with names that are also on Object.new.methods:
<byteit101[m]> (trimmed to the first 10 jars)
<headius> Nice
<byteit101[m]> (I ignored com and org)
<byteit101[m]> I do like that jython groovy and jruby all make an appearance here though :-)
subbu has quit [Ping timeout: 260 seconds]
subbu has joined #jruby