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:07 reportable6 left, reportable6 joined 01:07 evalable6 left 01:09 evalable6 joined 01:21 linkable6 joined 01:39 frost joined 02:39 linkable6 left, evalable6 left 02:40 evalable6 joined
moon-child cu=1 seems suspicious as well 03:58
oh already mentioned
06:00 statisfiable6 left, coverable6 left, squashable6 left, evalable6 left, shareable6 left, releasable6 left, unicodable6 left, sourceable6 left, bisectable6 left, greppable6 left, tellable6 left, notable6 left, committable6 left, reportable6 left, nativecallable6 left, bloatable6 left, benchable6 left, quotable6 left 06:01 bisectable6 joined, unicodable6 joined, squashable6 joined 06:02 coverable6 joined 06:03 committable6 joined, sourceable6 joined, notable6 joined, greppable6 joined 07:01 evalable6 joined 07:02 statisfiable6 joined 07:03 nativecallable6 joined 07:41 [Coke] left, linkable6 joined 08:01 benchable6 joined 08:02 quotable6 joined, bloatable6 joined, releasable6 joined 08:03 tellable6 joined
MasterDuke fwiw, locally everything builds fine and a spectest doesn't report any problem with MI_SECURE set to 4 08:24
08:56 [Coke] joined 09:03 shareable6 joined
Geth MoarVM: MasterDuke17++ created pull request #1635:
Correctly free memory allocated by libuv		 09:30
10:03 linkable6 left, evalable6 left 10:06 evalable6 joined
Geth MoarVM: 781a479989 | (Daniel Green)++ | src/io/fileops.c
Correctly free memory allocated by libuv

Use the correct libuv function to do it. According to
  docs.libuv.org/en/v1.x/fs.html#c.uv...eq_cleanup "Cleanup request.
Must be called after a request is finished to deallocate any memory libuv might have allocated."		 10:08
MoarVM: 2cb8d1a84b | MasterDuke17++ (committed using GitHub Web editor) | src/io/fileops.c
Merge pull request #1635 from MasterDuke17/correctly_cleanup_after_libuv_functions
MoarVM: dogbert17++ created pull request #1636:
Update libuv to version 1.43.0		 10:17
MoarVM: MasterDuke17++ created pull request #1637:
Include stdbool.h instead of using our own defines		 10:21
11:05 linkable6 joined
Geth MoarVM: 01c3e8f54b | (Daniel Green)++ | src/debug/debugserver.c
Include stdbool.h instead of using our own defines
 11:17
