Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
vrurg .tell jnthn If'm getting right your complaint about NQP in detached head, then the solution would be to use --gen-nqp=master 00:37
yoleaux vrurg: I'll pass your message to jnthn.
Kaiepi .tell lizmat, the RI::JSON optimization broke the JVM since it doesn't support NFD yet 00:54
yoleaux Kaiepi: What kind of a name is "lizmat,"?!
Kaiepi .tell lizmat the RI::JSON optimization broke the JVM since it doesn't support NFD yet
yoleaux Kaiepi: I'll pass your message to lizmat.
ugexe vrurg: that is a side effect of their complaint, not the primary complaint 01:15
so why not only rebuild moar/nqp when running Configure.pl instead of when running make? 01:17
vrurg ugexe: sorry, what's them main one then? :) Anyway, I didn't see make rebuilding nqp yet. 01:18
Oops, I see the point. Too late for today, but will get it straighten out tomorrow. 01:21
Configure.pl must not be worried about `nqp` with `--expand`.
.tell jnthn Got the problem reproduced, will have it fixed Monday. 01:22
yoleaux vrurg: I'll pass your message to jnthn. 01:23
Kaiepi can someone merge github.com/rakudo/rakudo/pull/2959/ and its related commits now that the moarvm one's been committed or do they still need to be reviewed? 01:33
ugexe Kaiepi: spacing/tabs are off in the java one 01:35
MasterDuke i restarted travis to see if it shows anything different now 01:36
ugexe they were already off, but your changes just put them somewhere else that is wrong
also if you make a test in nqp your PR will tell you if your java implementation is correct 01:37
MasterDuke oh wait, shouldn't github.com/perl6/nqp/pull/553 be merged first?
ugexe yes, if we know the java version works. 01:38
MasterDuke why don't we have appveyor for nqp?
ugexe we should 01:42
MasterDuke Kaiepi: travis-ci.org/perl6/nqp/jobs/542696075#L883
so we need another nqp bump first, right? 01:43
Kaiepi shit i forgot to update the bootstrap files again
ugexe why do you need to rebootstrap? 01:44
MasterDuke the --gen-moar=master job passed
ugexe i didnt think that'd require rebootstraping... 01:45
anyways, Kaiepi did you manage to find a way to test this on jvm ? 01:46
Kaiepi oh 01:49
actually wait --gen-moar=master passed 01:51
so i did remember
i tested it on the jvm, but not properly
well, i guess there isn't a proper way to test if there are no tests written for this 01:52
but i did check to see if nqp::freemem and nqp::totalmem worked
01:53 evalable6 left
ugexe yeah thats all i really meant 01:54
are you sure you needed to rebootstrap nqp at all though?
01:54 evalable6 joined
ugexe i thought that was only if you changed an existing op 01:54
Kaiepi i didn't, i thought the test you posted that failed was the --gen-moar one, not --gen-moar=master 01:55
i did change nqp::cpucores to return an int64 instead of an int32 01:56
MasterDuke i don't think it's really whether or not you change vs add an op, but whether that op is used in nqp itself when compiling 01:57
ugexe Kaiepi: there are a bunch of .moarvm and .jar files in that PR 01:59
Kaiepi yeah, because i ran m-bootstrap-files and j-bootstrap-files after updating nqp::cpucores 02:00
MasterDuke i don't think that was required
ugexe its also good to decouple your PR from the rebootstrap since they are unrelated 02:03
we cannot revert one without the other for instance 02:04
Kaiepi QAST::OperationsJAST.map_classlib_core_op('totalmem', $TYPE_OPS, 'freemem', [], $RT_INT, :tc);
shit i didn't notice that
also nqp::cpucores is called as soon as $*SCHEDULER is created, which iirc complained about cpucores having the wrong return type before i ran m-bootstrap-files 02:08
ugexe ah that sounds plausible
Kaiepi do i need to move the changes to the bootstrap files to a separate commit or are they fine where they are? 02:09
ugexe it would be better if they were split, but i wont let that stop me from merging it anyway 02:11
i'll at least wait for the s/totalmem/freemem/ 02:17
02:54 evalable6 left 02:59 evalable6 joined, ChanServ sets mode: +v evalable6 03:06 AlexDani` joined 03:11 AlexDaniel left 07:25 klapperl_ left, klapperl joined
jnthn . 08:59
hah, just got messages in #moarvm...ain't I awake this mroning :) 09:00
*morning
.tell vrrug My complaint is that I just configured with a --prefix so it would use the NQP I build as I please (which I'm pleased to do :-)), and then it decided to try and rebuild it automatically for me in `make`, leaving me with a detached HEAD in NQP. I'm not saying that's wrong for everyone, just that I'd like a way to have it leave my other source trees alone. :) 09:02
yoleaux jnthn: I'll pass your message to vrrug.
Geth rakudo: dc78257514 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals/JSON.pm6
Restore old str-escapes version for JVM backend

Since the JVM backend doesn't know about NFD yet		 09:12
lizmat Kaiepi: ^^ 09:14
jnthn m: say 26.40 / 32.98 09:27
evalable6 0.800485
jnthn That's the improvement on the Rakudo speedup-match branch for `my $x = "foo bar baz wat is it"; my $total = 0; for ^1_000_000 { $total = $total + $x.split(/\s+/).elems }`
lizmat faster? or less memory? :) 09:28
cool
jnthn Oddly, the NQP one doesn't show much difference on Rakudo build time now I measure it here at the office.
Not immediately sure why 09:29
Maybe match construction is just far less dominant 09:30
Ah, damn, failing spectests :(
Oh, nearly all of them in :P5 tests though 09:31
Kaiepi i've been messing with the js backend 09:34
i can almost get perl6-js to build, but i need to add support for bindlexdyn because that's causing it to fail right at the very end of compiling
also thanks lizmat 09:35
jnthn nqp: my $m := "a" ~~ /<ident> & <alpha>/; say(nqp::elems($m.list)) 09:36
ah, darn, no but here for NQP
Also that should be .hash :)
m: use nqp; nqp::getcomp('nqp').eval(q|my $m := "a" ~~ /<ident> & <alpha>/; say(nqp::elems($m.hash))|) 09:37
evalable6 (exit code 1) Cannot call method 'eval' on a null object
in block <unit> at /tmp/M9prxiAQbR line 1
jnthn aww
m: use NQP:from<nqp>; use nqp; nqp::getcomp('nqp').eval(q|my $m := "a" ~~ /<ident> & <alpha>/; say(nqp::elems($m.hash))|) 09:38
evalable6 (exit code 1) ===SORRY!===
Could not find NQP at line 1 in:
file#/home/bisectable/git/…
jnthn, Full output: gist.github.com/467c4596c0ee14bb14...557051e0fd
jnthn Hm, that's 0 on mater of NQP also, though 09:40
m: say ("a" ~~ /<alpha> & <ident>/).hash.elems
evalable6 2
Geth nqp/match-speedup: 4 commits pushed by (Jonathan Worthington)++ 09:52
nqp/match-speedup: d7ab1e7d12 | (Jonathan Worthington)++ | src/QRegex/P6Regex/Actions.nqp
Fix capnames with &

Not sure how we ever passed a Rakudo test for /<alpha> & <ident>/ in the past with this broken.
Kaiepi now that the issues brought up with the nqp pullreq are fixed can this be merged? github.com/rakudo/rakudo/pull/2959 09:56
Geth nqp: Kaiepi++ created pull request #554:
Use --release 9 instead of -source 1.9 in the JVM's Makefile		 10:02
jnthn Wow, the capnames construction in P5Regex was totally wrong for quantifiers, and we just got away with it before because we didn't use that information to avoid work. 10:06
*avoid
Kaiepi: Hm, seems it totally fails CI? 10:08
Kaiepi oh for fuck's sake 10:10
it was just working yesterday
Geth nqp/match-speedup: 9d14819169 | (Jonathan Worthington)++ | src/QRegex/P5Regex/Actions.nqp
Correct construction of capnames in P5Regex

We got it totally wrong for anything quantified, and never noticed before because we didn't really use this information.
jnthn Does it need an NQP bump maybe? 10:11
I'll do one shortly
Well, if the spectest passes this time :P
Kaiepi i think i forgot to run m-bootstrap-files after fixing nqp::totalmem actually calling nqp::freemem's function 10:12
jnthn Hm, shouldn't need to rebootstrap just for adding ops 10:13
Geth nqp/master: 6 commits pushed by (Jonathan Worthington)++
jnthn huh, where on earth did tools/build/NQP_REVISION go? 10:15
timotimo it's now under templates/
jnthn huh
Geth rakudo/master: 5 commits pushed by (Jonathan Worthington)++ 10:17
timotimo Cheapean 10:18
nice
jnthn haha
lizmat timotimo: did you see MasterDuke's find re nqp::slice ? 10:19
jnthn Coulda fixed it if I'd seen it before the branch merge :P
timotimo i don't think i did
Kaiepi bastille% nqp -e 'nqp::say(nqp::coerce_is(nqp::freemem()))' 10:23
2049646592
bastille% nqp-j -e 'nqp::say(nqp::coerce_is(nqp::freemem()))'
78787256
bastille% nqp-js -e 'nqp::say(nqp::coerce_is(nqp::freemem()))'
1965273088
bastille% nqp -e 'nqp::say(nqp::coerce_is(nqp::totalmem()))'
8180408320
bastille% nqp-j -e 'nqp::say(nqp::coerce_is(nqp::totalmem()))'
98566144
bastille% nqp-js -e 'nqp::say(nqp::coerce_is(nqp::totalmem()))'
8180408320
ok everything should work now with the latest commit i pushed to the nqp pullreq
(don't worry about the jvm returning different numbers, it measures what's free or available to the jvm itself, not the system) 10:24
timotimo lizmat: where do i look for that? 10:32
lizmat timotimo: comments on github.com/MoarVM/MoarVM/commit/60...d25b1abf19 10:33
timotimo nooooo i broke it 10:35
doesn't b0rk on my end :( 10:39
oh
maybe i don't have that moar commit yet
10:43 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined
Geth nqp: 479c5dd1ba | (Jonathan Worthington)++ | src/core/NQPRoutine.nqp
Add int to constants to avoid a lot of unboxing
 10:49
timotimo oh, hm, the fastcreate uses the size of MVMArray even though it might actually be a different kind of repr being used 10:56
considering just dropping that piece for now, reintroducing it later when i've had enough time to get it right 10:59
Geth nqp: a917b00517 | (Jonathan Worthington)++ | src/QRegex/Cursor.nqp
Some small optimizations to !cursor_init

These save a bit when it's used many times, as it is when we match lots of simple regexes in a loop.		 11:12
11:13 Kaiepi left
Geth rakudo: 9107215a99 | (Jonathan Worthington)++ | src/core/Rakudo/Iterator.pm6
ReifiedListIterator can be a PredictiveIterator

Since the list is already reified, we know how many elements there are. This is a significant speedup for things like `$foo.split(/\s+/).elems` as it can just return the elements of the list (in fact, the `.elems` part is now fully inlined into the caller).		 11:15
rakudo: ce30ff2aa9 | (Jonathan Worthington)++ | src/core/Str.pm6
Avoid a little indirection in split(/regex/)
11:15 Kaiepi joined 11:20 roho joined 11:21 roho left
Geth rakudo: bed0695df2 | (Jonathan Worthington)++ | src/core/Str.pm6
Call !match-list directly in split

Rather than going through .match with all of its related checks along the way.		 11:34
lizmat timotimo:could you run another module indexing ? 11:35
modules.perl6.org/dist/Pod::To::Ma...n:CLARKEMA is a 404 :-(
timotimo jj said he runs it via a cron job
oh, but only daily?
lizmat yeah... and this was a new entry 17 hours ago
timotimo i'll do it right now
lizmat timotimo++
jnthn That split/elems benchmark is now running in 64% of the time it used to. :) 11:36
lizmat it's the only new module in this week's PsW
*P6w
jnthn Lunch, lesson, etc. &
lizmat jnthn++
timotimo wow, nice. 11:37
lizmat notable6: weekly 11:39
notable6 lizmat, 6 notes: gist.github.com/a12afe2a4f3a02f9e1...14bc827f14
Geth nqp: 104a5ce4d4 | (Ben Davies)++ | tools/templates/jvm/Makefile.in
Use --release 9 instead of -source 1.9 in the JVM's Makefile

This shuts up warnings about the target being the wrong version of the JDK and warnings about -bootclasspath being needed.		 11:43
nqp: 655b50b5d0 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | tools/templates/jvm/Makefile.in
Merge pull request #554 from Kaiepi/jvm-release

Use --release 9 instead of -source 1.9 in the JVM's Makefile
nqp: Kaiepi++ created pull request #555:
[js] Refactor src/vm/js/nqp-runtime/global-context.js		 11:45
lizmat cycling, before it starts to rain& 12:02
timotimo modules.perl6.org should be up to date now 12:15
12:59 pmurias joined
pmurias Kaiepi: I looked at the PR 12:59
Kaiepi: all the adhoc tweaks/cleanups seem fine (scs where not kept in a map because that code is from before I started depending on Map being present) 13:00
Kaiepi alright 13:02
pmurias Kaiepi: restoreThisGlobalContext seems to be only used in rakudo.js
here github.com/rakudo/rakudo/blob/mast...ime.js#L16 13:03
Kaiepi: so I think we could just get rid of the entire complex mechanism at store stuff on the context
the runtime cost of a redirection to a singleton instead of a global is that high right? 13:04
Kaiepi looks like you're right, none of the methods on GlobalContextWrapper besides initialize are actually used and initialize shouldn't even exist 13:10
pmurias Kaiepi: the early design was to just save and restore globals on the context, then I decided to just move that over there and maybe migrate back to globals if the indirection is too costly 13:13
Kaiepi wait 13:16
the methods on GlobalContextWrapper are used in rakudo
pmurias Kaiepi: yes 13:23
Kaiepi: I was considering just moving everything on top of the context and removing the saving/restoring dance 13:24
13:41 skids joined
vrurg .tell jnthn not sure you'd have time to reply this week. In short about the subsets: their current behavior is a bug. It's not like breaking backward compat just for the sake of a new feature. 13:42
yoleaux vrurg: I'll pass your message to jnthn.
pmurias Kaiepi: any thoughts on that? 13:58
Kaiepi i agree, after poring through the code i don't see much of a point in saving/restoriing the global context 14:09
pmurias Kaiepi: should I merge the PR in? 14:55
vrurg ugexe: You're a great critic. May you have a look at github.com/perl6/problem-solving/issues/3 too and say what you think? 14:57
Kaiepi sure pmurias, since removing the need for GlobalContextWrapper is pretty annoying to do and spreads over two repos 15:00
ugexe vrurg: i'll try and remember to take a look at it after work 15:01
pmurias Kaiepi: I'll make rakudo.js just keep everything on the global context tommorow 15:06
Kaiepi ok 15:07
15:12 pmurias left 15:26 ggoebel joined 15:49 Kaiepi left 15:52 pamplemousse joined 16:21 pamplemousse left 16:23 pamplemousse joined 16:34 pamplemousse_ joined 16:35 pamplemousse left 16:56 pamplemousse_ is now known as pamplemousse 17:07 pamplemousse left 17:11 pamplemousse joined 17:46 Kaiepi joined
Geth nqp: vrurg++ created pull request #556:
nqp-configure submodule update		 18:02
rakudo: vrurg++ created pull request #2970:
Prevent rebuild of nqp without --gen-nqp.		 18:04
18:09 pamplemousse_ joined 18:13 pamplemousse left 18:14 pamplemousse_ is now known as pamplemousse
Geth nqp: 852a32c7eb | (Vadim Belman)++ | 3rdparty/nqp-configure
nqp-configure submodule update
 18:21
nqp: 86f2366472 | (Vadim Belman)++ (committed using GitHub Web editor) | 3rdparty/nqp-configure
Merge pull request #556 from vrurg/build-revamp

nqp-configure submodule update
18:42 Kaiepi left 18:51 brrt joined
brrt \o 18:51
why do I have to redownload NQP?
(when invoking rakudo Configure.pl)
ugexe maybe github.com/rakudo/rakudo/pull/2970 fixes it 18:53
vrurg brrt: aha, 2970 does. Only waiting for CI to complete before merging. 18:54
brrt Hm. Ok 18:55
I'll wait for a bit then
vrurg appveyor is still broken. I thought it was fixed already. 18:59
nine I think....this elaborate plan to fix the P6 subclass of a P5 class in Inline::Perl5 may actually work thanks to Perl 5 destructors being able to resurrect their object multiple times 19:03
yoleaux 7 Jun 2019 19:40Z <japhb> nine: Is there any chance of a python3-compatible Inline::Python this year? (Asking because of the global deprecation of python2 at EOY, and because my $dayjob is switching over presently.)
nine .tell japhb Yes, Python 3 compatibility should be pretty straight forward. Especially since Perl 5's Inline::Python can serve as a template
yoleaux nine: I'll pass your message to japhb.
19:04 ggoebel left
ugexe vrurg: weeks ago appeveyor went red. since then 3 other windows regressions have occured. 19:12
so everytime we think we fixed that last one... we see a new test failure :/ 19:13
vrurg Ok, so I don't rely on it yet. 19:14
Geth rakudo: f15f56875a | (Vadim Belman)++ | 3 files
Prevent rebuild of nqp without --gen-nqp.
 19:15
rakudo: f935bd20ad | (Vadim Belman)++ | tools/lib/NQP/Config/Rakudo.pm
Don't try parse version when no binary found.
rakudo: 1ccfc01349 | (Vadim Belman)++ (committed using GitHub Web editor) | 3 files
Merge pull request #2970 from vrurg/build-revamp

Prevent rebuild of nqp without --gen-nqp.
ugexe it should just be failing tests now, not failing build
vrurg brrt: try now, pls.
ugexe ===SORRY!===
Cannot determine the brand of your nmake utility. at C:/projects/rakudo/nqp/3rdparty/nqp-configure/lib/NQP/Config.pm line 171.
vrurg ugexe: Cannot catch this problem. Is it reproducible in your case? 19:16
brrt vrurg: complains bitterly, but is otherwise moving ahead 19:17
vrurg brrt: It should complain because your nqp is seemingly old. 19:18
brrt i don'
t think that's true though
vrurg What is it complaining about then? 19:19
brrt that it's old
:-P
vrurg Yep, but what versions does it report as expected/current? And check what binary path it checks against. 19:20
Another thing about the fix: Configure.pl would only update nqp if --gen-nqp or --gen-moar is specified. I think this is how it must be. 19:23
brrt yes, that's how it used to be 19:24
ugexe vrurg: maybe you should add debug output to see why it does not match. this error is seemingly random, yes, but didnt happen last release 19:25
even just create dummy PR with the debug changes so you can use appveyor itself to discover
vrurg ugexe: already planned. Need to have some things done first right now.
brrt vrurg: works now 19:26
vrurg brrt: 👍🏻
ugexe: unfortunately, I still don't have access to 'restart' button on appveyour. It complicates debugging. 19:27
ugexe only guess is output of `run` has not fully populated whatever it string checks for valid data for, but IPC::Cmd->run doesn't work like that so i dont see how
vrurg: you can just open a dummy PR that you dont expect to merge 19:28
and force push empty commit to rerun
or just push new commits since PR wont be merged
vrurg ugexe: Sure, as a workaround. Just an annoyance. ;)
ugexe I think you need someone with higher privs than me to set that up for you on appveyor
at very least seems like you should be pattern matching on out_buffer or error_buffer, not on the mixed buffer 19:33
lizmat reportable6: 2019-06-03T12:00:00 2019-06-10T00:00:00Z 19:35
reportable6 lizmat, OK, working on it! This may take up to 40 seconds
lizmat, gist.github.com/3de2432737660198c1...1205d02571 19:36
Geth rakudo: vrurg++ created pull request #2971:
Debug PR
ugexe NQP::Config::__ANON__("Command failed (status 512): nmake install\x{a}") called at -- vrurg, wonder if that \x{a} is legit 19:38
vrurg ugexe: where did you get this? 19:41
ugexe ci.appveyor.com/project/rakudo/rak...cyn7#L1023
line 1023 and line 1030
seems like maybe its trying to do "nmake install\n" or something 19:43
a missing chomp or some such
vrurg Ah, this is how Carp::longmesg outputs \n from a string paramter.
ugexe ah, then nevermind 19:44
now that there is debug output it will never fail :P 19:46
lizmat notable6: weekly
notable6 lizmat, 7 notes: gist.github.com/fbe9b7f213cd97b876...03cfd6a876
vrurg The output is matched against /Microsoft .* NMAKE/s – how simplier could that be? Not even mix of stdout/stderr could break it unless something totally unrelated is printed. 19:47
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2019-06-10T19:47:33Z”
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/06/10/...te-course/ 19:49
vrurg lizmat++ 19:50
ugexe vrurg: i just looked around in appveyor and I can't find any permissions with my name, just moritz, so i'm not sure why I can restart builds 20:09
vrurg: where are all these "need?" coming from? ci.appveyor.com/project/rakudo/rak...g=true#L43 20:24
20:39 Kaiepi joined 20:51 pamplemousse left 20:52 pamplemousse joined 21:01 brrt left 21:25 skids left
japhb . 22:09
yoleaux 19:03Z <nine> japhb: Yes, Python 3 compatibility should be pretty straight forward. Especially since Perl 5's Inline::Python can serve as a template
japhb .tell nine Ah, good to know re: python3, thank you. 22:10
yoleaux japhb: I'll pass your message to nine.
vrurg ugexe: "need?" is a debug leftover. 22:17
Geth rakudo: vrurg++ created pull request #2972:
Remove overlooked debug print.		 22:25
22:27 pamplemousse left
Geth rakudo: e3df375275 | (Vadim Belman)++ | tools/lib/NQP/Config/Rakudo.pm
Remove overlooked debug print.
 22:27
rakudo: 8a6a0aeaa7 | (Vadim Belman)++ (committed using GitHub Web editor) | tools/lib/NQP/Config/Rakudo.pm
Merge pull request #2972 from vrurg/build-revamp

Remove overlooked debug print.
ugexe vrurg: so what is happening in appveyor is Microsoft is matched from STDERR and NMAKE from STDOUT 22:31
seems like IPC::Cmd bug
22:31 pamplemousse joined
ugexe but the bug might only be with mixing stderr/stdout streams 22:32
vrurg Could be a bug. I would limit the regexp to the version line only. It is sufficient to make sure it is nmake. 22:33
Geth nqp/master: 4 commits pushed by (Ben Davies)++, (Nick Logan)++ 22:38
rakudo: 31671f8f71 | (Ben Davies)++ | src/core/Kernel.pm6
Implement support for Kernel.free-memory and Kernel.total-memory
rakudo: ab738b4ee1 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/Kernel.pm6
Merge pull request #2959 from Kaiepi/mem

Implement support for Kernel.free-memory and Kernel.total-memory
22:45 pamplemousse left
vrurg ugexe: As to appveyor permission, I was asking their support but they're sending me to the project owners. Maybe moritz knowns better what could be the cause. 22:49
22:56 travis-ci joined
travis-ci NQP build failed. Nick Logan 'Merge pull request #553 from Kaiepi/mem 22:56
travis-ci.org/perl6/nqp/builds/543962497 github.com/perl6/nqp/compare/86f23...754f16e14e
22:56 travis-ci left
vrurg My build just've failed too. 22:59
22:59 Kaiepi left
Geth nqp: 8c90f62668 | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/MOAR_REVISION
Bump MoarVM
 23:00
rakudo: 8a37b9311c | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP
 23:01
23:17 travis-ci joined
travis-ci NQP build passed. Nick Logan 'Bump MoarVM' 23:17
travis-ci.org/perl6/nqp/builds/543970341 github.com/perl6/nqp/compare/26754...90f62668e8
23:17 travis-ci left
timotimo make: *** No rule to make target 'tools/build/gen-moar-runner.pl', needed by 'nqp-m'. Stop. 23:25
mhhh ... huh?
vrurg timotimo: Re-run Configure.pl. Looks like Makefile is outdated. 23:26
timotimo ah, i did run configure, but it errored 23:27
i don't have IPC/Cmd.pm
when did we start requiring that?
"install 11 packages" 23:28
vrurg I would need to bisect it, but for a couple of weeks now.
timotimo damn
fedora users all over the world will groan at that
vrurg How did fedora choose what modules come included with Perl5? 23:29
Mostly a rethoric question though...
timotimo ha 23:30
yeah
vrurg I checked out with perldoc.perl.org/index-modules-I.html as to avoid anything non-standard. 23:31
Guessing that CentOS would do the same.
timotimo most probably
vrurg Anyway, I'd vote for leaving this one in. qx{} isn't sufficient in many respects. 23:34
timotimo i guess that's fair 23:36
i wonder if we want to put in specific verbiage for users of distros that cut everything out of the perl installation? like "fedora users can run `sudo dnf install perl-IPC-Cmd` to install the missing package" 23:37
MasterDuke lizmat: around? if so, do you have a repro for that bad profile you showed me? 23:40
vrurg timotimo: when I was working on Foswiki there was a branch for autoinstalling necessary modules using cpanm. But a message is definitely easier to implement. ;) 23:46
timotimo well, then a user would ahve to install cpanm first 23:47
and probably also set up that local lib stuff
vrurg No because cpanm can be used as module. I integrated it. Not that it was a simple task but eventually I got it working.
23:48 travis-ci joined
travis-ci Rakudo build failed. Vadim Belman 'Merge pull request #2972 from vrurg/build-revamp 23:48
travis-ci.org/rakudo/rakudo/builds/543958685 github.com/rakudo/rakudo/compare/1...6a0aeaa724
23:48 travis-ci left
ugexe how is qx insufficient? 23:49
i haven't seen any advanced usage that would suggest that
vrurg ugexe: Complications with spaces in pathnames. 23:51
With run() I use @cmd.
ugexe if (ref($cmd) eq 'ARRAY') {$cmd = join(" ", @{$cmd});} 23:58
thats the code from IPC::Cmd
vrurg 🤦🏻‍♂️ 23:59
ugexe it does have a quote_args utility function though

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!