🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
cpan-raku New module released to CPAN! Red (0.1.13) by 03FCO 00:10
raku-bridge <DataKinds> hey, I'm trying to use cro and cro stub http generated a project that's not booting 03:09
<DataKinds> it's telling me Failed to import resources/fake-tls/server-crt.pem as PEM/ASN1/PKCS12
raku-bridge <DataKinds> commenting out the tls argument and changing http from <1.1 2> to <2> to Cro::HTTP::Server.new fixed it, but now obviously I can't do HTTPS 03:19
<DataKinds> err, to <1.1>
lembark Anyone good at examining Raku with valgrind [or anything similar]? 04:38
Trying to track down a serious memory leak in 6.d, need to see what layer it's in so that I can try to generate a realistic example that doesn't require moving a 128GiB .xz file around for testing. 04:39
fling is there a simple perl -> perl6 code converter? 05:22
raku-bridge <DataKinds> fling: no converter, but there's this modules.raku.org/dist/Inline::Perl5:cpan:NINE 05:45
<DataKinds> Why can't you put a type constraint on an our-scoped variable? that's not documented anywhere I can find 05:47
lembark Q: Any good docs on raku garbage collection (e.g., how to trigger it)? 05:55
moritz it usually triggers itself. nqp::force_gc() exists but is not portable 06:03
Geth doc: 1bab6f4132 | (Richard Hainsworth)++ (committed using GitHub Web editor) | 2 files
Expand on the use of {*} with proto (#3500)

  * Expand on the use of {*} with proto
The documentation was not as clear as I needed. I tried several times to understand it, but failed. I got it nearly right when I asked on perl6-users. Crucially '{*}' is a special token without whitespace - this needs to be noted. ... (5 more lines)		 06:33
linkable6 DOC#3500 [closed]: github.com/Raku/doc/pull/3500 Expand on the use of {*} with proto
raku-bridge <DataKinds> can you export a dynamic variable? 06:58
raku-bridge <DataKinds> I'm just trying to set up a little configuration a-la rails initializers 07:02
lizmat bisectable6 VM.request-garbage-collection 07:10
AlexDani` lizmat: colon 07:11
lizmat ah, duh 07:11
AlexDaniel bisectable6: VM.request-garbage-collection 07:13
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel ah, you already did it in #raku-dev :) 07:14
bisectable6 AlexDaniel, Output on all releases: gist.github.com/76f985c4a38efcba7c...5701ede9b9
AlexDaniel, Bisecting by exit code (old=2020.02.1 new=2020.05.1). Old exit code: 1
AlexDaniel, bisect log: gist.github.com/b29a04ba8dcc3e68e4...8beb8ce460
AlexDaniel, (2020-04-24) github.com/rakudo/rakudo/commit/e2...5585468532
AlexDaniel, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/cef86c9836206bd88f...53c2c98020
AlexDaniel, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
AlexDaniel, Output on all releases and bisected commits: gist.github.com/5b0164be88cd092569...bd39a7b70c
lizmat clickbaits rakudoweekly.blog/2020/06/29/2020-...loud-gone/ 08:09
samebchase- lizmat: Thank you! It was an enjoyable read. 08:42
[ptc] lizmat++ 10:12
lizmat news.perlfoundation.org/post/jonat...sion-20-06 # jnthn's grant extension request, please comment! 10:32
sadly I found out too late about this to add it to the RWN :-(
antoniogamiz .pod6 files seems to be not recognized by github yet mm 11:41
tbrowder lizmat: thnx for another great weekly. i wasn't able to join the cloud event but yr blog makes it seem like i was there albeit not concurrently. 12:01
El_Che tbrowder: the non-concorrency is the main advantage. See at your own pace! 12:24
tbrowder El_Che: roger! 12:49
timotimo lizmat: should we go through the lightning talks and put relevant ones in the next weekly? 13:42
like the libusb raku binding had a lightning talk to go with it
lizmat aaahhh did I miss that ? 13:48
grrr
timotimo probably because there was already more than fits on three plates on your plate that week :) 13:50
lizmat hehe 13:51
added to this weeks RWN 13:56
Geth ecosystem: 117a5d97a9 | (Jonathan Stowe)++ | META.list
Oopsie with GD rename
 14:04
cpan-raku New module released to CPAN! DBIish::Transaction (1.0.4) by 03RBT 14:58
Geth doc: 344bf16fea | Coke++ | 11 files
perl6 -> raku
 15:23
doc: c356974326 | Coke++ | doc/Language/functions.pod6
whitespace
linkable6 Link: docs.raku.org/language/functions
eery Hmm... what would the process look like to add another JIT target to MoarVM? Is everything sort of hardcoded to amd64 or could it support multiple archs 17:27
timotimo i think it's not very hardcoded, but i haven't looked closely yet 17:31
eery fair enough. don't have the time or skill to work on that front but just curious how "easy" it would be, as "easy" as any JIT backend is to write 17:34
performance seems pretty good without it at least 17:35
timotimo true, spesh optimizes a bunch of stuff to better moar bytecode already and that's worth a lot
jnthn There's really two JITs, a "lego JIT" which is the original one and is certainly quite attached to amd64, and an expression JIT, which is newer and in theory easier to port; currently it does what it knows how, but falls back to the lego JIT for things it doesn't know how to handle. 17:37
The goal is to move fully over to the expression JIT, at which point porting should be a bit easier, though yeah, I don't think I'd ever describe it as "easy" :)
timotimo true, and we just kind of lazily let a lot of stuff to the lego jit still 17:38
timotimo looking at some output from setting the MVM_SPESH_LOG environment variable to a filename and running a script 17:39
can perhaps give you an idea of what the code that gets fed to the jit looks like
timotimo the expr jit starts anew on every basic block, and in the spesh log you can see where the expr jit "bails" on each BB 17:40
if there's no frames where there are no "expr jit bail" comments in them, then we're in a little spot of bother for this plan, but of course adding individual bits to the expr jit is possible 17:41
eery yeah I think I see how the JIT identifies blocks to compile, will have to run this on an x86 box to see what those jit logs look like 17:49
timotimo yeah, MVM_JIT_DEBUG you mean? 17:50
eery well, I thought the spesh logs also had references to the jit in them? 17:51
timotimo that's right
but it'll mostly be information on bailing out 17:52
with jit debug also set you get more internal-ish dumps from the jit
eery ah neat
timotimo since the exprjit is based on expression trees and tiling, you'll be getting a DOT language dump of trees as well as a linear list of the "tiles"
eery hmm, MVM_JIT_DEBUG? 17:54
timotimo i think that's the one 18:08
probably just need to set it to "1" or "yes" or whatever 18:09
[Coke] DOT? 18:13
(my expansion of that is always "Department of Transportation" which I am 99% sure is incorrect here. :)
timotimo ha
the graphviz file format
[Coke] DOH. 18:15
thank you. :)
timotimo that's the Department of Health tho 18:16
eery I just realized while DOT has "of" in it the initialism for DH doesn't, and now that's gonna bother me 18:18
timotimo but DH is Diffie-Hellman key exchange? 18:19
MasterDuke .tell lembark i've had success before using heaptrack to find leaks in moarvm. a regular profile or heap snapshot will give you information at the raku level 19:10
tellable6 MasterDuke, I'll pass your message to lembark
El_Che the p5p perl7 thread is... interesting 20:37
lizmat has been unsubscribed from p5p for years now 20:40
interesting in what sense ?
El_Che that there isn't much of a consensus on the what Perl 7 will be 20:44
moritz my summary would be: 20:45
El_Che dramatic pause
moritz * most people agree that having some kind of version bump to 7 is a good thing
* most people are very worried about breaking backwards compat 20:46
* all people who mention the timeline do so in a "that's WAY too short" way
lizmat yeah, changing a language is *HARD* 20:47
moritz * the biggest point of contention seems to be how to deal with legacy code
El_Che well, there is considerable group of people that considers eternal 5.8 support the most important issue 20:48
moritz (with SaywerX basically saying "it's been holding us back, and non-mantainers aren't language contributors", and everybody else says CPAN is Perl's biggest strength, we cannot break that
El_Che I don't see how you can reconcile that view with a Perl 7 as the rebirth of the maguage
l 20:49
lamg
lang
moritz :-)
El_Che sorry
moritz late here too
</summary>
I'm generally all in the "let's move forward" camp
El_Che however, of Perl 7 is postponed for ever, or is just an bump keeping the status-quo, I don't think Perl could survive that 20:50
moritz but I have no idea how much of the code that we use for $work (for example) has active maintainers
El_Che old code will no disappear, but the brand will be completely dead for new development
not
damn I am a crappy blind typist 20:51
(moving from azerty yo qwerty)
moritz and then we'd need a better way to bring it to p7 compat than becoming the new maintainer on PAUSE, which is a lengthy, arduous process
rypervenche I find it rather shocking (although I really shouldn't) how many people on Twitter who haven't kept up with either Perl or Raku immediately think "Ahh, Perl 7, so Perl 6 failed" 20:52
El_Che we're Raku now, so the bad rep is actually directed at Perl
(not really fair) 20:53
timotimo just saw "syntactic vinegar" for the first time
El_Che moritz: I think CPAN is a double edged sword for Perl
rypervenche Although reading through some of the social media, it's still amazing to see just how much work Liz is doing out there. 20:54
El_Che if the code rot starts to spread faster than new code while forcing modules author to write compatible code with ancient perl releases... not a good place to be
rypervenche: If I didn't know lizmat IRL, I would suspect she's a powerfull AI ;) 20:55
kawaii rypervenche: ahhhh you make me search 'perl6' on Twitter and I only managed to read maybe 2 or 3 Tweets before I was forced to close the browser window.
are people really like this?
lizmat hmmm... 20:56
hobbs there's pretty much nothing worse than people
timotimo always the loud minority that you're seeing 20:58
El_Che "I don't think the defaults for .pl, .pm, or non-extension files can change.
However, .pl7 and .pm7 files could default to perl 7 features. Hopefully
including warnings."
it's like looking at the past
Grinnz me has Opinions on the merit of a direction that would even make people consider that as a "solution" 21:03
+/
El_Che to be honest, after reading somne of the thread (the list UI is terrible), I fear for immobility and a mishmash of both the perl5->6 AND python2->3 transitions :( 21:04
while at the same time, I feel Perl 7 is needed 21:05
fingers crossed!
Grinnz: I think I saw your name in the discussion (DB, right?) 21:13
Grinnz indeed
Geth whateverable: 55cfbe31b0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 13 files
Make sure Reply is mixed in

Otherwise a gisted reply will lack some basic information (bot name, query, etc.).		 22:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!