Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:04 Ven`` left 00:55 lizmat left 01:00 lizmat joined, p6bannerbot sets mode: +v lizmat
lucasb m: class { multi method m(1) {}; method gist {'XXXXXXXXXXXX'} }.m 01:45
camelia Cannot resolve caller m(XXXXXXXXXXXX: ); none of these signatures match:
(<anon|1>: Int $ where { ... }, *%_)
in block <unit> at <tmp> line 1
lucasb ^^ gist string leaked into error message
01:46 lucasb left 02:59 lizmat left 03:01 MasterDuke joined 03:03 ufobat_ joined 03:04 p6bannerbot sets mode: +v ufobat_ 03:07 ufobat left 03:17 MasterDuke left 03:20 leont left 07:35 robertle joined, p6bannerbot sets mode: +v robertle 08:43 lizmat joined, p6bannerbot sets mode: +v lizmat 09:32 robertle left
jnthn I don't think the gist string "leaked" into the error, so much as it was a deliberate design choice to use gist there to convey the value that was being passed in some reasonable way 09:33
yoleaux 02:49Z <Xliff> jnthn: Well, I finally had time to try your valgrind idea. Have no idea how to parse the results, though. gist.github.com/Xliff/8e402d623cea...45e820d7fd
Geth rakudo: 10693d16f1 | (Elizabeth Mattijsen)++ | 2 files
Make sure BagHash/MixHash.push-all push proxies as well

Because PositionalBindFailover uses .push-all internally to generate its cache of values, we need to pass proxies in there to make %bh <<+=>> 3 work
Spotted while writing exhaustive infix metaop tests.		 09:59
roast: 8e726026a3 | (Elizabeth Mattijsen)++ | S03-metaops/infix.t
More tests and tweaks

  - enable %h <<+=>> 3 tests, they now work on BagHash/MixHash
  - move to div tests to real section
   - div= *always* removes all keys from a SetHash as True div X where X > 1
   is always False, because 1 div X where X > 1 is always 0		 10:04
lizmat London sight seeing + socializing & 10:52
yoleaux 22 Nov 2018 11:53Z <SmokeMachine> lizmat: very good article! Would it worth to tell that currently custom specialization of X::Control won’t be catched by a CONTROL phaser but will by a CATCH?
22 Nov 2018 14:37Z <uzl> lizmat: Great article! BTW, `say $foo;` doesn't throw a warning even when outside of the quietly block. I guess you meant to use `print`?.
22 Nov 2018 14:38Z <uzl> lizmat: I also have a question about the article on containers: colabti.org/irclogger/irclogger_lo...11-20#l424
10:52 lizmat left 11:16 lucasb joined 11:17 p6bannerbot sets mode: +v lucasb
lucasb m: use MONKEY-TYPING; augment class Str { multi method foo(Int) {} }; 'hi there'.foo 11:21
camelia Cannot resolve caller foo(Str: ); none of these signatures match:
(Str: Int, *%_)
in block <unit> at <tmp> line 1
lucasb m: use MONKEY-TYPING; augment class Str { multi method foo(1) {} }; 'hi there'.foo
camelia Cannot resolve caller foo(hi there: ); none of these signatures match:
(Str: Int $ where { ... }, *%_)
in block <unit> at <tmp> line 1
lucasb ^^ deliberate design choice? :) 11:22
jnthn I'm not sure what you're asking is deliberate 11:43
Nothing looks surprising to me there
lucasb In the message "Cannot resolve caller foo(hi there: )", is the substring "hi there" a more descriptive description of the type Str than the string "Str" itself, as shown in the previous error message? The only thing that changed was the signature (Int) vs (Int $x where $x == 1) 11:48
jnthn oh, I see 11:59
I wonder if it's being very smart and figuring out a type mis-match vs. constraint mis-match 12:00
"very smart" :)
In that I guess it's saying "do we have any constraints" 12:01
And if yes, then emitting the values, not just the types
That's kinda helpful, though arguably less so on the invocant
Though technically one could constrain that too :) 12:02
lucasb thanks for confirming, jnthn! 12:05
I just wanted to point that it was using the .gist, like the snippet "class { multi method m(1) {}; method gist {'XXXXXXXXXXXX'} }.m" in the backlog
12:06 leont joined 12:07 p6bannerbot sets mode: +v leont 12:13 [Tux] left 12:17 j3nnn1 joined, p6bannerbot sets mode: +v j3nnn1 12:21 leont left 12:22 [Tux] joined, p6bannerbot sets mode: +v [Tux]
|Tux| Rakudo version 2018.10-174-g10693d16f - MoarVM version 2018.10-91-g8c67e1697
csv-ip5xs0.901 - 0.909
csv-ip5xs-206.813 - 6.820
csv-parser21.780 - 22.186
csv-test-xs-200.427 - 0.460
test7.997 - 8.035
test-t1.755 - 1.798
test-t --race0.803 - 0.822
test-t-2029.968 - 30.320
test-t-20 --race10.263 - 10.418
 12:37
