[00:55] *** Altai-man_ joined [00:57] *** sena_kun left [02:55] *** sena_kun joined [02:57] *** Altai-man_ left [03:57] *** nativecallable6 left [03:57] *** committable6 left [03:57] *** statisfiable6 left [03:57] *** bloatable6 left [03:57] *** squashable6 left [03:57] *** notable6 left [03:57] *** bisectable6 left [03:57] *** tellable6 left [03:57] *** evalable6 left [03:57] *** linkable6 left [03:57] *** shareable6 left [03:57] *** greppable6 left [03:57] *** reportable6 left [03:57] *** sourceable6 left [03:57] *** coverable6 left [03:57] *** releasable6 left [03:57] *** unicodable6 left [03:57] *** quotable6 left [03:57] *** nativecallable6 joined [03:57] *** notable6 joined [03:58] *** sourceable6 joined [03:58] *** coverable6 joined [03:58] *** releasable6 joined [03:58] *** evalable6 joined [03:58] *** bisectable6 joined [03:58] *** squashable6 joined [03:58] *** reportable6 joined [03:59] *** shareable6 joined [03:59] *** bloatable6 joined [03:59] *** unicodable6 joined [03:59] *** tellable6 joined [03:59] *** quotable6 joined [03:59] *** greppable6 joined [03:59] *** committable6 joined [03:59] *** 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- [08:18] ¦ problem-solving: Altai-man assigned to jnthn Issue Current Rakudo (possibly MoarVM as well) development process hinders releasing https://github.com/Raku/problem-solving/issues/206 [08:34] *** jmerelo left [08:42] Files=1306, Tests=111383, 217 wallclock secs (28.78 usr 8.09 sys + 3034.93 cusr 284.30 csys = 3356.10 CPU) [08:51] ¦ rakudo/set_equality: 105 commits pushed by 16 authors [08:51] ¦ rakudo/set_equality: review: https://github.com/rakudo/rakudo/compare/dbd69ba72658...56d550c46391 [08:55] *** Altai-man_ joined [08:57] *** sena_kun left [09:06] ¦ problem-solving: lizmat unassigned from jnthn Issue Current Rakudo (possibly MoarVM as well) development process hinders releasing https://github.com/Raku/problem-solving/issues/206 [09:13] *** jjatria left [09:16] *** jjatria joined [09:16] *** jmerelo joined [09:17] *** leont joined [09:22] *** jmerelo left [09:22] ¦ roast/set_equality: 23 commits pushed by (Elizabeth Mattijsen)++, (Patrick Böker)++, (Mikhail Khorkov)++, (Christian Bartolomäus)++ [09:22] ¦ roast/set_equality: review: https://github.com/Raku/roast/compare/715fb79b93a2...7bc05610b659 [09:48] *** jmerelo joined [10:03] *** ShimmerFairy joined [10:04] m: m: "42" ~~ / $<0=count>=(\d+) /; say $0, $ # how to make something a positional as well as a named capture :-) [10:04] rakudo-moar 0144905fb: OUTPUT: «「42」「42」␤» [10:06] ¦ rakudo/master: 4 commits pushed by (Elizabeth Mattijsen)++ [10:06] ¦ rakudo/master: 701f4cfb40 | Implement set equality operators [10:06] ¦ rakudo/master: dbd69ba726 | Simplify Setty/Baggy.ACCEPTS [10:06] ¦ rakudo/master: 56d550c463 | Merge branch 'master' into set_equality [10:06] ¦ rakudo/master: f470b544d4 | Merge pull request #3727 from rakudo/set_equality [10:06] ¦ rakudo/master: review: https://github.com/rakudo/rakudo/compare/0144905fb0e1...f470b544d49c [10:07] ¦ roast: 715fb79b93 | (Elizabeth Mattijsen)++ | 2 files [10:07] ¦ roast: Tests for Rakudo PR #3727 [10:07] ¦ roast: review: https://github.com/Raku/roast/commit/715fb79b93 [10:07] ¦ roast: 7bc05610b6 | (Elizabeth Mattijsen)++ | 1582 files [10:07] ¦ roast: Merge branch 'master' into set_equality [10:07] ¦ roast: review: https://github.com/Raku/roast/commit/7bc05610b6 [10:07] ¦ roast: da1c4f2b66 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files [10:07] ¦ roast: Merge pull request #646 from Raku/set_equality [10:07] ¦ roast: [10:07] ¦ roast: Tests for Rakudo PR #3727 [10:07] ¦ roast: review: https://github.com/Raku/roast/commit/da1c4f2b66 [10:32] *** ShimmerFairy left [10:33] *** ShimmerFairy joined [10:33] ShimmerFairy o/ [10:34] o/ [10:56] *** sena_kun joined [10:57] *** Altai-man_ left [11:15] *** jjmerelo joined [11:38] <[Tux]> Rakudo version 2020.06-6-gf470b544d - MoarVM version 2020.06-4-g06d8cdd16 [11:38] <[Tux]> csv-test-xs-20 0.400 - 0.408 [11:38] <[Tux]> csv-ip5xs 0.844 - 0.871 [11:38] <[Tux]> test-t --race 0.876 - 1.106 [11:38] <[Tux]> test-t 2.007 - 2.101 [11:38] <[Tux]> csv-ip5xs-20 8.060 - 8.190 [11:38] <[Tux]> test 8.450 - 8.486 [11:38] <[Tux]> test-t-20 --race 10.304 - 10.525 [11:38] <[Tux]> csv-parser 27.398 - 29.981 [11:38] <[Tux]> test-t-20 33.903 - 35.248 [11:50] *** jjmerelo left [12:55] *** Altai-man_ joined [12:57] *** sena_kun left [14:00] * lizmat notices that raku.org is not telling anybody where to download binary packages [14:00] or am I missing something? [14:01] * lizmat would like to link to binary package download locations [14:01] in the RWN [14:01] <[Coke]> https://raku.org/downloads - first section is binary star packages. [14:01] notable6: weekly [14:01] lizmat, 1 note: 2020-06-18T12:58:07Z : https://news.ycombinator.com/item?id=23560339 [14:01] [Coke]: which is out of date [14:01] <[Coke]> ok [14:02] <[Coke]> I think I already opened a ticket about that. [14:03] notable6: weekly reset [14:03] lizmat, Moved existing notes to “weekly_2020-06-22T14:03:01Z” [14:04] <[Coke]> ... but I can't find it. :( [14:06] 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): https://gist.github.com/ShimmerFairy/d3875e9331215b27512b6310ec6e22c0 [14:07] 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:14] *** lucasb joined [14:17] *** patrickb joined [14:19] lizmat, [Coke]: https://rakudo.org/downloads has the binary packages. That page is linked on rakudo.org/downloads on the right. [14:20] I think we should promote those builds more instead of star (which is not built for every release). [14:21] But I've had enough website stuff for a while after reworking rakudo.org ... [14:21] ok [14:21] :-) [14:22] 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:23] A while ago the official recommendation was that people should use the Star releases. They are more stable and have packages included. [14:25] 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:28] 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:32] *** Kaeipi left [14:33] and yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/06/22/2020-25-on-time/ [14:33] *** Kaeipi joined [14:37] patrickb: I would back you on this. I'd rather recommend rakubrew especially if it gets `default-modules` command. :) [14:38] vrurg: Can you elaborate? (Maybe in a ticket) [14:42] 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:43] 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` [14:44] 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:45] Also _installing_ loads of modules will always install stuff the user will never use. [14:46] Would something akin to Task::Kensho in Perl be a viable alternative? [14:49] patrickb: It wouldn't be the default behavior. In neither way. But it would greatly simplify a beginner's experience. [14:50] 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:51] *** krunen left [14:52] patrickb: Got it about Task::Kensho. Well, I like the idea. Task::RakudoStar? [14:55] *** sena_kun joined [14:57] *** Altai-man_ left [15:00] *** patrickb81 joined [15:02] *** patrickb left [15:05] *** krunen joined [15:05] vrurg: Something like that. Could be a module that simply depends on others + a very nice readme explaining them. [15:07] I'd like to keep the name "Rakudo" out there. Such a bundle is agnostic of the backend. Task::StarBundle? [15:07] patrickb81: But it still fits into my proposal. `rakubrew star` command could install this module by default. [15:07] Then one can just do `rakubrew download && zef install Task::StarBundle` and that's it. [15:07] patrickb81: I'll try to remember to make a ticket on this. Worth further discussion perhaps. [15:08] Why integrate into rakubrew? That's our chance to lessen fear of contact users might have with a package manager! [15:15] 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:18] *** krunen left [15:20] 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 https://github.com/rakudo/rakudo.git && cd rakudo && perl Configure.PL --build-moar --install` is any harder or more to type than rakudobrew [15:21] *** krunen joined [15:21] ¦ rakudo: Kaiepi++ created pull request #3767: [WIP] Make Parameter.BUILD more robust [15:21] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3767 [15:22] ¦ roast: Kaiepi++ created pull request #649: Add tests for Parameter.BUILD [15:22] ¦ roast: review: https://github.com/Raku/roast/pull/649 [15:26] Perhaps back in the hectic pre-Christmas days having a kind of LTS release was more useful than it is today. [15:27] 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:32] nine: Wrt rakubrew not being worth it: I agree if one sees rakubrew as an alternative to building rakudo oneself as a developer. [15:34] 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. [15:35] 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:36] 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] Why would a plain user need to build a commit/switch between versions? [15:37] nine: Painless update to newer versions and easy switching back should something go wrong. [15:38] 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. [15:39] If distro packages aren't up-to-date enough, why not simply help with keeping them up to date? [15:39] nine: Given plain user == developer building stuff using raku [15:40] I've done some 20 years of developing with Perl without having to compile it myself [15:40] 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. [15:41] And if I'm compiling myself, doing `git checkout 2020.01 && bash config.status` isn't terribly hard either. [15:42] 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] by the way, patrickb81, is MVM_gcc check on azure is the thing I think about or? [15:42] patrickb81: so why instead of working around that lack not simply fix it? Which would help all other users, too [15:43] 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:45] 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:48] because? [15:49] 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:50] 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] 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. [15:50] Which we don't [15:51] So we're back to "solution looking for a problem" [15:52] I do agree that a good integration into distros is a good thing to have and will ease a lot of pain. [15:54] I do not agree that the benefits a tool that installs and manages a programming language provides can be fully dismissed. [15:56] 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:57] Then providing good distro support on a wide range of distros is a lot of work. [15:59] 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. [16:00] 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:01] 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:03] *** jmerelo left [16:03] As to the upgrade experience: I've just tried rakubrew, installed 2020.06 and zef, installed 2020.02, switched and.... zef is gone [16:04] That would be really nice to have. [16:04] nine: zef and packages are installation specific [16:04] One does need to reinstall packages. [16:05] And we're back to "why would we want to inflict this pain onto our users?!" [16:06] nine: Are we arguing about which solution is better now? [16:06] By throwing a Perl solution onto a Raku non-problem we just remove one of our greatest advantages. [16:06] The discussion started out as which way of installation to recommend to our users [16:07] 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. [16:09] 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:10] No idea what the average experience is on Windows or mac though [16:10] 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. [16:10] nine: I'm fine with recommending distro packages to users given there not too out of date. [16:10] Next on my list is really just the command I posted above. [16:11] I think the packages you and nxadm create are quite popular actually. [16:11] 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) [16:11] The "not too out of date" can be solved easily. [16:11] Yours and nxadms packages are really up to date. [16:12] 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. [16:12] Why is that ad bad thing? [16:13] The ability to switch between versions is what very few users actually need and what's causing all the pain. [16:13] Are there often differences between versions of rakudo, or are the only meaningful differences between standard versions? [16:14] ShimmerFairy: we still follow rakudo releases quickly at work for stability and performance fixes. [16:14] I should be clearer, I meant changes that you need to swap versions for. [16:15] ShimmerFairy: I think raku is meant to stay backwards compatible. Language releases allow breakages. [16:15] 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? [16:15] Pretty close to gcc [16:15] Except for bugs. But we got a lot better with them in the last few years. [16:16] We do have the occasional regrettable regression, but that usually just means "wait with upgrading to the next release" [16:17] nine: wrt. "The ability to switch between versions is rarely needed" Do you consider upgrading a switch of versions? [16:18] 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". [16:19] 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:21] Then I agree. I have rarely had the need to work with multiple rakudo versions in parallel _on the same system_. [16:49] 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. [16:50] 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] But don't test different versions of the same compiler. [16:50] It isn't. [16:50] I see. [16:51] Those MVM_* jobs are actually direct conversions of respective jobs in the travis configuration. [16:52] 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:53] First we have to establish a list of configurations to test for, I guess. [16:55] *** Altai-man_ joined [16:56] Have to leave. o/ [16:57] *** patrickb81 left [16:57] *** sena_kun left [18:21] *** Altai-man_ left [18:22] *** sena_kun joined [18:48] * lizmat finally groks the ginormous hack inside of matching when the name of a capture is '$!from' or `$!to` [18:49] basically, a Match object as a sub-capture merely to be able to set the $!from or $!to of the parent capture [18:51] my $submatch := $subcur.MATCH(); [18:51] if $name eq '$!from' || $name eq '$!to' { [18:51] nqp::bindattr_i(self, NQPMatch, $name, $submatch.from); [18:51] may I say: YUCK! :-) [18:55] *** Altai-man_ joined [18:57] *** sena_kun left [19:18] 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:54] *** lucasb left [20:15] *** Altai-man_ left [20:18] *** sena_kun joined [20:18] *** sena_kun left [20:18] *** sena_kun joined [20:18] seems a bit overkill to offer as the preferred way for beginners [20:20] 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:21] be neat if we had something like the perl smoking infra [20:22] weekly: https://www.phoronix.com/forums/forum/software/programming-compilers/1188031-perl-5-32-released-with-unicode-13-0-support-performance-enhancements?p=1188189#post1188189 [20:22] nine, Noted! (weekly) [20:27] <[Coke]> ironically, my first thought was "why add a perl 5.32 article". :) [20:27] 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 [20:30] *** MasterDuke left [20:31] *** sena_kun joined [20:31] *** sena_kun left [20:31] *** sena_kun joined [20:33] FWIW: rakudobrew is more than satisftying its promise helping me track down a SEGV in the current release. [20:33] R3765 [20:33] R#3765 [20:33] R#3765 [open]: https://github.com/rakudo/rakudo/issues/3765 [SEGV] Segmentation Fault occurring in 2020.06 after Converting Script to a Module [20:34] which again is hardly a beginner's task [20:35] No, but "rakudobrew build moar" ... is [20:36] :) [20:38] 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:40] Is there any progress with https://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] 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 [20:41] building off master/head has been needed quite a few times but perhaps that's more historical now that i think of it [20:42] sena_kun: do we really need a point release? The CentOS package can easily carry that patch for a cycle. [20:43] <[Coke]> nine++ [20:44] nine, https://colabti.org/irclogger/irclogger_log/raku?date=2020-06-21#l350 [20:45] 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:47] 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:48] 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:50] 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:55] *** Altai-man_ joined [20:55] 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:57] *** sena_kun left [21:11] i should probably put tests somewhere that verify that heap snapshots always work ... [21:12] * Altai-man_ encourages timotimo to do this great thing [21:12] haha [21:19] *** MasterDuke joined [21:20] no idea where i should put that [21:21] there's like seventy different CI solutions that have all been tried by our little troupe, is azureCI the current winner? [21:22] timotimo, yes. [21:26] Xliff: is your segfaulting code available somewhere? [21:27] MasterDuke: Can make it so, yes. [21:28] 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. [21:32] MasterDuke: OK. Getting things organized. [21:32] k [21:34] MasterDuke: git clone https://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 [21:35] MasterDuke: Will also need -> https://github.com/Xliff/p6-GLib.git and https://github.com/Xliff/p6-GIO.git [21:36] Best if all 3 are checked out in the same parent [21:37] 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] where's GstInspect? [21:37] That module should be located in bin/ [21:42] *** MasterDuke left [21:54] *** MasterDuke joined [21:59] Xliff: i get a segv, but the backtrace in gdb isn't very informative [22:02] OK. [22:02] Anything I can do? [22:03] *** sena_kun joined [22:05] *** Altai-man_ left [22:08] do you have your moarvm built with debugging symbols? [22:08] Unfortunately, no. [22:08] I'd have to rebuild. [22:08] well, for moarvm that's pretty easy [22:09] how do you build? [22:10] rakudobrew [22:11] pretty sure there's a way to pass moarvm options `--debug=3` [22:11] Yeah, but need to force moar rebuild. [22:12] 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:13] Well, I can do it from cmd line. [22:18] Get the same thing. [22:20] Oh crap. [22:20] The crash is in glib. But I don't get it. [22:21] 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() [22:22] So... precompilation? [22:22] yeah, it runs fine [22:23] could be. i'd suggest pinging nine++ in the bug report with this info [22:28] Yup. Precompilation [22:29] Adding a "no precompilation" to GstInspect solves the issue, here. MasterDuke, can you confirm? [22:29] yep, works here [22:30] Thanks!~ [22:32] bug updated\ [22:41] *** evalable6 left [22:41] *** bisectable6 left [22:43] *** committable6 left [22:43] *** 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 [23:37] *** Altai-man_ joined