#raku-dev on 5 April 2020 - Raku Programming Language Log

01:22 sena_kun joined 01:23 Altai-man_ left 03:08 linkable6 left, evalable6 left 03:10 evalable6 joined 03:11 linkable6 joined 03:21 Altai-man_ joined 03:23 sena_kun left 05:22 sena_kun joined 05:23 Altai-man_ left

AlexDaniel

sena_kun: looks promising :) github.com/Raku/Blin/pull/23

06:30

greppable6: \.\..*\.reverse

06:32

greppable6

AlexDaniel, 24 lines, 15 modules: gist.github.com/66034742de35b4d630...7faba1f25a

AlexDaniel

Xliff: well, you can add arguments to the one you did before

06:34

Xliff: for example, JSON::Fast is likely to pass tests everywhere so it'll be `OK`

Xliff: I think module Sum is AlwaysFail

06:36

Xliff: basically pick anything from here: gist.github.com/AlexDaniel/acf237b...e5abb8a785

06:38

just keep in mind that some of them have dependencies :)

[Tux]

Rakudo version 2020.02.1-291-g30e7a67c5 - MoarVM version 2020.02.1-73-gc7e75be60

csv-ip5xs	0.694	-	0.694
csv-ip5xs-20	5.839	-	5.879
csv-parser	23.546	-	24.095
csv-test-xs-20	0.376	-	0.388
test	7.565	-	7.620
test-t	1.949	-	1.961
test-t --race	0.948	-	0.986
test-t-20	31.316	-	31.357
test-t-20 --race	9.519	-	9.575

07:06

07:08 maggotbrain left 07:21 Altai-man_ joined 07:23 sena_kun left

MasterDuke

is geth down? don't think i saw 30e7a67c55546e934ae46ed600e04c1c503cece5 go by

08:27

linkable6

(2020-04-04) github.com/rakudo/rakudo/commit/30e7a67c55 Add s/PERL6/RAKU test environment variables

tyil

MasterDuke: I'll kick him

08:34

MasterDuke

woohoo, got my branch building rakudo and passing nqp's `make m-test` and rakudo's `make m-test m- spectest`. compile times seem unchanged, but heaptrack reports ~4gb less allocated

08:35

tyil

considering to just kick him on a daily basis at this point, tbh

08:35 Geth_ joined, Geth left

tyil

it doesn't report anything in particular in the logs as to why it's having troubles

08:35

lizmat

Files=1306, Tests=111228, 213 wallclock secs (28.90 usr 8.27 sys + 3009.80 cusr 267.12 csys = 3314.09 CPU)

08:46

MasterDuke

oom killer?

tyil

the process runs just fine

08:47

if the OOMkiller were to come around, kubernetes would restart the process somewhere

and there would be no problem

09:05 Voldenet joined, Voldenet left, Voldenet joined

Xliff

m: use NativeCall; class A repr<CPointer> {}; my $a = A.new; +$a.say

09:14

camelia

5===SORRY!5=== Error while compiling <tmp>
Unable to parse class definition
at <tmp>:1
------> 3use NativeCall; class A7⏏5 repr<CPointer> {}; my $a = A.new; +$a.s
expecting any of:
generic role

Xliff

m: use NativeCall; class A is repr<CPointer> {}; my $a = A.new; +$a.say

camelia

WARNINGS for <tmp>:
A.new
Useless use of "+" in expression "+$a.say" in sink context (line 1)

Xliff

m: use NativeCall; class A is repr<CPointer> {}; my $a = A.new; (+$a).say

camelia

Cannot resolve caller Numeric(A:D: ); none of these signatures match:
(Mu:U \v: *%_)
in block <unit> at <tmp> line 1

Xliff

^^ What would it take to get that to work?

09:15

09:22 sena_kun joined 09:24 Altai-man_ left 09:35 hungrydonkey left, hungryd80 joined

Geth_

