|
00:18
kjp left
00:33
kjp joined
00:39
iwuvmika joined
00:42
kjp left
00:58
kjp joined
01:59
iwuvmika left
02:08
iwuvmika joined
04:25
vrurg_ joined
04:28
vrurg left
06:33
finanalyst joined
06:39
iwuvmika left
06:42
iwuvmika joined
10:02
finanalyst left
|
|||
| Geth | rakudo/lizmat-91: 62b165b198 | (Elizabeth Mattijsen)++ | 2 files Lose the idea of fast checking typed Arrays The problem really, which I previously hadn't realized, is that an Int array doesn't guarantee that all values in there are strictly of Int, but could also be any subclass of Int. Which basically means that the same path should be taken that was taken for untyped arrays. ... (12 more lines) |
11:00 | |
| rakudo/lizmat-82: 4 commits pushed by (Elizabeth Mattijsen)++ | 11:03 | ||
| rakudo/main: f8134ffbfd | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/allomorphs.rakumod Remove GUARDED-NUMERIC implementation-detail sub (#6863) It was only called in one place, and the code was minimal, so just move the code to where it was being called |
11:04 | ||
| rakudo/main: b0bdeead38 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/literals.rakumod RakuAST: inline ::QuotedString.IMPL-CHECK-PROCESSORS (#6865) It was only called in one place. Also only do processor checking only if there are any processors to check |
11:05 | ||
| rakudo/main: 0b9326d740 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/literals.rakumod RakuAST: simplify ::QuotedString.IMPL-NATIVE-LITERAL-KIND (#6866) Checking for processors can be done in a single if. Use the same logic as the "ast-type" method which follows |
11:06 | ||
| rakudo/main: 83fad92f81 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/var-lowering.rakumod RakuAST: streamline ::IMPL::VarLoweringFrame.IMPL-WALK (#6870) - remove unnecessary variable - merge 2 if structures - rewrite without needing return |
11:07 | ||
|
12:17
iwuvmika left
12:18
iwuvmika joined
|
|||
| lizmat | hmmm... why does Num cmp Num have different semantics form nqp::cmp_n(num,num) ? | 13:04 | |
| looks like nqp::cmp_n treats NaN as equal to any Num | |||
| m: use nqp: dd nqp::cmp_n(NaN,42e0) | 13:05 | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Confused at <tmp>:1 ------> use nqp<HERE>: dd nqp::cmp_n(NaN,42e0) |
||
| lizmat | m: use nqp; dd nqp::cmp_n(NaN,42e0) | ||
| camelia | 0 | ||
| lizmat | Moar currently defines it as: GET_REG(cur_op, 0).i64 = (a > b) - (a < b) | 13:08 | |
| Geth | rakudo/lizmat-91: 98fbb3468d | (Elizabeth Mattijsen)++ | 2 files Fix sorting of NaN Turns out the behaviour of Num cmp Num differs from nqp::cmp_n in the handling of NaN: nqp::cmp_n considers NaN equal to any other num, whereas infix:<cmp>(Num,Num) considers NaN higher than any other num value. Introduce a numcmp helper sub and use that to compare Num values in the Num fastpath |
13:45 | |
| rakudo/lizmat-92: e9a5a48d14 | (Elizabeth Mattijsen)++ | src/core.c/Num.rakumod Streamline infix:<cmp>(Num,Num)/(num/num) - Num cmp Num about 1.5x as fast - num cmp num about 2x as fast github.com/rakudo/rakudo/pull/6871.../98fbb3468 showed that there is a subtle discrepancy between infix:<cmp>(Num,Num) ... (7 more lines) |
14:24 | ||
| rakudo: lizmat++ created pull request #6872: Streamline infix:<cmp>(Num,Num)/(num/num) |
14:25 | ||
| rakudo/main: c1920c0953 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/literals.rakumod RakuAST: if "&val" is not resolved, don't bother doing a call (#6861) Before this commit a dummy Callable was being inserted to mimic val() processing. There's no need for that, as that Callable just returned the value as is. Instead just call the val() processor if it is available. Practically this will only affect core setting compilation before val() processing as becomes active. Still felt this was needed for code clarity. |
15:51 | ||
| rakudo/add-AI-policy: 53487fd862 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Revert "Bump NQP to get line number annotations fix" This reverts commit 065fcb97b8f8c065d3aad5b62543eb4b8d5ed771. |
15:54 | ||
|
16:17
vrurg joined
16:18
vrurg_ left
16:39
vrurg_ joined
16:41
vrurg left
|
|||
| ab5tract | What is the point of saying we will only merge after review if we merge without review? | 19:25 | |
| I’m on vacation with family and cannot really discuss it further but i wanted to say: I don’t get it | 19:26 | ||
| lizmat | I've only merged the ones that were out there for 5 days | 19:36 | |
| should I wait longer? | 19:37 | ||
| lizmat steps away from the kb | 19:44 | ||
| [Coke] | That one didn't have a requested reviewer, either - I think this points to us needing to agree on a commit/merge policy. | ||
| I think both sides are reasonable there, just want things written down so there's no confusion. | 19:45 | ||
|
20:18
finanalyst joined
20:38
vrurg joined,
vrurg_ left
20:45
vrurg_ joined,
vrurg left
21:02
vrurg joined,
vrurg_ left
21:12
vrurg_ joined,
vrurg left
|
|||
| japhb | Working on that. Sadly $day-job is having a heavy week. :-( | 21:19 | |
|
21:24
finanalyst left
|
|||
| [Coke] | blin clear through NEW=c1920c0953 | 23:54 | |