00:42 lucasb left 00:50 sena_kun joined 00:52 Altai-man_ left
Kaiepi m: my @x = [{ x => [1,2], y => <a b>, }]; say @x[0]<x>; say @x[0]<y>; 01:32
camelia Nil
(a b)
Kaiepi m: my @x = [{ x => [1,2], y => <a b>, }]; say @x[0]<x>; say @x[0]<y>;
camelia Nil
(a b)
Kaiepi m: my @x = [{ x => [1,2], y => <a b>, }]; say @x[0]<x>; say @x[0]<y>;
camelia [1 2]
Nil
Kaiepi found this over a question someone posted on twitter, it happens on v2020.02.1 as well as master 01:34
not sure how to bisect something that's inconsistent like this though 01:35
MVM_SPESH_DISABLE and MVM_JIT_DISABLE don't seem to have any effect
01:59 cognominal joined 02:02 cognomin_ left 02:06 finsternis joined
timotimo Kaiepi:that's just hash order randomization 02:39
m: my @x = [{ x => [1,2], y => <a b>, },]; say @x[0]<x>; say @x[0]<y>;
camelia [1 2]
(a b)
timotimo m: my @x = [{ x => [1,2], y => <a b>, },]; say @x[0]<x>; say @x[0]<y>;
camelia [1 2]
(a b)
timotimo m: my @x = [{ x => [1,2], y => <a b>, },]; say @x[0]<x>; say @x[0]<y>;
camelia [1 2]
(a b)
timotimo m: my @x = [{ x => [1,2], y => <a b>, },]; say @x[0]<x>; say @x[0]<y>;
camelia [1 2]
(a b)
timotimo ^- don't iterate the hash into @x as pairs, then @x[0] will be the hash rather than just whatever Pair it pulled out first 02:40
02:49 Altai-man_ joined 02:51 sena_kun left 04:10 hungrydonkey joined 04:16 hungrydonkey left 04:29 hungrydonkey joined 04:50 sena_kun joined 04:52 Altai-man_ left 05:20 hungrydonkey left 06:21 squashable6 left 06:23 squashable6 joined 06:49 Altai-man_ joined 06:52 sena_kun left 08:34 Ven`` joined 08:45 AlexDaniel left 08:47 Kaeipi joined, Kaiepi left 08:50 sena_kun joined 08:52 Altai-man_ left
lizmat Files=1306, Tests=111242, 212 wallclock secs (28.96 usr 8.37 sys + 2991.09 cusr 271.17 csys = 3299.59 CPU) 08:52
08:56 [Tux] joined
MasterDuke timotimo: gist.github.com/MasterDuke17/cbe5c...f50d0c6b12 09:25
sena_kun gist.github.com/Altai-man/8bb9f8f1...2d95a1ca84 <- latest blin log 10:17
alas, no time to sort false positives out today, but weekend is close 10:18
MasterDuke anyone have an idea why this action method github.com/Raku/nqp/blob/master/sr...#L266-L269 for this regex github.com/Raku/nqp/blob/master/sr...#L174-L176 (which should be token) gets called between 0 and 3 times for each line directive it sees? 10:24
m: EVAL "#line 2 foo\nsay q|hi|"
camelia hi
MasterDuke i added a note in the action method and for ^^^ it prints three times 10:25
but usually it's twice
10:49 Altai-man_ joined 10:52 sena_kun left
timotimo holy ... i thought the exception file has some annoying stuff, but i wouldn't have expected it to actually take the longest 11:53
lizmat I think it's role composition that's taking a lot 11:58
timotimo mostly X::Syntax and maybe X::CompileTime? 12:00
lizmat X::Comp X::Control 12:01
X::OS X::IO 12:02
X::MOP
"my role X::MOP is Exception { }" que ? 12:03
X::Syntax
Rakudo::Iterator also does a lot of Iterator
native_array does a lot of Positional and Iterable 12:04
so it feels that making role composition faster would be a win 12:05
timotimo mhm 12:14
MasterDuke: good work in any case! 12:30
that line annotation thing is curious. probably related to backtracking? 12:31
jnthn Well, the problem today is that we immediately compile role bodies 12:49
(I mean, it solves some problems, but makes others :))
The others really being increased compile times
12:50 sena_kun joined 12:52 Altai-man_ left
timotimo from just literally having more code? 12:54
or is that the problem it makes
jnthn I guess the increased compile time is the main drawback 12:55
Maybe we can do better in RakuAST 12:56
timotimo by interpreting instead of compiling i assume?
jnthn Perhaps so
Though failing that we might be able to better batch/re-use the first compilation too 12:57
timotimo was your suggestion to parse roles and accumulating their QAST until one of them is needed and then compile all of them at once? 13:04
jnthn Potentially something like that 13:06
timotimo that can't possibly be difficult ... 13:09
jnthn With today's architecture it'd be terrifying :) Maybe with the RakuAST one, less so
MasterDuke timotimo: but all the comment grammars are tokens. and why would the action get called multiple times? is that a usual thing to have happen? 13:19
timotimo whatever is calling it could be backtracking 13:25
MasterDuke i guess for some reason i don't expect the actions to be called until the grammar is finished. seems like a lot of extra work being done 13:36
jnthn Actions are called after a rule has matched. 13:37
If they weren't, how would we do things like `BEGIN`?
13:38 Ven`` left
MasterDuke hm, does make sense 13:39
14:02 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 14:21 samebchase-2 is now known as samebchase- 14:33 sena_kun left 14:34 sena_kun joined, sena_kun left 14:35 sena_kun joined
Geth ¦ rakudo: patrickbkr self-assigned Broken links in annoucement github.com/rakudo/rakudo/issues/3530 14:38
AlexDaniel did I just find broken math? :) 14:45
m: say (-5)**(-1)
camelia -0.2
AlexDaniel m: say (-5.0)**(-1)
camelia -1.8
AlexDaniel github.com/rakudo/rakudo/blob/fa3c...#L244-L265 14:46
say 2 + (-5.0)**(-1) 14:47
evalable6 1.8
AlexDaniel m: say 0 + (-5.0)**(-1)
camelia -0.2
AlexDaniel actually, not sure why it fails to normalize there
this is not really what I was trying to test 14:48
14:49 Altai-man_ joined
AlexDaniel m: say (-5.0)**(-1) + 0 14:49
camelia -0.2
AlexDaniel anyway R#3641 14:50
linkable6 R#3641 [open]: github.com/rakudo/rakudo/issues/3641 [math][rationals] Broken math in ** with Rats that fail to normalize ( (-5.0)**(-1) )
AlexDaniel 6c: say (-5.0)**(-1)
committable6 AlexDaniel, gist.github.com/36dc2d1333dcb93ce9...49bf076cb8 14:51
AlexDaniel bisect: say (-5.0)**(-1)
bisectable6 AlexDaniel, Bisecting by output (old=2015.12 new=fa3c0db) because on both starting points the exit code is 0
14:51 sena_kun left
bisectable6 AlexDaniel, bisect log: gist.github.com/4206bbe1ff3adf2961...6ff145a4ba 14:52
AlexDaniel, (2018-07-31) github.com/rakudo/rakudo/commit/d1...075d38d55f
AlexDaniel more than 10x as fast!
Altai-man_: ↑ it's an old regression but in my heart there's a special place for math that looks wrong :) 14:53
[Tux] Rakudo version 2020.02.1-345-gfa3c0dba9 - MoarVM version 2020.02.1-107-gab089e947
csv-ip5xs0.812 - 0.863
csv-ip5xs-208.291 - 8.731
csv-parser24.109 - 24.569
csv-test-xs-200.389 - 0.390
test7.753 - 7.764
test-t1.953 - 1.985
test-t --race0.974 - 0.993
test-t-2031.697 - 32.021
test-t-20 --race9.131 - 9.863
 15:34
