00:25 SmokeMachine left 00:26 SmokeMachine joined 00:52 Kaiepi left 00:53 Kaiepi joined 01:30 rypervenche left 01:33 rypervenche joined 01:34 sena_kun left 01:49 sena_kun joined 01:54 AlexDaniel left 02:11 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Add Compiler.backend method 02:11
travis-ci.org/rakudo/rakudo/builds/649667638 github.com/rakudo/rakudo/compare/1...b416edb96d
02:11 travis-ci left 02:13 MasterDuke left 03:34 sena_kun left, robertle joined 03:48 sena_kun joined 04:03 tobs left 04:28 tobs joined 04:50 hungrydonkey left 04:58 hungrydonkey joined 05:08 Kaiepi left 05:14 squashable6 left 05:17 squashable6 joined 05:34 sena_kun left 05:47 sena_kun joined 06:19 moon-child left, moon-child joined 07:07 jmerelo joined
jmerelo This persistent error is rather annoying travis-ci.com/Raku/doc/builds/1487...urce=email 07:07
It fails in different files, almost always in that test, but sometimes in others, too
It's the same error as here: github.com/MoarVM/MoarVM/issues/943 07:10
07:33 sena_kun left 07:37 domidumont joined
nine japhb: :api is treated as a version (passed to Version.new). We don't put that many restrictions on versions. They may even be more free than the components that make up a module's short name. 07:45
m: say Version.new("Foo") 07:46
camelia vFoo
07:47 sena_kun joined
lizmat Files=1302, Tests=110400, 210 wallclock secs (28.92 usr 8.41 sys + 2940.00 cusr 279.21 csys = 3256.54 CPU) 07:54
Geth nqp: f6eb0c2143 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get srand / rand_I fixes, MasterDuke++
 08:03
nine jmerelo: have you tried what jnthn++ suggested in that MoarVM ticket? Have you tried --ll-exception?
jmerelo nine: I can try and add that to the Travis configuration, I guess... 08:04
nine So you can't reproduce the issue locally? 08:05
jmerelo nine: it's a flapper. Happens from time to time locally or in Travis You look at history travis-ci.org/Raku/doc/builds, most fails are not real fails, but that kind of error 08:06
nine: this one, for instance travis-ci.org/Raku/doc/builds/648769290
nine: or this one travis-ci.org/Raku/doc/builds/649442291 08:07
nine: happens once every 10 times or so. Used to be more, but as I say, it totally flaps.
nine In that case I'd run it like `while perl6 -Ilib t/02-tests-valid.t ; do true ; done` to reproduce locally. That's still much nicer than waiting for Travis to fail 08:08
jmerelo nine: it does not depend on Rakudo version, either. It's been happening for as long as I remember. And it does not always fail in the same place, but it does tend to happen there. But OK, I'll do that
nine: it does fail locally after a while 08:12
nine: you can check it out yourself, it's just the normal Raku/doc repo 08:13
Geth rakudo: f95bf76a7b | (Elizabeth Mattijsen)++ | 2 files
Bump NQP to get srand / rand_I fixes

  - MasterDuke++
  - also re-enable and extend tests
  - Fixes R#3469		 08:14
linkable6 R#3469 [closed]: github.com/rakudo/rakudo/issues/3469 [BLOCKER][regression] Varying results despite fixed srand seed
jmerelo nine: --ll-exception does not add a lot of light, since it does not seem to be a Failure. It simply fails. Also with the options suggested by jnthn 08:15
nine Well that means it's not a spesh or JIT issue and not happening due to parallel run of test files. 08:18
08:19 jmerelo left
lizmat wonders whether vrurg has any ideas about github.com/rakudo/rakudo/issues/3478 08:37
08:42 hungrydonkey left
nine Intruiging. I've had that test running for quite a while in a loop and it didn't fail. Then I ran the whole test suite (with just one job concurrently) and bang 08:47
Oh, the test is using 2 threads! I start to think that this may actually be a bug in p6doc 08:48
Geth roast: dd77e18ca2 | (Elizabeth Mattijsen)++ | S32-str/contains.t
Add tests for invalid position handling
 08:51
