Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:00 reportable6 left 00:01 reportable6 joined 00:33 xiaomiao left 00:34 xiaomiao joined 01:03 MasterDuke joined 02:04 linkable6 left, evalable6 left 02:06 evalable6 joined, linkable6 joined 05:12 linkable6 left, evalable6 left 05:13 linkable6 joined 05:15 evalable6 joined 06:00 reportable6 left 06:02 reportable6 joined 07:12 squashable6 left 07:14 squashable6 joined 07:56 squashable6 left 07:58 squashable6 joined 08:00 eroux joined
lizmat is lazy 11:06
do we have a separate (strand) representation for a single character in MoarVM?
timo1 i don't think so 11:10
you mean when there's a single-grapheme strand in a stranded string, like what you get when you .join a string with "a" or something as the joiner? 11:11
lizmat I'm more thinking of the result of "foobar".comb
producing 6 single-grapheme strands 11:12
timo1 i've investigated something like that under the name in-situ storage in the past, but i don't think i ever finished it
well, that's a full mvmstring each time though right?
lizmat I guess it is, but should it be?
timo1 do you mean the strings that result from a .comb shouldn't reference the original string? 11:13
lizmat ah, they do?
timo1 if we create mvmstrings with the storage type "strand" then yes 11:14
lizmat ah, ok, so let's say I slurp a large file, then do a few .substr on that large string
the substrings would keep the whole file alive in memory then? 11:15
timo1 very possible
lizmat and I guess there's no way around that then
(thinking the IRC logs website specifically) 11:16
reading all the logs at startup to e.g. determine the different nicks seen
but having no interest in the whole file afterwards
and then reading files again afterwards for searches, and getting them in memory once again 11:17
timo1 that one storageoptimized or whatever it's called op that we have will turn a stranded string into a directly-as-array-stored string 11:19
lizmat but there's no HLL way to do that I guess 11:23
timo1 no, we treat it as an implementation detail
well, you can apply a regex to the string and that will do the storageoptimized thing 11:24
lizmat ah, indexingoptimized you mean
timo1 that's the one
lizmat hmmm,,, I guess it won't be possible to do the reverse: 11:25
as in telling a string that it should break all links with strings that are substrings of it 11:26
timo1 not easily
jnthn Well, the string doesn't know about the things that have substring'd it, the relationshipo goes the other way. You'd need to have the thing copied out in the first place 11:27
lizmat yeah, but that means keeping track, and if you forget one of the substrings, it will keep the large one alive 11:28
timo1 i think given that a strand has at the very least one pointer to the target string, plus the start / count / repetitions fields, it would often be cheaper to store short strings not as strands, ever
jnthn I think there may already be some heuristic like that, not sure. 11:29
timo1 quite possibly yeah
jnthn If you're building up a hash of unique nicks, though, then the first time you see one you could encode/decode to have it really detached, store that as the hash key. For the strings you get just to check if the thing exists, they're getting gc'd very soon anyway.
timo1 but nicknames from the irclog will often be longer than that threshold
lizmat jnthn: noted 11:30
jnthn Maybe `.substr` could get an adverb like :copy
To disable the reuse of the original string 11:31
lizmat which would do the encode/decode then for now?
:copy I mean
jnthn Since it's implemented in the setting it can use the nqp op
indexingoptimized or whatever it's called
Which will do away with any strands
lizmat ack 11:32
12:00 reportable6 left 12:01 reportable6 joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/06/19/2023-...llections/ 12:34
MasterDuke jnthn: speaking of strands and indexingoptimized, have you seen github.com/Raku/nqp/pull/803 ? afk for a bit, but should be back some later 13:32
13:50 linkable6 left, evalable6 left 13:52 linkable6 joined 13:53 evalable6 joined 18:00 reportable6 left 18:02 reportable6 joined 19:09 sena_kun joined 20:07 SmokeMachine left 20:08 SmokeMachine joined 20:09 rypervenche left, jnthn left 20:10 jnthn left, rypervenche joined 20:12 jnthn joined, coleman left, coleman joined 20:34 sena_kun left 23:22 squashable6 left 23:25 squashable6 joined 23:26 Techcable left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!