|
00:12
hankache_ joined
00:16
hankache left
00:35
Pixi` is now known as Pixi
02:57
hankache joined
03:00
hankache_ left
06:08
hankache left
06:17
finanalyst joined
07:40
ShimmerFairy left
07:41
ShimmerFairy joined
08:07
[Coke] left
08:34
[Coke] joined
09:11
hankache joined
10:19
djinni`_ left
10:25
djinni` joined
|
|||
| ShimmerFairy | I've found an interesting issue, but I'm not sure if it's a bug. (This comes from a context where I need to build up arguments to self.bless across multiple function calls) | 10:34 | |
| m: class Foo { has Int @.bar; method new() { my @bar = 1, 5, 7; self.bless(:@bar) } }; say Foo.new | |||
| camelia | Foo.new(bar => Array[Int].new(1, 5, 7)) | ||
| ShimmerFairy | m: class Foo { has Int @.bar; method new() { my @bar = 1, 5, 7; self.bless(|{:@bar}) } }; say Foo.new | 10:35 | |
| camelia | Type check failed for an element of @!bar; expected Int but got Array ([1, 5, 7]) in method new at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| ShimmerFairy | Note that passing along the args in a hash like this *usually* works, just not for arrays. (If the array is untyped, then it'll make an array of an array, which is not intended) | 10:36 | |
| lizmat | m: class Foo { has Int @.bar; method new() { my Int @bar = 1, 5, 7; self.bless(|{:@bar}) } }; say Foo.new | 13:10 | |
| camelia | Type check failed for an element of @!bar; expected Int but got Array[Int] (Array[Int].new(1, 5, 7)) in method new at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| lizmat | hmmm | ||
| c: HEAD class Foo { has Int @.bar; method new() { my Int @bar = 1, 5, 7; self.bless(|{:@bar}) } }; say Foo.new | |||
| committable6 | lizmat, ¦HEAD(bb691c0): «Type check failed for an element of @!bar; expected Int but got Array[Int] (Array[Int].new(1, 5, 7)) in method new at /tmp/SB8Lyk2t3B line 1 in block <unit> at /tmp/SB8Lyk2t3B line 1 «exit code = 1»» | ||
| lizmat | c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.bless(|{:@bar}) } }; say Foo.new | 13:11 | |
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [[1, 5, 7],])» | ||
| lizmat | meh | ||
| c: HEAD class Foo { has @.bar }; say Foo.new( :bar(1,5,7) ) | |||
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [1, 5, 7])» | ||
| lizmat | c: HEAD class Foo { has @.bar }; my @bar = 1,5,7; say Foo.new( :@bar ) | 13:12 | |
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [1, 5, 7])» | ||
| lizmat | ok, so the issue is *really* with .bless | ||
| please make an issue :-) | |||
| hmmm... weird: | 13:18 | ||
| .new basically does nqp::create(self).POPULATE(%attrinit) | |||
| which is also what bless does: nqp::create(self).POPULATE(%attrinit); | |||
| c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.POPULATE({:@bar}) } }; say Foo.new | 13:19 | ||
| committable6 | lizmat, ¦HEAD(bb691c0): «Cannot look up attributes in a Foo type object. Did you forget a '.new'? in method new at /tmp/lSWGdMepNB line 1 in block <unit> at /tmp/lSWGdMepNB line 1 «exit code = 1»» | ||
| lizmat | c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.CREATE.POPULATE({:@bar}) } }; say Foo.new | 13:20 | |
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [[1, 5, 7],])» | ||
| lizmat | c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.bless(:@bar) } }; say Foo.new | ||
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [1, 5, 7])» | ||
| lizmat | looks like |{:@bar} is somehow messing up things | 13:21 | |
| c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.bless(|Map.new(:@bar)) } }; say Foo.new | 13:22 | ||
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [1, 5, 7])» | ||
| lizmat | problem is that { :@bar } puts the array inside a container | ||
| c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.bless(|%(:@bar)) } }; say Foo.new | 13:23 | ||
| committable6 | lizmat, ¦HEAD(bb691c0): «Foo.new(bar => [[1, 5, 7],])» | ||
| lizmat | c: HEAD class Foo { has @.bar; method new() { my @bar = 1, 5, 7; self.bless(|(:@bar,)) } }; say Foo.new | 13:32 | |
| committable6 | lizmat, ¦HEAD(bb691c0): «Too many positionals passed; expected 1 argument but got 2 in method new at /tmp/t0w_0U2ZM8 line 1 in block <unit> at /tmp/t0w_0U2ZM8 line 1 «exit code = 1»» | ||
| lizmat | meh | 13:33 | |
| Geth | rakudo/lizmat-64: 7 commits pushed by (Elizabeth Mattijsen)++
|
13:38 | |
| ugexe | ah back to nqp-fying the core, against the wishes of many core devs past | 14:00 | |
|
14:00
ugexe left
|
|||
| lizmat | huh? | 14:03 | |
| github.com/rakudo/rakudo/pull/6835 *is* NQP | |||
| *all of the commits mentioned in these messages, are in NQP | 14:05 | ||
| except the first one, which is actually in Perl 5 | |||
| and what about github.com/rakudo/rakudo/pull/6807 ? Is that one without NQP ? | 14:07 | ||
| lizmat steps away from the kb | 14:08 | ||
| [Coke] | Guessing ugexe is referring to the last commit range here on lizmat-64: github.com/rakudo/rakudo/compare/0...3ff5693478 | 17:30 | |
| lizmat | which all are in nqp files, *not* Raku files (except the first, which is Perl 5) | 17:34 | |
| don't let the .rakumod extension fool you, it's NQP | |||
| which is why you see := everywhere instead of = | 17:35 | ||
| and the only reason this should up, is because the lizmat-64 branch had conflicts, and I fixed those | 17:36 | ||
| *shows | 17:41 | ||
| [Coke] | ah, perhaps I'm mistaken then. | 18:36 | |
|
23:42
hankache_ joined
23:44
hankache left
|
|||