00:55 Altai-man_ joined 00:57 sena_kun left 02:55 sena_kun joined 02:57 Altai-man_ left 03:57 nativecallable6 left, committable6 left, statisfiable6 left, bloatable6 left, squashable6 left, notable6 left, bisectable6 left, tellable6 left, evalable6 left, linkable6 left, shareable6 left, greppable6 left, reportable6 left, sourceable6 left, coverable6 left, releasable6 left, unicodable6 left, quotable6 left, nativecallable6 joined, notable6 joined 03:58 sourceable6 joined, coverable6 joined, releasable6 joined, evalable6 joined, bisectable6 joined, squashable6 joined, reportable6 joined 03:59 shareable6 joined, bloatable6 joined, unicodable6 joined, tellable6 joined, quotable6 joined, greppable6 joined, committable6 joined, linkable6 joined 04:00 statisfiable6 joined 04:40 ShimmerFairy left 04:55 Altai-man_ joined 04:57 sena_kun left 06:56 sena_kun joined 06:57 Altai-man_ left 08:01 jmerelo joined 08:06 samebchase-1 is now known as samebchase-
Geth ¦ problem-solving: Altai-man assigned to jnthn Issue Current Rakudo (possibly MoarVM as well) development process hinders releasing github.com/Raku/problem-solving/issues/206 08:18
08:34 jmerelo left
lizmat Files=1306, Tests=111383, 217 wallclock secs (28.78 usr 8.09 sys + 3034.93 cusr 284.30 csys = 3356.10 CPU) 08:42
Geth rakudo/set_equality: 105 commits pushed by 16 authors
review: github.com/rakudo/rakudo/compare/d...d550c46391		 08:51
08:55 Altai-man_ joined 08:57 sena_kun left
Geth ¦ problem-solving: lizmat unassigned from jnthn Issue Current Rakudo (possibly MoarVM as well) development process hinders releasing github.com/Raku/problem-solving/issues/206 09:06
09:13 jjatria left 09:16 jjatria joined, jmerelo joined 09:17 leont joined 09:22 jmerelo left
Geth roast/set_equality: 23 commits pushed by (Elizabeth Mattijsen)++, (Patrick Böker)++, (Mikhail Khorkov)++, (Christian Bartolomäus)++
review: github.com/Raku/roast/compare/715f...c05610b659		 09:22
09:48 jmerelo joined 10:03 ShimmerFairy joined
lizmat m: m: "42" ~~ / $<0=count>=(\d+) /; say $0, $<count> # how to make something a positional as well as a named capture :-) 10:04
camelia ｢42｣｢42｣
Geth rakudo/master: 4 commits pushed by (Elizabeth Mattijsen)++ 10:06
roast: 715fb79b93 | (Elizabeth Mattijsen)++ | 2 files
Tests for Rakudo PR #3727
 10:07
roast: 7bc05610b6 | (Elizabeth Mattijsen)++ | 1582 files
Merge branch 'master' into set_equality
roast: da1c4f2b66 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Merge pull request #646 from Raku/set_equality

Tests for Rakudo PR #3727
10:32 ShimmerFairy left 10:33 ShimmerFairy joined
lizmat ShimmerFairy o/ 10:33
ShimmerFairy o/ 10:34
10:56 sena_kun joined 10:57 Altai-man_ left 11:15 jjmerelo joined
[Tux] Rakudo version 2020.06-6-gf470b544d - MoarVM version 2020.06-4-g06d8cdd16
csv-ip5xs0.844 - 0.871
csv-ip5xs-208.060 - 8.190
csv-parser27.398 - 29.981
csv-test-xs-200.400 - 0.408
test8.450 - 8.486
test-t2.007 - 2.101
test-t --race0.876 - 1.106
test-t-2033.903 - 35.248
test-t-20 --race10.304 - 10.525
 11:38
