Geth rakudo: ugexe++ created pull request #6451:
Remove dead code from Perl6::ModuleLoader		 02:44
03:15 apogee_ntv left, apogee_ntv joined
Geth nqp/ugexe/dispatch-op-arg-release-kind: 6098829c6a | (Nick Logan)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Release dispatch op arg registers under their coerced kind

Previously add-dispatcher-op recorded each argument's register kind before coercing small-int, uint, and num32 arguments to full-width registers, then released the coerced register under that stale kind. That put an int64 register on the uint64 free-list (and similar for the other coerced kinds), so a later fresh_register of that kind in the same ... (7 more lines)		 03:26
nqp: ugexe++ created pull request #854:
Release dispatch op arg registers under their coerced kind		 03:27
ugexe m: run $*EXECUTABLE, q[-e], q[use nqp; sub f(uint $x) { nqp::dispatch("boot-value", $x) }; say f(3)]; BEGIN %*ENV<RAKUDO_RAKUAST>=1 03:30
camelia Bytecode validation error at offset 50, instruction 8:
operand type 160 (?) does not match register type 32 (int64) for op decont_u in frame f
in block <unit> at -e line 1

The spawned command '/home/camelia/rakudo-m-inst-2/bin/perl6-m' exit…
ugexe m: run $*EXECUTABLE, q[-e], q[use nqp; sub f(uint $x) { nqp::dispatch("boot-value", $x) }; say f(3)];
camelia 3
ugexe fixes that
Geth rakudo: ugexe++ created pull request #6452:
RakuAST: literalize an unhandled node to the sentinel, not a die		 04:04
rakudo: ugexe++ created pull request #6453:
RakuAST: deparse and raku a "will" trait via .phase and .block		 04:32
05:39 hurufu joined 06:59 [Tux] left, [Tux] joined 07:19 [TuxCM] joined 07:20 [Tux] left 08:01 rnddim joined, ShimmerFairy left 08:02 rnddim left, rnddim joined, rnddim is now known as ShimmerFairy 08:04 ShimmerFairy left, ShimmerFairy joined
Geth rakudo/main: 5eaeac3775 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
RakuAST: deparse and raku a "will" trait via .phase and .block

RakuAST::Trait::Will holds .phase and .block, but both handlers reached for .type and .expr, which it does not have. .raku threw "No such method
  'type'", and .DEPARSE had no candidate at all: the deparse method was
mistakenly named "raku", so it both shadowed the real .raku and left
  "will" traits to fall through to the base "Deparsing ... not yet
implemented" catcher. So `my $x will begin { }` could be neither deparsed nor reconstructed.
Rename the deparse method and read .phase and .block in both handlers.		 08:56
rakudo/revert-6453-ugexe/deparse-will-trait: 33ff040431 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Revert "RakuAST: deparse and raku a "will" trait via .phase and .block"

This reverts commit 5eaeac37755a93d3f3efa886a7dc8c952f27a117.
lizmat huh? 08:57
ab5tract oh wow, if I've ever seen that `my $x will begin { }` syntax before, I've forgotten it by now 14:39
I can dig it 14:40
lizmat fwiw, I think BEGIN my $x .... is clearer 15:35
it's just that for consistency *any* phaser can be specified
[Coke] ok, dropping (finally) off the perl6-users mailing list 16:17
well, trying to. not sure if the unsub email I just sent is being listened to by anything. 16:19
ugexe anyone have any other NYI type suggestions I should look into? 16:41
anyone know why we have bindpos_u and atpos_u but not other seemingly expected _u variants like push_u, pop_u, shift_u, unshift_u? 16:53
m: my uint @a; @a.push(2**64-1) 17:01
camelia Cannot unbox 64 bit wide bigint into native integer. Did you mix int and Int or literals?
in block <unit> at <tmp> line 1
ugexe if someone wanted to do the moarvm part of that but not the rest i could drive that to completion 17:07
i came about this from github.com/rakudo/rakudo/commit/a64c2f55f9 17:15
lizmat it was my understanding that nine didn't think they would be necessary 17:37
ugexe do you have any evidence of that? the link i showed suggests he thought the opposite at one time 17:44
lizmat it was just from memory... and that commit indeed points to it being needed.. 17:50
m: use nqp; my uint $a = -1; my uint @a; nqp::push_i(@a,$a); dd @a # this appears not needing it 17:56
camelia uint = array[uint].new(18446744073709551615)
ugexe m: my uint @a; @a.push(my uint $ = 2**64-1) 18:11
camelia ( no output )
ugexe nqp::push_i(self, T.^unsigned ?? (my uint $ = non-iterable.AT-POS($_)) !! (my int $ = non-iterable.AT-POS($_)))) for ^$elems; 18:16
so we'd need to do something like that then
(on the lines nine commented on that i linked) 18:20
maybe even `my T $ = ...` would work 18:23
i guess the question still remains if push_u etc should exist still stands, but the question of if the lack of it can be worked around the answer is yes 18:25
18:39 hurufu left 18:40 hurufu joined
japhb I think the _u variants should be there for real, and not just be workarounds. 18:57
Workarounds tend to be either slow or wrong, and when I use unsigned integers I typically want exactly NOT that. 18:58
20:28 hurufu left 21:05 ShimmerFairy left 21:06 ShimmerFairy joined 21:34 committable6 left, bloatable6 left, jjatria left, committable6 joined, bloatable6 joined, jjatria joined
lizmat the _u variants could just be synonyms , at least initiallly? 23:26
ugexe whats the point of that though 23:27
lizmat because at the VM level they'd do the same thing?
ugexe i personally don't like the idea of faux constraints that don't actually work
we already will presumably have to deal with the fallout of making push_i working differently (correctly) with uints 23:29
no use in adding a second vector with push_u
(assuming aliases) 23:31
lizmat m: dd UInt.HOW.^nam # isn't that the real underlying issue? 23:42
camelia Method NQPClassHOW.nam not found
in block <unit> at <tmp> line 1
lizmat m: dd UInt.HOW.^name
camelia "Perl6::Metamodel::SubsetHOW"
lizmat that there's no HLL equivalent to uint ? 23:43
it's late here, so will check in again tomorrow
&
ugexe yeah probably 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!