01:00 Kaeipi left 01:34 sena_kun joined
Geth rakudo: bf2a542fc8 | tinmarino++ | docs/Building-Rakudo.md
Doc tipo Configure -> Configure.pl
 01:36
rakudo: 26f4a36993 | tinmarino++ | docs/Building-Rakudo.md
Fix typo
rakudo: 66b78ccbef | (Vadim Belman)++ (committed using GitHub Web editor) | docs/Building-Rakudo.md
Merge pull request #3510 from tinmarino/master

Documentation small tipos
01:36 Altai-man_ left
01:48 finsternis joined 02:33 cognominal joined 02:36 cognomin_ left
vrurg greppable6: WrapHandle 02:48
greppable6 vrurg, 7 lines, 2 modules: gist.github.com/3ddf2b46e0b0bdb69a...392b70b39c
AlexDaniel` 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, sourceable6 left, bloatable6 left, tellable6 left, notable6 left, unicodable6 left, releasable6 left, shareable6 left, benchable6 left, committable6 left, statisfiable6 left, evalable6 left, reportable6 left, quotable6 left, nativecallable6 left, squashable6 left, bisectable6 left, linkable6 left, coverable6 left, sourceable6 joined, statisfiable6 joined, greppable6 joined, releasable6 joined 04:43 benchable6 joined, notable6 joined, coverable6 joined, squashable6 joined, nativecallable6 joined 04:44 reportable6 joined, bloatable6 joined, shareable6 joined, bisectable6 joined, linkable6 joined, quotable6 joined, committable6 joined 04:45 evalable6 joined, tellable6 joined, unicodable6 joined 05:34 sena_kun joined 05:36 Altai-man_ left
nine 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: github.com/rakudo/rakudo/commit/0498e803b5 06:59
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, Altai-man_ joined
Altai-man_ github.com/MoarVM/MoarVM/issues/1246 09:21
lizmat Files=1303, Tests=111207, 211 wallclock secs (28.53 usr 8.24 sys + 2957.08 cusr 280.39 csys = 3274.24 CPU) 09:26
|Tux| Rakudo version 2020.02-26-g66b78ccbe - MoarVM version 2020.02-2-gbaca0c13b
csv-ip5xs0.704 - 0.707
csv-ip5xs-205.814 - 6.039
csv-parser21.997 - 23.202
csv-test-xs-200.363 - 0.383
test7.301 - 7.673
test-t1.815 - 1.817
test-t --race0.807 - 0.810
test-t-2029.904 - 30.164
test-t-20 --race8.291 - 9.181
 09:28
09:35 sena_kun joined 09:36 Altai-man_ left
Geth rakudo: cb7be78cdf | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.pm6
Reorganize R:I compiling options logic

  - instead of doing this ad-hoc, do it once during startup
  - add method STAGESTATS to get the --stagestats string if specified
  - this is useful functionality that should probably be exposed
  - in preparation of more repo optimizing work		 10:19
lizmat m: say $*EXECUTABLE.absolute 10:28
evalable6 /tmp/whateverable/rakudo-moar/cb7be78cdf648a872cb1e1b7a703adae54062637/bin/rakudo
lizmat vrurg: can we assume that all possible executors nowadays start with "rakudo" ?? 10:29
10:48 domidumont left 11:34 Altai-man_ joined 11:37 sena_kun left 12:24 leont joined
lizmat 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?
morityz
Altai-man_ lizmat, do we have it? who built?
lizmat tyil
Altai-man_ hmm
I don't think it is wise to rush its publishing, because there will be a point 13:06
lizmat www.nntp.perl.org/group/perl.perl6...g8150.html
Altai-man_: this is 2020.01 !!
Altai-man_ ah, phew
sorry
tyil nani
Altai-man_ I am brain dead right now, never mind. :[ 13:07
tyil oh, hi
Altai-man_: I built a rakudo-star, announced it on 2 MLS
Altai-man_ +1 on announcing 2020.01 star.
lizmat nanu
tyil but Im in a meeting right now
lizmat oki
I'd like to announce it in the RWN today :-)
AlexDaniel` Altai-man++ 13:12
nine 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?
lizmat nine: not sure... but fwiw, I'm currently working on a. grokking that piece of the code thoroughly, and b. making it faster 13:18
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:19
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
nine That re-rechecking of dependencies is not for changes to the installed modules. What happens is that we notice that something in the <lib> 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.
I do see several ways to attack this issue:
* 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
* 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<v1.2+>: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.
tyil ok, done with meeting
nine If I'm right that cache can save several minutes there already
tyil Altai-man_: I announced it on perl6-users and perl6-compiler, are there other places I should announce it? 13:33
I have contemplated announcing it on the fediverse too :p 13:35
lizmat tyil: so rakudo.org/downloads is up to date ? 13:36
or this: rakudo.org/star
or rakudo.org/news ?
13:36 Altai-man_ left
lizmat I'm not sure who can update that 13:36
tyil lizmat: the first page doesn't list star releases, the 2nd link contains an outdated r* 13:37
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
nine UTC+1 13:39
tyil one of my favourite timezones
I suspect he's got his own work to do right now, then
I'll send him an email 13:40
13:42 sena_kun joined
tyil sent~ 13:43
13:55 epony left
vrurg lizmat: yes, all runners are now rakudo-prefixed. perl6- is only for backward compat, apparently. 14:05
lizmat ok, cool, that means some cleanup can be in place :-)
leont nine: that sounds like the kind of compilation time I have at work, with a reasonably sized C++ application and its test suite. 14:09
rba tyil: as far as i know the news is part of the rakudo.org repo. 14:10
tyil rba: github.com/perl6/rakudo.org ? 14:13
nine 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:15
lizmat wow 14:16
yes... indeed
Geth rakudo: 638c8955f5 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Most of the arguments are constant

  - so initialize them at startup
  - including stagestats and target
  - makes installing core modules about .1 second faster (8.9 -> 8.8)		 14:18