13:00 ufobat___ joined, ufobat_ left, p6bannerbot sets mode: +v ufobat___ 13:37 brrt joined 13:38 p6bannerbot sets mode: +v brrt 14:27 leont joined 14:28 p6bannerbot sets mode: +v leont 14:55 donaldh joined 14:56 p6bannerbot sets mode: +v donaldh 17:05 brrt left 17:38 jsimonet left, jsimonet joined 17:39 p6bannerbot sets mode: +v jsimonet
lucasb m: dd (.list, .hash) given \(1,2,'a'=>1,'b'=>2) 17:57
camelia ((1, 2, :a(1), :b(2)), Map.new(()))
lucasb m: dd (.list, .hash) given (1,2,'a'=>1,'b'=>2).Capture 17:58
camelia ((1, 2), Map.new((:a(1),:b(2))))
lucasb So, while the capture construct \(...) makes a clear distinction between named parameters and pair objects 17:59
List.Capture goes the extra effort of partitioning the list into list/hash parts
List.Capture had this design choice, either handle all pair objects as positionals or as named parameters 18:01
Either way choosen, would be make it impossible to achieve the other, no? 18:02
currently, there's no way to create a capture from a list that contains positional pair objects
the same way as would be no way to create a capture from a list that contains named parameters, if List.Capture had choosen to make all elements as positionals, instead of splitting the list into two. 18:03
^^ is my interpretation correct? 18:08
timotimo that will at least make Capture.List.Capture partially round-trip 18:12
lucasb m: dd (.list, .hash) given \(1,2,'a'=>1,'b'=>2).List.Capture 18:15
camelia ((1, 2), Map.new((:a(1),:b(2))))
lucasb ^^ do you mean like that? 18:16
I don't think Capture.List.Capture round-tripped the right way like this
the Capture's positinal pairs ended up as named parameters, no? 18:17
here's List.Capture: github.com/rakudo/rakudo/blob/mast...#L895-L919 18:21
18:22 hankache joined 18:23 p6bannerbot sets mode: +v hankache
lucasb what you all think about a named paramater for List.Capture like somelist.Capture(:handle-pair-objects-as-positinals) 18:25
*positionals :) 18:26
just as an experiment :)
to try to remedy the current situation. the name of the flag can be bikeshedded 18:27
18:33 hankache left, hankache joined 18:34 p6bannerbot sets mode: +v hankache 18:37 hankache_ joined 18:38 p6bannerbot sets mode: +v hankache_ 18:40 kmel joined, hankache left, p6bannerbot sets mode: +v kmel 18:43 hankache_ left 18:47 kmel left
SmokeMachine lucasb: that's the same, but the opposite for hashes... 18:49
m: dd (.list, .hash) given {"a" => 1, "b" => 2}.Capture
camelia ((), Map.new((:a(1),:b(2))))
SmokeMachine lucasb: I think a List converted to a Capture should only populate the .list part, as a Hash converted to a Capture should only populate the .hash part... as it is currently... 18:51
I mean the oposite 18:53
lucasb "a List converted to a Capture should only populate the .list part" 18:55
I can agree with that. But I also can view the side of the current implementation, that splits/partition the list into list/hash parts 18:56
but this is perl, so I think an API the that combines all sides is prefered 18:57
thus, I propose List.Capture(:all-pairs-are-positionals) and List.Capture(:all-pairs-are-named-args) 18:59
whatever the actual flag names would be 19:00
AlexDaniel fwiw I'll be busy tomorrow for the whole day 19:04
SmokeMachine m: dd (.list, .hash) given Capture.new: :list(1, 2, "a" => 1, "b" => 2) # lucasb this works too 19:05
camelia ((1, 2, :a(1), :b(2)), Map.new(()))
AlexDaniel someone please please take a look at R#2499 :)
synopsebot_ R#2499 [open]: github.com/rakudo/rakudo/issues/2499 [⚠ blocker ⚠] Failures in Perl6::Parser module
lucasb :{(Any) => 1}.Capture #=> warns: Use of uninitialized value of type Any in string context 19:55
:{(Str) => 1}.Capture #=> dies: Cannot unbox a type object (Str) to a str
:{(Mu) => 1}.Capture #=> dies: Type check failed in binding to parameter 'key'; expected Any but got Mu (Mu)
leont Hashes are string indexed by default 19:58
SmokeMachine not with `:{}`
leont Not?
SmokeMachine m: my $a = :{42 => 1}; $a.keys.head.^name.say 19:59
camelia Int
lucasb leont: it's "objects hashes". First time I saw the syntax ":{...}" I thought it was strange, but now I'm used to it :) 20:05
I was just trying to show that Hash.Capture has trouble converting an object hash to a capture. dunno how it's supposed to behave 20:06
Hash.Capture, as List.Capture, also has to make the decision if things should ended up on the .list or .hash side of the Capture 20:07
leont Ah, I see 20:19
20:23 Ven`` joined 20:24 lucasb left, p6bannerbot sets mode: +v Ven``, Ven` joined 20:25 p6bannerbot sets mode: +v Ven` 20:28 Ven`` left 21:19 Ven` left 21:44 patrickb joined, p6bannerbot sets mode: +v patrickb 23:32 patrickb left 23:35 j3nnn1 left 23:40 lizmat joined, p6bannerbot sets mode: +v lizmat 23:47 donaldh left

Powered by Cro and the Raku® Programming Language.

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

Thank you!