00:01 sena_kun joined 00:03 Altai-man_ left 00:47 Kaiepi left 01:35 Kaiepi joined 01:48 vrurg left, vrurg joined 02:00 Altai-man_ joined 02:03 sena_kun left 03:05 lucasb left 04:02 sena_kun joined 04:04 Altai-man_ left 05:24 Kaiepi left 05:25 Kaiepi joined 06:01 Altai-man_ joined 06:03 sena_kun left 06:39 lichtkind_ joined 06:51 lichtkind_ left
Altai-man_ lizmat, gist.github.com/Altai-man/026a5bb1...ed38681ca1 07:54
08:02 sena_kun joined 08:04 Altai-man_ left
nine How can our code gen expect @END_PHASERS to be both a VMArray and an Array at the same time? 08:31
The answer is: it expects it to be an NQPArray type which is a VMArray with an unshift method. 08:36
09:47 softmoth left 10:01 Altai-man_ joined 10:03 sena_kun left
[Tux] Rakudo version 2020.06-7-gf1960baa9 - MoarVM version 2020.06-6-gbf6af07de
csv-ip5xs0.818 - 0.830
csv-ip5xs-207.646 - 7.720
csv-parser25.637 - 25.739
csv-test-xs-200.382 - 0.419
test7.700 - 7.749
test-t1.844 - 1.873
test-t --race0.819 - 0.843
test-t-2031.169 - 31.886
test-t-20 --race8.961 - 9.752
 11:14
11:15 Kaiepi left 11:43 Kaiepi joined 12:02 sena_kun joined 12:04 Altai-man_ left 12:25 Kaiepi left, Kaiepi joined
lizmat sena_kun thanks for the blin run 13:10
looks like Log::Async is a false positive, with fb6a12a as a commit 13:11
sena_kun lizmat, welcome. Consider taking a rest, it's Satruday. :)
lizmat hehe...
sena_kun Yeah, it is. I usually clean up false positives, but decided not to, it's a bit tiresome when blin runs are everyday.
lizmat okidoki... just wanted to check... 13:12
so Log::Async has a flapper, does its maintainer know
?
sena_kun I looked at how can it be better, actually, judged I am not really good enough right now.
lizmat, yeah
lizmat ok, again, thanks for the run 13:13
AlexDaniel sena_kun just an idea: if a commit produces identical .moarvm files to the previous commit, maybe it should be excluded from bisectng ? 13:19
AlexDaniel why?
like, what would it solve? 13:20
lizmat in the last Blin run, having Log::Async being flagged to a comment only change commit 13:21
AlexDaniel which is very indicative that it's a flapper
lizmat ah, ok, well, mark a flagged module as a flapper if the bisected commit is a comment only one ? 13:22
AlexDaniel hmmmmmmmm
lizmat just an idea to prevent more work by sena_kun and me in this case :-) 13:23
sena_kun Better to increase the number of runs to detect flapping.... Which is actually useless because you need to process around 1500 modules on a heavy-loaded machine and `sleep 0.1` code will just fail.
The nice solution is to fix all flappers. ;)
AlexDaniel sena_kun: it only attempts to deflap things that it will bisect 13:24
that is, only if there's good→bad transition between the endpoints
so you can actualy increase it significantly 13:25
bisection takes around 11 steps I think, so anything lower than can even speed things up (in some cases) because it will skip bisection and just say that it's a flapper
than that*
lizmat: it's a very interesting idea indeed. For example, there's already this check: 13:26
bisectable6: old=2015.12 say rand
bisectable6 AlexDaniel, Bisecting by output (old=2015.12 new=f1960ba) because on both starting points the exit code is 0
AlexDaniel, bisect log: gist.github.com/b07b235bcf160191ee...459e3d1877 13:27
AlexDaniel, (2015-12-25) github.com/rakudo/rakudo/commit/07...dc61f84053
AlexDaniel, The result looks a bit unrealistic. Most probably the output is different on every commit (e.g. ｢bisect: say rand｣)
lizmat nice
AlexDaniel that said, Log::Async appears as flapper for almost every blin run, so maybe just fixing the damn module is a good idea regardless of what I do to whateverable
lizmat: I'm not sure if .moarvm file is actually identical between the commits… maybe only since reproducible builds became a thing? 13:29
lizmat lemme actually test that assumption
AlexDaniel I expect it to be true, but only for recent-ish rakudo commits. Which is good for Blin! But maybe not perfect for bisectable6 13:31
lizmat probably
Geth rakudo/match-refactor: bda3a5dcfb | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Always look in Capture stack first for :exists