08:54 hungrydonkey joined 08:59 MasterDuke joined
Geth roast: 007a9df08e | (Elizabeth Mattijsen)++ | S32-str/substr-eq.t
Add tests for Str.substr-eq(:i, :m)
 09:03
09:07 domidumont left
Geth rakudo: 5e9d98c2a5 | (Elizabeth Mattijsen)++ | 3 files
Change extension of install-core-dist to .raku
 09:24
rakudo: ea1cb40750 | (Elizabeth Mattijsen)++ | 3 files
Change extension of upgrade-repository to .raku
09:24 domidumont joined
lizmat a configure will be needed after this 09:24
Geth rakudo: 3b8104ec77 | (Elizabeth Mattijsen)++ | 3 files
Change extension of makeMAGIC_INC_DEC to .raku
 09:30
rakudo: 4677f7416b | (Elizabeth Mattijsen)++ | 3 files
Change extension of makeNATIVE_ARRAY to .raku
rakudo: ac652c0ecd | (Elizabeth Mattijsen)++ | 3 files
Change extension of makeNATIVE_SHAPED_ARRAY to .raku
lizmat afk for a few hours&
09:34 sena_kun left 09:39 hungryd90 joined 09:42 hungrydonkey left 09:47 sena_kun joined 09:52 Kaiepi joined, Kaiepi left 09:53 Kaiepi joined
nine I think, I know what's going on with those p6doc tests 09:57
10:02 hungrydonkey joined 10:03 hungryd90 left
|Tux| Rakudo version 2020.01-172-gac652c0ec - MoarVM version 2020.01.1-37-g3c48ebaa9
csv-ip5xs0.719 - 0.740
csv-ip5xs-205.743 - 6.119
csv-parser22.393 - 22.691
csv-test-xs-200.365 - 0.370
test7.203 - 8.052
test-t1.713 - 1.783
test-t --race0.781 - 0.782
test-t-2029.176 - 29.505
test-t-20 --race8.338 - 8.795
 10:09
10:30 patrickb joined
Geth rakudo: f5ce80e1a6 | (Stefan Seifert)++ | 2 files
Fix concurrency issue with re-checking a precomp file's dependencies

When the repository's identity changes (whether through changes in source files or a `use lib` after loading modules) we re-check dependencies of precomp files as the change may have brought in a new version of a dependency. We store the resulting repo-id in the precomp store in the form of .repo-id files accompanying the precomp files. When writing those files we didn't protect ... (5 more lines)		 10:35
nine jmerelo: github.com/rakudo/rakudo/commit/f5ce80e1a6 fixes p6doc's tests 10:36
jmerelo: but please fix those late `use lib` in test files. You could probably just remove them as they're not used consistently anyway 10:41
Geth rakudo: e572320876 | (Elizabeth Mattijsen)++ | 3 files
Change extension of makeSLICE to .raku
 11:26
rakudo: deac4407d4 | (Elizabeth Mattijsen)++ | 3 files
Change extension of makeUNIPROP to .raku
sena_kun dogbert11: is github.com/MoarVM/MoarVM/issues/1237 reliable? 11:28
lizmat sena_kun: it was for me last week 11:29
Guest4508 sena_kun: it always happens after a random number of iterations 11:30
it should be noted that this is not a 'new' bug
11:33 sena_kun left 11:37 squashable6 left 11:39 squashable6 joined
lizmat sena_kun: still does for me on HEAD 11:39
Geth rakudo: 8fd7172c0f | (Elizabeth Mattijsen)++ | 6 files
Update she-bang of tools/build .raku scripts
 11:40
11:47 sena_kun joined
lizmat m: dd 1 Xxx 1 # is this correct ? 11:49
camelia ((1,).Seq,).Seq
lizmat perhaps X should flatten whatever it produces ? 11:50
sena_kun if it won't break anything... which I somehow, to be honest, doubt, no? 11:51
jnthn Don't think so, we'd not want that in general?
lizmat this is about github.com/rakudo/rakudo/issues/3444 11:52
jnthn hmm. 11:55
lunch, bbiab
12:04 Kaiepi left
Geth rakudo: c7e0df64cb | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Change signature on .rotor

  - as a fix for R#3444
  - the described problem occurred in the handling of the rotor spec
   *not* in the actual running of the .rotor function
  - not 100% sure this is the right solution
  - is spectest clean		 12:05
