timotimo | good post indeed | 00:27 | |
jnthn++ | |||
02:56
ilbot3 joined
06:59
domidumont joined
07:04
domidumont joined
07:12
geospeck joined
08:06
Ven joined
08:10
brrt joined
09:07
brrt joined
09:08
zakharyas joined,
brrt joined
09:38
scovit joined
10:09
zakharyas joined
10:20
robertle joined
11:00
Ven joined
12:50
Ven joined
|
|||
dogbert2 | jnthn: should I report the CLOSE phaser test problem (valgrind screams) against MoarVM or Rakudo ? | 13:00 | |
dogbert2 leans towards MoarVM | |||
jnthn | Probably MoarVM | 13:21 | |
Though nothing new was added to MoarVM at all in the process of fixing the issue | |||
So it's not a new problem, just uncovering an existing one | |||
dogbert2 | agreed, timotimo suspected a missing MVMROOT | 13:29 | |
perhaps some part of the MoarVM codebase is exercised a bit more after your recent Rakudo fixes | 13:31 | ||
nine: did you ever create a PR for the list manipulation bug you found a few days ago? | 13:32 | ||
13:42
AlexDaniel joined
|
|||
dogbert2 | jnthn: github.com/MoarVM/MoarVM/issues/749 | 14:06 | |
14:24
zakharyas joined
|
|||
MasterDuke | jnthn: do you have any further thoughts/comments on github.com/MoarVM/MoarVM/pull/689 ? | 14:29 | |
14:29
zakharyas joined
14:45
brrt joined
|
|||
jnthn | MasterDuke: Will check it when I get a spare moment :) | 14:54 | |
MasterDuke | thanks, no particular hurry, just following up on stuff i have open | 14:55 | |
14:58
committable6 joined
15:18
domidumont joined
|
|||
MasterDuke | any particular reason MVM_STRING_MAX_STRANDS is only 64? | 15:35 | |
MVMStringBody.num_strands is an MVMuint16 | 15:36 | ||
jnthn | Yes, it's so we collapse them after a while | 15:43 | |
Otherwise, a repeated concat will end up copying an every-lengthening array of strands | |||
*ever-lengthening | |||
MasterDuke | heh, yep, just nearly locked up my computer after bumping that up to 32k | 15:45 | |
16:10
brrt joined
|
|||
MasterDuke | `if (a->body.storage_type == MVM_STRING_STRAND) fprintf(stderr, "last strand of a = |%s|\n", MVM_string_utf8_encode_C_string(tc, (a->body.storage.strands[a->body.num_strands - 1]).blob_string));` | 17:25 | |
^^^ should print just the last strand of `a`, right? | |||
timotimo | yeah; don't forget to MVM_free, though | 17:26 | |
MasterDuke | even when debugging? | ||
17:39
domidumont joined
|
|||
timotimo | what's a memory leak or two between friends ā¦ | 17:51 | |
MasterDuke | huh. string a = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | 18:12 | |
but the last strand of a = 'for (1, 10, 100) -> $limit {my $x; my $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - ENTER now}' | |||
guess i'm not taking the strand's start and end into account | 18:14 | ||
m: my $x; my $y = "x" x 10; $x ~= $y for (1..100_000); say now - INIT now | 18:30 | ||
camelia | 1.55922485 | ||
MasterDuke | m: my $x; my $y = "xxxxxxxxxx"; $x ~= $y for (1..100_000); say now - INIT now | 18:31 | |
camelia | 0.05816356 | ||
MasterDuke | heh. concat checks if the last strand of the lhs == the rhs, in which case it just bumps the repetitions. but in the first case the last strand is just "x", not "xxxxxxxxxx" | 18:35 | |
timotimo | because different repetition count? | ||
ugexe | The good news is the getppid() fix for windows landed in libuv for 1.16.1; the bad news is there is a regression on windows for shell I just noticed that is caused by the last bump to libuv v1.15.0 | ||
regression caused by github.com/libuv/libuv/commit/b21c...b8850ffd18 | |||
perl6 -e "say shell(q|echo 42|).exitcode" - causes this to only print 0 (the 42 never gets printed) | 18:36 | ||
MasterDuke | timotimo: well, because it's checking a strand vs the whole string | ||
ugexe | but seems like since its just a flag that it can be tweaked in moarvm possibly | ||
MasterDuke | so i don't think we ever concat strings by just += repetition, e.g., "a" x 3 ~ "a" x 4 -> "a" x 7 | 18:44 | |
but i wonder if that would be too much special casing to implement? `if (rhs->num_strands == 1 && last strand of lhs == first strand of rhs) result->body.storage.strands[lhs->body.num_strands - 1]).repetitions += rhs->body.storage.strands[0]).repetitions` | 18:51 | ||
18:57
geospeck joined
|
|||
MasterDuke | can there be a string of one strand where the strands start and end don't encompass the whole blob_string? | 19:11 | |
timotimo | that sounds just like a substr of another string? | 19:12 | |
MasterDuke | yeah, guess so | ||
timotimo | oh, i get why you're getting the source code as the strand there | ||
it's convinced the best way to represent "x" is to have it be a substring of the whole source code | 19:13 | ||
could that be it? | |||
MasterDuke | maybe. that would explain why when i took start and end into account it was fine | 19:14 | |
timotimo | right | 19:15 | |
one single character substr'd out of a huge string is kind of an edge case where i say we should build a buffer instead | 19:16 | ||
MasterDuke | huh. looks like there's no convenience function to extract a strand as a standalone string | ||
timotimo | additionally, at some point we'll want to store very short strings inside the pointer or something :) | ||
aye, strands don't normally have interesting semantic value | |||
MasterDuke | right, but it is annoying if i want to see if the "base" of one strand is equal to the "base" of another | 19:18 | |
timotimo | true that | 19:19 | |
MasterDuke | i've got to manually substring both strands | ||
timotimo | do we have an eqat that has a start point for both strings? | 19:20 | |
MasterDuke | don't think so | ||
there's MVM_string_equal_at, but it just takes two strings and a length | |||
s/length/offset/ | 19:21 | ||
afk for a bit | 19:22 | ||
19:36
dogbert17 joined
|
|||
dogbert17 | ZOFFLOP: t/spec/S10-packages/basic.t (test #83) | 19:37 | |
heh ww | 19:46 | ||
22:26
releasable6 joined
|
|||
Geth | MoarVM: MasterDuke17++ created pull request #750: Optimize MVM_string_concat when the RHS is a... |
23:25 |