00:28 zakharyas joined 02:48 ilbot3 joined 05:06 mst joined 06:52 domidumont joined
Geth MoarVM/even-moar-jit: 33392bd235 | (Bart Wiegmans)++ | 2 files
Break reference cycles in ARGLIST compilation

It is possible for cycles to occur in moving values towards their call argument positions. In this case, we need to clear it in reverse order of dependencies, which is what we achieve by a stack.
Still todo: correctly spilling registers that 'survive' the call, correctly accounting for registers that are used by the call arg.		 06:58
MoarVM/even-moar-jit: 50508e0732 | (Bart Wiegmans)++ | 2 files
Implement ARGLIST/CALL conflict resolution

CALL may potentially use register values, which may conflict with the arguments used by ARGLIST, we have to move them out of the way prior to loading the ARGLIST values. Use a bitmap and (instrinic) find-first-set operations to efficiently find the conflicting register and a free spot. Will need to take care of potential CALL arg spilling; any values need to be inserted prior to the ARGLIST, which is a pretty good argument for merging CALL and ARGLIST.
06:58 brrt joined
brrt good * #moarvm
Geth MoarVM/even-moar-jit: 478224197f | (Bart Wiegmans)++ | src/jit/linear_scan.c
BitScanForward counts from 0

As per MSDN library, in contrast to FFS.		 07:18
07:44 brrt joined
samcv hello brrt 07:54
brrt hi samcv 07:56
Geth MoarVM/even-moar-jit: 56 commits pushed by (A. Sinan Unur)++, (Jan-Olof Hendig)++, (Jonathan Worthington)++, (Jeff Linahan)++, (Samantha McVey)++, (Timo Paulssen)++, (Daniel Green)++, (Moritz Lenz)++, (Stefan Seifert)++, (Lucas Buchala)++, (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/4...326ac8c789		 08:11
samcv 56! 08:28
oh you merged it huh
brrt yes 09:13
it's a merge commit
nwc10 good *, #moarvm 09:15
brrt ohai nwc10 09:55
in the continued spirit of rubberducking 09:56
i probably, nay, fairly surely, want to merge ARGLIST and CALL into a single node
well, that, or a single tile, at least
the simplest way to do that, would be to not output an ARGLIST tile at all 09:57
it's not necessary to be there
(the arglist can be indirectly gotten from the CALL, since the ARGLIST is the second parameter to the CALL
on the other hand.... 10:01
we kind of do want to distinguish between refs of the CALL itself, and refs of the ARGLIST
because the second we have to issue a load for, after spilling, and the first we don't 10:02
the real issue at hand is that we need to make sure that all register shuffles etc. are inserted *after* the loads for the CALL arg 10:04
nine When the same code handles the CALL and the ARGLIST, getting the order right is trivial, right? 10:10
brrt yeah 10:15
jnthn morning o/ 10:16
brrt well, loading the values before the CALL is done by insert_load_before_use, which uses the CALL as the reference tile, and the maximum order number of 1 (to mean 'just before the tile')
so i can start counting from 2 to order my new moves, and then i'll be good 10:17
jnthn Turns out if you introduce signal(SIGPIPE).tap: { say "SIGPIPE" } then it unbusts github.com/MoarVM/MoarVM/issues/547 10:34
(At the top of the script)
dogbert17_ cool
dogbert17_ sneaks away for an early lunch 10:36
Geth MoarVM: 2c5974bc11 | (Jonathan Worthington)++ | src/main.c
Ignore SIGPIPE by default.

We already handle (or should handle) various errors. This addresses issue #547, where a write to a process that does not exist would not break the Promise of the write, but instead cause the program to exit due to the SIGPIPE it received. This does not block users from adding their own SIGPIPE handler.		 10:53
MoarVM: b8861978d0 | (Jonathan Worthington)++ | src/main.c
Only call signal on non-Windows.
 11:07
nine -win 10-win 11
jnthn Don't think win11 is out yet :P
samcv jnthn, what does MVMROOT do? 11:08
jnthn Adds the location on the C stack holding a variable pointing to a MoarVM object to the temporary root set 11:11
Meaning that if GC occurs, then the variable will be updated
(Which the new address of the object)
samcv i'm gonna work on the ~~ m:i// problem rn 11:12
when does it need to be used?
jnthn Whenever you have any GC-managed object in a C variable, and you call code that might enter the garbage collector
Either by allocating a new object, blocking for I/O/sleep, or acquring a lock 11:13
samcv kk
jnthn samcv++ # looking at the m:i issue
jnthn is looking at github.com/MoarVM/MoarVM/issues/538 while he's in the area 11:16
I believe github.com/MoarVM/MoarVM/issues/547 is fixed, though seeing what Windows makes of the tests for that
OK, it passes those 11:17
samcv well I fixed that one RT, but broke all other matching with fc :P 11:28
because it depends on where in the string it got longer
Geth MoarVM: 249db32ed9 | (Jonathan Worthington)++ | src/io/procops.c
Only start readers if processed spawned OK.

This avoids a panic due to the task handle being used after release.		 11:36
11:36 lizmat joined
jnthn *process, d'oh 11:37
brrt jnthn, if on windows, can you try out something for me 11:44
i have a windows vm at home, but i couldn't get it to compile yesterday
jnthn brrt: Sure, what'd you like me to try? 11:45
brrt i want to see if i've wrapped the _BitScanForward intrinsic correctly
gist.github.com/bdw/92653ca6260e06...3f95fd833b 11:46
whether that, if compiled with MSVC, gives you the (1-offset) number of the first bit set
e.g. in 0b100, it ought to give you '3', in 0b101, it ought to give you 0 11:47
eh
give you 1, in the last case
i need that for efficient conflict resolution using a bitmap
also, it will give me your ssh private keys, if that's no problem 11:48
:-P
(it will work on gcc and clang, so far as I know) 11:49
dogbert17_ is back 11:50
jnthn, should I test something?
samcv jnthn, weird for MVM_string_equal_at_ignore_case i'm getting the offset as 115 even when both strings are 1 or 2 cp's long 11:58
Geth MoarVM: 8e292b8a06 | (Jonathan Worthington)++ | src/io/procops.c
Remove deprecated char-mode async proc reading.

At the VM level, we always do this in terms of bytes these days, and the language-level code manages the decoding. Removing it now to ease an upcoming fix.
MoarVM: 91aab714f8 | (Jonathan Worthington)++ | src/io/procops.c
Signal error to stdout/stderr on spawn failure.

So that the supplies that are on the receiving end of these will quit rather than just hang around.
samcv and obviously that's past the length of the string so it's probably why it's not matching it. or at least part of the reason. idk where it gets 115 from 11:59
jnthn dogbert17_: Could verify that the one I closed and the other one are fixed for you also...I pushed a test file to roast 12:02
brrt: heh heh...I read FFS something other than find first set :P 12:03
OK, seems 91aab714f8 fixes things up on windows too ;)
*:)
brrt: Um, some errors 12:05
samcv i'm not sure what is caling that mvm function. it doesn't seem to have a nqp op associated with it
maybe somewhere else in moar?
jnthn static inline ain't written like that 12:06
brrt oh
how ought it to be written
jnthn C:\consulting\MoarVM>ffs 50 12:07
50 2
C:\consulting\MoarVM>ffs 49
49 1
Checking
samcv jnthn, eqat_s is mapped to eqat, can i add a eqatic to map to eqatic_s
jnthn brrt: static __inline 12:08
brrt i think at least part of the problem is that MVMint32 isn't defined :-)
wait, what
jnthn Yeah, I already threw in a #define for that
brrt you're telling me that MSVC doesn't understand 'inline'
jnthn brrt: gist.github.com/jnthn/bdaf6aa21216...5e2555fee7 compiles 12:09
Lunch time here
samcv: Can help you hunt it down after lunch :)
bbi30
brrt thanks! :-)
have a good lunch
samcv i'm going to bed soon 12:10
but it just has to do with the offset changing when the grapheme number changes 12:11
Geth MoarVM/even-moar-jit: b6787d8a6c | (Bart Wiegmans)++ | src/jit/linear_scan.c
MSVC spells 'static inline' differently