rakudo: c9d9a096e8 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Streamline CompUnit::PrecompilationRepository a bit

  - use new $stagestats "constant"
  - use native arrays / hashes and nqp::ops to fill them
  - prevent use of intermediate arrays
  - prevent use of regex to check dependency string
Brings installing core modules below 8.8 seconds
lizmat m: dd $*RAKU.compiler.id 14:20
evalable6 "BA1A69BA1A40C2400CAC7DDB383C790B326C1245"
lizmat isn't that constant for the duration of the process? or do we assume people could be messing with $*RAKU ?
or is that basically recording the Raku version ? 14:21
m: use v6e.PREVIEW; dd $*RAKU.compiler.id 14:22
evalable6 "BA1A69BA1A40C2400CAC7DDB383C790B326C1245"
lizmat m: use v6c; dd $*RAKU.compiler.id
evalable6 "BA1A69BA1A40C2400CAC7DDB383C790B326C1245"
lizmat m: use v6.c; dd $*RAKU.compiler.id
evalable6 "BA1A69BA1A40C2400CAC7DDB383C790B326C1245"
lizmat looks like it is pretty constant
Geth rakudo: dumarchie++ created pull request #3511:
RFC: Change PositionalBindFailover MRO		 14:23
rba tyil: yes
nine The compiler's id is cosntant 14:24
tyil rba: ack, thanks 14:25
lizmat nine: ok, so no use looking that up every timde
*time
nine lizmat: I'd be surprised if there's much to gain though. The accessor will be inlined anyway 14:26
14:26 dumarchie joined
lizmat it's the dynamic lookup 14:27
that is slow for dynamic variables in PROCESS::
14:32 MasterDuke left
nine Darn....that one again: nine@sunshine:~> zef 14:36
===SORRY!===
No candidate found for 'zef'.
lizmat nine: is this on HEAD ? 14:39
did I just bork that ?
nine I've had the same issue a couple weeks ago 14:40
Oh! That's it: nine@sunshine:~> cat /home/nine/rakudo/install/share/perl6/site/bin/zef 14:45
#!/usr/bin/env perl6
/usr/bin/env perl6 will ignore $PATH and find /usr/bin/perl6 instead of /home/nine/rakudo/install/bin/raku 14:46
vrurg it reminds me to finally change all `env perl6` to `env raku`... 14:54
15:20 dumarchie left
nine On my laptop compilation time after a change goes from 1m50.783s to 0m14.515s with a resolver cache 15:34
15:34 Altai-man_ joined
leont That seems like a very good kind of change 15:36
15:36 sena_kun left
jnthn Wow. 15:39
15:48 Ven_de_Thiel joined
nine 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 15:55
16:00 dumarchie joined
nine 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:00
16:05 epony joined
nine Yeah, looks like there's another second to be had 16:06
(through the additional 3 lines of code) 16:07
Patch is gist.github.com/niner/3b8716dfc739...70028b9e6f for the curious
Ven_de_Thiel How costly is an extra lock-protect (the 2nd one) vs potentially recalculating the deps etc? 16:09
nine I guess negligible 16:10
Yeah, removing that lock there does not make a measurable difference 16:16
16:36 Guest1277 left 17:08 dumarchie left 17:12 toddr left
dogbert17 "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:16
17:19 hungrydonkey left 17:29 patrickb joined
patrickb ping tyil 17:29
tellable6 2020-02-23T19:37:06Z #raku <jmerelo> patrickb thanks, I appreciate that. So let's try next year...
tyil patrickb: o/ 17:30
patrickb tyil: Getting a release on rakudo.org should be simple. 17:31
tyil good to hear
17:31 sergot left
patrickb Did you already sign the files? 17:31
(result should be .asc files)
tyil dist.tyil.nl/raku/rakudo-star/ there's a checksum file and a pgp signature file
patrickb Looks good.
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.
tyil who has access to that webserver, and what are the requirements to get access?
patrickb The critical thing are the filenames. They are read and iterpreted by the website and interpreted. 17:33
rba
tyil I can name them in whichever way works best with existing infra
patrickb I suspect there is no process for gaining access except for a certain level of trust
tyil the names on dist.tyil.nl are just the ones I found convenient for myself
patrickb Looking at the existing rakudo star files and naming yours the same way should work 17:34
rba patrickb? 17:35
17:35 sena_kun joined
patrickb 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
rba ok.
tyil rba: it's about dist.tyil.nl/raku/rakudo-star/raku....01.tar.gz dist.tyil.nl/raku/rakudo-star/raku...tar.gz.asc and dist.tyil.nl/raku/rakudo-star/raku...cksums.txt 17:36
17:37 Altai-man_ left
patrickb tyil: Posts are part of the rakudo.org repository. They are markdown. github.com/perl6/rakudo.org/tree/master/post 17:37
So just clone that repository, add your news file and push
tyil yes, I found those with help from rba :)
patrickb Not sure if the site is autoupdated at the moment
Actually I think it's not 17:38
rba patrickb: if not autouptdate, let me know, I give it a push.
or pull LOLO
patrickb 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
rba tyil: if you had scp access to rakudo.org before, you ssh key might already been added.
tyil it's still v6.d, even now that it's Raku instead of Perl 6, correct?
patrickb tyil: I think so. We didn't change the versioning system. 17:40
tyil rba: `ssh rakudo.org` does not seem to work, I don't think I've ever had access
tbrowder 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:41
correction, it is a raku thing, but should i mention it in the raku docs? 17:42
rba tyil: you want me to add one of your github ssh public keys? Or send me as pm. 17:49
tyil: did you sign the tar.gz with the gpg key availalbe on github? 17:50
tyil rba: I have multiple SSH keys: home.tyil.nl/git/dotfiles/tree/.ss...d_keys#n5, but the one I most frequently use would be the one on line 5 (tyil@anoia.tyil.net) 17:51
rba tyil: will get the one you provieded.
tyil 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 is the PGP key ID, available at www.tyil.nl/pubkey.txt 17:52
it is the same one I use on github to sign with
(though my old key is also still on my github account I see)
also, my announcement post: github.com/perl6/rakudo.org/pull/35/files, please verify for obvious mistakes as this is my first time making one 17:53
rba: does rakudo.org listen on default port 22? 17:55
rba tyil: you may try something like: scp -p 2222 rakudo-star-2020.01.tar.gz rakudo.org@lavm-perl6infra-1.atiko...oads/star/
tyil ah 17:56
sena_kun if it'll result in network is unreachable error, try with `-P 2222` (note uppercase)
tyil rba: works 17:58
sena_kun: and I did use -P indeed :p
rba sure, use -P
sena_kun: I see. This was the mistake I sent you last time... 17:59
Geth rakudo: c909258273 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Avoid re-resolving the same dependencies multiple times

