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.
timotimo of course those CArrays that were allocated were in the tens or hundreds of kilobytes i believe 00:02
greppable6: CArray.*allocate 00:03
greppable6 timotimo, 33 lines, 8 modules: gist.github.com/c068c1d34dca677c27...af8fb4ee76
timotimo doesn't look like many modules obviously allocated huge CArrays, so might not have such a big effect on the ecosystem 00:04
any modules that work with big chunks of data and don't have to go to C would use Buf.allocate instead
which already uses setelemspos to create the right amount of slots 00:05
japhb Still, 3 orders of magnitude improvement for that particular case is nothing to sneeze at! 00:20
timotimo one day we'll emit memset, memcpy, and memmove when we detect equivalent loops 00:27
vrurg m: class Foo { method foo is raw { nqp::list(1,2) } }; Foo.new.foo.^name.say 00:52
camelia 5===SORRY!5=== Error while compiling <tmp>
Could not find nqp::list, did you forget 'use nqp;' ?
at <tmp>:1
------> 3Foo { method foo is raw { nqp::list(1,2)7⏏5 } }; Foo.new.foo.^name.say
vrurg m: use nqp; class Foo { method foo is raw { nqp::list(1,2) } }; Foo.new.foo.^name.say
camelia List
vrurg So, `is raw` is ignored for methods?
01:06 yoleaux left 01:34 AlexDaniel left 01:35 AlexDani` joined 01:46 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 03:06 yoleaux joined 05:35 nubie joined, nubie left
bartolin just a quick note: I've skimmed through the discussion about moving RT issues to github. I'll be afk until end of July, but I'd volunteer to help with the migration after that (I hope that's not too late) 06:24
06:50 [TuxCM] joined 07:16 patrickb joined 07:53 [TuxCM] left 08:06 tyil[m] left, tyil[m] joined
lizmat Files=1275, Tests=108165, 206 wallclock secs (27.05 usr 7.78 sys + 2851.82 cusr 279.11 csys = 3165.76 CPU) 08:21
09:12 [TuxCM] joined 10:03 MasterDuke left 10:55 vrurg left
Geth ¦ rakudo: tbrowder self-assigned Diagnostic or definition problem? github.com/rakudo/rakudo/issues/3036 11:46
11:51 ugexex joined 11:56 ugexe left 12:01 a3f joined, kawaii joined 12:02 a3f left, a3f joined 12:18 go|dfish joined
AlexDaniel bartolin: there's not much to do, actually 13:02
13:02 pamplemousse joined
AlexDaniel bartolin: they already have a script to do all the work, we just tell them where to put the issues and give permissions to open the tickets. That's about it 13:02
13:25 vrurg joined 13:46 ugexex is now known as ugexe 14:01 vrurg left 14:12 vrurg joined
nine Regarding the CLA discussion: I think we've destroyed any benefit that a CLA might have brought long ago. Yes, if all contributions are made by people who have signed a CLA (which says TPF gets to own the code), then it'd be easy to relicense. 14:14
But! Not all contributions were done this way. We've merged lots and lots and lots of pull requests of people without a signed CLA (at that time). 14:15
Their code still belongs to them. I really don't see how the PR/merge process changes that in any way.
patrickb I partly disagree. Doing a relicensing requires us to track down the contributors we don't have a CLA for. For those we can't, we have to throw the code out and rewrite. The more CLAs we already have, the fewer contributors we have to track down. 14:20
Having 100% coverage would be ideal. But every CLA we have helps. 14:21
ugexe node got rid of their CLA long ago fwiw 14:23
patrickb Question is whether we want to keep the option to relicense open or not. Artistic 1.0 seems to be a solid license that has gotten quite some real world usage. Artistic 2.0 is younger, but only a fresh up of Artistic 1.0 so I would say we might just accept the risk of "Oh noes, we didn't see this change in laws/loophole coming, we need to do somethi 14:26
ng about the license!"
14:27 lucasb joined 14:45 epony left 15:02 patrickb left 15:22 epony joined
AlexDaniel but isn't Artistic 2.0 very permissive anyway? So what kind of potential relicensing do we have in mind? 15:27
kawaii BSD-3 is also a viable candidate fwiw 15:28
AlexDaniel like, if you want to go into the copyleft direction, then you can already do that regardless of CLAs (Artistic 2.0 → GPLv3, easy) 15:29
in the opposite direction we have what, CC0 ? 15:30
it's also a bit weird that there's no “or later” clause, like in GPL 15:33
japhb m: sub postfix:<!>($n) { [*] 1..$n }; say 4!; 15:36
camelia 24
nine patrickb: you'd also need to hunt down contributors we have a CLA for if they made any contributions before signing. Which will probably be most of us, since there will usually be a couple of PRs until someone figures it's less tedious to give out the commit bit which is where we require the CLA 15:37
japhb m: say $*PERL.compiler.version
camelia v2019.03.1.680.g.82.fc.4.e.570
15:49 robertle joined 16:01 Kaiepi left 16:06 [TuxCM] left
pamplemousse I was wondering if anyone knows why adding print statements for debugging purposes in NQP causes a rebuild of Rakudo to fail? 16:11
For example, I added a print statement after the line here: github.com/perl6/nqp/blob/master/s...r.nqp#L444
jnthn Probbly because we use NQP scripts during the build, to generate code 16:12
And so your debug output ends up being compiled
pamplemousse And the rebuild of nqp goes just fine, but when I rebuild Rakudo, it prints out the text, then says it's confused near the print statement
jnthn Use note instead of print, so it goes to stderr
pamplemousse Oh that makes sense, thanks
16:23 Kaiepi joined 17:21 [TuxCM] joined 18:08 AlexDaniel left
bartolin jnthn++ mentioned the many roast tickets that have been created some years ago (in order to have an issue for every fudged test in roast). Here is a blog post about the process: www.perl.com/article/174/2015/5/12...r-tickets/ . Some of those tickets have been triaged (rejected, resolved, enriched with information), but I agree that the rest isn't particular useful. 18:19
Since I merged the PR to roast back in 2015, I could as well do some cleanup work. I plan to identify the placeholder tickets, create a PR for roast to remove the references to those tickets and after that close (reject) them in RT.
Any thought? 18:20
*RT tickets in the first sentence
18:23 vrurg left 18:32 AlexDaniel joined, pamplemousse left 18:37 AlexDaniel left 18:40 pamplemousse joined 18:44 pamplemousse left 19:16 lucasb left 19:32 MasterDuke joined 21:00 Kaiepi left 21:10 Kaiepi joined 21:47 nebuchadnezzar left 21:59 AlexDaniel joined
Geth roast: usev6++ created pull request #556:
Remove reference to placeholder tickets from RT		 22:11
AlexDaniel please comment: github.com/perl6/roast/pull/556#is...-509835289 22:40
23:13 Kaiepi left, Kaypie joined 23:40 vrurg 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!