drbobbeaty has quit [Quit: Textual IRC Client: www.textualapp.com]
drbobbeaty has joined #jruby
<headius> enebo: any concerns about this one? https://github.com/jruby/jruby/pull/7167
<lopex[m]> why not use cow ?
<headius> we will potentially modify the bytelist, but deeper into code that does not have the RubyString anymore
<lopex[m]> oh, the bytelist is not cow aware
<headius> yeah
<headius> I wish it were
<headius> I want a COW bytelist and a fully immutable version
<headius> all these frozen strings could be full immutable bytelists with fewer fields and safety guarantees
<lopex[m]> once frozen strings are default symbols become obsolete right ?
<headius> for that matter, having an immutable RubyString type would be possibly even better
<headius> they are still separate but it is hard to say why
<lopex[m]> object_id ? still the same ?
<headius> frozen strings can even be interned into a deduplication set
<lopex[m]> leaks ?
<headius> both dedup strings and symbols are GCable now
<headius> so I dunno
<headius> it
<headius> it's still two stores in CRuby as well
<headius> the string contents for both may go into a common store though
<lopex[m]> I still dont understand how there's no symbol leak in mri
<lopex[m]> now
<headius> we are doing that I think... the RubyString is frozen and deduplicated and used as the string for the symbol
<headius> they just made the table weak
<lopex[m]> ah, but how do they make mapping to object_id deterministic ?
<headius> but most symbols get hard referenced elsewhere like in the bytecode or identifier tables (methods, constants)
<lopex[m]> hashing ?
<headius> they are doing what we do now I believe
<headius> so it is not predictable in all the cases it used to be
<lopex[m]> oh
<headius> object_id is allocated on the fly
<lopex[m]> doh, I wish I could help with jcodings btw
<headius> I give you permission to help
<lopex[m]> it's the last thing I remember quite well
<headius> yeah ahorek and others have been getting involved to help
<lopex[m]> good there;s almost no changes in onigmo
<headius> we're managing
<lopex[m]> yeah, I've been following the changes
<headius> we even picked up a few folks to assist with jnr
<lopex[m]> no hear from wmeissner since then ?
<headius> no, I even emailed the last address I had for him
<lopex[m]> afaik, he got pissed of by some policy
<headius> he changed a license on some project, maybe ffi/ffi, and everyone FREAKED OUT
<headius> rather than just talked through it
<headius> so he was just done
<lopex[m]> aaah, I recall now
<headius> you have to have a thick skin for this game
<headius> I've had so many people be incredibly rude and later apologetic when they realize how nasty they were
<headius> but if you take it at face value, I can see why people quit
<lopex[m]> heh
<lopex[m]> on another note I have a jruby app bases on sinatra and my framework that has "Up 10 months" uptime
<lopex[m]> and there's on minute based monitoring activities
<lopex[m]> the one that talks to as400
<lopex[m]> and the other thing is that I'll have to learn that whole cloud thing more now, not that it bores me to hell, but I dont have a hear for it
<lopex[m]> *heart
<headius> hah very nice
<lopex[m]> oh, polyglot maven isbeing maintained, nice
<headius> barey
<headius> barely
<headius> we need to get push rights so we can take it over and update everything
<lopex[m]> I dont recall if this wa this thread https://news.ycombinator.com/item?id=30812156 but someone claimed loom is not a thing for another few years
<headius> yeah I have not jumped on it because it is probably still a good ways out
<headius> we should still do a fiber impl on top of it for folks that want to try it
<lopex[m]> wrt polyglot, I must complain about gradle/kotlin etc, those are very inconsistent and lack any docs
<headius> the polyglot support for them? I am not surprised... they both have their own preferred tools
<lopex[m]> it ends up this absurds like properties.add(org.jooq.meta.jaxb.Property().withKey("defaultNameCase").withValue("lower"))
<lopex[m]> in kotlin/gradle
<lopex[m]> and good luck finding the docs/api
<lopex[m]> the maven model as bad as it is doesn need any additional funny changes
<lopex[m]> er, wrt polyglot, I meant switching into instead of using gradle
<lopex[m]> btw why enebo is so quiet ?
<headius> I think he's just taking a quiet week to work on finishing some major parser changes and probably just taking a break too
<headius> My kid is off school this week so I've only been about 50% myself
<lopex[m]> just out of being curious
<lopex[m]> if that's a proper phrase
<headius> Out of curiosity
<lopex[m]> ah
<lopex[m]> the only one ?
<headius> You can be curious about something or wonder, out of curiosity, something something
<lopex[m]> yeah, I should;ve use that one
<headius> Those are the forms I'm familiar with but I'm not sure where "out of curiosity" comes from
<lopex[m]> well being here was one of the few english channels for me
<headius> See, there's a good reason for you to come back and hang out with us more often
<lopex[m]> yeah, I'm following some parts of developement at least
<lopex[m]> even that env one got me asking
<lopex[m]> "P
<lopex[m]> but the plethora of like the string constructors is asking for some formal tool application to make any refactorings
<headius> Once we get 9.4 out I'm going to pivot to a bunch of heavy optimization work so that will be fun
<headius> There's so much of Ruby that we don't optimize at all right now like super calls and refinements and variable length argument lists or keyword args
<lopex[m]> and I'm little worried about any potential joni perf regressions
<headius> Need to start leveraging invoke dynamic call sites more to fast path key operations
<lopex[m]> and how's truffle team now btw ?
<headius> Yeah I'm a little worried about that too, we used to be clearly the fastest compared to Java's regular expressions and most of the other third-party libraries
<headius> I don't think anyone runs them in production yet but they keep on soldiering on
<headius> They have two regular expression engines, when they can use a finite automata they fall back on a truffle provided engine that optimizes like any truffle language
<lopex[m]> first part is new need good benchamrks
<lopex[m]> modern ones
<headius> Hard to compete with a DFA using a bytecoded engine
<headius> They have a collection of benchmarks but I think they're mostly tiny synthetic benchmarks like from the benchmarks game or small one-off library benchmarks
<headius> They lean very heavily into the benchmark game style benchmarks because they run for a long time with a static data set and optimize very well on truffle
<lopex[m]> but DFA is not applicale for general case nonetheless
<headius> Correct, and in that case they fall back on Joni
<lopex[m]> yeah, they just syntax check for regexp and decide
<lopex[m]> I guess ?
<headius> Yes
<headius> I think as long as you don't have backtracking in the regular expression you can use a DFA
<lopex[m]> also, I know we discussed this before, but if joni falled back to artificial stack for some threshold this could be a huge win
<headius> We still can try to generate JVM byte code for it too
<headius> But yeah anything where we could fall back for simpler expressions would be a big win
<headius> For the vast majority of regular expressions in a typical app we are creating an entire by code machine and recompiling the regular expression repeatedly to match like one thing
<headius> Entire bytecode machine
<headius> I tried reusing a machine by clearing it and resetting it but it wasn't a whole lot faster
<lopex[m]> yeah
<lopex[m]> simple cases would be totally inlined like what truffle does
<lopex[m]> like ab?[cd]
<byteit101[m]> (re the cow discussion above) I remember once googling for "CoW list", then immediately facepalming when I saw google listing the breeds of the animal
<byteit101[m]> enebo, when you are back: https://github.com/byteit101/JRubyFX-FXMLLoader/blob/master/lib/jrubyfx-fxmlloader.rb imports lots of stuff to the top level, hence one of the fails in jrubyfx. should I manually copy that list to jrubyfx or since this is 2.0 make people import that themselves, or should we load some subset (fxcollections seems reasonable to autoload)
<lopex[m]> series of conditions
<lopex[m]> I think is quit old
<headius> Lol eclipse compared to IntelliJ now
<headius> Funny thing, keeping a complete indexed model of your entire project in memory takes a little bit of space
<lopex[m]> intellij can be a surprise for a while
<lopex[m]> can be buggy
<lopex[m]> headius: I agree
<lopex[m]> eclipse is no more
<lopex[m]> but scala community uses https://scalameta.org/metals/
jimtng[m] has joined #jruby
<jimtng[m]> Hi, is there a page that tracks the progress towards Ruby3.x compatibility?