MoarVM: 92b889186a | MasterDuke17++ (committed using GitHub Web editor) | src/debug/debugserver.c
Merge pull request #1637 from MasterDuke17/use_stdbool_in_debugserver
lizmat time for a MoarVM bump ? 11:20
MasterDuke eh, those are minor, mostly non-functional changes i was just pulling out from the mimalloc pr 11:23
no objection, i just probably wouldn't bother to do so myself right yet 11:24
11:24 RakuIRCLogger joined
lizmat well if there are no objections, I'd rather bump too many times than not enough, in the interest of bisectability 11:33
11:51 camelia left 11:55 camelia joined
nine m: 'say <alive>' 11:56
camelia WARNINGS for <tmp>:
Useless use of constant string "say <alive>" in sink context (line 1)
nine m: say <alive>
camelia alive
nine goes to fetch some coffee
dogbert11 nine: are you by any chance a build expert? 11:57
nine I wish :) 12:01
dogbert11 I just made a PR for libuv 1.43.0 but it fails on the Mac, see github.com/MoarVM/MoarVM/pull/1636 12:05
I guess my change to build/MakeFile.in was incorrect 12:06
MasterDuke dogbert11: just commented
dogbert11 MasterDuke++, I just tried to move it there and it works locally, should I amend the commit?
MasterDuke i'd rebase and force push, but yea 12:07
dogbert11 MasterDuke: my git fu is not up to par, whould I do a 'git pull --rebase' on my local branch? 12:16
*should
dogbert11 does know how to close a PR and create a new one but that's probably not the most optimal approach 12:18
12:21 camelia left, camelia joined
MasterDuke what i usually do is locally add a new commit with the change, git rebase -i HEAD~n, do a fixup or squash, then git push --force 12:29
it's what i just did with the mimalloc pr 12:30
dogbert11 let's se how badly I can mess this up :)
MasterDuke xkcd.com/1597/ 12:31
dogbert11 haha, I have done that many times 12:34
it ended with me doing the change, followed by an add and an amended commit followed by a forced push 12:36
what could go wrong :)
nine m: say <still here> 12:37
camelia (still here)
nine m: say dir "/tmp"
camelia Failed to get the directory contents of '/tmp': Failed to open dir: Permission denied
in block <unit> at <tmp> line 1
dogbert11 if this fails I'll do it the xkcd way
nine AppArmor++
Oh the irony: camelia's VM has been regularily running out of disk space because of old precomp files. The rebuild script (written in Perl) actually tried to delete them but failed because of a very Perlish bug: confusion between arrays and array references 12:40
MasterDuke doh 12:41
nine Fixed that, made the rebuild more robust, got rid of perlbrew and added AppArmor as an additional security layer. Thanks lizmat++ for asking about camelia security :)
12:44 camelia left, camelia joined
MasterDuke m: use Test; throws-like q|class {}.length|, Exception, message => /chars/    # ugh, trying to get rid of these `WARNING: unhandled Failure detected in DESTROY` 12:45
camelia ===SORRY!=== Error while compiling <tmp>
Failed to get the directory contents of '/home/camelia/.raku/dist': Failed to open dir: Permission denied
at <tmp>:1
MasterDuke m: say "hi" 12:46
camelia hi
MasterDuke m: use Test
camelia ===SORRY!=== Error while compiling <tmp>
Failed to get the directory contents of '/home/camelia/.raku/dist': Failed to open dir: Permission denied
at <tmp>:1
MasterDuke evalable6: use Test; throws-like q|class {}.length|, Exception, message => /chars/    # ugh, trying to get rid of these `WARNING: unhandled Failure detected in DESTROY`
evalable6 # Subtest: did we throws-like Exception?
1.…
MasterDuke, Full output: gist.github.com/dc1698f83c66a91350...75ecb504fb
nine m: use Test 12:48
camelia ( no output )
nine m: use Test; throws-like q|class {}.length|, Exception, message => /chars/
camelia # Subtest: did we throws-like Exception?
1..3
ok 1 - 'class {}.length' died
ok 2 - right exception type (Exception)
ok 3 - .message matches /chars/
WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, yo…		 12:49
lizmat wow, that's not a single one, that's very many of them 12:52
No such symbol '<anon|1>' 12:53
MasterDuke i think the actual source is github.com/rakudo/rakudo/blob/mast...kumod#L638 where the given code is EVALed 12:55
but i'm not sure. and haven't yet been able to fix anything 12:56
class {}.length   # where the '<anon|1>' comes from 12:57
m: class {}.length   # where the '<anon|1>' comes from
camelia No such method 'length' for invocant of type '<anon|1>'. Did you mean
any of these: 'chars', 'codes', 'elems'?
in block <unit> at <tmp> line 1
lizmat but why so many times? 12:58
MasterDuke that i don't know
m: use Test; throws-like q|Any.length|, Exception, message => /chars/    # ugh, trying to get rid of these `WARNING: unhandled Failure detected in DESTROY` 12:59
camelia # Subtest: did we throws-like Exception?
1..3
ok 1 - 'Any.length' died
ok 2 - right exception type (Exception)
ok 3 - .message matches /chars/
ok 1 - did we throws-like Exception?
MasterDuke that change would still keep the intent of the actual test, which tests that chars, elems, and codes are suggested, but graphs isn't 13:01
lizmat hmmm... I'd say Any.new.length 13:05
that Any.length throws that exception, could be considered a false friend? 13:06
m: Any.chars
camelia No such method 'chars' for invocant of type 'Any'. Did you mean
'chrs'?
in block <unit> at <tmp> line 1
MasterDuke `.length` is special-cased 13:07
lizmat yeah, I know... maybe *that* special casing should not suggest .chars on type objects, is what I'm saying 13:08
m: Any.chrs
camelia Cannot resolve caller chrs(Any:U); Routine does not have any candidates. Is only the proto defined?
in block <unit> at <tmp> line 1
MasterDuke ah
lizmat afk for a bit& 13:09
13:12 nine_ joined, camelia left 13:13 nine left
nine_ Those Failures are created by src/core.c/Exception.pm6:255 13:16
MasterDuke huh 13:17
nine_ I wonder why we try to look up a type by name when we also have the invocant at hand and can access its type directly
MasterDuke i think it's the container problem. sometimes the invocant is a different type than the name 13:18
m: my $a = "hi"; say $a.VAR.charss
evalable6 (exit code 1) No such method 'charss' for invoc…
MasterDuke, Full output: gist.github.com/b79d80291694e26030...b657b4bbba
MasterDuke i think i noticed that could happen when i was changing to that ^^^ message 13:19
13:20 camelia joined
nine_ We should still be able to pass the type as an additional argument shouldn't we? 13:20
MasterDuke i don't think i changed that part of the code, just wondered the same thing and added some prints
13:20 camelia left 13:21 camelia joined
MasterDuke m: my $a = "hi"; try say $a.VAR.charss; CATCH { default { dd $_ } } 13:21
camelia ( no output )
MasterDuke evalable6: my $a = "hi"; try say $a.VAR.charss; CATCH { default { dd $_ } }
evalable6
MasterDuke evalable6: my $a = "hi"; try { say $a.VAR.chars; CATCH { default { dd $_ } } } 13:23
evalable6 X::Method::NotFound.new(invocant => "hi", method => "chars", typename => "Scalar", private => Bool::False, addendum => Any, in-class-call => Bool::False, containerized => Bool::True)
MasterDuke hmm github.com/rakudo/rakudo/commit/d4...7566c39ca7 13:29
m: say class {}.length 14:00
camelia No such method 'length' for invocant of type '<anon|1>'. Did you mean
any of these: 'chars', 'codes', 'elems'?
in block <unit> at <tmp> line 1
MasterDuke you don't get the unhandled failures unless it's used in the throws-like 14:01
and the reason there are so many is because one is happening for each method it's testing as a suggestion here github.com/rakudo/rakudo/blob/mast...n.pm6#L255 14:03
m: use nqp; say nqp::can(::(1), "chars") 14:23
camelia 1
MasterDuke evalable6: use nqp; say nqp::can(::(1), "chars") 14:24
evalable6 1
MasterDuke huh, must be because of the way they run the code. if i run that locally with -e, i get `WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:
No such symbol '1'`
a simple fix is putting `.so` on the end of the `nqp::can()` 14:27
but i don't know if there's some underlying problem that should be fixed instead 14:33
nine_ Does putting .so onto the nqp::can actually fix the issue? 14:35
or even workaround, i.e. does it actually have any effect?
MasterDuke yes, in that i get the same stdout, but no WARNING... 14:36
nine_ That's quite odd I dare say. nqp::can's return value is 1 or 0 after all. Does --full-cleanup change anything? 14:37
MasterDuke if i run that example under gdb and break on MVM_exception_throw_adhoc, i get gist.github.com/MasterDuke17/3be85...42735e0e25
no change with --full-cleanup 14:38
nine_ Then I really don't understand this :) 14:39
14:50 frost left 14:52 vrurg left
MasterDuke oh interesting. if i put some note()s in find_symbol to print the parts of the @name, no more WARNING 14:53
nine_ Yeah, I think we just cannot rely on whether those WARNINGs show up or not 14:54
Geth MoarVM/master: 13 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/9...2bc4228b2c		 14:55
14:56 vrurg joined
MasterDuke any reason not to put the .so on the nqp::can() in Exception? 14:57
nine_ Can you explain why it appears to fix the issue? 14:58
MasterDuke nine_: src/6model/containers.c:695:5: warning: initialization of ‘void (*)(MVMThreadContext *, MVMObject *, MVMint64)’ {aka ‘void (*)(MVMThreadContext *, MVMObject *, long int)’} from incompatible pointer type ‘void (*)(MVMThreadContext *, MVMObject *, MVMuint64)’ {aka ‘void (*)(MVMThreadContext *, MVMObject *, long unsigned int)’} 15:06
[-Wincompatible-pointer-types]
  695 |     native_ref_store_u,
      |     ^~~~~~~~~~~~~~~~~~
