<headius[m]>
enebo: going to do a round of jnr releases today to get on latest asm and pull latest features
<enebo[m]1>
cool
<headius[m]>
trying to whittle away at 9.3 items
<enebo[m]1>
yeah I am going to try and stop on block stuff as I have made some progress but I could spend weeks on this
<enebo[m]1>
I have simplified the paths this round so it has been useful
<enebo[m]1>
Some minor reduction of work but definitely spreading of array to n-arity proc/normal stuff is consolidated a little more
<enebo[m]1>
probably by this afternoon I will look at **kwargs with no uses on caller side bug
<headius[m]>
yeah we can continue iterating on block dispatch paths, perhaps get closer to easy inlining and direct calls with indy
<enebo[m]1>
(which is related a little bit to that work although I suspect it will be nasty)
<headius[m]>
I got a few 9.3 issues closed late last week and then stumbled into the full modularization and wanted to see where we stand
<enebo[m]1>
for me I just want to be able to decompose all rules of binding from site to block params
<enebo[m]1>
it is getting much closer for me to the point I can probably be able to emit those as IR for inliner once we reconnect it
<headius[m]>
most libraries we depend on are now modular except dirgra... I added modularity to two of mine on Friday
<headius[m]>
yeah that would be excellent... too many call-outs and call-through paths that break inlining
<enebo[m]1>
At this point common yield vs specific yields are a little different. all calls are the same
<enebo[m]1>
the common yield has slightly inverted logic of the specific ones
<enebo[m]1>
specific ones are simpler than common since common can be anything at all
<enebo[m]1>
I would love to redo enumerable block stuff one day
<enebo[m]1>
It keeps getting rewritten but written on top of block logic which makes sense in the notion it is dispatching to a block but we contort so much to make it dispatch through our yield/call stuff in block. Like stuff in Enumerable where we have to impl yield and a doYield but then directly call it.
<headius[m]>
I would love to get rid of Java enumerable altogether
<headius[m]>
like today
<enebo[m]1>
I believe those are very specific because something else could call a different yield signature
<enebo[m]1>
I think though regardless of enumerable we internally do what enumerable does in several other classes and those may never be destined for Ruby impl
<headius[m]>
yeah fair enough
<headius[m]>
and we know from other impls that you can't actually implement Enumerable entirely correctly with standard Ruby semantics
<headius[m]>
both rbx and TR have to have special primitives for some parameter passing structures
<headius[m]>
feels like that should have been raised as a bug in CRuby years ago
<enebo[m]1>
yeah
<headius[m]>
enebo: this guy almost sounds like he would be on board with us unifying build and deploy for jnr-* and can help make that happen
<headius[m]>
I will monitor this and maybe we can push toward a single build deploy for all this stuff
<enebo[m]1>
sounds great
<headius[m]>
enebo: the jnr projects seem to get a lot of "question" issues so I am enabling GH discussions across all of them
<headius[m]>
I also enabled it for JRuby... dunno if we want to promote that as a way to communicate but we have no other "forum" anywhere
<headius[m]>
live chat is too big a leap for some folks
<enebo[m]1>
headius: ok. I guess we shall see how easy it will be to notice discussions as I feel GH is pretty bad and notifications
<headius[m]>
enebo: yeah ditto, I have that concern too
<headius[m]>
I have had to craft some search links I fire up every day to find updates
<headius[m]>
FYI only jnr-ffi, posix, enxio, unixsocket, and process need releases... just libs that depend on jnr-ffi
<headius[m]>
one thing we could chat about again is modularity and the jruby-dist
<headius[m]>
we have jruby-base now that will not shade anything but in order to be a good module citizen in the dist we should also not shade there
<headius[m]>
the jars should be copied to lib and added to classpath (8) or module-path (9)
<headius[m]>
there's no such thing as modules and shading at the same time as far as I can tell
<headius[m]>
or if we still want an uberjar then it needs to be relocating all those libs and rewriting the module dependency to point at our shaded packages
<headius[m]>
more complicated to be sure
<headius[m]>
will be an issue with -complete going forward too
<enebo[m]1>
hmm
<enebo[m]1>
For our main dist it is not really a huge deal to make a larger commandline from our launchers
<enebo[m]1>
So in that sense I think non-shaded is probably ok other than maybe us running into module conflicts but I assume that is the price of living in a proper module world
<enebo[m]1>
jruby-complete is ????
<headius[m]>
yeah I have not looked into what other libs are doing for their "complete" versions
<headius[m]>
this restriction of one module to one jar pretty much makes that impossible to do without breaking modularity
<enebo[m]1>
At one level they are two separate problems and we need not really consider them together unless we kill two birds with one stone
<headius[m]>
the jar inside dist right now is sort of halfway complete... all java stuff but none of the ruby stuff
<headius[m]>
it may be that complete really should relocate all APIs because otherwise I don't think it can ever live in the presence of those same libraries
<headius[m]>
which is a recipe for conflict right now anyway but it will run if they match
<headius[m]>
with modules it will hard error if the same package is in two modularized jars
<enebo[m]1>
yeah and even that idea to relocate all will be quite a challenge
<enebo[m]1>
if they depend on reflection etc...
<headius[m]>
shading does a decent job of detecting that but it is nowhere near perfect
<enebo[m]1>
ok another thing to consider for later javas is dumping joda?
<headius[m]>
yeah that could/should have happened in 9.3 but we need to cross that bridge soon
<headius[m]>
probably deprecate any public APIs right now that accept or return joda classes
<headius[m]>
and replace with versions that return new Java time
<headius[m]>
even if not using that internally
<headius[m]>
that really should be a 9.3 thing and it is not huge
<headius[m]>
I did try to make the conversion once and there are enough API diffs that it will be a bit of work
<headius[m]>
it is a much more "designed" API so there are not as many convenience methods
<headius[m]>
TFW you push all the releases to staging and then remember you didn't actually update any dependencies
<headius[m]>
Mondays amirite
<headius[m]>
enebo: hey if you want to crib off my modularity stuff look at headius/backport9
<headius[m]>
I have just been accepting that these have to build with 9 (for module-info) but the config I use ensures the actual library is compiled with 8 support
<headius[m]>
we will need dirgra modularized
<headius[m]>
I do wonder what potato they have the oss server running on at Sonatype
<headius[m]>
or if Nexus is just this slow
<enebo[m]1>
headius: yeah I will look at updating dirgra
<headius[m]>
it is frustrating that there are no good guides on directly converting between joda time and java time and back
<enebo[m]1>
So long as it is callable from Java we can just add it as a dep and maybe shade if we do not fully explode for dist and for compilete I guess we do shade
<headius[m]>
ah maybe I will job copy this... these are almost all one-liners
<enebo[m]1>
Ok well another thought is to just convert the methods we need
<headius[m]>
yeah
<enebo[m]1>
it is only 300 lines and 1/2 is boilerplate
<enebo[m]1>
we probably are only using 5-6 methods
<headius[m]>
I only need this now to provide non-deprecated versions of methods that use joda now
<headius[m]>
so in and out but still joda internally for all our stuff until we fully convert
<headius[m]>
nevermind everything about shading and deps... this has no maven coords