dogbert17 Hmm, shouldn't test-t be around 1.6-1.7 ? 15:48
MasterDuke that was it's lowest, it's been up around 1.9 for a while now 15:51
dogbert17 I wonder when that started 15:54
MasterDuke tux.nl/Talks/CSV6/speed4.html the various graphs would seem to suggest an upward trend starting around a year ago 15:57
dogbert17 interesting 16:02
comparing profiles done with master and 2019.07 respectively one noticable difference is this (although I don't know if it would affect runtime speed very much) 16:42
2019.07: Scalar replacement eliminated 225013 allocations (that's 5.23%). HEAD: Scalar replacement eliminated 88273 allocations (that's 2.12%). 16:43
jnthn dogbert17: Could be that Rakudo got optimizations that mean it creates less in the first place; check the allocations tab to see total numbers 16:45
16:50 sena_kun joined 16:51 Altai-man_ left
dogbert17 jnthn: 2019.07: Scalar 613783 HEAD: Scalar 600922. Looking at all the types in the Allocation tab the only big difference is that HEAD allocates 50000 VMStrings while 2019.07 don't allocate any at all 17:12
timotimo it's quite possible that the patch MasterDuke contributed to moarvm recently caused the difference 18:08
because it gets more allocating ops 18:09
18:11 patrickb joined
patrickb o/ 18:11
MasterDuke dogbert17: yeah, i'd compare against 2020.02 18:27
dogbert17 MasterDuke: will do 18:32
timotimo or cherry-pick the patch 18:34
18:49 Altai-man_ joined 18:51 sena_kun left 19:03 Xliff joined
Geth problem-solving: patrickbkr++ created pull request #178:
Solution for #20: Windows process argument quoting		 19:20
patrickb AlexDaniel: I have not entirely followed the problem-solving procedure in issue github.com/Raku/problem-solving/issues/20 - I created a PR even though I have not been formally asked. Can you turn that PR into a draft? (It seems I can't) 19:27
AlexDaniel patrickb: I also can't, but it's not a big deal
patrickb: what's the status of #20?
patrickb AlexDaniel: Or am I to formal and it's ok for this to just go forward? 19:28
AlexDaniel patrickb: I'm not sure. I see that jnthn is assigned but there was no comment from jnthn
patrickb AlexDaniel: Well I have done all I possibly can on that ticket. There is quite a large analysis, implementation, documentation, tests and solution description. 19:29
AlexDaniel patrickb: yeah, I see that, it's awesome
jnthn It's auto-assigned 'cus it's a language issue, but it also seemed like it was proceeding nicely without me. 19:30
I'll review the solution PR
AlexDaniel jnthn: ah okay! 👍
jnthn++
patrickb: I haven't used windows for so long that it's a bit hard for me to comprehend the issue. It looks so painful 19:32
20:50 sena_kun joined 20:52 Altai-man_ left 21:17 patrickb left 21:24 finsternis left
Geth rakudo/rakuast: cc44b48b44 | (Jonathan Worthington)++ | 5 files
Implement native scalar decls in RakuAST

As well as access to natively typed scalars. There are a couple of other deeper design tweaks here:
  * Now a resolved lexical variable access asks its resolvee how to do
   its code-gen. Since it knows about the declaration's properties, it
... (7 more lines)		 21:28
timotimo does this also allow us to build the correct codegen for "has int8 $!foo" when the access comes before the declaration? 21:59
i'm not sure how exactly it would
that's more of a "when does it get compiled" thing i guess?
[Coke] is qlist a QAST only version of list? 22:21
er, nqp::qlist
m: use nqp; dd nqp::qlist(1,2,3) 22:22
camelia (1, 2, 3)
[Coke] ... guess not qast only.
m: use nqp; dd nqp::list(1,2,3) 22:23
camelia (1, 2, 3)
[Coke] so, what's the difference?
22:29 guifa2 left
timotimo [Coke]:that's from back when list and qlist were two different implementations and we needed to switch things over slowly for some reason 22:47
22:49 Altai-man_ joined 22:52 sena_kun left 23:01 guifa2 joined
jnthn timotimo: I expect that should be fixed aside from any BEGIN sync-point in the middle shenanigans messing it up 23:07
[Coke]: What timo said, and qlist can surely go away; I'd forgotten it was even there 23:08
23:12 guifa2 left 23:13 guifa2 joined 23:28 Xliff left 23:35 j3nnn1 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!