rakudo: 3983b4f8f2 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6
Make (1..-Inf).reverse) work as intended

Fixes R#3595

09:43

linkable6

R#3595 [open]: github.com/rakudo/rakudo/issues/3595 [ranges][regression] (1 .. -Inf).reverse is wrong

Xliff

AlexDaniel: Do you really want both .output-old and .output-new?

09:45

AlexDaniel: gist.github.com/Xliff/a9bb1b058123...d46f609f29

09:47

AlexDaniel

Xliff: markdown in tickets is different from markdown that is in gists

so test your stuff in comments :D

I know, I know, but that's how it is :D

09:48

Xliff

Um. No.

09:49

It's how YOU want it. Not necessarily how it is.

AlexDaniel

Xliff: I mean that github parses markdown differently

09:50

depending on whether it's in tickets, gists or wikis

Xliff

It looks fine. See PR

I'm more concerned about comment length with both .output-new AND .output-old

AlexDaniel

Xliff: yeah… we can have nested collapsible things but it gets kinda ridiculous

09:52

Xliff: btw here's the source of my comment (in case you can't see it): gist.github.com/AlexDaniel/ae88320...0a25ba7f78

09:53

Xliff: ``` instead of <pre> so that there's no need to escape stuff, also the whole thing is indented so that it's part of the todo item

Xliff

<summary> + ``` does not work

09:56

AlexDaniel

Xliff: you need a newline before ``` I think

like an empty line

Xliff

And this whole indenting stuff might be taking this too far.

AlexDaniel

but it does need to be part of the todo item

09:57

Geth_

rakudo: c588323e51 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6
Make (foo .. foo).reverse correctly

Fixes R#3597

linkable6

R#3597 [open]: github.com/rakudo/rakudo/issues/3597 [ranges] (Inf ^.. Inf).reverse is wrong

AlexDaniel

otherwise you can't drag'n'drop todo items

Xliff

``` Does not work. Destroyes formatting.

10:00

Also, can't drag and drop TODO items at all.

10:01

Old Output will indent, New Output will NOT

AlexDaniel

Xliff: but it works here? github.com/Raku/Blin/pull/23#issue...-609363030

10:02

I can drag'n'drop but maybe just for my own comment

lizmat: I wonder, wouldn't it be simpler for everything if .reverse on a Range just returned a reversed Range object?

10:06

lizmat: that's fully not backward compatible but I'm not sure if it matters

lizmat

well, I guess you could consider a dedicated Range.reverse to be a premature optimization

10:07

as you could probably easily replace (a .. b).reverse by b ... a

10:08

AlexDaniel

what optimization

it's a completely different behavior

lizmat

but the latter is like 10 times slower

m: say (1..10).reverse

camelia

(10 9 8 7 6 5 4 3 2 1)

Xliff

Got it!

lizmat

m: say 10...1

camelia

(10 9 8 7 6 5 4 3 2 1)

lizmat

AlexDaniel: not very different in most cases

10:09

AlexDaniel

ah, I see what you're saying

lizmat

so, I'm fixing those tickets now

AlexDaniel

yeah for now that makes sense for sure

lizmat

once ... is optimized, I will look and see how much we can rip out

AlexDaniel

lizmat: I'm just trying to make sense of the behavior and right now “I don't know” is the only short explanation I have :)

10:11

so .reverse is like, uhm, having a range with sides reversed but it's allowed to count down ?

10:12

on a Range that is

10:13

lizmat

m: say (1..10).reverse # indeeed

camelia

(10 9 8 7 6 5 4 3 2 1)

AlexDaniel

on everything else it's just iterating backwards

lizmat

m: my @a = 1..10; say @a.reverse # functional equivalent

10:14

camelia

(10 9 8 7 6 5 4 3 2 1)

AlexDaniel

m: say (1..10.5).reverse

camelia

(10.5 9.5 8.5 7.5 6.5 5.5 4.5 3.5 2.5 1.5)

AlexDaniel

