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:02 reportable6 left 00:04 reportable6 joined 00:22 patrickb left 00:23 patrickb joined 00:39 patrickb left 00:46 [Coke] left 01:46 [Coke] joined 03:49 quotable6 left, committable6 left, greppable6 left, linkable6 left, statisfiable6 left, squashable6 left, bloatable6 left, tellable6 left, notable6 left, unicodable6 left, bisectable6 left, benchable6 left, shareable6 left, releasable6 left, nativecallable6 left, sourceable6 left, evalable6 left, coverable6 left, reportable6 left, bisectable6 joined, sourceable6 joined, bloatable6 joined 03:50 reportable6 joined 03:51 evalable6 joined, tellable6 joined, notable6 joined, greppable6 joined, benchable6 joined 04:49 unicodable6 joined 04:50 statisfiable6 joined 04:51 nativecallable6 joined 05:09 Kaiepi left, Kaiepi joined 05:49 quotable6 joined 05:51 linkable6 joined 06:02 reportable6 left 06:04 reportable6 joined 06:50 coverable6 joined 06:52 committable6 joined, squashable6 joined
Nicholas good *able6, #moarvm 07:32
08:14 frost joined
nine And a gracious good * to you! 08:55
MasterDuke anyone have any thoughts/comments on github.com/MoarVM/MoarVM/pull/1617 and github.com/MoarVM/MoarVM/pull/1608 ?
or github.com/rakudo/rakudo/pull/4650 and github.com/rakudo/rakudo/pull/4651 ? 08:56
do we want to wait until after the release for some/all of them? 08:57
nine Personally I'd feel comfortable with #1617 merged before the release. The changes are very straight forward. #4650 probably as well as the changes are almost exclusively in exception reporting, i.e. when the program failed already. 09:25
PR #1608 feels to invasive for merging before the release. Probably also needs changes, as the magic number 3000 is not explained anywhere. 09:26
Btw. 1000000000e0 looks curious. After all the point of scientific notation is to not have those long chains of 0s. 09:30
MasterDuke yeah, that 3000 was copied from one of the first uses of alloca (github.com/MoarVM/MoarVM/commit/47...a2a807c6), but now that isn't being used more frequently maybe we should add a `#define MAX_ALLOCA_SIZE 3000` somewhere 09:31
s/isn't/it is/
nine The explanation for the number can be found in logs.liz.nl/moarvm/2017-10-03.html. Would be great if this makes it into a comment and/or git log 09:35
MasterDuke ah nice, i was looking for comments on the prior commits that did the alloca but didn't see any 09:37
nine /* XXX We need a fetch_u at some point. */ 09:41
MasterDuke nine: i just tacked 'e0' on the end to make the literal a Num
nine Indeed...and only 6 years later we're gonna get it
1e9 would have saved me the counting of 0s :D
MasterDuke heh. but then you'd still have to count the 0s in the integer literal to make sure they're the same value! though i guess could also do something like `my constant $num-nano-literal = 1e9; my constant $int-nano-literal = $num-nano-literal.Int; ` 09:45
Nicholas www.youtube.com/watch?v=ZB3HcyJfbG8 (I did not know that this existed) 09:47
Not a RickRoll - a RickRoll looks like this: www.youtube.com/watch?v=dQw4w9WgXcQ 09:48
MasterDuke i'll add a commit to github.com/MoarVM/MoarVM/pull/1608 with a #define and referencing the reasoning for the limit
nine MasterDuke: No I wouldn't have to count because I happen to know that a nano is a billionth and that a billion has 9 zeroes. 09:49
MasterDuke i thought a RickRoll looked like this archive.nerdist.com/rick-rolls-ric...day-table/ 09:50
huh, now i'm looking at those literals and wondering why i didn't put '_'s in, i usually do (at least for personal use) 09:51
speaking of counting, i was amused by a recent coincidence. i had heard a rant a little while ago about counting in French (e.g., why is there a name for 70, but 80 is 4x20?!). then my daughter was practicing counting past 20 and got to 29, paused, and said "twenty ten, twenty eleven, ..." 09:56
moon-child 'there is a name for 70' actually, 70 is sixty-ten!
MasterDuke guess what's intuitive just depends on what you already know 09:57
moon-child soixante-dix
MasterDuke oh, right. i do actually know that, just hurriedly picked a wrong example 09:58
moon-child :)
Nicholas Or if you're Belgian. Fastest link I could find is www.fluentu.com/blog/french/belgian-french/
MasterDuke nice. another reason to like the belgians 09:59
timo it's difficult to sing along with the counting since the stress is on unexpected syllables 10:00
Geth MoarVM: 5503065c6a | (Daniel Green)++ | 2 files
Alloca the nativecall args that we can

The memory for CPPStructs is passed on, so it has to be malloced.		 10:05
MoarVM: 83c53580a7 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1617 from MasterDuke17/fix_memory_leaks_in_nativecall_libffi_and_dynasm

