<nirvdrum>
Outside of Rails, I'm not familiar with anyone using erubis.
<nirvdrum>
Granted, slim does collect string fragments into an array and then join the array.
<lopex>
and also, that's the case to actually use erv
<lopex>
*erb
<lopex>
why would you care given runtime makes it fast right ?
<nirvdrum>
Well, with something like slim, you're not really bound by STring#concat performance.
<nirvdrum>
Which is the point headius was making.
<lopex>
nirvdrum: but slim might change the strategy given ruby runtime if it;s worth
<lopex>
ppl will go adter it
<lopex>
*after
<lopex>
nirvdrum: why ? wrt concat
yfeldblum has joined #jruby
<nirvdrum>
Because it simply doesn't call it.
<lopex>
I'm a heavy slim user but I only server static outputs so I dont really care
<nirvdrum>
It does something like: buf = []; buf << '<head>'; buf << '<title>'; ...; buf.join("\n")
<lopex>
yes
<lopex>
nirvdrum: remember how ruby's String#join works ?
<lopex>
it first scans for to_str
<lopex>
just to guess the length of that joined buffer ahead
<nirvdrum>
Yes. But even if it's slow, it's called once rather than once per fragment.
<lopex>
right
<nirvdrum>
But, I still think there's a lot of legitimate ERB usages out there.
<nirvdrum>
Web was just the easiest thing to talk about.
<nirvdrum>
I can't recall if that came up in the Q&A or just Twitter.
<lopex>
nirvdrum: er +
<nirvdrum>
I've been meaning to look at AsciiDoctor more.
<lopex>
nirvdrum: I'm all sold for _
rcvalle has quit [Quit: rcvalle]
<lopex>
and then make it lazily to IO
<nirvdrum>
But I came back, was jetlagged and backlogged, then my sister's wedding, and then I caught a cold.
<lopex>
nirvdrum: never ever materialize the whole thing
<lopex>
nirvdrum: you think it;s doable ?
yfeldblum has quit [Remote host closed the connection]
<lopex>
given PE
<nirvdrum>
Well, JRuby needs to run on more than just Graal. I'm not sure to what degree HotSpot and Graal will differ.
<lopex>
hmm, you have an output (like rack)
<lopex>
the question is if that output must me and object
<lopex>
or, well, a + b + c >> socket
<nirvdrum>
I do believe a less radical move like storing clen in ByteList could yield some nice benefits without being as disruptive. Additionally, I'm a strong advocate of doing away with lazy code range scans. But, both require more work in RubyString.
<lopex>
that the situation right ?
<nirvdrum>
Tersely, I can model just about any string operation as an application of concat and substring. It might not be pretty, but the rules are simple and values propagate nicely.
<nirvdrum>
Sorry, I didn't quite follow the question.
<lopex>
PE should reassure nobody sees intermmediate "whole" string inbetween
yfeldblu_ has joined #jruby
<lopex>
let's assume we have a deeply nested rope to be sent over a socket
<lopex>
given ruby apis
<nirvdrum>
In the a + b + c case, we can either flatten the byte[] when called for or we can walk the tree and just use the array that we have.
<nirvdrum>
There are trade-offs.
<lopex>
nirvdrum: can you end up lazily walking the rope and writing to IO ?
<nirvdrum>
If you need the byte[] multiple times, building it up once and then storing it at the root could be advantageous.
<nirvdrum>
Walking the tree avoids duplicated byte copies.
<lopex>
the my point
<lopex>
yes
<nirvdrum>
Yes. We do both depending on the operation.
<nirvdrum>
It's heuristic-based where the heuristic is really my best guess.
<nirvdrum>
But it could naturally be smarter than that.
<lopex>
so ideally you'll never flattend the rope
<lopex>
in those cases
<nirvdrum>
Yes.
<lopex>
coool
<nirvdrum>
In others, you may want to flatten.
<lopex>
nirvdrum: hats off
<nirvdrum>
I do have a third case that I need to work out more.
<lopex>
nirvdrum: oh, since you're here, the case we discused with headius
<nirvdrum>
I think I mentioned it in the talk. I don't really recall. I have a byte[] reference in every node, even non-leaves. So, the nodes are really idempotent, not strictly immutable.
<lopex>
nirvdrum: once you have a stable (like in asession rope)
<nirvdrum>
But if the byte[] is written twice, it'd get the same results, so I'm okay with that.
<lopex>
nirvdrum: then you'd lke to flattend it right ?
<nirvdrum>
The problem with that cache is it still keeps the subtree around because child references are final.
<lopex>
nirvdrum: yeah, I watched the whole thing
<nirvdrum>
I haven't yet looked at the implications of relaxing that.
<lopex>
nirvdrum: it was really cool
<lopex>
yeah
<nirvdrum>
Immediately, your thread-safety guarantee is gone.
<lopex>
sure
<lopex>
nirvdrum: clojure has some really cool persistent trees
<lopex>
and really performant ones
<lopex>
same for vectors
<lopex>
and maps
<nirvdrum>
So, I think really you want to transition the node type at that point. And that requires a rethinking of it.
<nirvdrum>
The "string as a binary blob" case is still problematic. So, ropes aren't a panacea.
<lopex>
yeah
<nirvdrum>
I do think it helps bridge the gap between strings being mutable, but never modified, so they're effectively immutable.
<lopex>
nirvdrum: so virtualize ?
nicksieger has quit [Remote host closed the connection]
<lopex>
meaning change represnetation
<nirvdrum>
And based on the RubyKaigi Q&A, immutable strings will not be the default in Ruby 3.
<nirvdrum>
They don't want to pull a Python 3.
<lopex>
oh
<lopex>
hah
<nirvdrum>
Apparently uptake on that magic comment has been fairly low.
<nirvdrum>
And they're using that as a proxy vote.
<lopex>
python2/python3 is still like 50/50 ?
Aethenelle has joined #jruby
<nirvdrum>
I don't know what the split is.
<nirvdrum>
Both sides are substantial.
<nirvdrum>
bbiab. Dinner time.
<lopex>
very unlike ruby
<lopex>
but hey
<lopex>
you have graal and truffle and having []= is an issue ?
<lopex>
well
<lopex>
[Fixnum]=
<lopex>
I wonder if one could apply some deep learning wrt runtime profiles
<lopex>
the quick way might be to scan the sources (given limited ability to type propagate in ruby)
<lopex>
chrisseaton: but you've been looking at ruby corpus right ?
<lopex>
nirvdrum: I think ultimately we need real wolrd numbers for that []= thingy, one could optimize it in so many different means so we just need data ?
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lopex>
every datastructure obviously has pathological caes
<lopex>
but if one could pick up ones from the corpus (like interweaving substrings and []= in aloop would that make it easier ?)
<lopex>
chrisseaton: ^^
<lopex>
it doesnt have to be 100% reliable too
<lopex>
also the heuristices can be fed from the corpus
<lopex>
oh well, that' the whole point :{
<lopex>
enebo: !!
olle has quit [Ping timeout: 272 seconds]
<nirvdrum>
lopex: I think we can do a close enough approximation just by looking at I/O boundaries, using a local, private ByteList, and then promoting to a rope once stable.
<nirvdrum>
That's probably an oversimplification.
<lopex>
nirvdrum: but I thought you might really aggressively speculate on those
<lopex>
like
<lopex>
in rack you have "def write response ..."
<lopex>
thats the boundary right ?
<nirvdrum>
I mean reading.
<lopex>
oh I meant writing :P
<nirvdrum>
Writing really shouldn't need to worry about []=
<nirvdrum>
But, yeah, there's a lot of work left here.
<lopex>
right
<lopex>
yeah, given usage
<lopex>
yeah, since you pull a steam you;re goin to experience []= in cases
<lopex>
right
<lopex>
the blind short sighted thing is to depot to another structure
<lopex>
but I gather you;ve been through that
<nirvdrum>
I really haven't looked at it.
<lopex>
wrt writes on input from IO ?
<nirvdrum>
Just getting all the other string specs passing was a large enough effort.
<lopex>
oh hmm, isnt that the definition "writes on input on IO"
<lopex>
wrt problem
<lopex>
nirvdrum: anyways, the ropes are supercool, and you were right wrt familiarity issue
<lopex>
nirvdrum: sure we all know what trees are
<lopex>
just the usage
<nirvdrum>
What I was saying in the talk is if you do something like "\x00" * 1024 and then rewrite each byte, one at a time, that's going to build up a massive tree.
<nirvdrum>
And you incur the overhead of a node to represent what amounts to a single btye.
yfeldblu_ has quit [Remote host closed the connection]
Aethenelle has quit [Ping timeout: 244 seconds]
<lopex>
sure
<nirvdrum>
My point on the familiarity issue was more that Ruby strings are very similar to C strings. So, if that's all you've interacted with for the past 20 - 30 years, then seeing this tree is going to completely throw off your internal sense of how long operations should take.
<lopex>
nirvdrum: wrt repeatnode right ?
<lopex>
nirvdrum: the familiarity issue , as I understood was ( nobody gets what rope are) and really nobody gets it
<lopex>
nirvdrum: it's the very thing you were asked about from the audiance
<lopex>
nirvdrum: event from Ko1
<nirvdrum>
That's part of it. I was just saying that a downside to adopting them is there's a lot of tribal knowledge around how strings perform currently.
<nirvdrum>
You have things like the fast-ruby project telling people what methods they should be using.
<nirvdrum>
And if you use ropes, you turn all of that upside down.
<lopex>
sure
<lopex>
yeah, you make a revolution
<nirvdrum>
Even if ropes are better, you may have to retrain your engineers on how to reason about things *shrug*
<nirvdrum>
I guess having run a couple businesses, that's a risk I'd want to know about.
<lopex>
nirvdrum: dunny
<lopex>
nirvdrum: hey yourre entrepreneur
<lopex>
I'm not
<lopex>
nirvdrum: what I found weird is their negative response wrt ropes
<lopex>
them bein ko1 etc
<lopex>
enebo: !!
<lopex>
shite I'm dominating the channel
<lopex>
nirvdrum: somewhat it seems to be a political decision whether ropes etc
<lopex>
nirvdrum: I dont care
<lopex>
I'm all for it
<nirvdrum>
I think I misunderstood his question.
<nirvdrum>
tenderlove was explaining a bit more to me later.
<lopex>
like ?
<nirvdrum>
I think he was saying MRI has very long string methods and was wondering how ropes help with that, if at all.
<nirvdrum>
Whereas during the Q&A I thought he was asking how big the ropes code is.
<lopex>
I have no idea
<lopex>
probably would good
<lopex>
nirvdrum: doesnt make sens
<lopex>
nirvdrum: yea, I watched the thing
<lopex>
nobrained
<lopex>
nirvdrum: lie they are scared of anythung new
<lopex>
*like
<lopex>
who cares
<lopex>
"new need to run ruby code fast'
<lopex>
that's tje point
<lopex>
nirvdrum: but it might be lkie i was affraid of ropes
<lopex>
*like
<lopex>
who cares
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
deverly has joined #jruby
deverly has quit [Ping timeout: 264 seconds]
drbobbeaty has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Read error: Connection reset by peer]