00:08 frost-lab joined
Geth nqp: e53c01c48d | (Patrick Böker)++ | 2 files
Adapt tests to new `nqp::spawnprocasync` semantics

The op now takes the program name separately instead of implicitly deriving it from the first arg.
00:22
nqp: 8afa213447 | (Patrick Böker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #690 from patrickbkr/fix-spawnprocasync-tests

Adapt tests to new `nqp::spawnprocasync` semantics
00:25 patrickb left 00:38 travis-ci joined
travis-ci NQP build passed. Patrick Böker 'Merge pull request #690 from patrickbkr/fix-spawnprocasync-tests 00:38
travis-ci.org/Raku/nqp/builds/752207964 github.com/Raku/nqp/compare/d65a8c...fa213447ae
00:38 travis-ci left 00:44 lucasb left 03:29 Xliff left 04:06 leont left 05:24 linkable6 left, evalable6 left 05:26 evalable6 joined 05:27 linkable6 joined 07:53 frost-lab left 08:20 Kaiepi left, Kaiepi joined 08:42 frost-lab joined 09:06 patrickb joined
patrickb Yesterdays PR changed `spawnprocasync`, so that the `args` arrays first argument is the program to call. Now it occurred to me that this is not exactly the cleanest way to do that. 09:11
09:12 epony left
patrickb A separate `prog` argument would have been the more obvious choice. Is it worth the hastle to change it again or should I just leave it as is? 09:12
09:13 patrickb left 09:14 patrickb joined 09:22 Altai-man joined
lizmat patrickb: now would be the time to change that 09:29
please remember XS :-)
Files=1346, Tests=117152, 225 wallclock secs (30.33 usr 8.67 sys + 3112.91 cusr 303.46 csys = 3455.37 CPU)
09:52 epony joined 10:20 klapperl_ left
patrickb I'll do that then. Probably some time tomorrow. 10:37
o/
10:37 patrickb left
gfldex is there a way for MAIN to tell if it's being called by the runtime or by hand? 10:40
10:44 frost-lab left
lizmat gfldex: callframe should be able to tell you ? 10:48
gfldex that should work 10:53
Geth ¦ problem-solving: JJ assigned to codesections Issue Name (and release date) proposal for 6.e github.com/Raku/problem-solving/issues/254 11:53
11:57 sena_kun joined 11:59 Altai-man left 12:31 leont joined
Geth rakudo/faster-slice-access: 34 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/e...d86956ad2e
12:37
lizmat that was a troublesome rebase :-( caused by the spawnprocasync changes :-( 12:38
12:41 klapperl joined
Geth ¦ problem-solving: AlexDaniel self-unassigned There's a huge PR/issue deficit in the Rakudo repo github.com/Raku/problem-solving/issues/5 13:15
14:20 leont left 14:47 cog_ left 14:52 cog joined 14:55 sena_kun left 15:04 sena_kun joined 15:06 Xliff joined
Xliff \o 15:07
I'm getting JSON errors no matter where I run raku.
Invalid JSON: at 60: expected a json object, but got '"],\n \""'
15:08 sena_kun left
Xliff Oh piffle. Nevermind. Bad -I directive 15:09
15:39 sena_kun joined 15:57 Altai-man joined 15:59 sena_kun left 18:24 finsternis joined
Geth rakudo: nwc10++ created pull request #4151:
02-simple-args.c should #include <sys/types.h> to get ssize_t
19:11
19:51 Altai-man left 20:12 b2gills left
Geth rakudo: ac10a7a8bb | (Nicholas Clark)++ | t/04-nativecall/02-simple-args.c
02-simple-args.c should #include <sys/types.h> to get ssize_t

Without this the code won't even compile on Solaris.
I assume that other *nix platforms "leak" the definition of ssize_t when other headers are included, hence why it has not been spotted before.
20:20
rakudo: f89863249e | niner++ (committed using GitHub Web editor) | t/04-nativecall/02-simple-args.c
Merge pull request #4151 from nwc10/need-sys-types-for-ssize_t

02-simple-args.c should #include <sys/types.h> to get ssize_t
20:41 b2gills joined 22:38 sena_kun joined
ugexe m: say v0.1 ~~ v0.1.1; say v0.1.0 ~~ v0.1.1; say v0.1.1 ~~ v0.1; say v0.1.1 ~~ v0.1.0; 23:50
camelia False
False
True
False
23:51
tellable6 2020-12-23T22:04:25Z #raku <patrickb> ugexe: Do I understand correctly, that zef can't install from cpan on Windows, because there is no gzip?
ugexe feels like those should all be False
23:54 sena_kun left 23:55 Xliff left
ugexe a long time ago the first result would have been True as well, but I think i fixed that one without fixing the other one. 23:56
ah yes -- github.com/rakudo/rakudo/commit/01...f7629caea0 23:58