So let's use the pre-existing macro for it.		 12:13
brrt jnthn++ by the way
that said. 12:18
we could be using macro-based compiler feature detection, a lot more than we are now
that could potentially make MoarVM more easily crosscompileable 12:19
dogbert17_ jnthn: both RT's (125651, 128526) now generate exceptions instead of exiting silently 12:39
also MoarVM 538 works better on Linux now, instead of a moarvm panic it now says 'caught exception X::AdHoc \n Unhandled exception in code scheduled on thread 3 \n no such file or directory' 12:42
the RT's on the other hand only say Promise broken, why that happened isn't mentioned but perhaps that is the way it should be? 12:43
jnthn back 12:49
Curious 12:52
Original exception: Died with X::AdHoc+{X::Promise::Broken} 12:53
That's LTA
Oh
No, something is decidedly up 12:54
dogbert17_ uh oh 13:04
jnthn We convey a decent error from MoarVM land at least 13:05
Ah, this looks better
For some reason we seem to ahve been duplicately .done/.quit-ing the stdout/stderr supplies too 13:06
Which got filtered out, but still, it's waste
Spectesing a rakudo patch now that should get the error in better shape
dogbert17_ nice 13:07
jnthn Pushed and done version bumps so we can run tests :) 13:17
dogbert17_ pulls ... 13:18
lizmat also 13:19
jnthn reproduced gist.github.com/dogbert17/037f464c...95fae63ed9 locally, fwiw 13:20
dogbert17_ oh :) so you're going after the interesting stuff now :) 13:22
lizmat, don't think harness6 will play ball just yet ... 13:23
jnthn 'Don't duplicately .done/.quit the stdout and stderr channels' were these called twice?
jnthn Yes, .done and .quit were already called 13:24
Geth MoarVM: ffd32f5313 | (Jonathan Worthington)++ | src/6model/reprs/Decoder.c
MVMROOT decoder when building string result.

