sena_kun awww, constantly failing MISC/bug-coverage-stress-6.d and S17-procasync/kill, my old friends of slow machines 00:00
Geth roast/salortiz-is-List-tests: d9b99c9643 | (Salvador Ortiz)++ (committed using GitHub Web editor) | S32-list/create.t
Attend @vrurg requests
 00:03
00:45 sortiz left 01:06 sena_kun left, Altai-man_ joined 02:06 evalable6 left, linkable6 left 02:07 evalable6 joined 02:08 linkable6 joined 02:48 kvw_5 joined 02:52 kvw_5_ left 03:16 leont left
Geth rakudo: codesections++ created pull request #4209:
Implement space-delimited CLI arguments (S06; S19)		 03:19
09:04 sxmx joined 10:20 Kaiepi joined
lizmat Altai-man_++ # another Rakudo Compiler release! 10:37
El_Che not out yet, but imminent? 10:46
lizmat ah.... ok 11:04
$ raku -v
Welcome to Rakudo(tm) v2020.12-135-g9d5de05f4.
++Altai-man_ 11:05
:-)
11:12 Geth left
Altai-man_ Today. 11:13
I hope.
El_Che Altai-man_: ping me the (pre-) release commits or tags are there so I can build it on the linux distros I package, as a test run 11:46
Altai-man_ El_Che, github.com/rakudo/rakudo/commit/9d...dbb6b57f9c 12:05
El_Che Altai-man_: that commit and HEAD of MoarVM and NQP? 12:06
Altai-man_ El_Che, github.com/MoarVM/MoarVM/commit/37...9d7e5802e0 and github.com/Raku/nqp/commit/57e63c0...f9087e0e68
El_Che my devbuild trigger looks like this: raw.githubusercontent.com/nxadm/ra...vbuild.png
OK, I will trigger it now 12:07
Altai-man_ Some flappers are not flappers on this machine.
When run as a suite, that's why it takes so long.
And as I remember from last discussion fixing kill.t test is impossible or something. 12:08
El_Che Altai-man_: github.com/nxadm/rakudo-pkg/runs/1945853994 12:10
Altai-man_: sadly, github does not show the contents of the steps when not owner (but you can run the tests yourself if you fork the repo) 12:11
everything is building atm
Altai-man_ I wonder what would be first: packages ready or release shipped. 12:12
El_Che I am nog building the packages yet 12:13
this is just to test the release
Altai-man_ Isn't it "tested" by building packages? 12:14
El_Che it's similar
but two workflows
the devbuild does not package and upload them
just doe the build
with tests in debug mode and with optimizer disabled by default (it can be changed in the trigger I posted) 12:15
packages are only created and uploaden when I tag it
ok, everything fails :)
/opt/rakudo-pkg/bin/nqp-m version 2020.12 is outdated, 2020.12-19-g57e63c065 expected. at /__w/rakudo-pkg/rakudo-pkg/rakudo/3rdparty/nqp-configure/lib/NQP/Config.pm line 192. 12:16
so it looks something needs to be adapted at this stage:
+ cd rakudo
+ perl ./Configure.pl --relocatable '--backends=moar' '--prefix=/opt/rakudo-pkg'
Altai-man_ aaaaah 12:18
Or, hmm, I am not sure how this happens. 12:19
t/spec/MISC/bug-coverage-stress.rakudo.moar (Wstat: 256 Tests: 13 Failed: 1)
t/spec/S17-procasync/kill.t (Wstat: 65280 Tests: 8 Failed: 1)
El_Che, I guess release has to happen with bumps pushed for it to work. 12:20
El_Che that is a build check that should be adapted then 12:21
"version 2020.12 is outdated, 2020.12-19-g57e63c065" does not make much sense 12:22
(for after the release)
we could go for 2021.02-rc1 tag or something?
(not trying to slow down the release, it may be idea's for the future)
Altai-man_ no 12:23
Or, at least, not now
El_Che of course
nine El_Che: since you're also packaging rakudo, I wonder how you process the ChangeLog? 12:26
El_Che nine: I wasn't (besides "new upstream version"), but the new packaging system I use make it more feasable to import rakudo's 12:28
nfpm uses this under the hood for changelogs: github.com/goreleaser/chglog 12:29
nine I've found processing changelogs to be about 90 % of the time spent on packaging new releases. But I don't see a way to get around that considering the ~40 line limit and guidelines requesting to omit entries that are not relevant to a user (i.e. purely internal changes or changes affecting other platforms) 12:32
El_Che we could create a TL;DR metachangelog for each release? 12:34
nine Or create only that version. I mean, what do "Move `MVM_{set,get}_running_threads_context` to threadcontext.h" or "Cleanup two redundant returns" mean to the user anyway? If I want to get the full picture in all it's gory details, I can read the git history. 12:41
As a user I look into changelogs when after an update something doesn't work anymore and I want to find out if I need to do something differntly now. Or to find out if there's a chance that a certain bug is fixed already. 12:43
Fixed compiler warnings? Probably not so interesting 12:44
El_Che new features and bug fixes
nine essentially, yes
El_Che www.openldap.org/software/release/changes.html 12:45
I regularly look stuff like that to see if there is something there with negative sonsequences
nine "Move MVM_malloc_trim call after MVM_gc_collect_free_gen2_unmarked call"? What....does that mean? I have spent tons of time in the GC. And even I have to look at the commit in question to actually understand that message
That raises a good point. Maybe instead of the git history, the changelog should list fixed issues instead (plus a manually collected list of new features) 12:47
El_Che yes, so far we have been lucky with monthly releases (besides the dot release some times), but some people may want to pin releases for their apps in the feature 12:49
a semver "promise" could help with that, but that ship has sailed 12:50
Altai-man_ About moarvm changelog 12:51
I think since my first months of releasing it became, erm, kind of clear we have no free resources to make moarvm releases in time, so I am doing it.
It goes without saying I know about nothing about internals, so I am imitating git log. And in fact changelogs written before me go the same way: they do have the same cryptic lines like "Move MVM_malloc_trim call after MVM_gc_collect_free_gen2_unmarked call". 12:52
Erm, to be precise I am imitating how was it done before me, yes, and this imitates git log. 12:53
Even more, I spend time to rewrite such things in "Fix a leak" or something simpler, but it is not always possible.
El_Che Altai-man_: I think moarvm is something special
nine Altai-man_: that's totally understandable
El_Che users should only care about a rakudo tldr changelog, that include moarvm/nqp is user visible 12:54
because moarvm can hypothetically be used by other projects and not directly by users, the changelog could be more into the tech details
masak Altai-man_: you play it down, but that sounds awesome
Altai-man_ Rakudo changelog is better in this. It has clear section of additions/removals/changes/fixes etc, and if you don't want `Internals` section, just don't read it, it's at the end.
El_Che (but because as fas as I know rakudo is the only consumer, I wouldn't worry about that now) 12:55
I think the changelog expectations are different
there is the readable and standalone doc, eg, for the weekly; and there is the debian/openldap like companion changelog, being as brief and pertinent as possible 12:56
masak if the changelog is to have any purpose, it's as a kind of filtered Git log; something that has meaning to highly interested consumers of the software. maybe mostly on the internals/interfaces/API level of things.
El_Che afk, going to have a walk with daughter
13:09 leont joined
Altai-man_ ># Socket path '/home/koto/Devel/perl6-dev/R/rakudo/tools/releasable/temp/rakudo-test/rakudo-2021.02/t/spec/S32-io/test.sock' is too long (max length supported by this platform is 107 characters) 13:42
This is honestly hilarious
lucs Altai-man_: What platform is that? 13:47
Altai-man_ lucs, my gnu/linux box 13:48
lucs Heh.
Altai-man_ m: say $*VM 13:49
camelia moar (2020.12.98.gf.6.c.505.dae)
Altai-man_ Oh dammit. 13:54
Of course I forgot to mention the "not logged" commits... 13:55
releasable6, status
releasable6 Altai-man_, Next release will happen when it's ready. 1 blocker. 35 out of 135 commits logged
Altai-man_, Details: gist.github.com/b505646081d6484d41...415061c63b
Altai-man_ releasable6, status 13:56
releasable6 Altai-man_, Release date for Rakudo 2021.02 is listed in ā€œPlanned future releasesā€, but it was already released.
Altai-man_, and I oop! Backtrace: gist.github.com/b8b01e213cadd8e69f...2534eefa14
Altai-man_ I am kinda confused how this happens. 13:57
`2021-03-20 Rakudo #144 (Altai-man + Releasable)` is what in Future planned releases. 13:58
Ah, now that I posted it I see various grammar mistakes in the changelog. 14:03
Like `Add `MoarVM::SIL` helper module for developers to have better interface` instead of `to have a better interface`.
releasable6, status 14:06
releasable6 Altai-man_, Next release in ā‰ˆ27 days and ā‰ˆ4 hours. 1 blocker. 0 out of 1 commits logged (āš  35 warnings)
Altai-man_, Details: gist.github.com/f5f954458c93ae2d2b...b3a42e1824
Altai-man_ phew
weekly: twitter.com/koto_san_kana/status/1...0431765507 14:08
notable6 Altai-man_, Noted! (weekly)
Altai-man_ I am not really sure I will be able to do it with this hardware next month, heh. 14:11
OTOH maybe I just forgot how to utilize the infra server.
m: say $*VM 14:25
camelia moar (2020.12.98.gf.6.c.505.dae)
14:26 nwc10 left
Altai-man_ m: say $*VM 14:30
camelia moar (2020.12.98.gf.6.c.505.dae)
Altai-man_ it apparently does not like me
nine camelia@camelia:~/log> host -t aaaa -6 github.com 15:40
github.com has no AAAA record
You got to be kidding me...
Altai-man_ m: say $*VM 15:47
camelia moar (2020.12.98.gf.6.c.505.dae)
Altai-man_ ???
evalable6, say $*VM;
evalable6 moar (2021.02)
Altai-man_ phew
nine camelia can't update, because github clings to the 80s 15:51
Altai-man_ ouch
at least it seems the release is not broken in some obvious ways.
maybe in non-obvious ones, ofc
El_Che nine: azure isn't the best ipv6 example 15:52
nine lizmat: t/09-moar/11-inline-hash-key.t (Wstat: 256 Tests: 3 Failed: 1)
[ 557s] Failed test: 1
build.opensuse.org/package/live_bu...5.1/x86_64
lizmat I'm afraid it's a flapper 15:53
El_Che releasable6: status
releasable6 El_Che, Next release in ā‰ˆ27 days and ā‰ˆ3 hours. 1 blocker. 0 out of 1 commits logged (āš  35 warnings)
El_Che, Details: gist.github.com/1cbf5f68726c89d18d...0ff24eb459
El_Che ok, release is out, then?
nine And we didn't know that before the release? 15:54
lizmat well, it's a really sometimes flapper ?
nine so what?
Altai-man_ all tests are clean for me
nine Either tests pass a 100 %, or they must be considered failed. "It passes sometimes" is just not good enough
Altai-man_ nine, awesome. I love it. 15:55
nine, I think it is a great time to address that, given we just had a release and have a month before the next one.
Or whatever time is needed, really.
El_Che there are many flappers in a regular release. If you build enough you see a lot of them
Altai-man_ I'll now create a blocker ticket.
lizmat well, in case of the inline tests, the solution is simple: drop the tests
El_Che if you find it usefull, I can create tickets by running builds in a loop 15:56
nine which tests are known to be affected?
lizmat the inline tests scan the spesh inline log for inlines of things like AT-POS / AT-KEY
it now runs a loop for 1M times, which *should* be enough to inline things, I would guess 15:57
or is there a way that something does *not* get inlined, even if run 1M times ? 15:58
also note that originally the tests ran loops of 100K times, which apparently was not enough
I can expand it to have them run 10M times, but that feels even wronger than upping them from 100K to 1M 15:59
AlexDaniel` nine: well, I've been filing flappers as blockers in the past, that much they annoyed me
lizmat $ ls t/09-moar/*inline* 16:00
t/09-moar/10-inline-array-pos.tt/09-moar/13-inline-comparators-int.t
t/09-moar/11-inline-hash-key.tt/09-moar/14-inline-comparators-str.t
t/09-moar/12-inline-arithmetic.t
AlexDaniel` I believe there was a list of known flappers somewhere
El_Che maybe a meta flapper ticket?
AlexDaniel` but yeah, fixing them is work, so šŸ¤·
Altai-man_ does one
*makes
lizmat so, in case of the inline flappers: I repeat the question: is there a way in which code does *not* get inlined, even when run 1M times?
AlexDaniel` but really, there were just too many, and all of them were kinda weird
Altai-man_ github.com/rakudo/rakudo/issues/4212 16:03
El_Che Altai-man_++ 16:04
Altai-man_ I am not sure we have anything urgent, so can as well investigate this and brag about it next release, whenever it would be. :) 16:05
nine lizmat: you just cannot guarantee that. Spesh runs in a separate thread. Especially on a build machine that's running thousands of jobs a day, it's imaginable that the spesh thread doesn't get scheduled for a second. 16:06
lizmat well, that means that inlining is inherently untestable ? 16:07
nine lizmat: why does SIL not run the command with MVM_SPESH_BLOCKING? 16:08
lizmat because nobody told me to do that ?
nine If you want consistent behaviour, that would certainly take you a whole lot closer 16:09
lizmat so, does that not cloud the issue ?
what I mean is: does that make it completely reproducable ? 16:10
El_Che so far everything is building fine on github 16:11
everything passed on the first run! :) 16:12
more annoying: segmentation faults :( 16:20
make: *** [Makefile:1176: blib/Perl6/BOOTSTRAP/v6c.moarvm] Segmentation fault (core dumped)
lizmat aaah... we lost Geth again ? 16:23
github.com/rakudo/rakudo/commit/d8...2a430e714b # fix inline tests 16:24
nine: ^^
El_Che t/concurrency/03-semaphore.t failed on me 16:28
seen that fail before
lizmat que? 16:30
is that filename correct?
El_Che amd another flapper: t/02-rakudo/10-nqp-ops.t 16:45
nine lizmat: build.opensuse.org/package/live_bu...5.0/x86_64 16:56
[ 351s] t/09-moar/14-inline-comparators-str.t (Wstat: 256 Tests: 7 Failed: 1)
El_Che an another: t/02-rakudo/99-misc.t
nine [ 351s] Failed test: 1
El_Che that one I have seen fail a *lot*
nine Seems to be failing all the time actually: build.opensuse.org/package/show/ho...rl6/rakudo 16:57
El_Che t/09-moar/11-inline-hash-key.t failed as well, but already on the list
(releasing packages as we speak) 17:01
(done) 17:06
lizmat github.com/rakudo/rakudo/commit/85...a536061952 # nine: upped number of iterations 17:17
nine: I'm not sure what else I can do there, other than removing these tests altogether
if these tests are dependent on OS / load / hardware even with MVM_SPESH_BLOCKING set, then I guess we can't test for inlining reliably at all 17:18
or we should run the same test-file 10 times, and only fail if all of the runs fail ?
m: dd Array.list # works! 17:35
camelia (Array,)
lizmat m: dd Hash.list # WOT?
camelia Invocant of method 'list' must be an object instance of type 'Map', not
a type object of type 'Hash'. Did you forget a '.new'?
in block <unit> at <tmp> line 1
Altai-man_ oh no, is it a recent regression? 17:52
I remember documenting something with `list` and `Map`, or not really. 17:53
bisectable6, dd Hash.list
bisectable6 Altai-man_, Will bisect the whole range automagically because no endpoints were provided, hang tight
Altai-man_ 2020.12 has the same thing.
bisectable6 Altai-man_, Output on all releases: gist.github.com/bd0a6a2fe81d2e776a...b83425cf0b
Altai-man_, Bisecting by output (old=2020.06 new=2020.07) because on both starting points the exit code is 1
Altai-man_, bisect log: gist.github.com/62cb062eb2b8631964...1f8fb06d1a 17:54
Altai-man_, (2020-07-06) github.com/rakudo/rakudo/commit/5f...9d346fc713
Altai-man_, Bisecting by output (old=2017.04.3 new=2017.05) because on both starting points the exit code is 1
Altai-man_, bisect log: gist.github.com/7fb0a29b31384cb241...03b0445870
Altai-man_, (2017-04-27) github.com/rakudo/rakudo/commit/85...a6de601921
Altai-man_, Bisecting by exit code (old=2017.01 new=2017.02). Old exit code: 0
Altai-man_, bisect log: gist.github.com/f6933451ae3335c692...398424c2c2
Altai-man_, (2017-01-23) github.com/rakudo/rakudo/commit/2f...01b8cba8d5
Altai-man_, āš  New output detected, please review the results manually 17:55
Altai-man_, Output on all releases and bisected commits: gist.github.com/53a19fad23316721ed...29a5ed33c8
Altai-man_ Not a regression for sure, I guess.
AlexDaniel` well, that worked beautifully, but omg the amount of messages
the threshold should probably be at 2 bisect runs, not 3 17:57
18:01 Altai-man_ left 18:03 sena_kun joined
MasterDuke lizmat: what about running the test file repeatedly and the whole thing succeeding if one run succeeds? i.e., just prove that the given function can be inlined, not that it always is 18:19
lizmat well, I guess depends on what we want to test, doesn't it 18:20
18:21 Geth joined
lizmat but if inlining isn't always happening even with MVM_SPESH_BLOCKING, isn't there something wrong with MVM_SPESH_BLOCKING ? 18:21
MasterDuke dunno 18:23
Geth rakudo: 733c7f1c33 | (Christian BartolomƤus)++ | t/02-rakudo/03-corekeys-6e.t
Fix typo in test description
 18:37
nine lizmat: these tests are there to ensure that stuff will get inlined at some point, right? 18:43
lizmat right, so we don't have regressions (like we have had in the past) 18:44
I guess MasterDuke's idea of running a test X times, and accept as passed as soon as any of them passes is the best 18:45
nine They are not meant to ensure that inlining happens within a certain time or number of repetitions, righ?
lizmat , is the best idea
nope, they're there to ensure that inlining happens with sufficiently hot enough code
and that "sufficient" is apparently different in different corcumstances 18:46
nine But that's just "inlining must happen for hot code", not "inlining must happen on hot code withing 750 iterations"
lizmat indeed
but as we have seen, sometimes even 1M times is not enough 18:47
nine so why have the iteration limit in the test?
lizmat because we can only find out if something has been inlined from the spesh inline report, which is only available *after* the subprocess completes ?
nine According to what the test is supposed to check, it should not matter if it happens within 700 or 20 million iterations. All that matters is that it eventually does. So that's what the test actually should check
But the log is written during runtime? 18:48
lizmat I think it is in that case, yes
nine Btw. I've just had t/09-moar/14-inline-comparators-str.t failing on my own machine with nothing else happening and with the patch modified to set MVM_SPESH_BLOCKING but do 1 million iterations 18:49
Somethings definitely fishy there
lizmat but still, if after 20M iterations there is no inlining, should we go to 100M ?
well, there's that: that it *does* indicate an issue with inlining :-)
or with the spesh inline log, of course :-) 18:50
nine dinner &
lizmat git diff
oops
Geth rakudo: 6b83135a0b | (Elizabeth Mattijsen)++ | 2 files
Make sure Map / Array type objects iterarize / list ok
 18:52
bartolin lizmat: do you maybe remember if there was a specific reason to refer to '< await >' in github.com/rakudo/rakudo/blob/mast...-6.d.t#L59 while the tests for 6.c and 6.e to all lowercase subs (github.com/rakudo/rakudo/blob/mast...-6.c.t#L58 and github.com/rakudo/rakudo/blob/mast...6.e.t#L58) 19:09
lizmat doesn't ring an immediate bell, I'm afraid 19:12
sorry
bartolin np. I'm looking at failing tests for the JVM and noted that inconsistency. I guess it wouldn't hurt to change the test to use @lower as well ... 19:14
lizmat go ahead :-) 19:16
Geth rakudo/xxxmap-reimagined: 412d7706b6 | (Elizabeth Mattijsen)++ | 4 files
Re-imagine xxxmap, makes >>. about 2x as fast

This commit completely re-imagines the nodemap / deepmap / duckmap functionality, makes them about 2x as fast with about 1/8 of the memory churn (in a benchmark of `my @a = ^1000; @a>>.++ for ^1000`) So what does this do:
... (16 more lines)		 19:24
rakudo: lizmat++ created pull request #4215:
Re-imagine xxxmap, makes >>. about 2x as fast
20:10 finsternis joined 21:39 Kaiepi left 21:42 raiph joined 22:32 Kaiepi joined 22:35 raiph74 joined 22:36 raiph74 left 22:37 raiph 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!