[01:00] *** Kaeipi left [01:34] *** sena_kun joined [01:36] ¦ rakudo: bf2a542fc8 | tinmarino++ | docs/Building-Rakudo.md [01:36] ¦ rakudo: Doc tipo Configure -> Configure.pl [01:36] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/bf2a542fc8 [01:36] ¦ rakudo: 26f4a36993 | tinmarino++ | docs/Building-Rakudo.md [01:36] ¦ rakudo: Fix typo [01:36] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/26f4a36993 [01:36] ¦ rakudo: 66b78ccbef | (Vadim Belman)++ (committed using GitHub Web editor) | docs/Building-Rakudo.md [01:36] ¦ rakudo: Merge pull request #3510 from tinmarino/master [01:36] ¦ rakudo: [01:36] ¦ rakudo: Documentation small tipos [01:36] *** Altai-man_ left [01:36] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/66b78ccbef [01:48] *** finsternis joined [02:33] *** cognominal joined [02:36] *** cognomin_ left [02:48] greppable6: WrapHandle [02:48] vrurg, 7 lines, 2 modules: https://gist.github.com/3ddf2b46e0b0bdb69a383d392b70b39c [02:54] FWIW I'm planning to move nqp and roast repos next week [02:54] I'm currently busy with stuff, so sorry for not doing it earlier :) [03:00] *** Kaiepi joined [03:33] *** Altai-man_ joined [03:36] *** sena_kun left [03:42] *** leont left [04:42] *** greppable6 left [04:42] *** sourceable6 left [04:42] *** bloatable6 left [04:42] *** tellable6 left [04:42] *** notable6 left [04:42] *** unicodable6 left [04:42] *** releasable6 left [04:42] *** shareable6 left [04:42] *** benchable6 left [04:42] *** committable6 left [04:42] *** statisfiable6 left [04:42] *** evalable6 left [04:42] *** reportable6 left [04:42] *** quotable6 left [04:42] *** nativecallable6 left [04:42] *** squashable6 left [04:42] *** bisectable6 left [04:42] *** linkable6 left [04:42] *** coverable6 left [04:42] *** sourceable6 joined [04:42] *** statisfiable6 joined [04:42] *** greppable6 joined [04:42] *** releasable6 joined [04:43] *** benchable6 joined [04:43] *** notable6 joined [04:43] *** coverable6 joined [04:43] *** squashable6 joined [04:43] *** nativecallable6 joined [04:44] *** reportable6 joined [04:44] *** bloatable6 joined [04:44] *** shareable6 joined [04:44] *** bisectable6 joined [04:44] *** linkable6 joined [04:44] *** quotable6 joined [04:44] *** committable6 joined [04:45] *** evalable6 joined [04:45] *** tellable6 joined [04:45] *** unicodable6 joined [05:34] *** sena_kun joined [05:36] *** Altai-man_ left [06:59] lizmat: Looking at the commit that introduced $first-repo-id, the variable is used precicely for detecting and handling a `use lib` after we've already loaded some modules: https://github.com/rakudo/rakudo/commit/0498e803b5 [07:33] *** Altai-man_ joined [07:36] *** sena_kun left [07:57] *** domidumont joined [07:58] *** domidumont left [08:56] *** domidumont joined [09:05] *** Altai-man_ left [09:06] *** sena_kun joined [09:09] *** sena_kun left [09:09] *** Altai-man_ joined [09:21] https://github.com/MoarVM/MoarVM/issues/1246 [09:26] Files=1303, Tests=111207, 211 wallclock secs (28.53 usr 8.24 sys + 2957.08 cusr 280.39 csys = 3274.24 CPU) [09:28] <|Tux|> Rakudo version 2020.02-26-g66b78ccbe - MoarVM version 2020.02-2-gbaca0c13b [09:28] <|Tux|> csv-test-xs-20 0.363 - 0.383 [09:28] <|Tux|> csv-ip5xs 0.704 - 0.707 [09:28] <|Tux|> test-t --race 0.807 - 0.810 [09:28] <|Tux|> test-t 1.815 - 1.817 [09:28] <|Tux|> csv-ip5xs-20 5.814 - 6.039 [09:28] <|Tux|> test 7.301 - 7.673 [09:28] <|Tux|> test-t-20 --race 8.291 - 9.181 [09:28] <|Tux|> csv-parser 21.997 - 23.202 [09:28] <|Tux|> test-t-20 29.904 - 30.164 [09:35] *** sena_kun joined [09:36] *** Altai-man_ left [10:19] ¦ rakudo: cb7be78cdf | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.pm6 [10:19] ¦ rakudo: Reorganize R:I compiling options logic [10:19] ¦ rakudo: [10:19] ¦ rakudo: - instead of doing this ad-hoc, do it once during startup [10:19] ¦ rakudo: - add method STAGESTATS to get the --stagestats string if specified [10:19] ¦ rakudo: - this is useful functionality that should probably be exposed [10:19] ¦ rakudo: - in preparation of more repo optimizing work [10:19] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/cb7be78cdf [10:28] m: say $*EXECUTABLE.absolute [10:28] lizmat, rakudo-moar cb7be78cd: OUTPUT: «/tmp/whateverable/rakudo-moar/cb7be78cdf648a872cb1e1b7a703adae54062637/bin/rakudo␤» [10:29] vrurg: can we assume that all possible executors nowadays start with "rakudo" ?? [10:48] *** domidumont left [11:34] *** Altai-man_ joined [11:37] *** sena_kun left [12:24] *** leont joined [13:05] so we have a new Rakudo Star 2020.01, but it is not visible anywhere yet [13:05] what needs to be done / who can do it? [13:05] morityz [13:05] lizmat, do we have it? who built? [13:05] tyil [13:05] hmm [13:06] I don't think it is wise to rush its publishing, because there will be a point [13:06] https://www.nntp.perl.org/group/perl.perl6.users/2020/02/msg8150.html [13:06] Altai-man_: this is 2020.01 !! [13:06] ah, phew [13:06] sorry [13:06] nani [13:07] I am brain dead right now, never mind. :[ [13:07] oh, hi [13:07] Altai-man_: I built a rakudo-star, announced it on 2 MLS [13:07] +1 on announcing 2020.01 star. [13:07] nanu [13:07] but Im in a meeting right now [13:07] oki [13:07] I'd like to announce it in the RWN today :-) [13:12] Altai-man++ [13:16] With a reasonably sized Cro application at work, we ran into the situation that every change to the source leads to compile times of several minutes, with almost all of it spent re-checking dependencies of precomp files. [13:16] I see why this is the case, but I wonder if this has been reported before? [13:18] nine: not sure... but fwiw, I'm currently working on a. grokking that piece of the code thoroughly, and b. making it faster [13:19] the thought has always been that the compilation process itself is slow, but looking at the code, I think there's a substantial part that is *not* caused by that [13:20] also: I'm considering making RAKUDO_MODULE_DEBUG a setting compile time option [13:20] as part of the slowdown is the $*RMD lookup in many methods [13:27] *** lucasb joined [13:31] That re-rechecking of dependencies is not for changes to the installed modules. What happens is that we notice that something in the repository has changed. That something could e.g. be that you added your own implementation of Cro::Core. When you do that, you will expect it to actually get used. So we need to recompile everything that needs Cro::Core even if the installed module stays unchanged. [13:31] That dependency check is not hugely expensive, but it's also not free and I guess it just adds up with the 100s of modules we end up loading. [13:31] I do see several ways to attack this issue: [13:31] * we can cache the result of a resolution, i.e. not re-check dependencies when we already encountered the same dependency specification before and deemed it still correct [13:32] * we can try a quick parse of the dependency specification that's recorded in the precomp file. Currently we always parse with EVAL (since your use statement could be use Foo::Bar:auth(*.ends-with("@atikon.com")):ver:api(/:i stable/)) and EVAL is really slow. Most cases are trivial. [13:32] * we could try to determine if a change in the repository could actually affect dependency resolution at all. Not so sure about this one though. [13:32] ok, done with meeting [13:32] If I'm right that cache can save several minutes there already [13:33] Altai-man_: I announced it on perl6-users and perl6-compiler, are there other places I should announce it? [13:35] I have contemplated announcing it on the fediverse too :p [13:36] tyil: so https://rakudo.org/downloads is up to date ? [13:36] or this: https://rakudo.org/star [13:36] or https://rakudo.org/news ? [13:36] *** Altai-man_ left [13:36] I'm not sure who can update that [13:37] lizmat: the first page doesn't list star releases, the 2nd link contains an outdated r* [13:38] patrickb signed the Rakudo release on the first link you posted, so I'm assuming he knows [13:38] not sure in which timezone he operates [13:39] UTC+1 [13:39] one of my favourite timezones [13:39] I suspect he's got his own work to do right now, then [13:40] I'll send him an email [13:42] *** sena_kun joined [13:43] sent~ [13:55] *** epony left [14:05] lizmat: yes, all runners are now rakudo-prefixed. perl6- is only for backward compat, apparently. [14:05] ok, cool, that means some cleanup can be in place :-) [14:09] nine: that sounds like the kind of compilation time I have at work, with a reasonably sized C++ application and its test suite. [14:10] tyil: as far as i know the news is part of the rakudo.org repo. [14:13] rba: https://github.com/perl6/rakudo.org ? [14:15] Setting RAKUDO_RERESOLVE_DEPENDENCIES=0 in the environment brings down compilation time from 3 minutes to 10 seconds :) So implementing the solutions I listed will be well worth it. [14:16] wow [14:16] yes... indeed [14:18] ¦ rakudo: 638c8955f5 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6 [14:18] ¦ rakudo: Most of the arguments are constant [14:18] ¦ rakudo: [14:18] ¦ rakudo: - so initialize them at startup [14:18] ¦ rakudo: - including stagestats and target [14:18] ¦ rakudo: - makes installing core modules about .1 second faster (8.9 -> 8.8) [14:18] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/638c8955f5 [14:18] ¦ rakudo: c9d9a096e8 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6 [14:18] ¦ rakudo: Streamline CompUnit::PrecompilationRepository a bit [14:18] ¦ rakudo: [14:18] ¦ rakudo: - use new $stagestats "constant" [14:18] ¦ rakudo: - use native arrays / hashes and nqp::ops to fill them [14:18] ¦ rakudo: - prevent use of intermediate arrays [14:18] ¦ rakudo: - prevent use of regex to check dependency string [14:18] ¦ rakudo: [14:18] ¦ rakudo: Brings installing core modules below 8.8 seconds [14:18] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/c9d9a096e8 [14:20] m: dd $*RAKU.compiler.id [14:20] lizmat, rakudo-moar cb7be78cd: OUTPUT: «"BA1A69BA1A40C2400CAC7DDB383C790B326C1245"␤» [14:20] isn't that constant for the duration of the process? or do we assume people could be messing with $*RAKU ? [14:21] or is that basically recording the Raku version ? [14:22] m: use v6e.PREVIEW; dd $*RAKU.compiler.id [14:22] lizmat, rakudo-moar cb7be78cd: OUTPUT: «"BA1A69BA1A40C2400CAC7DDB383C790B326C1245"␤» [14:22] m: use v6c; dd $*RAKU.compiler.id [14:22] lizmat, rakudo-moar cb7be78cd: OUTPUT: «"BA1A69BA1A40C2400CAC7DDB383C790B326C1245"␤» [14:22] m: use v6.c; dd $*RAKU.compiler.id [14:22] lizmat, rakudo-moar cb7be78cd: OUTPUT: «"BA1A69BA1A40C2400CAC7DDB383C790B326C1245"␤» [14:22] looks like it is pretty constant [14:23] ¦ rakudo: dumarchie++ created pull request #3511: RFC: Change PositionalBindFailover MRO [14:23] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3511 [14:23] tyil: yes [14:24] The compiler's id is cosntant [14:25] rba: ack, thanks [14:25] nine: ok, so no use looking that up every timde [14:25] *time [14:26] lizmat: I'd be surprised if there's much to gain though. The accessor will be inlined anyway [14:26] *** dumarchie joined [14:27] it's the dynamic lookup [14:27] that is slow for dynamic variables in PROCESS:: [14:32] *** MasterDuke left [14:36] Darn....that one again: nine@sunshine:~> zef [14:36] ===SORRY!=== [14:36] No candidate found for 'zef'. [14:39] nine: is this on HEAD ? [14:39] did I just bork that ? [14:40] I've had the same issue a couple weeks ago [14:45] Oh! That's it: nine@sunshine:~> cat /home/nine/rakudo/install/share/perl6/site/bin/zef [14:45] #!/usr/bin/env perl6 [14:46] /usr/bin/env perl6 will ignore $PATH and find /usr/bin/perl6 instead of /home/nine/rakudo/install/bin/raku [14:54] it reminds me to finally change all `env perl6` to `env raku`... [15:20] *** dumarchie left [15:34] On my laptop compilation time after a change goes from 1m50.783s to 0m14.515s with a resolver cache [15:34] *** Altai-man_ joined [15:36] That seems like a very good kind of change [15:36] *** sena_kun left [15:39] Wow. [15:48] *** Ven_de_Thiel joined [15:55] I guess there's a bit more to be gained, e.g. there's no point in checking if a precomp file is still up to date when we have already loaded it [16:00] *** dumarchie joined [16:00] We should even be able to forego finding the precomp file in one of there stores in the first place if we have already loaded one for the exact same dependency specification [16:05] *** epony joined [16:06] Yeah, looks like there's another second to be had [16:07] (through the additional 3 lines of code) [16:07] Patch is https://gist.github.com/niner/3b8716dfc739abe669e39d70028b9e6f for the curious [16:09] How costly is an extra lock-protect (the 2nd one) vs potentially recalculating the deps etc? [16:10] I guess negligible [16:16] Yeah, removing that lock there does not make a measurable difference [16:36] *** Guest1277 left [17:08] *** dumarchie left [17:12] *** toddr left [17:16] "Unhandled exception: While looking for '/home/dogbert/repos/rakudo/perl6.moarvm': no such file or directory" # this has been happening for a few days now after a rakudo rebuild [17:19] *** hungrydonkey left [17:29] *** patrickb joined [17:29] ping tyil [17:29] 2020-02-23T19:37:06Z #raku patrickb thanks, I appreciate that. So let's try next year... [17:30] patrickb: o/ [17:31] tyil: Getting a release on rakudo.org should be simple. [17:31] good to hear [17:31] *** sergot left [17:31] Did you already sign the files? [17:31] (result should be .asc files) [17:31] https://dist.tyil.nl/raku/rakudo-star/ there's a checksum file and a pgp signature file [17:31] Looks good. [17:32] Then those files need to be uploaded to the rakudo.org webserver and placed in the folder where all the other release files reside [17:32] and that's it. [17:32] who has access to that webserver, and what are the requirements to get access? [17:33] The critical thing are the filenames. They are read and iterpreted by the website and interpreted. [17:33] rba [17:33] I can name them in whichever way works best with existing infra [17:33] I suspect there is no process for gaining access except for a certain level of trust [17:33] the names on dist.tyil.nl are just the ones I found convenient for myself [17:34] Looking at the existing rakudo star files and naming yours the same way should work [17:35] patrickb? [17:35] *** sena_kun joined [17:35] If the names are wrong the files will just not show up. So it's ok to try [17:35] rba: tyil needs to get some files on the rakudo.org server [17:35] ok. [17:36] rba: it's about https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz.asc and https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz.checksums.txt [17:37] *** Altai-man_ left [17:37] tyil: Posts are part of the rakudo.org repository. They are markdown. https://github.com/perl6/rakudo.org/tree/master/post [17:37] So just clone that repository, add your news file and push [17:37] yes, I found those with help from rba :) [17:37] Not sure if the site is autoupdated at the moment [17:38] Actually I think it's not [17:38] patrickb: if not autouptdate, let me know, I give it a push. [17:38] or pull LOLO [17:39] rba: There is a very minor change from a few days ago that's not live, but I'll happily wait for tyils post to happen before the update. [17:39] tyil: if you had scp access to rakudo.org before, you ssh key might already been added. [17:39] it's still v6.d, even now that it's Raku instead of Perl 6, correct? [17:40] tyil: I think so. We didn't change the versioning system. [17:40] rba: `ssh rakudo.org` does not seem to work, I don't think I've ever had access [17:41] hi, i notice the roast repo is still at the perl6 github site. i need to refer to that in an upcoming docs update. is that okay to still use that reference, or should i not mention it in the docs at all since it is a rakudo thing? [17:42] correction, it is a raku thing, but should i mention it in the raku docs? [17:49] tyil: you want me to add one of your github ssh public keys? Or send me as pm. [17:50] tyil: did you sign the tar.gz with the gpg key availalbe on github? [17:51] rba: I have multiple SSH keys: https://home.tyil.nl/git/dotfiles/tree/.ssh/authorized_keys#n5, but the one I most frequently use would be the one on line 5 (tyil@anoia.tyil.net) [17:51] tyil: will get the one you provieded. [17:52] 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 is the PGP key ID, available at https://www.tyil.nl/pubkey.txt [17:52] it is the same one I use on github to sign with [17:52] (though my old key is also still on my github account I see) [17:53] also, my announcement post: https://github.com/perl6/rakudo.org/pull/35/files, please verify for obvious mistakes as this is my first time making one [17:55] rba: does rakudo.org listen on default port 22? [17:55] tyil: you may try something like: scp -p 2222 rakudo-star-2020.01.tar.gz rakudo.org@lavm-perl6infra-1.atikon.io:public_html/downloads/star/ [17:56] ah [17:56] if it'll result in network is unreachable error, try with `-P 2222` (note uppercase) [17:58] rba: works [17:58] sena_kun: and I did use -P indeed :p [17:58] sure, use -P [17:59] sena_kun: I see. This was the mistake I sent you last time... [17:59] ¦ rakudo: c909258273 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationRepository.pm6 [17:59] ¦ rakudo: Avoid re-resolving the same dependencies multiple times [17:59] ¦ rakudo: [17:59] ¦ rakudo: When the repository chain's id changes (e.g. because a source file in a -Ilib [17:59] ¦ rakudo: repository got edited) we need to re-resolve the dependencies of the precomp [17:59] ¦ rakudo: files we load as the change could have brought in a new prefered version of a [17:59] ¦ rakudo: dependency. However doing so once is quite sufficient. There's no need to [17:59] ¦ rakudo: re-resolve the same dependency specification over and over which could happen [17:59] ¦ rakudo: in large applications with many modules sharing similar dependencies. [17:59] ¦ rakudo: Brings down compilation time in a real life code base from 110 to 14 seconds. [17:59] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/c909258273 [17:59] ¦ rakudo: 6956c06333 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationRepository.pm6 [17:59] ¦ rakudo: Avoid looking up the same precomp id multiple times [17:59] ¦ rakudo: [17:59] ¦ rakudo: If we have already loaded a precomp file, there's no need to search the precomp [17:59] ¦ rakudo: stores for its id as we already deemed it up-to-date once and would not load it [17:59] ¦ rakudo: again anyway. [18:00] ¦ rakudo: Brings down compilation time of a real world code base from 14 to 13 seconds. [18:00] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/6956c06333 [18:00] I can see the files on https://rakudo.org/downloads/star, but not yet on https://rakudo.org/star itself [18:00] Too bad this missed the release. Luckily we seem to be back on track again for monthly releases and a couple weeks of testing may not hurt with changes like these :) [18:01] patrickb: do you know if the star page is "hardwired"? [18:01] nine, we still have to do a point release, so technically it is possible... [18:02] rba: What do you mean with hardwired? [18:04] This https://rakudo.org/latest/star/src gives us the lastest star, so rakudo-star-2020.01.tar.gz, yet on https://rakudo.org/star it's says 2019.03. And the win and macos is broken now. [18:05] sena_kun: our programmers already learned about the RAKUDO_RERESOLVE_DEPENDENCIES=0 workaround today, so lets use that month for testing. You never know what comes up with a good real life mix of repositories and work flows. [18:06] nine, not insisting in any way. [18:07] tyil: Tried to verify your key using "gpg --receive-keys B6F697742EFCAF5F23CE51D5031D65902E840821". May you please add your key to a public key server? [18:07] I believe I uploaded it to pgp.mit.edu [18:08] *** domidumont joined [18:08] sena_kun: why do we need to do a point release? Did I miss something? [18:08] tyil: Do you have a binary build for win and/or macosx? [18:09] I do not [18:09] nine, tl;dr: musl on alpine wreaks havoc after dyncall bump, need to revert a bit of code and do a point. a longer story: https://github.com/MoarVM/MoarVM/issues/1246 [18:10] Anyone know how the binary build have been assembled for rakudo star macosx and windows? [18:11] tyil: pgp.mit.edu gives a timeout. Hmm... [18:11] rba: hankache was able to build a .msi [18:11] Ok, so no need for me to wait for the point release to update my packages [18:11] rba: can you `gpg --locate-key [email@hidden.address] [18:12] nine, no need, though I'd still appreciate help of someone who is skilled in C in writing a patch commit. [18:12] if nothing else, it's also on https://www.tyil.nl/pubkey.txt [18:13] tyil: I think of our "customers". How will they be able to verify the signature? [18:14] tyil: "gpg --locate-key [email@hidden.address] worked and then "gpg --verify rakudo-star-2020.01.tar.gz.asc rakudo-star-2020.01.tar.gz" worked too. [18:14] I can upload it to other servers if you like, but I'm mostly using WKD to get my keys to people these days [18:15] sena_kun: has someone reported this bug to dyncall upstream? [18:15] nine, I sent an email explaining the situation to dyncall maintainer, no reply yet [18:15] they don't have a pubilc bugtracker or I wasn't able to find it, alas [18:16] From the ticket it looks like this happened today. I'd just give them a bit of time and then take the resulting commit from their master tree [18:16] tyil: Maybe this needs to be documented somewhere? [18:16] rba: I can add it to documentation too [18:17] but that's a bit late for this release, if you have a server that's not down I can just send it there [18:17] tyil: I have MacOSX and I have windows around. But I like to make sure I do it right. So I would be able do the star builds with some help. [18:17] rba: Looking at the source code it seems it's actually static! I really didn't expect that... [18:17] rba: https://github.com/perl6/rakudo.org/blob/master/templates/star.html.ep [18:18] rba: I can do my best to help you out :) [18:18] patrickb: Uff, realllly static. [18:18] nine, the email was sent around 18 hours ago, not so much, but still. if you're against manual reverting this particular piece, I can't disagree. [18:19] patrickb: It's fine for, as I know now. [18:20] sena_kun: that's the good thing about monthly releases. The last release that worked on Alpine was just a month ago and the next one is scheduled in 4 weeks. This lowers the pressure to do point releases. [18:21] sena_kun: From my experience the dyncall devs are very responsive and willing to help. I'm sure they'll reply soon. [18:22] tyil: Will go through https://github.com/rakudo/star/blob/master/tools/star/mac-dmg.pod [18:23] nine, I clearly remember El_Che saying alpine releases are very important as they are used in CI environments. Maybe I am exaggerating the situation, though, but I don't mind doing a point with the commit taken, to be honest. If most of core devs think it is undesireable, I don't mind it either. [18:23] patrickb, will see, thanks for sharing. :) [18:23] * rba really need to get my homework done to find a time to setup my old MacMini for tasks like this and to share it... [18:23] * sena_kun wanders off to do a couple more Comma fixes [18:24] sena_kun: I agree with Alpine. This my choice as well for building docker images. [18:30] patrickb, mind a PM? [18:30] Wait a minute: if it's used for CI, why didn't it come up earlier? [18:31] sena_kun: ? [18:31] nine, used for CI, but not our CI. It seems MoarVM travis uses "linux" which means "ubuntu", not alpine. [18:33] Yeah, alpine is mainly used for minimalist docker images AFAIK [18:33] what will be a cool thing to do afterwards is to add it to travis configuration for rakudo to test musl env as well as glibc, then we'd discover that on the PR day [18:34] s/for rakudo/for moarvm/ [18:36] rba: if you want, can you see if --recv-keys is working for my key now? I added hkps://hkps.pool.sks-keyservers.net to my gpg.conf [18:36] and did a --send-keys [18:37] *** domidumont left [18:39] *** domidumont joined [18:49] *** domidumont left [18:50] *** Ven_de_Thiel left [18:53] *** domidumont joined [18:55] *** sena_kun1 joined [18:56] *** sena_kun1 left [18:56] *** MasterDuke joined [18:57] *** Altai-man_ joined [18:58] *** sena_kun left [18:58] Xliff: does https://github.com/rakudo/rakudo/commit/c909258273b09c526463b68d22a162dfc7568c70 do anything for your compile times? [18:58] MasterDuke, I'll pass your message to Xliff [19:00] tyil: Had to add "keyserver hkps://hkps.pool.sks-keyservers.net" to ~/gnupg/dirmngr.conf on Ubuntu and kill the dirmngr process running under the rakudo.org user. Then I was able to import the key... [19:01] hmm [19:01] I tried a --recv-keys in an ubuntu docker container without any additional configuration, and it worked there [19:04] rba: New rakubrew is there (v4). Can you upload? https://patszim.volans.uberspace.de/patcloud/index.php/s/qmkreEJLQDZcjbf [19:05] * rba will myself embed into a docker container in my next life. [19:10] patrickb: v4 in rakubrew.org [19:10] rba: Thank you! [19:11] patrickb: the repo has not changed, right? [19:11] rba: No. Only that one file. :-) [19:13] ¦ problem-solving: tbrowder++ created pull request #165: update reference [19:13] ¦ problem-solving: review: https://github.com/Raku/problem-solving/pull/165 [19:35] *** sena_kun joined [19:36] May one have a quick look about the build log for rakudo star on MacOSX ? https://gist.github.com/13274d2e68017700a3b9c3db3730e439 [19:36] *** Altai-man_ left [19:37] tyil: ↑ [19:38] rba: looks like everything built succesfully, and modules seem to have installed without error [19:40] *** domidumont left [19:44] .tell nine the last 2 commits appear to add ~.5 second to installing core libraries :-( [19:44] lizmat, I'll pass your message to nine [19:47] .tell nine forget what I said [19:47] lizmat, I'll pass your message to nine [19:49] is relieved [20:11] *** epony left [20:12] *** epony joined [20:15] lizmat: the latest rakudo star for GNU+Linux is available at https://rakudo.org/downloads/star, but https://rakudo.org/star has not been updated yet [20:16] rba: I merged the announcement post into the rakudo.org repo [20:16] tyil++ [20:19] notable6: weekly [20:19] lizmat, 2 notes: 2020-02-17T18:21:26Z : A new Raku dist template, with the bare minimum to start a module: https://github.com/JJ/raku-module-template ; 2020-02-20T20:10:18Z : https://www.reddit.com/r/rakulang/comments/f6vxes/design_flaws_in_raku [20:21] notable6: weekly reset [20:21] lizmat, Moved existing notes to “weekly_2020-02-24T20:21:30Z” [20:24] rakudo-star 2020.01 for MacOSX is available now: https://rakudo.org/star (windows still missing though) [20:33] ¦ nqp: b9a1878c4f | (Patrick Böker)++ | tools/build/update-submodules.pl [20:33] ¦ nqp: Build: Fix submodule update with space in git ref dir [20:33] ¦ nqp: review: https://github.com/perl6/nqp/commit/b9a1878c4f [20:33] ¦ rakudo: 3ec58489e7 | (Patrick Böker)++ | tools/build/update-submodules.pl [20:33] ¦ rakudo: Build: Fix submodule update with space in ref dir path [20:33] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3ec58489e7 [20:34] tyil: Do you have everything you need? I like to afk. [20:35] rba: yes, I think everything we can do is in order for lizmat to feel confident announcing it in rwn [20:36] tyil: I think there are errors in the announcement. Refering to MoarVM 2019.03? [20:36] tyil: https://rakudo.org/post/announce-rakudo-star-release-2020.01 [20:37] I was just fixing a couple [20:37] https://alerts.perl6.org/ died with the server last year. RIP. [20:37] https://github.com/perl6/rakudo.org/commit/b84feb90163a34552aa08adf3e7b762bf4e3c3d5 [20:38] https://perl6.org/downloads/ should be https://raku.org/downloads/ [20:38] I dont think theres a new variant of alerts.perl6.org [20:38] tyil: No, not that I'm aware of. [20:39] I never used alerts.perl6.org, how was it used? [20:39] did it scrape git logs or twitter announcements or something? [20:39] or was it a cms based website? [20:42] tyil: Sorry I give up for today, even though there is more work on https://raku.org/downloads/ ... Sorry. [20:42] rba: dont push yourself, I'm very grateful for your work today [20:43] tyil: Tomorrow is another day... [20:43] nine: Might your compile optimization also apply to Xliffs incredibly high build times? [20:52] maybe [21:27] *** cognomin_ joined [21:28] *** patrickb left [21:31] *** cognominal left [21:34] *** Altai-man_ joined [21:36] *** sena_kun left [21:37] and another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/02/24/2020-08-altered-noise/ [21:49] is anyone else going to damian's classes next month in lausanne? i just found out i got approved to go, just need to books travel/lodging [21:56] lizmat++ [22:51] *** pyrimidine left [22:52] MasterDuke: I'm considering going on Thu/Fri [22:53] cool, that's when i'll be there [23:35] *** sena_kun joined [23:37] *** Altai-man_ left