src/6model/containers.c:695:5: note: (near initialization for ‘native_ref_spec.store_u’)
nine_ MasterDuke: that's the warning I mentioned in the review. 15:09
MasterDuke ah, right 15:11
15:31 linkable6 left, linkable6 joined
MasterDuke huh. the simple example with nqp::can doesn't show WARNING if i disable spesh, or run it under rr, but does under gdb 15:33
but i suspect it's not actually spesh, it just perturbs the execution enough to cause it 15:34
nine_ Same as I suspect from the .so 15:36
MasterDuke doesn't seem to happen with GC_DEBUG set to 3 15:37
nine_ I see 2 real fixes for that: 1. explicitly test the value we get from the lookup and defuse it if we get a Failure or 2. get rid of that indirect lookup entirely and have the caller also pass the type object. I'd very much prefer 2 15:38
MasterDuke but why does it only get the failure sometimes? 15:39
nine_ I think it does get the Failure every time. After all, how should it find an '<anon|1>'? It's just that the Failure doesn't always get garbage collected. Or rather that after GC its destructor doesn't always get called. 15:40
MasterDuke oh...yeah 15:41
nine_ Ah, yes, of course with --full-cleanup, it would get GCed all right, but we can't run destructors anymore during global cleanup
15:49 linkable6 left 15:52 linkable6 joined 16:48 linkable6 left 16:49 linkable6 joined
samcv japhb, I got a message from you 3 months ago. "If I concatenate two strings $a = ($b ~ $c), I know MoarVM will apply renormalization around the join point, but 1) Can this cause a change in any character left of the join point *other* than the very last character? 2) Is there a fast way to definitively tell by looking at $c whether renormalization will cross the boundary? 3) Are there any combining" . Good question. I think we test concatenation and 18:07
normalization properly. Unicode section about this is here www.unicode.org/reports/tr15/#Stab...ode_Points
But essentially we are able to check that sort of thing. I am pretty sure we do it properly. Hopefully. For reference this is what we should do "the implementation finds the last code point L with Quick_Check=YES and Canonical_Combining_Class=0 in the first string and the first code point F with Quick_Check=YES and Canonical_Combining_Class=0 in the second string. It then normalizes the range of code points starting from (and including) L to the code point 18:08
just before F."
lizmat samcv++ 18:10
japhb samcv: Thanks for the reply!
samcv now furiously double checks we do things correctly... 18:11
japhb Yeah, I needed to know what we guaranteed to make sure Terminal::LineEditor was doing the right things.
samcv But I think the core question is: is it only two graphemes that can become one grapheme along the border, or can more than two graphemes combine? 18:12
japhb As far as I could tell, at most one character to the left of the join point is affected, because when the left string ($b in that example) was created, any modifiers/diacritics/etc. would have already been applied to create a synthetic.
samcv I suspect no more than 2 graphemes can combine, I feel like I maybe checked this years ago. Unicode article is mostly mentioning on codepoint level, in which case there can be many codepoints turn into a single one 18:13
japhb samcv: Right. And I think the MoarVM code assumes the invariant I just mentioned.
Right.
(Oh, FWIW, I didn't need to care about the right side of the join point -- and I suspect that more than one could be involved there, because the right side could start with flag indicators or emoji combiners that (I think?) wouldn't have combined yet without their base character.) 18:18
18:19 linkable6 left
samcv Ok, it looks like we maybe do things correctly. I don't think we check the Quick_Check property. We do check canonical combining class though. We try and combine the graphemes, and if they combine we renormalize the whole string. 18:19
assuming that, plus checking CCC is as good as checking CCC and quickcheck, then we are safe
18:20 linkable6 joined 19:02 discord-raku-bot left 19:03 discord-raku-bot joined 20:01 reportable6 joined
Nicholas so the SEGV in NQP - don't try building NQP @ e4b9f4c9f003f5a39bad674042e9614cb3a8f327 with MoarVM on master 20:23
ie origin/fix_unsigned
on x64_64 with ASAN, the same combination aborts nqp with various unhappy diagnostic errors. (No SEGV)
which is a bit odd
MasterDuke these are unrelated to the mimalloc pr/branch, right? 20:24
Nicholas exactly
mimalloc is fine with nqp master
MasterDuke impressive results by graalvm eregon.me/blog/2022/01/06/benchmar...eruby.html 20:31
Nicholas I wanted to read "yjit-bench" as "yeet-bench" 20:37
MasterDuke cranelift might do well on that one 20:38
21:15 evalable6 left, linkable6 left, evalable6 joined 21:16 linkable6 joined
Geth MoarVM: 1b1b7d59e5 | (Samantha McVey)++ | tools/Generate-Collation-Data.raku
Change Generate-Collation-Data.raku to use raku binary