An MVMString is a GC-able object, so fetching it may allocate, which in turn can cause the decoder to move. Thus the exit_single_user call could end up zeroing the wrong place.		 13:26
jnthn With that, we don't seem to trip it in the run I'm doing so far 13:28
dogbert17_ oO 13:31
we should let lizmat test your latest fix since that should improve harness6 (well at least a bit :-) 13:32
jnthn Well, unfortunately the bug was in the mechanism I added to detect concurrent mis-use 13:34
lizmat running with prove6 now, only got out of sequence errors in the uniprop test so far
jnthn So now we're back to seeing if it trips properly :S 13:35
dogbert17_ yep, will start running it in the background 13:39
jnthn Gah, I forgot to compile with debug symbols and got a harness6 segv, and of course now I've no symbols and what happens... 13:41
Ah,now got the mp_clear explosion again 13:42
Language class now; after will have a crack at it with rr-project.org/ 13:49
Aww...but I'm in a VM so seemingly don't have the required perf counters 'cus they ain't virtualized... :S 13:52
13:59 geekosaur joined
dogbert17_ jnthn: tested RT #125651 and RT #128526. Looks very good. Should be set to resolved :) 14:04
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125651
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128526
dogbert17_ jnthn: the example from MoarVM 547 still says 'Original exception: \n Died with X::AdHoc+{X::Promise::Broken}' though 14:15
14:22 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Only start readers if processed spawned OK. 14:22
travis-ci.org/MoarVM/MoarVM/builds/208939183 github.com/MoarVM/MoarVM/compare/b...9db32ed963
14:22 travis-ci left
timotimo i got myself rr now 14:48
what exactly are we trying it on now?
harness6?
dogbert17_ yes 14:49
timotimo let's see... 14:50
it's now rr-ing make it seems like m)
need to plug that in somewhere deep there
dogbert17_ I have run it three or four times already (i.e. spectest) in gdb. Not a single SEGV :(
timotimo i hope my 9 gigs of storage are enough. it's already reached 1.2gigs before it started any spec tests 14:51
nope, i better kill this and try it another way 14:52
dogbert17_ uh oh
timotimo no biggie, i can just trace it to my external usb hard drive that's almost 1tb free space 14:53
oh i forgot to set more test jobs this time 14:54
OK, the external hard drive is set as the tracing target 14:57
it'll be a bit slower, but at least it'll be enough space
dogbert17_ I got a SIGABORT, seems to be the bigint thingie 15:06
timotimo t/spec/S04-statement-modifiers/with.rakudo.moar - failed 2 tests 15:10
maybe i ought to update my rakudo before i try rr the next time
for some reason it's stopped growing at 2.5gb
i wonder if i can give jnthn a completed trace so he can inspect things? is that something that rr tries to do? 15:11
make traces compatible across different machines?
ah, still growing, but more slowly 15:12
dogbert17_ I wonder if I should have turned on jnthn's array debug support
timotimo also, it doesn't seem like it's really doing multiple tests in parallel?
okay, maybe a little bit
but even though i have 8 test jobs, it's not maxing out my CPU 15:13
emulates a single-core machine. So, parallel programs incur the slowdown of running on a single core. This is an inherent feature of the design. 15:19
fair enough 15:20
jnthn I wonder if I have access to anything I can run rr on...
Seems VirtualBox doesn't expose the hardware perf counters
timotimo can always buy a cheapo laptop from a discounter around the corner ;) 15:21
15:21 leedo joined
timotimo though i've heard that laptops that aren't thinkpads are kind of hit-and-miss with linux hardware support?! 15:21
jnthn I've got a linode I can try it on 15:27
brrt that depends a lot on what you want to do with it
timotimo hm, linode may also be "too" virtualized to do it 15:29
jnthn Aww, now I get errors about missing libc versions and stuff 15:30
And yeah, it likely is also 15:31
So won't sink too much time into that
dogbert17_ I got a SIGABORT,do you want a gist of it 15:32
timotimo github.com/mozilla/rr/wiki/Trace-Portability - just the question i was asking before
jnthn dogbert17_: Sure, can be interesting
dogbert17_: From spectest6, yes? 15:33
timotimo 7.4 GB by now
dogbert17_ make stresstest HARNESS_TYPE=6 TEST_JOBS=7
gist.github.com/dogbert17/b873fa5d...da0339f099
jnthn "VMware and KVM are known to work" 15:34
I think Linode uses KVM
timotimo cool 15:35
worth a try, then
jnthn Not if it's struggling with libc vesions :S
*versions
timotimo hmm 15:36
jnthn dogbert17_: Yeah, that looks like what I can often reproduce locally
dogbert17_ so, what more do you need :-) 15:37
I assume that the output doesn't give enough info
jnthn No, sadly it's not in the slightest clear why we end up with a corrupt P6bigint 15:39
dogbert17_ what can cause this, which I just got (spectest)
Unhandled exception in code scheduled on thread 11
No such method 'handle-entry' for invocant of type 'IterationBuffer'
in block at /home/dogbert/repos/rakudo/lib/TAP.pm6 (TAP) line 290
jnthn I believe that may be a separate issue; if it's in print-ruler or whatever it's called it may be spesh related 15:40
timotimo i wonder how much smaller the trace would be if i threw out the jit ... 15:41
dogbert17_ so there are at least two issues left
timotimo i've reached t/spec/integration!
jnthn timotimo: given we want it to crash that's...not so promising :P 15:44
timotimo yeah ;(
doesn't it usually crash very late into the spec test?
jnthn I've seen it anywhere
Early, middle, late
timotimo OK
jnthn Mine just blew in S32 15:45
timotimo is "tests out of sequence" a problem we want to look at?
t/spec/S15-unicode-information/uniprop.rakudo.moar (Wstat: 0 Tests: 161 Failed: 0)
Parse errors: Tests out of sequence. Found (29) but expected (27)
(plus another hundred lines)
Geth MoarVM/helgrind_support: 90e71ccfdd | (Timo Paulssen)++ | 3 files
annotate a few places for helgrind

hopefully cuts down on false-positives, but i haven't come up with a good way to actually test that yet!		 15:46
jnthn timotimo: I think IOninja was already looking in to that one
timotimo ok, cool
updating all my components now
jnthn The object it's trying to GC is really an Int, not something we mixed in to 15:47
So we can rule that part out
IOninja timotimo: that's caused by rt.perl.org/Ticket/Display.html?id...et-history 15:48
timotimo: it's a release blocker and I don't know how to fix it. So... have at it? :)
timotimo oh, damn 15:49
lizmat jnthn: fwiw, 4 runs of prove6, no segfault seen yet 15:52
jnthn lizmat: Lucky you, I get them almost every time 15:53
timotimo "lucky" :)
lizmat well, that means it just easier for you to debug :-) 15:54
timotimo oh! i had moarvm still with --optimize=0 15:55
i wonder if that's a good idea
jnthn I found one interesting thing examining the debug state 16:01
Which is that we were doing the gen2 freeing *after* marking a thread back to blocked rather than stolen
And that in theory means the thread could have started running again while another was freeing its gen2 still, and they'd race on the freelist 16:02
timotimo that'd be very bad :)
jnthn Done the simplest possible change to not do that 16:03
dogbert17_ is that change in master? 16:04
timotimo clearly not yet
dogbert17_ :-)
jnthn Just locally :)
Trying if it even helps us get through one local run
It still doesn't explain the rather spooky thing that everything we trip up on is an Int
16:04 geekosaur joined
timotimo yes, quite mysterious 16:05
jnthn Run 1 passed
But that's not enough to say anything
(Passed as in no SEGV; require.t fails due to bustage, and there's the unicode-information issue that's not the thing we're hunting here) 16:06
16:06 brrt joined
timotimo i could run more than one rr in parallel! 16:07
BBIAB
dogbert17_ so what you found was a bug but not necessarily the one we're after? 16:10
jnthn dogbert17_: Too early to say 16:11
dogbert17_ I'll wait :) 16:12
timotimo it is not advised to hold your breath at this time
jnthn Doing a third run at the moment 16:13
dogbert17_ jnthn, when you have time (RT's 125651 and 128526 can be set to resolved/closed) 16:28
Geth MoarVM: d4d9eb8ce1 | (Jonathan Worthington)++ | src/gc/orchestrate.c
Do gen2 sweep before letting stolen thread go.

Sweeping gen2 involves putting things onto a free list. Nursery sweeps are safe to do concurrently with the mutator running since there is no free list, just a now-unused fromspace that another thread is free to consider independently. However, gen2 sweeps manipulate a free list that is used to allocate, so the mutator runing at the same time would ... (6 more lines)
jnthn 4 successful runs, so sharing the commit for wider testing
RT #125651 closed 16:30
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125651
jnthn And now RT #128526 too 16:33
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128526
jnthn 5 completed harness6 runs now 16:36
dogbert17_ nice
jnthn That's the most I've ever seen
dogbert17_ where is lizmat when we need her :) 16:41
jnthn 6 fwiw :) 16:43
timotimo 6 is a good number 16:45
jnthn And the 7th was good too 16:51
Once I get to 10 I think I'll be satisfied :)
Especially if others can reproduce the improvement :) 16:52
timotimo this fixes what kind of failure now? the bigint explosion?
jnthn Yes
Well, none all of the failure modes we were seeing have recurred for me so far 16:53
timotimo that'd be pretty fantastic 16:54
jnthn Currently on run 9 16:57
Also may have a fix for another RT while was testing this out :) 16:58
timotimo rr is causing some tests to fail it seems like ... but the harness doesn't crash yet 17:00
of course it also takes quite a while to test all of this
jnthn Yup, 10 runs without a SEGV 17:11
Or any other kind of crash 17:12
Jsut the tests out of sequene one and require.t failing
timotimo ===( 0;4045 0/? 0/? 553/553 0/? 63/162 14/17 0/? 0/8)===fish: “env TEST_JOBS=8 _RR_TRACE_DIR=/…” terminated by signal SIGSEGV (Address boundary error) 17:13
cool!
wtf. 17:15
i "run" and "continue" and it says "program stopped."
the other one segfaulted, too! 17:16
timotimo builds new moarvm
i'll let it run in a while loop and see how often it succeeds 17:23
17:46 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'MVMROOT decoder when building string result. 17:46
travis-ci.org/MoarVM/MoarVM/builds/208968674 github.com/MoarVM/MoarVM/compare/9...d32f5313ba
17:46 travis-ci left
jnthn Bogus 17:48
dogbert17 is it LTA that the example from MoarVM 547 throws like this? 'Died with X::AdHoc+{X::Promise::Broken}' 17:52
18:02 domidumont joined 18:15 domidumont joined
timotimo 10 runs without trouble so far 18:21
18:28 vendethiel joined 18:45 agentzh joined
timotimo 21 successive successes 19:22
oh, wait 19:23
i tried to make it run as long as it doesn't crash
but the tests also fail, so my script should have immediately exited?!
jnthn heh :P
scripting fail :P
timotimo and of course my backscroll is only 1.8k lines
jnthn aww
timotimo in total, this day is one on which i'd like to flip every table in existence 19:24
and every table thas has ever existed, and every table that might ever exist in the future
TimToady avoids tables today 19:25
timotimo just imagine, carpenters in the future try building tables, but mysteriously they always end up flipped when they finish building them 19:26
moritz leading to an agile carpentry revolution, where unfinished tables are shipped to the customer before they get a chance to flip 19:42
timotimo yup 19:44
there'll always be a hole for a screw, but no screw
in every table around the world
TimToady that's overkill, all they really have to do is ship all new tables upside-down, and then everything works out 19:59
and we can ship all the old tables to Australia... 20:00
20:03 vendethiel joined 20:35 vendethiel- joined
jnthn will be very relieved if the spectest6 crashes really are all resolved by this fix 20:49
nwc10 well, it's still going round in circles
(That's a good thing)
jnthn :) 20:50
nwc10 hopes so too, because then it's a relatively small step to switching the default Rakudo harness to be 6
jnthn Aye
nwc10 IIRC that gets you parallel testing on Windows
er, "As I understand it"
jnthn Hm, I should try it on Windows :)
IOninja :)
nwc10 (I know why the Perl 5 harness can't do Windows)
(in parallel)
jnthn But yeah, in theory it should behave just the same on Windows 20:51
My $dayjob app that used to be Proc::Async-heavy worked just as well on Windows as on Linux, at least :) 20:52
lizmat is back 20:53
21:23 ggoebel joined
Geth MoarVM: samcv++ created pull request #548:
Fix string_equal_at_ignore_case when string `a` changes length		 21:37
samcv jnthn, let me know what you think of this PR. fixes the tests i have written using that op so at least all the ones i've written pass 21:38
if everything is fine, just tell me you approve and i'll merge it once spectest for roast comes back 21:39
jnthn Hmm...not quite sure about exposing eqatic at an nqp:: op off hand 22:10
'cus the ic is "integer constant" meaning it's a kinda wierd op; you can only give it a literal offset iirc 22:11
I'd probably declare the counter variable in the block where it's used
I'm a tad nervous about the termination of that while loop 22:13
(the one doing counter++)
Oh, I guess we know that they differ 22:14
Also, it doesn't MVMROOT a, but then accesses it 22:15
MasterDuke jnthn: don't want to distract you too much, but while you're reviewing PRs, have you looked at github.com/MoarVM/MoarVM/pull/546 ? 22:16
jnthn leaves comments 22:18
MasterDuke: Will take a look, though getting tired...
MasterDuke jnthn: no worries 22:19
samcv jnthn, the ic isn't `ignore case`? what?
jnthn Oh... 22:20
Yes, it is :D
hah
samcv heh
jnthn We did have an op that used ic for integer constant, I think :P
samcv jnthn, i don't get this "the foldcase if it expands to can never start off with the same first codepoint"? 22:22
i mean if the firstn cp is diffrent then counter ends up being value 0
jnthn Yes, what if the difference is at the end?
samcv you mean the very end? 22:23
jnthn if a is cccccC (where C is the codepoint that expands to 2 on foldcase)
samcv well tests i wrote pass
jnthn Then fca would become cccccXX (where XX is the expansion of C)
samcv i will add some extra just to double check
yeah i understand that
jnthn Well, XY
samcv what i wrote works for that too
jnthn Right, but it hinges on X != C 22:24
Which I'm pretty sure always must be true
But it's...not the most obvious loop termination condition :-)
22:24 Ven joined
samcv well it has to change, or else the length wouldn't change lol 22:24
jnthn Yes, I agree it'd be very odd if a codepoint being foldcase'd expanded to itself + another char 22:25
Because then fc(fc(x)) != fc(x)
And I'm pretty sure that identify holds
Anyway, I just get nervous about loops chugging through buffers where I don't immediately see why they terminate, is all :) 22:26
samcv ah k
jnthn I'm now convinced it's correct. It just wasn't obvious for a while *why* it was, so it may be worth a comment
samcv yeah of course. totally understandable
and even if it did expand to itself + another, it would still end the loop 22:27
it would just be off by one
jnthn Yes, but it'd be reading off the end of the buffer a then, potentially
Which could lead to SEGV
samcv i don't see why it'd be reading off the end, it would read up until they are different 22:28
jnthn Were it possible.
samcv yeah
jnthn Yeah but fca is longer than a
samcv oh i see what you're saying 22:29
:)
i will add an extra condition to make sure that can never happen
just to be safe 22:30
MasterDuke jnthn: replied to your comment 22:32
samcv jnthn, this patch is not perfect, but it should get us back to where we were before we changed it from lc to fc for certain characters 22:34
Geth MoarVM: beefd2b121 | (Daniel Green)++ | src/strings/ops.c
Check result of repeat/concat fit in an MVMString
MoarVM: dc40845b16 | (Jonathan Worthington)++ | src/strings/ops.c
Merge pull request #546 from MasterDuke17/add_checks_on_resulting_size_to_string_concatenating_and_repeating

