01:11 tellable6 left, evalable6 left 01:14 tellable6 joined, evalable6 joined 01:22 sena_kun left 01:37 sena_kun joined 01:49 kalkin- joined 01:50 Xliff left 01:53 kalkin left 02:47 vrurg_ joined 02:48 vrurg left 03:23 sena_kun left 03:38 sena_kun joined 04:53 ZzZombo_ joined 04:56 ZzZombo left 04:57 ZzZombo__ joined, ZzZombo__ is now known as ZzZombo 04:59 ZzZombo_ left 05:22 sena_kun left 05:38 sena_kun joined 05:58 Kaiepi left 05:59 Kaiepi joined 06:04 Kaiepi left 06:05 Kaiepi joined 06:18 Kaiepi left, Kaiepi joined 06:20 Kaiepi left 06:21 Kaiepi joined 07:23 sena_kun left 07:39 sena_kun joined 09:18 sena_kun left 09:33 sena_kun joined 11:04 kalkin- left
lizmat Files=1294, Tests=109646, 210 wallclock secs (27.82 usr 8.17 sys + 2957.14 cusr 269.20 csys = 3262.33 CPU) 11:11
11:12 kalkin- joined 11:23 sena_kun left
lizmat m: dd 0b111.11 11:29
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 3dd 0b111.7⏏0511
lizmat m: dd <0b111.11>
camelia RatStr.new(7.75, "0b111.11")
lizmat is there a reason for this discrepancy?
11:38 sena_kun joined 12:17 pheix joined 12:45 sena_kun left 12:57 pheix left 13:11 sena_kun joined 13:22 sena_kun left
lizmat m: dd <Nil> # seems like an oversight that we don't support that ? 13:26
camelia "Nil"
nine lizmat: why? Seems to me more likely to write code like my @zeros = <Zero Null Nil Zap Aught>; than to expect an actual Nil coming out of list quotes 13:30
13:37 sena_kun joined 14:19 Kaeipi joined 14:20 Kaiepi left 14:23 Kaeipi left 14:24 Kaiepi joined 14:29 lucasb joined 14:44 vrurg joined 14:46 vrurg_ left 14:50 AlexDaniel left, vrurg_ joined 14:52 vrurg left 15:22 sena_kun left 15:38 sena_kun joined 16:54 Kaiepi left 16:58 Kaiepi joined 17:24 sena_kun left
lizmat m: dd <NaN Inf> # we do so for NaN and If 17:29
camelia (NumStr.new(NaN, "NaN"), NumStr.new(Inf, "Inf"))
lizmat nine ^^^ 17:30
bisectable6: role A { method a() { 666 } }; class B does A { has $.a = 42}; dd B.new.a 17:34
bisectable6 lizmat, On both starting points (old=2015.12 new=d5a34f1) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «666␤»
lizmat bisectable6: role A { has $.a = 666 }; class B does A { has $.a = 42}; dd B.new.a 17:35
bisectable6 lizmat, On both starting points (old=2015.12 new=d5a34f1) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «04===SORRY!04=== Error while compiling /tmp/knmt4TjqVq␤Attribute '$!a' already exists in the class 'B', but a role also wishes to compose it␤at /tmp/knmt4TjqVq:1␤»
17:39 sena_kun joined
lizmat m: dd <42.25*-10**4> 18:17
camelia RatStr.new(422500.0, "42.25*-10**4")
lizmat m: dd 42.25*-10**4
camelia -422500.0
lizmat which is correct?
18:28 lucasb left
lizmat m: dd -10**4 # I guess shorter 18:30
camelia -10000
lizmat I guess the current val processing is wrong 18:36
japhb lizmat: NaN and Inf are defined concrete Numeric values; Nil is not any of those. Thus I'm not surprised by that sort of discontinuity. 18:47
lizmat probably, but if you're using a CLI, it could be nice if you could just say "Nil" to indicate the absence of a value 18:48
japhb lizmat: As for the processing of <42.25*-10**4> I would not be surprised if it was a bug, but I also would not be surprised if that's a literal interpretation of the relevant synopsis.
lizmat but should val processing be different from general expression evaluation ? 18:49
japhb lizmat: Can you give an example of when it would be useful to be able to specify Nil in the command line args, instead of just not having that flag in the args at all? 18:50
lizmat sub MAIN($a, $b) { }; foo Nil 42 18:51
japhb The only think I can think of off the top of my head is slightly simplifying programs-that-spawn-other-programs. But that seems like an edge case for creating the Nil special case.
lizmat: Oh, you're thinking about having positional args that aren't ''.
lizmat yeah 18:52
japhb My thought is that that feels like it belongs in getopt module territory.
lizmat it's just that I know that Nil has historically been implemented *after* val() processing, so I wondered if we missed something there 18:53
japhb I think val() processing *should have been* a true subset of expression parsing, where they overlap. There are some things that val() can handle that normal expressions cannot, and that is a little odd. That ship may have sailed though. And in any case, it's a matter of waterbed complexity -- handling all of val() parsing in normal expressions would most likely push up the waterbed somewhere else. 18:56
lizmat: It's possible, yes. (missed out on Nil because history)
lizmat which cases can val() handle that normal expression handling can't ? 18:57
japhb val() after all has the advantage of being able to assume the entire string should parse as a single value.
lizmat I thought val processing was a subset of expression parsing
japhb Well (and I'm reaching into misty memory now), aren't Complex values treated differently? val() producing a compile-time value and normal expressions not going that far? Or is that no longer true? 18:59
m: dd <1+2i>
camelia <1+2i>
japhb m: dd 1 + 2i
camelia <1+2i>
japhb Oh duh, dd is evaluating the runtime value 19:00
I need to look at the AST, and ... I'm not sure the bots can do that
lizmat yeah it can be tricky
m: dd val('1 + 2i') # ensure runtime
camelia "1 + 2i"
lizmat m: dd val('1+2i') # ensure runtime
camelia ComplexStr.new(<1+2i>, "1+2i")
japhb m: dd 1 + 0i 19:01
camelia <1+0i>
japhb (phew)
lizmat m: dd val('1+0i')
camelia ComplexStr.new(<1+0i>, "1+0i")
lizmat m: dd val('1+Inf\i')
camelia ComplexStr.new(<1+Inf\i>, "1+Inf\\i")
japhb Ah yes, there's a difference.
m: dd <1+2i>, val('1+2i'); 19:02
camelia <1+2i>
ComplexStr.new(<1+2i>, "1+2i")
lizmat val creates allomorphs
japhb Right, but notice that <1+2i> is *not* an allomorph. 19:03
even though <...some real expression...> is
lizmat m: dd <4> 19:04
camelia IntStr.new(4, "4")
lizmat hmmm
I wonder if that's an issue with ComplexStr.perl
japhb github.com/perl6/specs/blob/master...x-literals 19:05
lizmat m: dd <1+2i>.^name
camelia "Complex"
japhb It's spec ^^
Intentional discontinuity. 19:06
Hmmm, github.com/perl6/specs/blob/master...-semantics is interesting too. 19:11
lizmat yeah, I've been looking a lot at that section the past weeks 19:14
I'm also implementing Blob literals, but different from this spec: github.com/perl6/specs/blob/master...b-literals 19:15
japhb The bit about no-space=no-val being useful for separating out a single constant from the surrounding expression precedence was I think what I had been trying to remember before. 19:16
lizmat :16{ aa bb cc } -> Blob.new(0xaa,0xbb,0xcc)
luckily the grammar already deals with that, as far as I have been able to determine
19:23 sena_kun left 19:38 sena_kun joined 21:22 sena_kun left 21:38 sena_kun joined 22:44 Xliff joined
Xliff o/ 22:45
I'm having a bit of trouble with some metaprogramming.
Can someone tell me why my overridden ClassHOW method incorporate_multi_methods isn't getting executed? 22:46
github.com/Xliff/Method-Also/blob/...so.pm6#L38 22:49
23:04 Kaeipi joined, Kaiepi left 23:23 sena_kun left 23:36 sena_kun joined 23:44 sena_kun left