m: my @a = 1..10.5; say @a.reverse

camelia

(10 9 8 7 6 5 4 3 2 1)

AlexDaniel

not exactly…

lizmat

hmmm... that would be a bug :-)

10:15

care to make a ticket?

AlexDaniel

lizmat: it's by design, this is why we have this conversation

lizmat

hmmmm

10:16

premature optimization :-(

AlexDaniel

lizmat: now you *can* fix this particular case with maths, I think

10:17

but then what about Num ranges? :)

m: dd $_ for 10e0..15e0

camelia

10e0
11e0
12e0
13e0
14e0
15e0

AlexDaniel

lizmat: but if we say that .reverse is supposed to produce exactly the same values just in reverse, then maybe there's a way to get there eventually

10:19

m: say (Inf ^.. Inf).reverse[^10]

10:21

camelia

(Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil)

AlexDaniel

e: say (Inf ^.. Inf).reverse[^10]

evalable6

(Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil)

AlexDaniel

lizmat: I'm a bit confused as to why it still prints what it prints, but either way the fix for R#3597 is possibly not right

10:24

linkable6

R#3597 [open]: github.com/rakudo/rakudo/issues/3597 [ranges][tests needed] (Inf ^.. Inf).reverse is wrong

AlexDaniel

now that I squinted a bit harder it's probably right

10:25

lizmat

m: dd ("1"..9).reverse.head(10) # another case :-(

10:27

camelia

This type cannot unbox to a native string: P6opaque, Int
in block <unit> at <tmp> line 1

AlexDaniel

lizmat: oh I have not even considered mixed types

10:30

lizmat