Since we only want to know whether something exists, we can first go through the capture stack, as that will short-circuit when the name is found. Only if that fails, check for the name in the capnames hash.
rakudo/match-refactor: 086a9772b4 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Use ifnull for the capnames test

Simplifies the check for :exists, as well as AT-POS/AT-KEY		 13:33
nine No, .moarvm files won't be identical since the compiler's id contains the SHA of the full source code 13:35
lizmat ah, ok, then scratch that idea :-)
AlexDaniel sena_kun sorry for the noise
AlexDaniel nine: bummer
github.com/Raku/whateverable/issues/378 13:38
anyway, it's an interesting idea, I like it
I'd be really happy to remove that hardcoded check 13:39
nine Incidentally, the main reason for hashing the full source in the first place was making builds reproducible. Before that we used the build time stamp 13:40
AlexDaniel sure, using the timestamp was wrong right away… 13:45
but hmm another option would be to use like a hash of all source files, or something like this
nine that's what we do right now? 13:46
AlexDaniel ah, I completely misread you, nevermind :)
need more coffee I guess
nine: I confused git SHA with source code SHA x) I go hide now 13:47
nine Well, there's not much difference between those :) 13:48
AlexDaniel well, not exactly, because info of the commit itself is part of the sha 13:50
that is you can make many commits and you'll end up with different shas, even if the source is the same 13:51
oh, TIL `git commit --allow-empty` 13:52
nice
dogbert17 lizmat: Algorithm-ZhangShasha seems to be another false positive (or flapper)
nine Flappers really should be treated like any other test failure, i.e. bug. They clearly show that something's wrong. 13:54
AlexDaniel nine: well, when Blin says that something is a Flapper it means that it flaps on both “old” and “new” revisions 14:00
so it's a bug, but in the module itself
if it doesn't flap on “old”, then it will actually try to bisect it I think (but without deflapping on each step), and will give a wrong result :(
so if you see tens of weird results in blin, it means that rakudo itself is flapping 14:01
14:01 Altai-man_ joined
AlexDaniel it can be improved, I think there's a ticket about it somewhere 14:01
lizmat afk for a few hours&
nine Can still be a bug in rakudo, just one that's been there for longer
Altai-man_ Log::Async is clearly a case of tests written with sleep and on heavy load other threads don't catch up. 14:02
AlexDaniel nine: yeah, but what can I do. Release managers or those helping with releases tend to file tickets when they notice flappers, like github.com/bduggan/p6-log-async/issues/28 14:03
nine Oh, yes, using sleep in tests is horrible
AlexDaniel but there are so many modules that have flapping tests that it's hard to even propose that a Flapper status in blin can mean something else than just a module having shitty tests
14:03 sena_kun left
AlexDaniel I'm working on a PR for Log::Async, hang tight :) 14:04
nine It's sad to se so much use of sleep in a language with such great async primitives. But we do that even in our own tests
Altai-man_ applauds
AlexDaniel nine: let's see if you find and hints of frustration here 14:15
nine: “MoarVM panic: Internal error: Unwound entire stack and missed handler” 14:16
great async primitives but you can't `return` from a react block
14:18 camelCaser joined, ccamel left
AlexDaniel bisectable6: sub foo() { react whenever Promise.in(1) { return 42 } }; say foo 14:20
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel should've given something smaller than 1…
bisectable6 AlexDaniel, Output on all releases: gist.github.com/6d93cbb21a10eb22e0...177928edc0 14:21
AlexDaniel, Bisecting by output (old=2016.11 new=2016.12) because on both starting points the exit code is 1
AlexDaniel don't bother, bisectable6
bisectable6 AlexDaniel, bisect log: gist.github.com/ec564c15e03d06fc01...c16ff9fd62
AlexDaniel, (2016-12-13) github.com/rakudo/rakudo/commit/a9...edae694199
AlexDaniel, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/34cfbaf654b765e031...eb583bc109 14:22
AlexDaniel, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
AlexDaniel, Output on all releases and bisected commits: gist.github.com/d390037ed825ada196...4fdae5f809
AlexDaniel R#3772 14:23
linkable6 R#3772 [open]: github.com/rakudo/rakudo/issues/3772 [ASYNC] Can't return from a react block
nine AlexDaniel: at least I said "great", not "perfect" :D 14:24
AlexDaniel I'd describe that as funky 14:26
14:32 Geth left, Geth joined
jnthn Making it work is pretty funky too: catch the control exception, somehow convey it back to the awaiting thread, and rethrow it there. 14:42
Probably possible.
nine Second in-process precomp issue fixed today. Continuing my average of 1 fix per day. 5 spec test files still failing 15:10
AlexDaniel can somebody review this? github.com/bduggan/p6-log-async/pull/30 15:50
maybe there are better solutions
nine: ↑ 15:52
Altai-man_: any other common flappers? 16:02
16:02 sena_kun joined
AlexDaniel sena_kun: ↑ 16:02
sena_kun AlexDaniel, Async::Cache, I think? 16:03
16:04 Altai-man_ left
nine AlexDaniel: why only 3 seconds time out? 16:12
AlexDaniel nine: make it an hour to make these big endian machines happy? :) 16:13
nine sure
AlexDaniel but seriously, what should I change it to?
there are other tests that do `sleep 1` soo… I'm just scratching the surface here 16:14
nine I'd say even a couple of minutes would be fine. The time out only matters if there's an actual bug which would otherwise cause a hang, i.e. pretty much never
If such a bug creeps in, you will usually not run those tests dozens of times while ignoring the bug. You'll investigate anyway and then the default timeout doesn't matter 16:15
AlexDaniel fine 16:18
c36052f0f793d22
ahhh linkable6 doesn't work that fast
github.com/bduggan/p6-log-async/pu...7f02dcba9d
my reasoning – if we break something in rakudo we'd have to bisect this module, so the bigger the timeout, the more you'd have to wait for bisection to finish 16:19
so having it too high can also be less than awesome, especially in the presence of other sleep tests that are more sensitive 16:20
nine ok
changes make sense to me 16:22
dogbert17 t/spec/S17-procasync/kill.t is a wellknown flapper 16:23
AlexDaniel oooooooh spectests 16:25
right
let's see
dogbert17 only fails under load (test #5) 16:26
AlexDaniel I've been running raku-cache-async without any issues, so yeah, next
dogbert17 # Failed test 'signal SIGINT got handled' - # at t/spec/S17-procasync/kill.t line 47 - # expected: '0' - # got: '2' 16:27
16:28 softmoth joined
AlexDaniel yeah, it easily flaps 16:41
so how come SIGINT propagates to .signal sometimes? 16:44
ooooooooooh it's cuz it's too fast 16:45
that looks like a language trap to me, actually 16:47
if you want to set up a signal handler, it has to be reaaaally early in the program 16:48
and even then it's possible that your handler won't be set up in time because of the slow startup of rakudo
interesting
jnthn I don't think it's about slow startup, I think it's because putting the handler in place is an async operation 16:49
It's the case with various things, but for most it doesn't matter. I guess here it kinda does.
(we dedicated a thread to libuv, and send async stuff to it, and it gives stuff back to us async) 16:50
AlexDaniel well my hypothesis is that the klil signal comes before the handler is set
but I could be wrong
there's this other failure I see: 16:51
# You planned 7 tests, but ran 8
jnthn Who sends the kill signal, though?
AlexDaniel the test file 16:52
it starts a new program with `signal(\qq[$signal]).act: { .say; exit };` in it, then it kills it 16:53
so I'm actually a bit surprised that it can pass
jnthn Ohh, I see.
AlexDaniel ah wait, I'm misreading it. It waits for output first
right, but then you're actually correct, the handler setup is async so it's a bit too quick to respond there 16:54
so the process does `say 'Started';`, and the test file immediately kills it, with no time for the process to get ready
or, well, with very little time there
jnthn Right, the message is still being dealt with by the event loop thread while the Started output is being sent 16:55
I guess we'd sorta like some kinda "ack" to know it was set up
Probably something we should fix in signal(...) 16:57
If our tests run into it, somebody else will too
AlexDaniel I can rewrite the test nicely with react/whenever though 16:59
or… hm… maybe not really 17:00
jnthn I'm not sure that'd help, if I understand the issue correctly
AlexDaniel yeah, I see that now :S
like, I can maybe hack something with SIGUSR1 to see that the handlers are kinda there… but yeaaah… 17:01
ShimmerFairy Doesn't the signal installer give you a Promise or something that can tell you when it's done installing, and you can wait to print "Started" until then? 17:06
AlexDaniel well, it gives you a supply object right away. I expected it to only do that once the supply is fully functional and the handler is there, but apparently that's not the case? 17:11
jnthn No, that's not the case 17:23
For many things (like a timer), it doesn't much matter
But for signals and maybe filesystem watchers it's trappy 17:24
And given it's one of the easier traps to fix, I think we should do that. :)
18:01 Altai-man_ joined 18:03 sena_kun left 20:02 sena_kun joined 20:04 Altai-man_ left
nine AlexDaniel++, jnthn++ # finally making sense of this flapper 20:47
AlexDaniel sourceable6: signal(2) 21:01
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/f196...ls.pm6#L16
21:12 softmoth left
AlexDaniel jnthn: so I was thinking, maybe I can try passing CurrentThreadScheduler to signal() to make a difference? I don't know if it will work, but turns out it does .queue instead of .cue so I get “No such method 'queue'” currently, is it wrong? github.com/rakudo/rakudo/blob/f196...ls.pm6#L46 21:13
tho, I can still give it a ThreadPoolScheduler with 1 max thread, and then do `say 'Started'` 21:15
don't know if it's a big brain idea or small brain one
I mean, .cue({ say 'Started'}) 21:16
now I'm back to the other “You planned 7 tests, but ran 8” issue which seems to be different, investigating… 21:17
ah no, it didn't fix anything, alright… 21:18
21:19 softmoth joined
lizmat Q: what is the signature for a sub to accept a native int array of *any* size? 21:24
m: sub a(byte @a) { dd @a }; my byte @b = 1,2,3; a @b 21:26
camelia array[byte].new(1, 2, 3)
lizmat which would lead you to think you could say:
m: sub a(array @a) { dd @a }; my byte @b = 1,2,3; a @b # alas 21:27
camelia 5===SORRY!5=== Error while compiling <tmp>
Calling a(Positional[byte]) will never work with declared signature (array @a)
at <tmp>:1
------> 3rray @a) { dd @a }; my byte @b = 1,2,3; 7⏏5a @b # alas
AlexDaniel nine: halp. What did you mean here? d298eb2326aec66efd
linkable6 (2020-03-28) github.com/Raku/roast/commit/d298eb2326 Fix flappy timing based Proc::Async::kill tests
AlexDaniel nine: I'll explain. This line doesn't even run: github.com/Raku/roast/blob/998d247...kill.t#L41 21:28
nine: so when it does run, the test count is wrong
lizmat feels to me that github.com/rakudo/rakudo/blob/mast...y.pm6#L558 should be externalized?
AlexDaniel nine: if I add a sleep in between these lines, then it always runs! github.com/Raku/roast/blob/998d247....t#L34-L35
21:29 hoelzro left, Xliff left, hoelzro joined 21:36 softmoth left
AlexDaniel ahhhhhh it's related to stdout caching, I think… 21:50
not caching but buffering
22:01 Altai-man_ joined 22:04 sena_kun left 22:10 lucasb joined
AlexDaniel so I can only .kill a process once?????? 22:46
whaaaaaaat
timotimo that can't be right 22:47
maybe it's for the benefit of windws systems that don't have any other signal besides "kill" 22:48
AlexDaniel whaaaaat 22:49
wait it does work, but then it also doesn't work… hold on
timotimo you should perhaps strace or perf trace it 22:50
AlexDaniel timotimo: can you try it? My mind goes insane a bit. Here's a script 22:52
timotimo: gist.github.com/AlexDaniel/c624be8...5197795a8e 22:53
so it should send SIGTERM, SIGTERM, SIGKILL
whatever happens in the bash script doesn't really matter BECAUSE IT'S SIGKILL 22:54
but the process keeps going?
I was just playing with this flapping tests, trying out different things
and I thought, well, what if I try to test it with SIGUSR1 first and only then try the SIGINT stuff 22:55
timotimo ah i wish the thread pool scheduler could be made to kick in a little less often
it spams the t,race log quite heavily
AlexDaniel and I wasted like an hour trying to figure out why the signal is not received, but it turns out that it is not being sent? whaaat
I mean… SIGUSR1 is not a thing on windows, I guess? So that's a wasted effort anyway 22:56
let's maybe run it on all releases? 22:57
e: gist.github.com/AlexDaniel/c624be8...5197795a8e 22:58
evalable6 (exit code 1) 04===SORRY!04=== Er…
AlexDaniel, Full output: gist.github.com/514b1bca9616d91de8...7aff315402
timotimo 0.000 ( 0.014 ms): :20677/20677 kill(pid: 20680 (bash), sig: TERM) = 0
TERM
AlexDaniel e: gist.github.com/AlexDaniel/c624be8...5197795a8e 22:59
huh?
timotimo the process gets killed via spawn_cancel 23:00
so i imagine after that point there is no longer a task in the event loop that corresponds to the process
AlexDaniel c: HEAD gist.github.com/AlexDaniel/c624be8...5197795a8e
committable6: help? 23:01
committable6 AlexDaniel, Like this: committable6: f583f22,HEAD say ‘hello’; say ‘world’ # See wiki for more examples: github.com/Raku/whateverable/wiki/Committable
AlexDaniel c: HEAD gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel c: HEAD say 42
I have no idea… 23:02
23:03 evalable6 left 23:04 committable6 left 23:06 committable6 joined
AlexDaniel committable6: HEAD say 42 23:07
committable6 AlexDaniel, ¦HEAD(f1960ba): «42␤»
AlexDaniel committable6: HEAD gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel, ¦HEAD(f1960ba): «2613␤TERM␤SIGKILL not sent, absolute failure␤ «exit code = 42»» 23:08
AlexDaniel 6c: gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
timotimo did you har what i sad 23:09
committable6 AlexDaniel, gist.github.com/024379e1ccbe557a13...cb39ee25d7 23:10
AlexDaniel timotimo: yes, but I did not comprehend it
timotimo "yeah we'll only ever kill a process once"
perhaps i misread the code
because i pretty much only read like five lines 23:11
AlexDaniel 6c: gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel timotimo: so, that kinda sucks? 23:12
timotimo yeah, we'd need a separate implementation for general-purpose signal sending
there's also processes we haven't started that we may want to signal
we may already have wanted something for that anyway 23:13
AlexDaniel but how did I write this snippet then? docs.raku.org/type/Proc::Async
I'm pretty sure I did test the SIGKILL part
timotimo couldn't tell ya :| 23:14
didn't look when the code around that location changed
AlexDaniel well, committable should come back to us soon…
committable6 AlexDaniel, gist.github.com/fbad4427402b414360...81ddf10fb7
AlexDaniel it needs a `done` 23:15
6c: gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel, gist.github.com/41c94301806b1be385...dbc7219f0a 23:18
AlexDaniel timotimo: that makes sense?
bisect: old=2017.10 gist.githubusercontent.com/AlexDan...ll-what.p6
bisectable6 AlexDaniel, Successfully fetched the code from the provided URL 23:19
AlexDaniel, Bisecting by exit code (old=2017.10 new=f1960ba). Old exit code: 0
timotimo where did uname come from
bisectable6 AlexDaniel, bisect log: gist.github.com/964af5ee77bb8c3540...610f5ead7d 23:20
AlexDaniel, (2017-11-14) github.com/rakudo/rakudo/commit/03...6709fc608c
AlexDaniel timotimo: I think old rakudo versions did something dumb like trying to use the shell to run uname, or something 23:22
apparently it's not an issue anymore
Geth: ver github.com/rakudo/rakudo/commit/03...6709fc608c
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....0-g7532371
AlexDaniel Geth: ver github.com/Raku/nqp/commit/7ce25e2...5309573e59 23:23
Geth AlexDaniel, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/2...1-g8744857
AlexDaniel that's not the one
Geth: ver github.com/rakudo/rakudo/commit/03...6709fc608c
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....0-g7532371
AlexDaniel Geth: ver github.com/Raku/nqp/commit/7532371...3f07de80d4
Geth AlexDaniel, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/2...5-ge694386
AlexDaniel timotimo: is this anywhere near the code you were looking at? 23:24
timotimo yes
AlexDaniel which one?
timotimo github.com/MoarVM/MoarVM/compare/2...896ac76R60
23:24 evalable6 joined
timotimo i think this is more about "cancel before it was properly started" though 23:24
AlexDaniel timotimo: alright… can you file a bug report? My brain is toast 23:25
timotimo i need a nap and then i'm hoping to be continuing with new-disp, but this irclog should be enough to get me or someone else up to speed to file the bug later
AlexDaniel c: 0378292e4^,0378292e4 gist.githubusercontent.com/AlexDan...ll-what.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel, ¦0378292e4^: «TERM␤finished␤0␤9␤» ¦0378292: «TERM␤SIGKILL not sent, absolute failure␤ «exit code = 42»»
AlexDaniel this is absolutely the one
okay, have a good nap! 23:26
.tell timotimo please file a ticket about .kill! Thanks! colabti.org/irclogger/irclogger_lo...06-27#l261 23:30
tellable6 AlexDaniel, I'll pass your message to timotimo 23:31
AlexDaniel .tell jnthn can you file a ticket about signal()? You definitely can describe it better than me. Thanks! colabti.org/irclogger/irclogger_lo...06-27#l194 23:32
tellable6 AlexDaniel, I'll pass your message to jnthn
23:37 AlexDaniel left

Powered by Cro and the Raku® Programming Language.

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

Thank you!