When the repository chain's id changes (e.g. because a source file in a -Ilib repository got edited) we need to re-resolve the dependencies of the precomp files we load as the change could have brought in a new prefered version of a dependency. However doing so once is quite sufficient. There's no need to re-resolve the same dependency specification over and over which could happen in large applications with many modules sharing similar dependencies. Brings down compilation time in a real life code base from 110 to 14 seconds.
rakudo: 6956c06333 | (Stefan Seifert)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Avoid looking up the same precomp id multiple times

If we have already loaded a precomp file, there's no need to search the precomp stores for its id as we already deemed it up-to-date once and would not load it again anyway. Brings down compilation time of a real world code base from 14 to 13 seconds.
tyil I can see the files on rakudo.org/downloads/star, but not yet on rakudo.org/star itself
nine 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 :)
rba patrickb: do you know if the star page is "hardwired"? 18:01
sena_kun nine, we still have to do a point release, so technically it is possible...
patrickb rba: What do you mean with hardwired? 18:02
rba This rakudo.org/latest/star/src gives us the lastest star, so rakudo-star-2020.01.tar.gz, yet on rakudo.org/star it's says 2019.03. And the win and macos is broken now. 18:04
nine 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:05
sena_kun nine, not insisting in any way. 18:06
rba tyil: Tried to verify your key using "gpg --receive-keys B6F697742EFCAF5F23CE51D5031D65902E840821". May you please add your key to a public key server? 18:07
tyil I believe I uploaded it to pgp.mit.edu
18:08 domidumont joined
nine sena_kun: why do we need to do a point release? Did I miss something? 18:08
rba tyil: Do you have a binary build for win and/or macosx?
tyil I do not 18:09
sena_kun 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: github.com/MoarVM/MoarVM/issues/1246
rba Anyone know how the binary build have been assembled for rakudo star macosx and windows? 18:10
tyil: pgp.mit.edu gives a timeout. Hmm... 18:11
tyil rba: hankache was able to build a .msi
nine Ok, so no need for me to wait for the point release to update my packages
tyil rba: can you `gpg --locate-key [email@hidden.address]
sena_kun nine, no need, though I'd still appreciate help of someone who is skilled in C in writing a patch commit. 18:12
tyil if nothing else, it's also on www.tyil.nl/pubkey.txt
rba tyil: I think of our "customers". How will they be able to verify the signature? 18:13
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
tyil I can upload it to other servers if you like, but I'm mostly using WKD to get my keys to people these days
nine sena_kun: has someone reported this bug to dyncall upstream? 18:15
sena_kun nine, I sent an email explaining the situation to dyncall maintainer, no reply yet
they don't have a pubilc bugtracker or I wasn't able to find it, alas
nine 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
rba tyil: Maybe this needs to be documented somewhere?
tyil rba: I can add it to documentation too
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
rba 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.
patrickb rba: Looking at the source code it seems it's actually static! I really didn't expect that...
rba: github.com/perl6/rakudo.org/blob/m...ar.html.ep
tyil rba: I can do my best to help you out :) 18:18
rba patrickb: Uff, realllly static.
sena_kun 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.
rba patrickb: It's fine for, as I know now. 18:19
nine 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:20
patrickb sena_kun: From my experience the dyncall devs are very responsive and willing to help. I'm sure they'll reply soon. 18:21
rba tyil: Will go through github.com/rakudo/star/blob/master...ac-dmg.pod 18:22
sena_kun 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. :)
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...
sena_kun wanders off to do a couple more Comma fixes
rba sena_kun: I agree with Alpine. This my choice as well for building docker images. 18:24
sena_kun patrickb, mind a PM? 18:30
nine Wait a minute: if it's used for CI, why didn't it come up earlier?
patrickb sena_kun: ? 18:31
sena_kun nine, used for CI, but not our CI. It seems MoarVM travis uses "linux" which means "ubuntu", not alpine.
leont Yeah, alpine is mainly used for minimalist docker images AFAIK 18:33
sena_kun 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
s/for rakudo/for moarvm/ 18:34
tyil 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, MasterDuke joined 18:57 Altai-man_ joined 18:58 sena_kun left
MasterDuke Xliff: does github.com/rakudo/rakudo/commit/c9...dfc7568c70 do anything for your compile times? 18:58
tellable6 MasterDuke, I'll pass your message to Xliff
rba 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:00
tyil hmm 19:01
I tried a --recv-keys in an ubuntu docker container without any additional configuration, and it worked there
patrickb rba: New rakubrew is there (v4). Can you upload? patszim.volans.uberspace.de/patclo...EJLQDZcjbf 19:04
rba will myself embed into a docker container in my next life. 19:05
patrickb: v4 in rakubrew.org 19:10
patrickb rba: Thank you!
rba patrickb: the repo has not changed, right? 19:11
patrickb rba: No. Only that one file. :-)
Geth problem-solving: tbrowder++ created pull request #165:
update reference		 19:13
19:35 sena_kun joined
rba May one have a quick look about the build log for rakudo star on MacOSX ? gist.github.com/13274d2e68017700a3...db3730e439 19:36
19:36 Altai-man_ left
rba tyil: ā†‘ 19:37
tyil rba: looks like everything built succesfully, and modules seem to have installed without error 19:38
19:40 domidumont left
lizmat .tell nine the last 2 commits appear to add ~.5 second to installing core libraries :-( 19:44
tellable6 lizmat, I'll pass your message to nine
lizmat .tell nine forget what I said 19:47
tellable6 lizmat, I'll pass your message to nine
nine is relieved 19:49
20:11 epony left 20:12 epony joined
tyil lizmat: the latest rakudo star for GNU+Linux is available at rakudo.org/downloads/star, but rakudo.org/star has not been updated yet 20:15
rba: I merged the announcement post into the rakudo.org repo 20:16
lizmat tyil++
notable6: weekly 20:19
notable6 lizmat, 2 notes: 2020-02-17T18:21:26Z <sena_kun>: A new Raku dist template, with the bare minimum to start a module: github.com/JJ/raku-module-template ; 2020-02-20T20:10:18Z <El_Che>: www.reddit.com/r/rakulang/comments...ws_in_raku
lizmat notable6: weekly reset 20:21
notable6 lizmat, Moved existing notes to ā€œweekly_2020-02-24T20:21:30Zā€
rba rakudo-star 2020.01 for MacOSX is available now: rakudo.org/star (windows still missing though) 20:24
Geth nqp: b9a1878c4f | (Patrick Bƶker)++ | tools/build/update-submodules.pl
Build: Fix submodule update with space in git ref dir
 20:33
rakudo: 3ec58489e7 | (Patrick Bƶker)++ | tools/build/update-submodules.pl
Build: Fix submodule update with space in ref dir path
rba tyil: Do you have everything you need? I like to afk. 20:34
tyil rba: yes, I think everything we can do is in order for lizmat to feel confident announcing it in rwn 20:35
rba tyil: I think there are errors in the announcement. Refering to MoarVM 2019.03? 20:36
tyil: rakudo.org/post/announce-rakudo-st...se-2020.01
tyil I was just fixing a couple 20:37
rba alerts.perl6.org/ died with the server last year. RIP.
tyil github.com/perl6/rakudo.org/commit...2bf4e3c3d5
rba perl6.org/downloads/ should be raku.org/downloads/ 20:38
tyil I dont think theres a new variant of alerts.perl6.org
rba tyil: No, not that I'm aware of.
tyil I never used alerts.perl6.org, how was it used? 20:39
did it scrape git logs or twitter announcements or something?
or was it a cms based website?
rba tyil: Sorry I give up for today, even though there is more work on raku.org/downloads/ ... Sorry. 20:42
tyil rba: dont push yourself, I'm very grateful for your work today
rba tyil: Tomorrow is another day... 20:43
patrickb nine: Might your compile optimization also apply to Xliffs incredibly high build times?
nine maybe 20:52
21:27 cognomin_ joined 21:28 patrickb left 21:31 cognominal left 21:34 Altai-man_ joined 21:36 sena_kun left
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/02/24/2020-...red-noise/ 21:37
MasterDuke 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:49
tyil lizmat++ 21:56
22:51 pyrimidine left
lizmat MasterDuke: I'm considering going on Thu/Fri 22:52
MasterDuke cool, that's when i'll be there 22:53
23:35 sena_kun joined 23:37 Altai-man_ 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!