[00:01] *** kensanata joined [00:02] *** patrickz left [00:16] Hm. I'm getting a warning when compiling 2020.6 [00:17] ...when compiling moarvm [00:18] src/core/interp.c:3315:36: warning: variable ‘coderef’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered] [00:19] ...and a bunch more with libuv.. [00:30] *** Cabanossi left [00:36] *** Cabanossi joined [00:44] *** oneeggeach left [00:46] *** xinming_ left [00:46] *** kensanata left [00:48] *** xinming_ joined [00:51] *** MilkmanDan left [00:53] *** melezhik joined [00:53] I've added 2020.06 version to RakuDist [00:54] *** MilkmanDan joined [00:55] *** Altai-man_ joined [00:57] *** sena_kun left [01:14] *** melezhik left [01:21] *** molaf joined [01:32] *** rir left [02:02] Thanks a lot to all contributors for all the continuous work that went in the june release! [02:05] *** Manifest0 left [02:06] *** Manifest0 joined [02:13] *** Cabanossi left [02:17] *** oodani left [02:17] *** oodani joined [02:23] *** Cabanossi joined [02:55] *** sena_kun joined [02:57] *** Altai-man_ left [03:41] *** MilkmanDan left [03:44] *** _jrjsmrtn joined [03:44] *** __jrjsmrtn__ left [04:41] *** MilkmanDan joined [04:47] *** zacts joined [04:55] *** Altai-man_ joined [04:57] *** sena_kun left [05:18] *** OpenZen left [05:31] *** Cabanossi left [05:39] *** Cabanossi joined [05:47] *** stoned75 left [05:48] *** stoned75 joined [06:01] *** skids joined [06:42] *** stoned75 left [06:43] *** skids left [06:50] *** guifa left [06:56] *** sena_kun joined [06:57] *** Altai-man_ left [07:09] *** wamba joined [07:24] *** famra joined [07:26] *** brtastic joined [07:26] *** famra left [07:27] *** famra joined [07:31] *** famra left [07:43] *** famra joined [07:44] *** aborazmeh joined [07:44] *** aborazmeh left [07:44] *** aborazmeh joined [07:44] *** famra left [07:44] *** leont joined [07:47] [07:48] *** famra joined [07:48] *** zacts left [07:48] *** famra left [07:49] *** zacts joined [07:50] *** famra joined [07:51] *** oddp left [07:52] *** famra_ joined [07:54] *** famra left [07:54] *** soursBot joined [07:57] *** famra_ left [08:00] *** famra joined [08:01] *** famra left [08:02] *** famra joined [08:02] how can you turn off the GC? [08:03] *** famra left [08:04] assuming that's even possible hehe [08:04] *** xinming_ left [08:05] *** xinming_ joined [08:08] ahhh no it's okay i can get garbage collection time with --profile that's all i needed 🙂 [08:15] *** rindolf joined [08:16] *** ensamvarg left [08:17] *** wamba left [08:17] *** ensamvarg joined [08:21] *** tejr left [08:30] *** wamba joined [08:38] *** tejr joined [08:47] *** aborazmeh left [08:55] *** Altai-man_ joined [08:57] *** sena_kun left [09:10] *** rbt left [09:11] *** rbt joined [09:15] *** brtastic left [09:48] *** zacts left [09:49] *** zacts joined [09:55] *** Sgeo left [10:31] *** pecastro joined [10:41] *** aborazmeh joined [10:41] *** aborazmeh left [10:41] *** aborazmeh joined [10:56] *** sena_kun joined [10:57] *** Altai-man_ left [10:59] *** soursBot left [11:09] *** aborazmeh left [11:13] *** soursBot joined [11:24] *** libertas joined [11:24] *** grondilu joined [11:36] *** synthmeat left [11:36] *** synthmeat joined [11:42] *** oddp joined [11:45] *** grondilu left [11:51] *** Xliff joined [11:55] *** brtastic joined [12:08] *** tejr left [12:08] *** tejr joined [12:12] *** zacts_pi joined [12:14] *** libertas left [12:14] *** zacts left [12:17] *** libertas joined [12:21] *** MilkmanDan left [12:22] *** libertas left [12:24] *** libertas joined [12:27] *** cpan-raku left [12:27] *** zacts_pi left [12:28] *** cpan-raku joined [12:28] *** cpan-raku left [12:28] *** cpan-raku joined [12:31] *** libertas left [12:33] *** libertas joined [12:55] *** Altai-man_ joined [12:57] *** brtastic left [12:57] *** tejr left [12:57] *** sena_kun left [12:57] *** tejr joined [12:58] *** tejr left [12:59] *** tejr joined [13:04] *** vike left [13:07] *** vike joined [13:13] *** nwc10 joined [13:13] good *, #raku [13:13] (I hope that UGT applies ehre too) [13:13] so, if I have: [13:13] evalable6: my @versions = (1.0, 11.0, 12.0, 12.1, 13.0, 2.0, 3.0, 4.0, 5.0); say my @sorted-emoji-versions = @versions>>.Num.sort.reverse; say "Emoji versions: ", @sorted-emoji-versions.join(", "); [13:13] nwc10, rakudo-moar 34f985de9: OUTPUT: «[13 12.1 12 11 5 4 3 2 1]␤Emoji versions: 13, 12.1, 12, 11, 5, 4, 3, 2, 1␤» [13:14] how would I have that sort in the same (numeric) order, but not truncate the ".0" bits? [13:14] I'm a bit lost as how to say "Sort numericaly, but don't cast to a number" [13:14] m: say my @sorted-emoji-versions = @versions.sort(*.Num).reverse; say [13:14] rakudo-moar 34f985de9: OUTPUT: «5===SORRY!5=== Error while compiling ␤Variable '@versions' is not declared. Did you mean 'Version'?␤at :1␤------> 3say my @sorted-emoji-versions = 7⏏5@versions.sort(*.Num).reverse; say␤» [13:15] * m: my @versions = (1.0, 11.0, 12.0, 12.1, 13.0, 2.0, 3.0, 4.0, 5.0); say my @sorted-emoji-versions = @versions.sort(*.Num).reverse; say [13:15] ah damn [13:15] anyway, you get the point [13:16] not yet... (hangon) [13:17] basically `.sort(*.Num)` to use something else to sort [13:23] thanks. Lets see if I can get emojis now. [13:23] I blame the Unicode consortium :-) [13:24] inconsistent URLs (.../latest/... has to be unpicked differently to get 12.1.0 of UCD and 12.1.0 of UCA instead of 13 of both. Silly ftp server that must have changed as I assume samcv's script used to work, etc) [13:26] aaaaaaaaaaaaaaaaaaargh, emoji-13.0/emoji-data.txt does not exist [13:27] because they put it somewhere else. [13:52] Is anyone able to install IO::Socket::Async::SSL on 2020.06? The t/ciphers.t test hangs on me. [13:55] m: ^10 .map: &[+] [13:55] rakudo-moar 34f985de9: ( no output ) [13:55] m: say ^10 .map: &[+] [13:55] rakudo-moar 34f985de9: OUTPUT: «(1 5 9 13 17)␤» [13:55] Um, what's happening here? [13:59] rbt: installed fine for me [14:00] phew [14:00] damn. That means I need to investigate [14:00] * Altai-man_ still compiles to try out [14:00] FWIW, this module tests are explicitly skipped by blin. [14:00] Closing the socket is stalling. [14:01] *** nwc10 left [14:01] * lizmat is on MacOS [14:01] This passes fine. [14:01] diff --git a/t/ciphers.t b/t/ciphers.t [14:01] index a1d28f7..e6ccf79 100644 [14:01] --- a/t/ciphers.t [14:01] +++ b/t/ciphers.t [14:01] @@ -29,7 +29,7 @@ lives-ok [14:01] my $s = await IO::Socket::Async::SSL.connect('localhost', TEST_PORT, [14:01] ca-file => 't/certs-and-keys/ca.crt', [14:01] ciphers => 'HIGH'); [14:01] - $s.close; [14:01] +# $s.close; [14:01] }, [14:01] 'Connection ok when ciphers match up'; [14:03] * Altai-man_ starts to pray [14:04] Incidentally, it would be nifty if Test could take a maximum runtime and fail if it is exceeded. [14:04] *** xinming_ left [14:05] ===> Testing [OK] for IO::Socket::Async::SSL:ver<0.7.5> [14:05] can't confirm [14:05] start { sleep 500; exit } # rbt [14:05] *** libertas left [14:05] This is Rakudo version 2020.06 built on MoarVM version 2020.06 [14:05] I have a linux box [14:05] *** xinming_ joined [14:06] I'm also Linux. 5.4.0-37-generic [14:07] 5.4.35_1 nothing interesting. :S [14:07] Thanks for testing. I'll do some digging and see what I can find. [14:07] rbt, good luck. [14:08] Erm. Anyway to get a profile from something like this? [14:08] --profile? [14:09] raku --profile --profile-filename=/tmp/results.html foo.raku [14:09] It doesn't get written if you ctrl+c the process. [14:09] I think you can ping #moarvm for instructions on debugging. [14:09] Because you likely want a debugger to see what happens, not profiler. [14:10] Indeed. [14:10] Okay. thanks. [14:12] *** libertas joined [14:14] *** xinming_ left [14:15] *** xinming_ joined [14:16] *** libertas left [14:20] *** libertas joined [14:32] *** pecastro left [14:32] *** libertas left [14:38] *** libertas joined [14:45] *** pecastro joined [14:49] *** MilkmanDan joined [14:55] *** sena_kun joined [14:57] *** OpenZen joined [14:57] *** Altai-man_ left [14:57] *** patrickb joined [15:00] *** soursBot left [15:07] *** MilkmanDan left [15:09] *** brtastic joined [15:16] *** libertas left [15:33] *** soursBot joined [15:43] *** JJMerelo joined [15:49] *** dataangel joined [15:52] *** tejr left [16:03] *** tejr joined [16:03] *** mowcat joined [16:06] *** xinming_ left [16:07] *** xinming_ joined [16:07] *** brtastic left [16:34] *** wamba left [16:35] *** wamba joined [16:53] *** stux|RC left [16:54] *** stux|RC joined [16:55] *** Altai-man_ joined [16:57] *** sena_kun left [17:05] *** soursBot left [17:06] *** soursBot joined [17:32] Altai-man: I found the issue and made a fix which basically breaks with a bit of noise but I'm far from certain it is the right action to take. [17:32] https://github.com/jnthn/p6-io-socket-async-ssl/pull/53 [17:33] *** iiiy joined [17:33] rbt, we don't need a point release? :) [17:35] No. I think I got a quirky OpenSSL update from Ubuntu. [17:35] Basically, the module ignore warnings while setting up the socket but not while tearing it down. [17:36] So a promise was not getting kept (or broken). [17:36] Same error with 2020.02.01 [17:42] *** melezhik joined [17:43] .tell rbt I recall having the same issues with IO::Socket::Async::SSL even on older Rakudo versions, when I test modules with RakuDist [17:43] melezhik, I'll pass your message to rbt [17:43] so yeah, it hangs sometimes ( I guess some tests do ) [17:54] *** iiiy left [17:56] *** MilkmanDan joined [18:02] *** melezhik left [18:09] *** vrurg left [18:15] *** brtastic joined [18:16] releasable6: status [18:16] El_Che, Next release in ≈27 days and ≈0 hours. There are no known blockers. Changelog for this release was not started yet [18:17] El_Che, Details: https://gist.github.com/57ef5d95b269b0a70050a4dbfea8bab3 [18:17] *** OpenZen left [18:17] *** OpenZen joined [18:18] *** tejr left [18:18] *** tejr joined [18:22] *** MilkmanDan left [18:24] New module released to CPAN! Gnome::N (0.17.9) by 03MARTIMM [18:37] *** JJMerelo left [18:39] *** vrurg joined [18:47] *** brtastic left [18:51] rakudo-pkg building atm [18:55] *** sena_kun joined [18:56] *** Sgeo joined [18:57] *** Altai-man_ left [18:58] *** soursBot left [19:10] *** rbt left [19:10] *** guifa joined [19:11] *** rbt joined [19:12] Hooray, I can do now do my $foo = “aosidoi 363% adftervd” ~~ //; say $foo; say $+foo; [19:12] and get ‘363%’ and 3.63 respectively [19:12] err +$foo [19:22] I have a failure building a relocabable rakudo that I didn't have with previous releases: https://gist.github.com/nxadm/385dc568b7cdd88a9cb7fbebc89fb875#file-rakudo-fail-L5532 [19:22] the relocatable releases are done on the oldest supported linux distros [19:23] in this cases x64 is done on centos6 [19:23] does it ring a bell? [19:23] it looks like the new code makes some compiler assumptions it didn't before [19:27] El_Che did you see the conversation on #raku-dev? [19:27] It boils down to this: https://github.com/MoarVM/MoarVM/pull/1318 [19:28] For the precomp builds on rakudo.org I just patched the file. [19:28] I see [19:28] *** kensanata joined [19:30] Can i work around by export env vaiables or is patching the only way to go? [19:33] El_Che: I can't promise, but I think patching is the only way to go. You need to make gcc do other stuff. Can't do that with env vars or some such... [19:34] thx [19:36] Please patch. I suspect most of the people with such old glibc use binaries and if you are compiling on something like centos, you can as well drop here and ask. I am also wondering if we can make our CI to check such cases. [19:36] 2020-06-21T18:33:39Z #raku-dev sena_kun: Precomp builds are done and uploaded. [19:37] One thing I am sure of is we won't do points every month, it is more robust to fix infrastructure which allowed that to happen and move forward in 27 days. [19:41] Naming preference question [19:41] In CLDR, there are two data points in the exemplar characters set. “standard” and “auxiliary” [19:42] For English, standard is A-Z, but auxiliar includes accented characters that are commonly encountered but not strictly English [19:42] I’ve made a token called but I’m not sure the best way to call standard, versus standard+auxiliarly [19:44] I’ve thought about :strict (to limit to standard) or :broad / :lax (to open it up to auxiliary), but I’m not really liking those names, nor am I convinced which one should be the default mode. ANy thoughts? [19:44] I will move my relocatable builds to ubuntu 14.04, released on the same year as centos 6 [19:44] still supported [19:51] *** soursBot joined [20:03] *** aborazmeh joined [20:03] *** aborazmeh left [20:03] *** aborazmeh joined [20:16] *** MilkmanDan joined [20:21] * moritz doesn't dare upgrading his work laptop from ubuntu 14.04 to a current LTS until he's at the office again, where he can fall back on a desktop PC [20:22] wow, how long have you been in lockdown? [20:24] since mid March [20:24] 2015? [20:24] :P [20:25] erm, 18.04 [20:25] sorry :D [20:25] but I've been in lockdown since befor the 20.04 LTS release [20:27] I went once to the office to get 2 screen for home [20:28] and took all my (test) laptops with me :) [20:28] I have a stack op laptops on my desk :) [20:28] of [20:29] 20.04 is a greate release [20:29] as 19.10 was as well [20:29] El_Che: Ubuntu 14.04 has glibc 2.19. Such builds will break on: CentOS/RHEL 6 and 7. [20:29] the best in years [20:29] *** MilkmanDan left [20:30] yeah, I'm bumping the releases. I have debs and rpms for old supported releases except centos 6 [20:30] but it will be unsupported this year [20:30] * moritz read lots of negative things about 20.04 and snaps [20:31] yeah, ubuntu is betting hard on snaps [20:31] I don't use it, except a few they installed for gnome [20:31] as long as apt continues to work on the command line, I'm good :D [20:31] *** MilkmanDan joined [20:32] https://gist.github.com/nxadm/7759cd726b379faa34300ed6718c51a0 [20:32] thatś what installed on my laptop [20:33] pretty much the runtime + a few gnome pieces that I need to look into to replace them with debs [20:33] the annoying part is that they also install snap on servers [20:33] but I just remove it [20:39] * lizmat snaps it not [20:39] :) [20:44] *** xinming_ left [20:44] *** xinming_ joined [20:48] *** kensanata left [20:50] sena_kun: if you're talking about packagers, I get your point. If you're talking about regular users compiling the release, then no dot release is less than ideal [20:50] *** aborazmeh left [20:55] *** Altai-man_ joined [20:56] El_Che, I do agree it is LTA. But I also think about how many regular users have distros from 2011 which _insist_ on compiling instead of just using a package in this particular environment. If anyone wants to do a point release, I won't object. [20:57] *** sena_kun left [20:58] Altai-man_: I certainly agree about using binaries (no surprises there :) ), I just think source has the "official status" and expectations if you know what I mean [21:01] *** rindolf left [21:06] I may be reacting worse than usual right now because of the hell of last couple of weeks and stuff. While I do agree with statement the releases should have enough quality, yet this will be a third in a row failed release which needed a point, so much quality (nope). Maybe I am not just qualified enough to do this properly. [21:07] Altai-man_: you had all of the green lights you could expect, so please don't blame this on yourself [21:07] Altai-man_: I don't see it as you not being qualified. The thought didn't cross my mind [21:08] we need more lights that can go red if we want to prevent this sort of thing in the future [21:08] lizmat, that's why I am saying about "make a visible clear test for such cases first" every time. [21:08] Altai-man_: it's the same when I'm refactoring core stuff: if all tests pass, and blin his happy, and someone finds an issue after that [21:09] Altai-man: I'd vote for no point release this time. The chance for someone stumbling over this are quite slim. [21:10] Altai-man_: there is a long story of dot releases, and I don't think anyone thought of blaming AlexDaniel` or Zoffix. The other way round actually. A dot release is a lot of extra work. [21:11] so what happened? What's the bug in the release? [21:11] I'm starting to backlog now, but maybe there's a TL;DR [21:12] An option is to amend the release notes? [21:12] "Make fails on older compiler" https://github.com/MoarVM/MoarVM/issues/1309 [21:13] *** soursBot left [21:16] hm [21:16] AlexDaniel: The build fails on ancient GCCs (< 5.0). [21:16] AlexDaniel`, to compiler from sources using gcc in centos 6 you need to add a parameter by hands / patch code by hands. Can just use binaries which presumably will be patched. [21:16] s/compiler/compile/ [21:16] and 7, I just saw [21:17] I wouldn't call it ancient… that's like 2014-2015? [21:18] Datapoint: The build was broken for years until I fixed building on older GCCs some months ago. Nobody had noticed before. [21:18] Altai-man_: if I were you I'd give it a day or two, then decide [21:18] maybe more issues will pop up and it'll make the decision easier [21:18] or more bug reports [21:18] about the same issue [21:18] Let me just ask quickly... Applying a patch, archiving it as 2020.06 and replacing on the server is the most horrible idea I could thought of, right? [21:18] patrickb: oh. Hmm [21:19] or if it remains quiet then no need to do anything [21:19] The only reason this came up so quickly now is that the precomp system El_Che and I are using both build on CentOS 6. [21:19] Altai-man_: yes, pretty horrible? [21:19] Ok, forget that. [21:19] you wonderful people :) [21:19] s/precomp system/infrastructure for creating the precompiled binaries/ [21:20] I have a question though, why haven't you noticed it before the release? [21:20] honestly, fixing that is perhaps more important than fixing the release [21:21] .oO( we need more lights that can go red ) [21:21] AlexDaniel`, we use newer envs for all the checks and then after making a release binaries are created. [21:21] AlexDaniel: Testing does not use ancient OSes. Only the infra for creating the pre built binaries. [21:21] the release won't matter in a month, but being able to know that the release is not breaking for older compilers is an everlasting beauty [21:22] yeah but can't we make like nightly binaries? [21:22] So the idea would be to muddle in a test on CentOS 6 into the MoarVM tests? [21:23] yeah, that's one way [21:23] Either this or move binaries creation earlier in the pipeline. [21:23] but as long as something is running before the release it'll be much better than the current situation [21:24] https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros <- azure provides centos 6, 7, 8. [21:25] Can't we extend out current setup to use it to create artifacts? [21:26] Altai-man: That's what already happens. [21:26] The precomp releases I create use the azure pipeline of rakudo [21:26] It has two stages: Test and Build_Precomp_Release [21:27] Currently a flag triggers which of the two should be run. [21:27] patrickb, are you missing something out? Why wasn't the bug detected then? [21:28] The precomp build stage is currently hidden behind a flag. It's not run by default. [21:28] patrickb, a-anything preventing us from enabling it? [21:32] *** gordonfish left [21:37] patrickb, doesn't "The build was broken for years until I fixed building on older GCCs some months ago" contradict with "I have been building Raku on Centos 6 since 2015" in the ticket? [21:38] Oh, they are referring to two different bugs. [21:42] *** mowcat left [21:43] let me find that commit... [21:47] https://github.com/MoarVM/MoarVM/commit/23c16b303163c621858365dbf56eb <- That's the one. Could be it was CentOS 4 or 5 at that time. [21:48] Enabling the precomp build stage is not entirely trivial. It builds based on the final release source archive that it downloads. [21:48] Such archives are not available for every commit. [21:48] I see. [21:49] *** brtastic joined [21:49] ¦ doc: 1d19613151 | (Patrick Böker)++ | 3 files [21:49] ¦ doc: Document `:$win-verbatim-args` argument of `run()` and related functions [21:49] ¦ doc: review: https://github.com/Raku/doc/commit/1d19613151 [21:49] ¦ doc: 63cfe662ed | (Patrick Böker)++ (committed using GitHub Web editor) | 3 files [21:49] ¦ doc: Merge pull request #3347 from patrickbkr/problem-solving20 [21:49] ¦ doc: [21:49] ¦ doc: Document `:$win-verbatim-args` argument of `run()` and related functions [21:49] ¦ doc: review: https://github.com/Raku/doc/commit/63cfe662ed [21:50] *** wamba left [21:52] It might be possible to make it work for every commit by implementing a switch to either use a release source archive or a checkout. But then the build won't be exactly the same. [21:53] Ok, so I'm going afk for now, then $dayjob. Will think about if we need a point. [21:53] o/ [21:54] patrickb, never mind the nightly then, I guess just tweaking the setup to have explicit checks for this case is enough. [21:54] s/this case/centos/ [22:31] *** Cabanossi left [22:43] *** Cabanossi joined [22:55] *** sena_kun joined [22:57] *** Altai-man_ left [23:03] *** stoned75 joined [23:07] *** brtastic left [23:18] *** patrickb left [23:48] *** pecastro left [23:55] *** leont left