yeah... I think some cleanup is needed :-(

AlexDaniel

Xliff: it looks pretty good!

10:32

Xliff: don't put the sha in `` because in rakudo/rakudo repo github will automatically create links for shas

10:33

Xliff: and you don't even need to substr it I think

it's a bit ugly in plaintext but as a ticket it'll be fine

Xliff

*shrug*

10:34

Is it enough to do for now?

Getting tired and need to accomplish something on my own stuffs before I pass out. :/

10:35

Oh, you want me to finish before merge. See? tired.

AlexDaniel

well, I dunno. There's also output that is not in ``` ```, meaning all html stuff needs to be escaped

escaping ``` is probably significantly easier :)

10:36

Xliff

Again, ``` does not work.

Dunno why, but inside of <details>, using ``` destroys the formatting. <pre> was the only alternative.

AlexDaniel

Xliff: I just edited your comment with ```

10:37

Xliff

Checking

Hmmm... newline before ```?

10:38

Did you already mention that?

See? tired. :P

lizmat

m: dd (NaN..NaN).head(10)

10:39

camelia

(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq

lizmat

this feels... weird... I sorta expected this to produce a single NaN value ?

AlexDaniel

m: dd (NaN...NaN).head(10)

10:40

camelia

(NaN,).Seq

AlexDaniel

lizmat: I don't even know what to expect now, really. Cognitive overload because of all edge cases

lizmat

yeah... anyways, lunch has arrived&

10:41

Xliff

AlexDaniel: Committed.

10:42

10:43 hungryd80 left, hungrydonkey joined

Xliff

m: use NativeCall; class A is repr<CStruct> { has uint32 $!a }; my $a = $a.new; say cast(Pointer[A], $a);

10:45

camelia

5===SORRY!5=== Error while compiling <tmp>
Cannot use variable $a in declaration to initialize itself
at <tmp>:1
------> 3r<CStruct> { has uint32 $!a }; my $a = $7⏏5a.new; say cast(Pointer[A], $a);
expecting any of:
ter…

Xliff

m: use NativeCall; class A is repr<CStruct> { has uint32 $!a }; my $a = A.new; say cast(Pointer[A], $a);

camelia

5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
cast used at line 1. Did you mean 'cas', 'last'?

Xliff

m: use NativeCall; class A is repr<CStruct> { has uint32 $!a }; my $a = A.new; say nativecast(Pointer[A], $a);

camelia

NativeCall::Types::Pointer[A]<0x3b40910>

Xliff

m: use NativeCall; class A is repr<CStruct> { has uint32 $!a }; my $a = A.new; my $b; nativecast(Pointer[A], $a); my $c = nativecast(Pointer, $a); $b.deref.say

10:46

camelia

No such method 'deref' for invocant of type 'Any'
in block <unit> at <tmp> line 1

Xliff

m: use NativeCall; class A is repr<CStruct> { has uint32 $!a }; my $a = A.new; my $b = nativecast(Pointer[A], $a); my $c = nativecast(Pointer, $a); $b.deref.say

10:47

camelia

A.new

11:20 Kaiepi left 11:21 Altai-man_ joined 11:24 sena_kun left 11:25 Kaiepi joined 11:30 hungryd2 joined 11:31 hungrydonkey left 11:36 hungryd2 left 11:37 hungrydonkey joined 11:40 hungryd68 joined 11:42 hungrydonkey left 12:11 Kaiepi left 12:13 Kaiepi joined 12:21 brrt joined 12:24 hungrydonkey joined, hungryd68 left 12:32 hungryd77 joined, hungrydonkey left 12:36 hungrydonkey joined, hungryd77 left

lizmat

AlexDaniel: I'm stopping with trying to fix the Range anomalies

12:50

AlexDaniel

lizmat: it simply never ends, right?

lizmat

I think we need a discussion on how these edge cases should work

or apply some simple rules as: if startpoint and endpoint are the same, then only 1 value will be generated for ..

12:51

and no values will be generated for ^.. ..^ and ^..^

m: dd (NaN..NaN).head(10)

camelia

(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq

lizmat

m: dd (NaN^..NaN).head(10)

12:52

camelia

(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq

lizmat

m: dd (NaN..^NaN).head(10)

camelia

().Seq

lizmat

m: dd (NaN^..^NaN).head(10)

camelia

().Seq

lizmat

there's currently a test depending on the current NaN .. NaN behaviour

Altai-man_

yay

12:54

AlexDaniel

lizmat: IMO we just need to define some predictable and easy to understand behavior for ..

currently it does magic

12:55

lizmat: I actually had a draft of a ticket proposing changes to the string behavior with .., and it all made sense until I realized that people often want to have single-letter ascii string ranges

12:58

lizmat

maybe we should re-read "Range and RangeIter semantics" in the specs

AlexDaniel

and I couldn't make myself propose to use (‘a’.ord..‘z’.ord)».chr insead :D

lizmat

basically, if a type support .succ that should be used to create the range

12:59

m: dd NaN.succ # the reason NaN..foo produces (NaN,NaN....)

13:00

camelia

NaN

AlexDaniel

lizmat: yeah, both .. and ... relying on .succ was my conclusion also, if I'm not mistaken

13:03

lizmat

ok, I thought I could fix this quickly, but am not now with ... refactoring in my head

13:04

Geth_

¦ rakudo: lizmat self-unassigned (Inf .. Inf) is wrong github.com/rakudo/rakudo/issues/3596

¦ rakudo: lizmat self-unassigned Reversed ranges with NaN are wrong (maybe?) github.com/rakudo/rakudo/issues/3599

13:05

¦ rakudo: lizmat self-unassigned (Inf ... Inf) is wrong github.com/rakudo/rakudo/issues/3600

¦ rakudo: lizmat self-unassigned Run time SORRY when dividing an Inf range by 0 github.com/rakudo/rakudo/issues/3598

Altai-man_

m: use nqp; my $code = start { my $c := nqp::getcomp('Raku') || nqp::getcomp('perl6'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; await $code;

13:06

camelia

An operation first awaited:
in block <unit> at <tmp> line 1

Died with the exception:
existskey requires a concrete object (got a NQPMu type object instead)
in block at <tmp> line 1

Altai-man_

bisectable6, use nqp; my $code = start { my $c := nqp::getcomp('Raku') || nqp::getcomp('perl6'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; await $code;

13:07

bisectable6

Altai-man_, Bisecting by output (old=2015.12 new=c588323) because on both starting points the exit code is 1

Altai-man_, bisect log: gist.github.com/f5a3a4774d6fb77af9...3ee64a8f49

Altai-man_, (2016-05-12) github.com/rakudo/rakudo/commit/33...d4efe221de

13:22 sena_kun joined 13:24 Altai-man_ left

AlexDaniel

lizmat: so my thought process was like this: 1) remove magical string special-casing and just let .succ do the work, this is fairly obvious and it also has a bonus of making ‘ab’.IO .. ‘ba’.IO and ‘ab’..‘ba’ function the same way. If we decide that magical pattern generation is very useful we can have a separate sub for that 2) however, IO-like .succ still counts the wrong way for negative numbers, so let's just admit that .su

13:35

can't be well defined, ban it and let users choose the behavior they want explicitly 3) OK, cool, but now people can't do simple stuff like ‘a’..‘z’ which is extremely common

maybe instead of banning Str.succ we can make it more magical to count the right way, but uhh…

13:36

Xliff

m: ('ab'.IO .. 'ad'.IO).gist.say

13:37

camelia

IO::Path.new("ab", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))..IO::Path.new("ad", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))

AlexDaniel

m: say (‘ab’..‘ba’)[^10]

Xliff

m: ('ab'.IO..'ad'.IO).gist.say

camelia

(ab aa bb ba Nil Nil Nil Nil Nil Nil)

IO::Path.new("ab", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))..IO::Path.new("ad", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))

AlexDaniel

m: say (‘ab’..‘ba’)[^10]

camelia

(ab aa bb ba Nil Nil Nil Nil Nil Nil)

AlexDaniel

m: say (‘ab’.IO..‘ba’.IO)[^10]

camelia

("ab".IO "ac".IO "ad".IO "ae".IO "af".IO "ag".IO "ah".IO "ai".IO "aj".IO "ak".IO)

13:38 brrt left

Xliff

m: ('ab'.IO..'ad'.IO)[^4]

13:38

camelia

( no output )

Xliff

m: ('ab'.IO..'ad'.IO)[^4].say

camelia

("ab".IO "ac".IO "ad".IO Nil)

Xliff

m: ('ab'.IO...'ad'.IO).say

camelia

("ab".IO "ac".IO "ad".IO)

AlexDaniel

another example from my wall of text:

13:39

m: say (‘-5’...*)[^10]

camelia

(-5 -6 -7 -8 -9 -10 -11 -12 -13 -14)

AlexDaniel

m: say (-5...*)[^10]

camelia

(-5 -4 -3 -2 -1 0 1 2 3 4)

AlexDaniel

same with .. btw

(why is it counting down? It's not counting down, it's doing .succ on Str!)

13:40

.oO( which in this case .succs )

lizmat

well, that's why you should use dd rather than say

13:41

AlexDaniel

lizmat: as if output printing can fix bad design? :)

13:43

that said I have no clue what would be a better one

13:44

lizmat

m: dd "-5".succ, (-5).succ, -5.succ # shit happens

13:45

camelia

"-6"
-4
-6

Geth_

nqp: MasterDuke17++ created pull request #612:
Write large chunks of bytecode to a file on the fly instead of doing it all in memory first

AlexDaniel

lizmat: well yeah, and the shittier shit is that .. and ... also do something completely different for strings :)

13:48

13:48 Altai-man_ joined

AlexDaniel

sourceable6: ‘foo’.succ

13:48

sourceable6

AlexDaniel, github.com/rakudo/rakudo/blob/c588...r.pm6#L770

13:51 sena_kun left

AlexDaniel

Xliff: btw $bisected is unused