Alloca the nativecall args that we can
jnthnwrthngtn moarning o/ 10:06
10:51 shareable6 joined
Nicholas \o 10:51
10:51 releasable6 joined 11:51 evalable6 left, linkable6 left 12:03 reportable6 left 12:52 linkable6 joined 13:04 reportable6 joined 13:17 rypervenche left 13:22 rypervenche joined 13:25 Kaipi joined 13:27 Kaiepi left 14:23 patrickb joined 14:28 vrurg_ joined 14:30 vrurg left 14:54 evalable6 joined
nine One of the last spect test failures I get is nqp::bindpos_u(to, $i, from.AT-POS($j = ($j + 1) % $values)) blowing up, because `from` is a signed intarray, AT-POS returns an IntPosRef and but we codegen a decont_u on that instead of a decont_i, because the target requires a uint register 15:25
jnthnwrthngtn Arguably an explicit conversion is a good thing there... 15:36
But if there's a test already that's maybe awkward
I assume the test isn't actually doing _u? Can we have int and uint candidates and decide on the lex ref type, and one can do the conversion? 15:37
16:01 evalable6 left, linkable6 left 16:22 vrurg joined, vrurg_ left
nine Problem is that the only place where we have information about the required type and the data type is MVM_VMArray_at_pos. Codegen doesn't know the result of the AT-POS. MVM_6model_container_decont_u, native_ref_fetch_u and MVM_nativeref_read_positional_u don't know what slot type the array has 16:27
Of course MVM_VMArray_at_pos can do the coercion easily. But this is also the place where all those helpful error messages come from that let me do the other fixes. Can't have both :/ 16:29
jnthnwrthngtn What is the actual code that you golfed the nqp::op version from? 16:30
16:30 patrickz joined
jnthnwrthngtn m: my int $x = 2.5 16:30
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot assign a literal of type Rat (2.5) to a native variable of type int. You can declare the variable to be of type Real, or try to coerce the value with 2.5.Int or Int(2.5)
at <tmp>:1
------> 3…
16:30 patrickb left
nine Haven't committed/pushed my local version yet, but the code originates from: github.com/rakudo/rakudo/blob/mast...f.pm6#L637 16:31
I have replaced the atpos_i with AT-POS since from may be signed or unsigned
jnthnwrthngtn We can't use the meta-object to determine what type of array from is and have separate code-paths? 16:34
m: my Buf $x .= new; my int @arr; say $x.^array_type 16:35
camelia (uint8)
jnthnwrthngtn m: my Buf $x .= new; my int @arr; say $x.^array_type; say @arr.^array_type
camelia (uint8)
(int)
nine No, that's just too obvious a solution. 16:37
nine is testing the fix
It's like magic! 16:42
MasterDuke m: my Buf $x .= new; my int @arr; say $x.^array_type.^unsigned; say @arr.^array_type.^unsigned # nice, just learned about this 16:47
camelia 1
0
jnthnwrthngtn :) 16:49
nine Well, this time it's harder: my uint @a = 1, 2; $_++ for @a' 16:55
MVMArray: atpos U64 expected int register, got 4 instead
jnthnwrthngtn Does ++ have a uint is rw and int rw candidate? 16:58
nine It's postfix:<++>(int $a is rw --> int) that's getting passed an UIntPosRef but treats it as signed.
jnthnwrthngtn I think that's how I'd expect it to work
I'm not sure a UIntPosRef should bind there
nine It doesn't I tried adding one but setting build failed with Ambiguous call to prefix:<++>
16:59 TempIRCLogger left 17:00 TempIRCLogger joined
jnthnwrthngtn Yeah, uint and int would be equally tight, so if int accepts a UIntPosRef we'll have a bad time. 17:00
grmbl, finally found time to look over the failures from my attr init replacement, and it looks like some modules fail because I'm broken blin or zef itself in an apparently subtle way 17:01
m: class C { has %.h = (); submethod BUILD() { %!h<k> = 42 } }; C.new.h.say 17:10
camelia {k => 42}
17:11 TempIRCLogger left, TempIRCLogger joined
nine How does rakudo determine whether e.g. an int accepts a UIntPosRef? 17:26
jnthnwrthngtn github.com/rakudo/rakudo/blob/mast....nqp#L1821 17:31
I guess iscont_i is answering true on UIntPosRef?
17:42 TempIRCLogger left, TempIRCLogger joined
nine It does. So I'll have to add an iscont_u 17:47
Now that's something I know how to do :)
17:57 TempIRCLogger left, TempIRCLogger joined 18:02 reportable6 left, evalable6 joined 18:06 TempIRCLogger left, TempIRCLogger joined 18:30 TempIRCLogger left, TempIRCLogger joined 18:45 TempIRCLogger left, TempIRCLogger joined 19:02 linkable6 joined 19:04 reportable6 joined 20:48 colemanx left, colemanx joined 23:08 squashable6 left 23:11 squashable6 joined 23:36 squashable6 left 23:38 squashable6 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!