Also made a bit of the instructions more clear.		 22:31
MasterDuke samcv++ i've you've got some (a lot of) free time, github.com/MoarVM/MoarVM/pull/1520 is still an open question 22:33
samcv MasterDuke, I notice if I look at the description in S03 for OR ~^, it says "logically padding the shorter buffer with 0 values. returning a buffer sufficiently large to contain all non-zero integer results (which for XOR is at most the size of the longer of the two buffers)". It doesn't seem to make sense to special case the AND. I think we should return a string the same length as the longest string 23:05
It is true that it says ~& should give us the length of the shorter buffer: "returning a buffer sufficiently large to contain all non-zero integer results (which for AND is at most the size of the shorter of the two buffers).". I don't know if that is really a good thing. So I think we should have the ~^ and ~& match regarding the resulting string length 23:06
23:07 linkable6 left
MasterDuke what do you think about left vs right padding? 23:08
23:10 TempIRCLogger left, TempIRCLogger joined
samcv MasterDuke, I think it's definitely right padding we would want. One thing to note is that Perl5 does have the difference in functionality of the `&` and the `^` functions. So maybe that's where S03 gets it from. Though I'm not sure what other languages do there. 23:11
23:13 RakuIRCLogger left, RakuIRCLogger joined
samcv To be honest, string binary AND and binary OR seems like a Perly artifact.. Maybe we should look at other languages which have XOR or XAND builtin for buffers for example (I think maybe they won't have it by default for strings) 23:17
Or we could just do what perl5 does and what S03 says, have AND work differently than OR, pad on the right 23:18
MasterDuke that would likely have less roast fallout 23:19
samcv In the end I feel that it's a not heavily used feature. So it may make sense to just do what Perl5 does, given it's sort of a holdover from Perl5. With codepoints I think it's not very useful to do bitwise operations. 23:22
MasterDuke greppable6 is quite out of date at this point, but it only found two modules using ~^ (github.com/raku-community-modules/...t/HMAC.pm6 and github.com/tokuhirom/p6-WebSocket/.../Frame.pm)
and i don't think it found any using ~& 23:23
samcv m: say (Buf.new(1,2) ~& Buf.new(1,2,2))
camelia Buf:0x<01 02 00>
samcv FYI. Bitwise with buffers does the length of the longest buffer
MasterDuke or any using ~| 23:25
m: say (Buf.new(1,2) ~^ Buf.new(1,2,2))
camelia Buf:0x<00 00 02>
MasterDuke m: say (Buf.new(1,2) ~| Buf.new(1,2,2))
camelia Buf:0x<01 02 02>
samcv So, my opinion is now: ~& should be the length of the longest string. Even though ~& says differently, we should have ~& work similarly for bytes and for strings. Since the theory is that for strings we are converting to a 32 bit encoding and then doing bitwise operations on that. 23:27
I think the buffer version of things is more useful in general, and if that has been sufficient and not complained about for so long, it shouldn't hurt to do the same thing for strings 23:28
MasterDuke istr when i was last looking at this i noticed a problem that we are being a little fast-and-loose with codepoints vs graphemes in the iterator we use 23:29
but i'm a little hazy on the details, and am pretty sure i didn't have time to construct any problematic (if actually possible) examples 23:30
but thanks. it's too late today, but i'll go back over this log at some point and clarify the PR
oh, another option for ~& is to pad with 1s (i.e., just copy the remainder of the longer string) 23:32
but i do see how consistency with Buf would be good 23:33
looks like python, ruby, and javascript don't do bitwise operators on strings 23:37
Voldenet bitwise ops on strings make no sense in the first place 23:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!