11:50 jjmerelo left 12:55 Altai-man_ joined 12:57 sena_kun left
lizmat notices that raku.org is not telling anybody where to download binary packages 14:00
or am I missing something?
lizmat would like to link to binary package download locations 14:01
in the RWN
[Coke] raku.org/downloads - first section is binary star packages.
lizmat notable6: weekly
notable6 lizmat, 1 note: 2020-06-18T12:58:07Z <lizmat>: news.ycombinator.com/item?id=23560339
lizmat [Coke]: which is out of date
[Coke] ok
I think I already opened a ticket about that. 14:02
lizmat notable6: weekly reset 14:03
notable6 lizmat, Moved existing notes to “weekly_2020-06-22T14:03:01Z”
[Coke] ... but I can't find it. :( 14:04
ShimmerFairy I've made a gist demonstrating why I think the handling of virtual left margins in Pod currently is bad (see the sample output beneath the source): gist.github.com/ShimmerFairy/d3875...10ec6e22c0 14:06
I've been thinking about once again trying to work on Pod parsing in Raku, and this is one thing I'd like it if we could fix. 14:07
14:14 lucasb joined 14:17 patrickb joined
patrickb lizmat, [Coke]: rakudo.org/downloads has the binary packages. That page is linked on rakudo.org/downloads on the right. 14:19
I think we should promote those builds more instead of star (which is not built for every release). 14:20
But I've had enough website stuff for a while after reworking rakudo.org ... 14:21
lizmat ok
:-)
patrickb Also I have a bit of an outsider opinion wrt Rakudo Star. So I'm having a bit of a hard time deciding to what level it should be promoted. 14:22
A while ago the official recommendation was that people should use the Star releases. They are more stable and have packages included. 14:23
I object that opinion a bit. Our montly releases have become quite stable. And I prefer to encourage users to learn how to use zef instead of presenting them a preselected set of packages. 14:25
So I personally would make the monthly pre-built releases archives more visible and decrease visibility of Star. But I recongnize that I shouldn't do that until more people come to the same conclusion. 14:28
14:32 Kaeipi left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/06/22/2020-25-on-time/ 14:33
14:33 Kaeipi joined
vrurg patrickb: I would back you on this. I'd rather recommend rakubrew especially if it gets `default-modules` command. :) 14:37
patrickb vrurg: Can you elaborate? (Maybe in a ticket) 14:38
vrurg patrickb: So loaded, never thought about a ticket. :) In brief, Star is good because it builds/installs rakudo+zef+default set of modules. rakubrew does it all already. So, to my view, Star could be replaced with `rakubrew build` + `build zef` + `default-modules` or `star-modules` 14:42
The last command would just install all the same modules Star currently installs. 14:43
It could all be covered by, say, `rakubrew star moar 2020.06`
patrickb Hm. I wouldn't like baking a fixed set of modules into rakubrew. One of the reasons I dislike module lists is that they tend to become stale. 14:44
Also _installing_ loads of modules will always install stuff the user will never use. 14:45
Would something akin to Task::Kensho in Perl be a viable alternative? 14:46
vrurg patrickb: It wouldn't be the default behavior. In neither way. But it would greatly simplify a beginner's experience. 14:49
I don't know what Task::Kensho does. Gonna have a look. But with regard to the module list, it could be downloadable. No need to hardcode it into rakubrew. So, community would be able to update and have it as 'recommended for beginners' 14:50
14:51 krunen left
vrurg patrickb: Got it about Task::Kensho. Well, I like the idea. Task::RakudoStar? 14:52
14:55 sena_kun joined 14:57 Altai-man_ left 15:00 patrickb81 joined 15:02 patrickb left 15:05 krunen joined
patrickb81 vrurg: Something like that. Could be a module that simply depends on others + a very nice readme explaining them. 15:05
I'd like to keep the name "Rakudo" out there. Such a bundle is agnostic of the backend. Task::StarBundle? 15:07
vrurg patrickb81: But it still fits into my proposal. `rakubrew star` command could install this module by default.
patrickb81 Then one can just do `rakubrew download && zef install Task::StarBundle` and that's it.
vrurg patrickb81: I'll try to remember to make a ticket on this. Worth further discussion perhaps.
patrickb81 Why integrate into rakubrew? That's our chance to lessen fear of contact users might have with a package manager! 15:08
vrurg patrickb81: because rakudostar is still about quite a lot of hand work for a beginner. rakubrew is much easier to start using it, to my view. I'd better think of releasing resources spent on RakudoStar for something else. 15:15
15:18 krunen left
nine I have not seen a use for Star in years and think none of claims of better stability have ever been backed up with actual facts. I also don't think rakudobrew is worth the extra complexity. It's not like `git clone github.com/rakudo/rakudo.git && cd rakudo && perl Configure.PL --build-moar --install` is any harder or more to type than rakudobrew 15:20
15:21 krunen joined
Geth rakudo: Kaiepi++ created pull request #3767:
[WIP] Make Parameter.BUILD more robust		 15:21
roast: Kaiepi++ created pull request #649:
Add tests for Parameter.BUILD		 15:22
ShimmerFairy Perhaps back in the hectic pre-Christmas days having a kind of LTS release was more useful than it is today. 15:26
nine Oh, I'd still see a value of an actual LTS release and have fantasized a lot about doing one. It's that LTS doesn't just mean "just release it less often" but "maintain it for longer". And no one has ever done the maintaining part on Star which is why those claims to stability are so easy to dismiss. 15:27
patrickb81 nine: Wrt rakubrew not being worth it: I agree if one sees rakubrew as an alternative to building rakudo oneself as a developer. 15:32
I disagree if one sees rakubrew as a way to install (not necessarily build) a rakudo release and zef and keep it up to date. 15:34
sena_kun uses rakubrew because it offers quick and working "build a commit/switch between versions" solution. Doing the same with `git clone - build` way leads to re-inventing the wheel fast.
When it comes to actual developer who likely wants to have an official release somewhere handled by distro pm and cares about bleed, then maybe it is less useful. 15:35
patrickb81 I mostly use it to have an up to date version of rakudo installed. When a new version comes out `rakubrew download moar 2020.06 && rakubrew switch moar 2020.06`. If it somehow doesn't work, just switch back. 15:36
nine Why would a plain user need to build a commit/switch between versions?
patrickb81 nine: Painless update to newer versions and easy switching back should something go wrong. 15:37
Also not having to think up a scheme where to put it and how to get the thing into path. 15:38
Distro packages are the obvious alternative except for the switch back part and not being so up-to-date.
nine If distro packages aren't up-to-date enough, why not simply help with keeping them up to date? 15:39
patrickb81 nine: Given plain user == developer building stuff using raku
nine I've done some 20 years of developing with Perl without having to compile it myself 15:40
ShimmerFairy I'd say my distro has a bunch of "switch between different versions" stuff for things like gcc or python. But then again I use gentoo, so perhaps not a very typical Linux user.
nine And if I'm compiling myself, doing `git checkout 2020.01 && bash config.status` isn't terribly hard either. 15:41
patrickb81 nine: I have a few perl apps running on CentOS 6 and 7. Both don't provide current perls. What I ended up doing is installing a perl via perlenv. 15:42
sena_kun by the way, patrickb81, is MVM_gcc check on azure is the thing I think about or?
nine patrickb81: so why instead of working around that lack not simply fix it? Which would help all other users, too
The whole idea behind rakudobrew sounds like "there's this thing in the Perl world, we obviously have to have something similar" without wondering whether we actually have the same problems. 15:43
patrickb81 nine: It's a question of what you consider the cleanest / best approach. I like the idea of not touching system packages much for stuff I develop myself. 15:45
nine because? 15:48
patrickb81 I have quite some bad experiences trying to install some perl module - first via a distro package (often doesn't exist or outdated), then via cpan and installing into the system (this often breaks + me fearing breaking the system because I mess with system perl). 15:49
Having a perl installed only for that specific app keeps things separate, stays far away from system perl. I did that before all the container hype started. 15:50
nine Thank you for confirming my point: there's some problem with Perl so we need the same solution with Raku. Without ever wondering whether we actually have that problem, too.
Which we don't
So we're back to "solution looking for a problem" 15:51
patrickb81 I do agree that a good integration into distros is a good thing to have and will ease a lot of pain. 15:52
I do not agree that the benefits a tool that installs and manages a programming language provides can be fully dismissed. 15:54
I do not think that good distro support will ease the exact same pains. Distros do lag behind upstream. Depending on distro by days, weeks or months. 15:56
Then providing good distro support on a wide range of distros is a lot of work. 15:57
Throwing out our own package repositories is less work because the communications aspect with the distros is gone. But still a lot of work. Supporting every distro that's out there is near to impossible. 15:59
rakubrew on the other hand works about anywhere. The "runtime support cost" is very small. I don't need to change anything in rakubrew to make it support the latest rakudo release. 16:00
nine Really most of the work in packaging rakudo for openSUSE is in trimming down the changelog to fit into 30 lines. If someone were to extend the spec file for Fedora or create the appropriate packaging files for Debian & friends and Arch, we'd cover most distros already with no additional work per release 16:01
16:03 jmerelo left
nine As to the upgrade experience: I've just tried rakubrew, installed 2020.06 and zef, installed 2020.02, switched and.... zef is gone 16:03
patrickb81 That would be really nice to have. 16:04
nine: zef and packages are installation specific
One does need to reinstall packages.
nine And we're back to "why would we want to inflict this pain onto our users?!" 16:05
patrickb81 nine: Are we arguing about which solution is better now? 16:06
nine By throwing a Perl solution onto a Raku non-problem we just remove one of our greatest advantages.
The discussion started out as which way of installation to recommend to our users
And I'm arguing that by recommending rakubrew we'd do our users a disservice as it has major drawbacks. 16:07
Compared to relatively minor advantages.
ShimmerFairy On Linux at least, I'd argue most people are used to their existing package manager providing the language, and a number of modules depending on how popular the lang is with the distro's maintainers. 16:09
No idea what the average experience is on Windows or mac though 16:10
nine Really, distro packages trump all other ways in my opinion as they can be installed with tools the user is already familiar with like just clicking a link on a webpage on openSUSE. In just 30 seconds I can have rakudo up and running.
patrickb81 nine: I'm fine with recommending distro packages to users given there not too out of date.
nine Next on my list is really just the command I posted above.
patrickb81 I think the packages you and nxadm create are quite popular actually. 16:11
ShimmerFairy The only thing I don't like is when package managers desperately try to stop other package managers from existing (e.g. gentoo's texlive packages refuse to allow tlmgr to exist)
nine The "not too out of date" can be solved easily.
patrickb81 Yours and nxadms packages are really up to date.
nine And yes, I do see the situations where distro packages are not appropriate and we should provide a good "install from source" option. And I do see room for improvement there. I'd still argue that rakubrew in its current for is not this as it conflates two different uses in one tool. 16:12
I.e. simple installation and the ability to switch between versions.
patrickb81 Why is that ad bad thing?
nine The ability to switch between versions is what very few users actually need and what's causing all the pain. 16:13
ShimmerFairy Are there often differences between versions of rakudo, or are the only meaningful differences between standard versions?
nine ShimmerFairy: we still follow rakudo releases quickly at work for stability and performance fixes. 16:14
ShimmerFairy I should be clearer, I meant changes that you need to swap versions for.
patrickb81 ShimmerFairy: I think raku is meant to stay backwards compatible. Language releases allow breakages. 16:15
ShimmerFairy Like, on the scale from "I need to select the right python3 installation or else" and "why would I go to an older version of gcc they have -std", where does rakudo sit?
nine Pretty close to gcc
patrickb81 Except for bugs. But we got a lot better with them in the last few years.
nine We do have the occasional regrettable regression, but that usually just means "wait with upgrading to the next release" 16:16
patrickb81 nine: wrt. "The ability to switch between versions is rarely needed" Do you consider upgrading a switch of versions? 16:17
ShimmerFairy Same sort of regression thing happens with gcc at times (except I usually blame the other program for being badly written after all :P) 16:18
I wouldn't. "switch versions" implies you're doing it for a non-upgrade reason, or else you'd say "upgrade".
nine patrickb81: no. I meant the ability to have multiple rakudo versions installed in parallel and being able to switch between them. Upgrading is exactly the use case that rakubrew handles worse compared to git pull 16:19
patrickb81 Then I agree. I have rarely had the need to work with multiple rakudo versions in parallel _on the same system_. 16:21
sena_kun: wrt "MVM_gcc": Do you mean the Azure build job in the MoarVM repo? 16:49
The different jobs there test different compiler and library combinations.
sena_kun patrickb81, yes. I had not see it before and wondering if I just missed it or it is a new job to cover older gcc. 16:50
patrickb81 But don't test different versions of the same compiler.
It isn't.
sena_kun I see.
patrickb81 Those MVM_* jobs are actually direct conversions of respective jobs in the travis configuration. 16:51
I think I'll try to get the precomp release stage in rakudo to work on normal commits and enable it. That way we'll have "nightlies" and ensure the release build process won't be broken. 16:52
sena_kun First we have to establish a list of configurations to test for, I guess. 16:53
16:55 Altai-man_ joined
patrickb81 Have to leave. o/ 16:56
16:57 patrickb81 left, sena_kun left 18:21 Altai-man_ left 18:22 sena_kun joined
lizmat finally groks the ginormous hack inside of matching when the name of a capture is '$!from' or `$!to` 18:48
basically, a Match object as a sub-capture merely to be able to set the $!from or $!to of the parent capture 18:49
my $submatch := $subcur.MATCH(); 18:51
if $name eq '$!from' || $name eq '$!to' {
nqp::bindattr_i(self, NQPMatch, $name, $submatch.from);
may I say: YUCK! :-)
18:55 Altai-man_ joined 18:57 sena_kun left
vrurg nine: I was away, just followed the discussion. I have just one note: rakubrew is indispensable for module developers if they want to maintain backward compat for older releases. 19:18
19:54 lucasb left 20:15 Altai-man_ left 20:18 sena_kun joined, sena_kun left, sena_kun joined
jdv79 seems a bit overkill to offer as the preferred way for beginners 20:18
i've used perlbrew for that exact reason - test a module before release on different perl versions. but is that the general beginner case? also, in hte perl eco you can get a similar deferred result if you kick an dev rel and let the smokers hit it for a bit. 20:20
be neat if we had something like the perl smoking infra 20:21
nine weekly: www.phoronix.com/forums/forum/soft...ost1188189 20:22
notable6 nine, Noted! (weekly)
[Coke] ironically, my first thought was "why add a perl 5.32 article". :) 20:27
nine Phoronix forum as a place of reasonable discussion and positive attitude towards Perl and Raku. "In the most unlikely of places" indeed
20:30 sena_kun left, MasterDuke left 20:31 sena_kun joined, sena_kun left, sena_kun joined
Xliff FWIW: rakudobrew is more than satisftying its promise helping me track down a SEGV in the current release. 20:33
R3765
R#3765
linkable6 R#3765 [open]: github.com/rakudo/rakudo/issues/3765 [SEGV] Segmentation Fault occurring in 2020.06 after Converting Script to a Module
nine which again is hardly a beginner's task 20:34
Xliff No, but "rakudobrew build moar" ... is 20:35
:) 20:36
sena_kun I am not sure there is a point to argue about. Distro packages should be promoted first for usual users, then rakubrew is a cool enuogh tool which does some specific jobs easier. 20:38
Is there any progress with github.com/MoarVM/MoarVM/pull/1318 ? I see the check has failed with a segfault. I imagine this is necessary for us to go for 2020.06.1. 20:40
jdv79 though in defense of not using distro pkgs - there have been many many times where something is broken and/or fixed quite recently and its a pita
building off master/head has been needed quite a few times but perhaps that's more historical now that i think of it 20:41
nine sena_kun: do we really need a point release? The CentOS package can easily carry that patch for a cycle. 20:42
[Coke] nine++ 20:43
sena_kun nine, colabti.org/irclogger/irclogger_lo...06-21#l350 20:44
I was really reluctant about it at first, but if there is a demand and we have expectations (not irony), it is not really end of the world to do it from my point of view. 20:45
nine sena_kun: I would never stand in the way of people scratching their itches. If someone insists on compiling rakudo on some ancient system, they're welcome. I just don't see any obligation for you or me or anyone else to go out of our way to make that possible. 20:47
Feeling pressured takes the fun out of things and leads to burned out developers. That's much worse than some user who doesn't contribute anything not getting their preferred way. 20:48
Someone insisting on building from source can certainly apply a patch. Or wait for the patch to be committed and build from that. Or compile the previous release. Or do a point release for us. 20:50
20:55 Altai-man_ joined
Altai-man_ Wise enough. Truth be told, I still have some pressure to deliver Comma this week with quite an amount of patching, heh. On the other hand, we will get a fix next release. The thing which kind of irritated me is that people think about things continuing to work and then we have no tests for it. 20:55
20:57 sena_kun left
timotimo i should probably put tests somewhere that verify that heap snapshots always work ... 21:11
Altai-man_ encourages timotimo to do this great thing 21:12
timotimo haha
21:19 MasterDuke joined
timotimo no idea where i should put that 21:20
there's like seventy different CI solutions that have all been tried by our little troupe, is azureCI the current winner? 21:21
Altai-man_ timotimo, yes. 21:22
MasterDuke Xliff: is your segfaulting code available somewhere? 21:26
Xliff MasterDuke: Can make it so, yes. 21:27
It's part of the GLib stuff I am working on, so getting that setup may take a little work. 21:28
Would love to get this stuff released, but it takes a long time to prep due to the number of compunits.
MasterDuke: OK. Getting things organized. 21:32
MasterDuke k
Xliff MasterDuke: git clone github.com/Xliff/p6-GStreamer.git; cd p6-GStreamer; git checkout gst-inspect 21:34
MasterDuke: Crashing script would then be bin/gst-inspect-mod.pl6
MasterDuke: Will also need -> github.com/Xliff/p6-GLib.git and github.com/Xliff/p6-GIO.git 21:35
Best if all 3 are checked out in the same parent 21:36
MasterDuke: You can then set the P6_GTK_HOME env variable to the parent directory, and then use the p6gtkexec script to run bin/gst-inspect-mod.pl6 21:37
MasterDuke where's GstInspect?
Xliff That module should be located in bin/
21:42 MasterDuke left 21:54 MasterDuke joined
MasterDuke Xliff: i get a segv, but the backtrace in gdb isn't very informative 21:59
Xliff OK. 22:02
Anything I can do?
22:03 sena_kun joined 22:05 Altai-man_ left
MasterDuke do you have your moarvm built with debugging symbols? 22:08
Xliff Unfortunately, no.
I'd have to rebuild.
MasterDuke well, for moarvm that's pretty easy
how do you build? 22:09
Xliff rakudobrew 22:10
MasterDuke pretty sure there's a way to pass moarvm options `--debug=3` 22:11
Xliff Yeah, but need to force moar rebuild.
MasterDuke yeah, think you need to do a full moarvm+nqp+rakudo rebuild with rakudobrew (but i haven't really used it, so don't necessarily take my word for it) 22:12
Xliff Well, I can do it from cmd line. 22:13
Get the same thing. 22:18
Oh crap. 22:20
The crash is in glib. But I don't get it.
MasterDuke: Check to make sure that bin/gst-inspect.pl6 runs on your end? 22:21
OK. Runs on my end. Only diff is that logic is in a module and run via exported sub MAIN()
So... precompilation? 22:22
MasterDuke yeah, it runs fine
could be. i'd suggest pinging nine++ in the bug report with this info 22:23
Xliff Yup. Precompilation 22:28
Adding a "no precompilation" to GstInspect solves the issue, here. MasterDuke, can you confirm? 22:29
MasterDuke yep, works here
Xliff Thanks!~ 22:30
bug updated\ 22:32
22:41 evalable6 left, bisectable6 left 22:43 committable6 left, unicodable6 left 22:44 committable6 joined 22:47 bisectable6 joined 22:48 evalable6 joined 22:51 benchable6 joined 22:55 Altai-man_ joined 22:58 sena_kun left 23:37 Altai-man_ left, Altai-man_ 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!