Check result of repeat/concat fit in an MVMString
jnthn samcv: Yeah. Does my final comment make sense? 22:35
samcv yeah
MasterDuke jnthn++ it took me longer than it should have to get myself sure it wouldn't overflow, but by the end i was fairly confident 22:37
jnthn yeah, I shoulda looked a little more at the context :) 22:38
MasterDuke heh, i still haven't been able to reason out the mp_get_int64 business. i generally try to use Perl (5|6) to *avoid* thinking about the bittedness of my numbers! 22:44
samcv jnthn, i updated my PR github.com/MoarVM/MoarVM/pull/548 tell me if i MVMROOT'd correctly 22:47
jnthn MasterDuke: I'm afraid MoarVM is one of the places where we do a bunch of the thinking that lets others think less. ;-) 22:49
samcv: Hmm, github ain't showing me any updates :S 22:50
Still just shows the commit from an hour ago
samcv ok try now 22:51
jnthn samcv: Yeah, that MVMROOTing is right 22:58
samcv yay 23:02
jnthn Feel free to merge that PR once you're happy with it 23:07
jnthn is off to rest :)
'night
samcv thanks jnthn 23:10
23:29 geekosaur joined
samcv u: { .chr.fc.chars > 1 } 23:34
23:46 zakharyas joined 23:48 geekosaur joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!