linkable6 R#3444 [open]: github.com/rakudo/rakudo/issues/3444 Code produces "Seq is already in use/consumed" error once, but subsequently works.
12:07 Kaiepi joined
Geth roast: 0e07a4d5c9 | (Elizabeth Mattijsen)++ | S32-list/rotor.t
Add test for R#3444
 12:09
linkable6 R#3444 [open]: github.com/rakudo/rakudo/issues/3444 Code produces "Seq is already in use/consumed" error once, but subsequently works.
Geth rakudo: 7b679604c8 | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/CREDITS to .raku
 12:19
rakudo: 416fd513c3 | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/contributors to .raku
 12:20
rakudo: ca99c7ca6a | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/create-release-announcement to .raku
rakudo: 5437517935 | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/release-dates to .raku
 12:21
rakudo: 82ea32928e | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/speedup to .raku
 12:22
rakudo: 4ec31e2cd2 | (Elizabeth Mattijsen)++ | 2 files
Change extension of tools/install-dist to .raku
 12:23
rakudo: af292586a3 | (Elizabeth Mattijsen)++ | 6 files
Update she-bangs of tools/*.raku scripts
 12:24
rakudo: 81014e7881 | (Elizabeth Mattijsen)++ | tools/install-dist.raku
Make tools/install-dist.raku internally consistent
 12:26
12:34 lucasb joined
nine [ 339s] cp: cannot stat 'tools/install-dist.p6': No such file or directory 12:45
[ 339s] error: Bad exit status from /var/tmp/rpm-tmp.VWFvKK (%install)
build.opensuse.org/package/live_bu...eed/x86_64
lizmat: ^^^ 12:56
lizmat nine: yeah, I was wondering whether that would break stuff 12:57
want me to revert that one ?
or do you have a clue where it is still referenced with the old extension ?
nine My guess is that it will hit all the distro packagers 12:58
lizmat ok, I'll revert that one for now 12:59
13:00 hungrydonkey left
Geth rakudo: 925e73df84 | (Elizabeth Mattijsen)++ | 2 files
Revert "Change extension of tools/install-dist to .raku"

This reverts commit 4ec31e2cd283e27ec9b2e0e11800fd6f62d30164.		 13:01
13:01 hungrydonkey joined 13:04 patrickb left
Geth rakudo: dd7b4ce51b | (Elizabeth Mattijsen)++ | tools/install-dist.p6
Revert "Change extension of tools/install-dist to .raku"

This reverts commit 4ec31e2cd283e27ec9b2e0e11800fd6f62d30164.		 13:08
lizmat not sure how that last commit got that message, but at least it's internally consistent again now 13:09
sena_kun releasable6: status 13:11
releasable6 sena_kun, Next release in ā‰ˆ9 days and ā‰ˆ5 hours. 4 blockers. 0 out of 179 commits logged
sena_kun, Details: gist.github.com/6bc99347947cae2063...49e3dfb255
lizmat sena_kun: I only see 2 blockers ? 13:14
13:14 patrickb joined
sena_kun lizmat: hmm, how so? 13:15
lizmat github.com/rakudo/rakudo/issues?q=...%3ABLOCKER
sena_kun lizmat: two are from moarvm repo 13:16
lizmat aaah.. ok
sena_kun one is a moarvm panic on a roast test, which is a serious issue. second is a plain regression, then go build issues and a flapping method call, which seems like a regression to me. not sure if 100% blocker, but giving jnthn++ does some work recently with rakudo, I think it possibly can be investigated. 13:17
jnthn I'm not sure either of the MoarVM ones are regressions? 13:18
sena_kun github.com/MoarVM/MoarVM/issues/1237 looks like a regression
jnthn It ain't; I remember spending hours hunting it 6 months ago... :/ 13:19
I managed to repro it one time in 1000 runs today :/
And I'd forgotten to stick a breakpoint in MVM_panic, so it was all for nothing :|
sena_kun because 1)we passed part of spectest before, it's a release requirement?; 2) lizmat has said yesterday it was reliable?
colabti.org/irclogger/irclogger_lo...02-13#l135 <- 13:20
lizmat it's reliable on MacOS
jnthn Every run?
sena_kun maybe "reliable" is "reliably works most of the time" rather than "reliably dies"
jnthn lizmat: Reliably fails, or reliably passes? 13:21
lizmat reliably crashes after 30 to 50 times
sena_kun "it should be noted that this is not a 'new' bug" <- hmm, not a regression then, indeed.
jnthn Well yes, given I already said I tried to find it 6 months ago, not new at all ;) 13:22
The MacOS build one - hmm...I wonder if that's related to us upgrading to a new dyncall? Or does it pre-date that?
My assumption with MacOS + build is that Apple broke something yet again :/
lizmat but it is broken on older MacOS's , no ? 13:24
jnthn ah, it's about gcc-10, which is maybe the thing that's new 13:25
patrickb jnthn: If you are refering to my dyncall update PR - that hasn't been merged yet
jnthn patrickb: Oh. Then if we're lucky it may even fix it ;-)
lizmat ok, so merge it and bump ? 13:26
patrickb The PR only updates the separate dyncall repo. After merging and before bumping the respective submodule in the moarvm repo needs to be updated.
jnthn Let's try that and see if it helps 13:27
github.com/MoarVM/dyncall/pull/7/f...35f20e3R31 possibly helps 13:30
Though doesn't sound a direct hit on the bug
13:33 sena_kun left 13:48 sena_kun joined
patrickb I won't have time to actually do stuff until at least tomorrow evening... But feel free to just go ahead. 14:07
lizmat is not sure what needs to be done more than merging the PR ? 14:13
Geth Ā¦ rakudo: vrurg self-assigned Build process calling Raku does not use `--ll-exception` github.com/rakudo/rakudo/issues/3478
jnthn lizmat: Bumping the submodule version in the MoarVM repo too 14:15
I could do it, but by MoarVM is in pieces at the moment things to trying to get derived specializations to work :)
*thanks to
lizmat has had quite a few fights with submodules, but will try anyway 14:16
jnthn Who hasn't... :)
lizmat Ah, I see the PR is already merged
jnthn Yes, I did that bit :) 14:18
lizmat so I need to clone the dyncall ? then get the git describe and paste that somewhere ?
jnthn I think you pull it and then commit in MoarVM iirc 14:19
cd 3rdparty/dyncall ; git pull ; cd ../.. ; probably a commit now?
patrickb jnthn: Yes, that's about it. 14:20
lizmat You are not currently on a branch.
Please specify which branch you want to merge with.
jnthn This is in the set of things I do rarely enough that I've typically forgotten what to do :)
lizmat: ah, git checkout master before the git pull 14:21
Geth nqp: 3bbce8c3ab | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get latest dyncall support

And a fix uninlining segfault fix		 14:25
roast: 6c88e8735a | (Elizabeth Mattijsen)++ | S32-str/index.t
Refine some index() tests

  - fix RT references
  - use fails-like to test for type of failure		 14:29
rakudo: 5685648a31 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP

  - get new dyncall support
  - fix uninlining segfault		 14:36
14:46 MasterDuke left
timotimo lizmat: thank you very much for working on the :i and :m support for more string methods/subs <3 14:57
i'm not quite grokking the code yet, but i wonder if we can get multi-needle split faster by using the fact that each needle's positions list is sorted; so we can just merge the lists together with the simpler merge algorithm compared to having to actually sort stuff 15:22
i imagine that $positions is made up of lists where each list has every position a given needle exists at?
15:33 sena_kun left 15:47 sena_kun joined
japhb nine: I let your idea percolate around in my brain overnight, and this morning it gelled into a new idea, but it hinges on this question: Is there anything that prevents an auth from itself being a long name for another module? That feels like less of a conceptual abuse than trying to wedge something into ver ... and it frees up ver itself for allowing the calling program and plugins to agree on an API 16:06
revision.
The idea is that, since right now two modules of the same short name but different auth are effectively two different people's (or org's) different view of the module, this would instead be different *module's* view of the plugin slot. 16:08
And since long names are guaranteed unique, we can use those modules 16:09
*module's long names as auths without fear of collision
16:10 hungrydonkey left
japhb So I'm thinking Foo::Bar::SomeSlot::Plugin:auth('Foo::Bar::Slartibartfast:auth<someauth>:ver<1.2.3>'):ver<5.6> means that Foo::Bar::Slartibartfast:auth<someauth>:ver<1.2.3> plugs into Foo::Bar at the plugin slot Foo::Bar::SomeSlot, expecting that slot's plugin API to be version 5.6 (or compatible) 16:14
Lots of plugin modules could independently install at Foo::Bar::SomeSlot::Plugin, each declaring their expected plugin API, and this would let the current CURI implementation find them all compatible plugins for a particular slot quickly, 16:15
*and* doesn't violate the immutability rules that make vendor packages painless.
(No need to modify some special plugin registry at install time, in other words.) 16:16
nine Don't you hate it when an obviously horrible idea fixes all the problems so nicely? 16:34
And to be clear: I do think that it's horrible and would have unwanted side effects. It's just hard to find them...
16:36 domidumont left 16:42 patrickb left
japhb nine: Well, right now it's the horrible idea above, or the horrible idea of yet again rejiggering repo installs to make them compatible with a use case the current CURI design wasn't really built for. 16:46
japhb briefly considers calling a module that implements this horrible idea "Plugin::Hack" ... or maybe "Plugin::Hack::Horrible::NoReally" 16:49
I mean, if you use a plugin loader with a name like that, you've pretty much signed up for the unwanted side effects right at the get-go. ;-)
nine Well one side effect would be that any system grouping modules by auth (e.g. a list on modules.raku.org) will show some confusing output for those plugins. 16:50
That's why I'd still prefer abusing :api, as I really can't think of anything where that really hurts. Well except that you'd miss out on :api semantics for specific plugins of course :) Which...a plugin system needs to handle btw. the same plugin may be installed in multiple versions 16:52
japhb Yeah, that last bit is one reason why I was thinking of using real long names in the auth hack -- because they would carry a valid real version for the plugin. 16:56
nine: Thinking about that modules.raku.org issue, I feel like there's a way around that, but I don't have a general solution for that now. ( Some partial solution ideas, but none are terribly satisfying.) 16:59
nine: It's key that not only can plugins be installed with multiple versions, but plugin *slots* also have multiple versions, and plugins need to be able to declare what API version they are safe to load into. 17:00
There's always the possibility of using one of these hacks (auth or ver, doesn't matter) just to find a resources tree, that then can contain metadata for loading. But pretty soon you're getting into "let's build a database on top of a virtual file system on top of a database implemented as a filesystem" territory. 17:02
All of this would be a lot easier if we didn't have the vendor packages problem to work around. :-( 17:03
17:34 sena_kun left 17:48 sena_kun joined 17:50 dogbert11 left
Geth roast: 13ad2bb268 | (Elizabeth Mattijsen)++ | S32-str/index.t
Add tests for Str.index(:i, :m)
 17:58
rakudo: vrurg++ created pull request #3480:
Added *_RUNNER_OPTS variable		 18:33
rakudo: 701c38df64 | (Vadim Belman)++ | 2 files
Added *_RUNNER_OPTS variable

It currently defines `--ll-exception` for detailed diagnosis of installation stage problems.
rakudo: fbeb3e346f | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #3480 from vrurg/rakudo_3478

Added *_RUNNER_OPTS variable
19:32 sena_kun left
nine japh: a solution could be to have plugins register for a namespace prefix. Or that we create lookup directories for all possible prefixes, i.e. Foo, Foo/Bar, Foo/Bar/Plugin for Foo::Bar::Plugin::Baz 19:40
19:48 sena_kun joined
lizmat vrurg++ thanks much! 20:07
vrurg lizmat: my pleasure!
It also pushed me to do change perl6- prefix to rakudo- on executables... 20:08
lizmat vrurg: I don't see that in the diff? 20:09
vrurg WIP
lizmat aaah ok
Geth roast: 085d8a78e1 | (Elizabeth Mattijsen)++ | 2 files
Change extension of t/spec/super-fudger to .raku
 20:14
roast: 9e3e59f3c3 | (Elizabeth Mattijsen)++ | super-fudger.raku
Update she-bang
 20:15
20:19 MasterDuke joined
Geth rakudo: 90fc61bbb6 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Enable :i/:m on sub form of index/rindex

  - except that Str.rindex is not ready for that yet		 20:25
roast: 5fe52c27bc | (Elizabeth Mattijsen)++ | S32-str/index.t
Add tests for :i/:m for sub form of index
lizmat writing tests++ :-)
m: index( "foo", "o") for ^50000; say now - INIT now 20:29
camelia 0.02802055
lizmat m: "foo".index("o") for ^50000; say now - INIT now
camelia 0.0155095
lizmat hmmm... looks like I pessimized that with 90fc61bbb6 20:30
linkable6 (2020-02-13) github.com/rakudo/rakudo/commit/90fc61bbb6 Enable :i/:m on sub form of index/rindex
20:43 dogbert17 joined
dogbert17 is trying to figure out which commit broke Perl6::Parser 20:49
lizmat dogbert17++ 20:55
dogbert17 it might come back and bite you :)
I'm getting close, only three possibilities left 20:56
Geth rakudo: ec13c3d014 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Make sub index about 20x as fast (again)

Commit 90fc61bbb6 slowed down sub index roughly 20x, so it seemed appropriat to fix this. So instead of just capturing all named parameters, and slipping them through, create candidates for the expected named parameters, and pass those through. Also create a candidate without any named parameters. After this, index("foo","o) is roughly 2x as slow as "foo".index("o").		 20:58
dogbert17 lizmat: the culprit seems to be github.com/rakudo/rakudo/commit/ca...a357721cec 21:10
Geth rakudo: ea44c194a8 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Make Cool.index also pass on :i and :m properly

Without affecting performance too much
lizmat dogbert17: ah! maybe a change in behaviour of the Raku grammar was not expected by Perl6::Parser ? 21:12
MasterDuke i thought Perl6::Parser broke a while ago? 21:13
sena_kun MasterDuke: it was clean on 2020.01
MasterDuke ah
sena_kun but reliably broken on last time I run blin, which was 5 days ago, Saturday 21:14
lizmat yeah, it is broke allright
Geth rakudo: 327c74a6e7 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Simplify sub index candidates

Named parameters can be optional and still expected. This is different from methods, where unexpected nameds are just ignored.		 21:19
21:32 sena_kun left
Geth rakudo: 2176292965 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Restore exact behaviour of List.index/indices/contains

With c9b0218544 a warning is issued with regards to using a List as a string, when that is most likely not what one wants. However, that commit also changed the string on which the method operates for a list like <a b c> from "a b c" to "abc". This commit restores the "a b c" behaviour.		 21:45
21:47 sena_kun joined
Geth roast: 072904cb96 | (Elizabeth Mattijsen)++ | S32-str/index.t
Add proper tests for Cool.index

By using a Match object, which should be quite common.		 21:56
rakudo: 73c5a25e89 | (Elizabeth Mattijsen)++ | src/core.c/Cool.pm6
Make sure that Cool.contains passes on :i, :m
 22:07
roast: 882ca2795e | (Elizabeth Mattijsen)++ | S32-str/contains.t
Add proper tests for Cool.contains

By using a Match object, which should be quite common.		 22:08
lizmat and that concludes my hacking for today&
japhb lizmat++ # Streak of good hacking days 23:25
23:34 sena_kun left 23:48 sena_kun 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!