|
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/knmt4TjqVqAttribute '$!a' already exists in the class 'B', but a role also wishes to compose itat /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
|
|||