00:02 sena_kun joined 00:04 Altai-man_ left 00:34 softmoth joined 01:13 samcv left, samcv_ joined 01:14 lucs left, lucs joined 02:01 Altai-man_ joined 02:03 sena_kun left 03:23 lucasb left 04:02 sena_kun joined 04:03 Altai-man_ left 04:19 camelCaser left 04:20 camelCaser joined 06:01 Altai-man_ joined 06:04 sena_kun left
nine AlexDaniel`: oh, sorry, I copied some code from my fix in 6f05fb3fe437a586870066d440b9226063a8a1dc 07:31
linkable6 (2020-03-28) github.com/Raku/roast/commit/6f05fb3fe4 Replace flappy timing in stress test with actual synchronization
07:42 JJMerelo joined
ShimmerFairy m: say "#" ~~ /\#/ 07:52
camelia ｢#｣
ShimmerFairy Funny, I was under the impression that backslashing an octothorpe wasn't allowed in regexes.
JJMerelo AFAIR it's allowed in regexes, not in tokens or rules in grammars
ShimmerFairy m: my token foo { \# }; say "#" ~~ /<foo>/ 07:55
camelia 5===SORRY!5===
Regex not terminated.
at <tmp>:1
------> 3my token foo { \# }; say "#" ~~ /<foo>/7⏏5<EOL>
Regex not terminated.
at <tmp>:1
------> 3my token foo { \# }; say "#" ~~ /<foo>/7⏏5<EOL>
Malformed regex
at <tmp>…
JJMerelo my token foo { "#" }; say "#" ~~ /<foo>/
evalable6 ｢#｣
foo => ｢#｣
ShimmerFairy I'm really not a fan of that, regexes should behave the same everywhere the slang shows up.
JJMerelo I raised an issue a long time ago... Let me see if I can find it 07:56
Right, exactly that... 2.5 years ago github.com/rakudo/rakudo/issues/1324
ShimmerFairy I could've sworn Raku used to complain if you tried to do \# in a regex, but I don't mind which of three choices are picked. I just don't see the need for inconsistency here :) 07:57
JJMerelo: funny seeing other people in that bug report's IRC snippets going "I could swear we had a warning against that" 07:59
As I recall, it was flat-out disallowed because "literal #" and "unspace a comment" are equally likely meanings, so it's hard to pick a side. 08:00
JJMerelo Yep, story repeats itself...
Which is why I sometimes get too insistent on having old issues addressed... They're bound to pop up sooner or later, resulting in frustration and lost time 08:01
08:02 sena_kun joined
ShimmerFairy Yeah, maybe I should go around poking at the "old bugs" tracker. 08:02
Luckily, I only asked this because I was reading the old S02 and noticed it saying "\# in a regex is fine" and being utterly confused, not because I was working with actual code :P 08:03
08:04 Altai-man_ left
JJMerelo Yeah, sometimes it's like kicking the proverbial wasp nest, but sometimes people see those bugs and can actually do something about them... 08:04
Now we're also at the beginning of a new release cycle, it's the time and moment to draw their attention. 08:05
releasable6 status
releasable6: status
releasable6 JJMerelo, Next release in ≈20 days and ≈10 hours. There are no known blockers. Changelog for this release was not started yet
JJMerelo, Details: gist.github.com/167565285ff8881e1c...2bc6a1002f 08:06
09:00 samcv_ left 09:01 samcv joined 09:14 JJMerelo left 09:34 JJMerelo joined 10:01 Altai-man_ joined 10:04 sena_kun left
nine I think I just hit the case I feared: some cases need all imported stashes to be marked neverrepossess while other's don't work with that 10:30
Kaiepi .tell jnthn, is github.com/Raku/nqp/pull/597 ok on the condition that nqp::listen always be called directly after nqp::bind_sk when binding streaming sockets? 10:45
tellable6 Kaiepi, I'll pass your message to jnthn
10:46 JJMerelo left
Kaiepi my implementation of happy eyeballs is a bit inefficient as it stands now... 10:54
on platforms other than openbsd, unless &*CONNECT picks an address with a better route than what v6.c's would, resolving addresses with happy eyeballs tends to be quite a bit slower, despite the A/AAAA queries being handled in parallel 10:55
nine Kaiepi: where does the inefficiency come from? 10:57
Kaiepi the main way i can think of to optimize it is to keep a probe socket to get source addresses for connections and reconnect it instead of creating a socket for every address received, but that requires proper udp sync socket support to do
not entirely sure yet nine, this happens regardless of whether address sorting actually happens 10:58
for connections that succeed
11:35 raku-bridge left, raku-bridge joined, MasterDuke left, MasterDuke joined, kawaii left, kawaii joined, lizmat left, lizmat joined, samcv left, samcv joined 11:36 timotimo left, timotimo joined 11:44 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 12:02 sena_kun joined 12:03 Altai-man_ left
nine So the two cases when handling stashes are: * vertically, i.e. the module that triggered the precompilation wants to repossess and * horizontally, i.e. a module that just gets precompiled for the same parent does not want to repossess 12:41
nqp::neverrepossess isn't the right tool for this as it's an all or nothing 12:42
Geth nqp: 49b2be035e | (Stefan Seifert)++ | docs/ops.markdown
Document nqp::neverrepossess
 12:49
ShimmerFairy That reminds me, I should probably show off my work on improving NQP documentation soon, probably as a forked repo. It'd be nice to not go too far with an approach people end up not liking. 13:09
lizmat ShimmerFairy++ 13:10
ShimmerFairy I'm just worried my work may come across as too bulldozer-y, so far I've been working in a local branch off master.
lizmat ShimmerFairy: maybe a bulldozer is what we need for nqp 13:11
dogbert17 .tell AlexDaniel if you're still interested in flappers then t/spec/MISC/bug-coverage-stress.t is another one
tellable6 dogbert17, I'll pass your message to AlexDaniel
lizmat I think it hasn't had any substantial work on it done for many, many years
AlexDaniel dogbert17: thanks, but I don't know 13:12
dogbert17 perhaps it's the same problem as yesterday, 'not ok 3 - Supply.merge on signals handles signal'
AlexDaniel dogbert17: I have no idea on how to fix the procasync flapper
ShimmerFairy yeah, one of my things is turning all the documentation into .rakupod files, instead of the mishmash of adhoc-ly chosen formats it currently is.
AlexDaniel ShimmerFairy: well… I mean, we have a full zoo of doc formats 13:13
dogbert17 AlexDaniel: I guess it will have to be a bug/enhancement issue
ShimmerFairy (it will also force me to eventually actually improve Raku's pod support for the NYI features I'd like to use) 13:14
AlexDaniel ShimmerFairy: can I ask a crazy question? :) 13:15
ShimmerFairy sure :)
AlexDaniel ShimmerFairy: what about making rakudoc markdown-compatible? 13:16
so that it'd be possible to write **foo** and have it in bold, and stuff like that
ShimmerFairy You could totally (theoretically) have a DOC use Pod::PlusMarkdown; module that modified the Pod grammar to allow for that stuff. But there's really no need for base Pod to have that kind of stuff. 13:17
AlexDaniel what do you mean no need x) 13:18
there's a reason why people keep writing non-pod documents
ShimmerFairy I think the main reason for that is because rakudo's Pod support has been severely neglected, honestly, not due to the quality of the format itself.
AlexDaniel it's not about the quality 13:19
it's just that I won't use a yet another format
the world converged on shitty markdown, too bad, but trying to push people to use something else is counter-productive at this point
lizmat feels like a problem-solving ticket? or is there one already ? 13:20
ShimmerFairy Should we support Doxygen standard too? And qtdoc? Those are also widely-used documentation formats.
Like I said, Raku has the (theoretical) power to let you modify Pod grammar all you want, so you'd need a really good reason to cram backwards-compat-breaking Markdown syntax in there by default. 13:21
AlexDaniel no, just markdown
okay fine, I told you it's just a crazy idea :) you can keep pushing a new format
ShimmerFairy Not really new, especially if you consider it an iteration on Perl's POD. 13:22
lizmat AlexDaniel: Nobody is forcing anybody to use rakupod, so if you're happy documenting in markdown, please do so
in the end it's about content 13:23
and ShimmerFairy appears to be wanting to add content
AlexDaniel lizmat: not exactly, no
btw I created this page a few years ago, maybe some will find it interesting: oddmuse.org/wiki/Wiki_Syntax_Refactoring 13:24
ShimmerFairy I have no problem with a 'p6doc' or similar program supporting the installation of documentation in other formats, or with people modifying the grammar for their own Pod documents. My only objection is making things like **bold** standard when we have a perfectly good B<bold> for people to use already.
AlexDaniel at least at the time I didn't find any good comparison between different doc languages, though maybe there is one now
lizmat abandons the idea of making Match completely lazy 13:30
the hack for <( )> is causing to much interference with the force
*too 13:31
AlexDaniel lizmat: now thinking about it, not sure if I understand your defensive comment. My point is that a markdown-based doc format would've been an amazing modern feature for a great language, it almost makes too much sense 13:56
ShimmerFairy: rakudoc is not “new” only if you're considering taking away from perl5 marketshare with their POD, for everyone else it's an absolutely new format
but I get it, it's Raku, of course there has to be its own thing… 13:57
lizmat no, that is not what I was saying
I said: a. this is worth a problem solving issue
and b. ShimmerFairy appears to want to add content primarily, which we sorely lack in nqp 13:58
starting a format discussion at that point, is counter-productive
format are what they are: formats
we can write programs to convert one format to another 13:59
we cannot write programs to create content
making markdown the primary documentation format for Raku documentation is another question altogether
one that we should discuss 14:00
ShimmerFairy The main reason why I didn't just leave formats be is that only Pod is really suited for technical documentation (and the other good choices would be really divorced from the Raku ecosystem: texinfo, latex, docbook...) 14:01
14:01 Altai-man_ joined
moritz much happier with markdown than pod for writing 14:01
ShimmerFairy In particular, I can (sadly theoretically at the moment) create a custom =for Vm block or a M<vm:moar|blah> code to say "mark this bit as backend-specific documentation", and just let the renderer take care of it. 14:02
Also, with Raku Pod you could install the documentation as Raku modules of sorts, and then easily access them through 'p6doc' and make it easy to hyperlink between the different documentation files. 14:03
moritz that is not pod specific
14:04 sena_kun left
moritz but just a side effect of us supporting pod atm 14:04
AlexDaniel treegrep: (\.md|\.markdown) 14:05
greppable6 AlexDaniel, gist.github.com/ce47b3d73121b6785f...baa03a7916
ShimmerFairy Fair, but Pod has a L<doc:> schema that means I really don't have to care how or where it's installed (e.g. the HTML renderer could link to another webpage with that doc, the in-terminal 'p6doc' renderer could just load up the local module's doc, etc.)
AlexDaniel treegrep: (\.pod|\.pod6)
greppable6 AlexDaniel, gist.github.com/3dc9fc3e386e8d1610...6887d4cac2
moritz the other formats don't really care about the format of the URI schemes either 14:07
no reason not to use doc: links in Markdown
ShimmerFairy yeah, I realized that about a minute after I said that :) 14:08
by the way, is the RakuAST work expected to shake up the Pod part of the parser in any way, or is Pod's AST still going to be a separate collection of classes? 14:20
lizmat pretty sure it's not going to be affected 14:22
but jnthn would know for sure :-)
AlexDaniel so I'm filing a ticket and looking for some examples, do you know other languages that get it right besides Julia and Crystal? 14:23
Nim is using RST, from what I understand
ah, Swift 14:24
Rust 14:26
ah okay that's more than enough for me 14:30
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue Raku needs a modern doc format that is familiar to most people github.com/Raku/problem-solving/issues/207 14:31
nine The only reason for me writing Inline::Perl5's READMe in markdown is because Github rendered it and the POD6 tooling was barely existent at that time 14:35
ShimmerFairy exactly, that's why Markdown gets the play it does in our repos, especially for readmes. 14:37
AlexDaniel oh I forgot to mention that in the ticket
that a doc format should just be a doc format and shouldn't require executing any code? a good opportunity to fix that? Although I don't really know about that issue, can you really put code in rakudoc now? 14:38
ShimmerFairy The only place is theoretically in certain cases of A<>, but I want to axe that precisely because code-in-doc is icky 14:39
AlexDaniel IIRC last time we tried to get github to render rakudoc we faced that wall 14:40
nine Just about the only thing I actually know about Markdown is how to `quote code` and ```code blocks``` (which sucks to type on a German keyboard layout) and that for some reason it insists on rendering my *bold* stuff in italic instead 14:42
ShimmerFairy Yeah, I don't think devs really "know" Markdown, they just understand the very basics of syntax. 14:43
AlexDaniel pretty sure most people know it more than they know rakudoc xD 14:51
I had some contributions to Raku/doc repo, but I don't remember how to do links, code blocks, numbered lists, bullets… 14:52
oh, inline code stuff is maybe X<>, but multiline? hmm
Geth ¦ problem-solving: lizmat unassigned from jnthn Issue Raku needs a modern doc format that is familiar to most people github.com/Raku/problem-solving/issues/207 14:53
ShimmerFairy X<> is for index entries 14:56
AlexDaniel well… 14:57
nine Do me _the_ most important feature of POD has always been the ability to put structured documentation right where the code is. 15:00
I was looking for how mixing code and docs work in rust as that's listed as an example of Markdown supporting language when I came across this: github.com/rust-lang/rust/issues/29474 15:03
So it appears that they aren't that satisfied with Markdown but inertia is keeping them on it 15:04
moritz =begin md\n ... =end md?
nine: this seem to be just a few guy's (m/f/d) opinion 15:05
AlexDaniel “For a long time, we were using pandoc which supported many, many extensions and it wasn’t much of an issue. We switched over to hoedown since it was a much smaller dependency (“what do you mean I need to install HASKELL to generate documentation for Rust!?”).” 15:07
raku-bridge <Rogue> Is there any internal reason CStructs have to be passed by reference? This seems like a rather arbitrary limitation
AlexDaniel yeah, I thought about pandoc too
nine: the argument seems to be that maybe they should use ReST instead, and it's not an unpopular decision. I think Nim does it, and Go a bit too 15:14
ShimmerFairy moritz: in the comment I'm about to post, I address the idea of a =Markdown block.
nine I guess we haven't thrown out TIMTOWTDI with the rename, so supporting multiple formats would be a pretty classic solution :) 15:16
AlexDaniel nine: … I'd prefer good solution, no classic ones :S 15:18
if someone can explain how pandoc is going to make everything awesome, then sure
good solutions, not* 15:19
my fingers are acting up x)
ShimmerFairy Posted my response. 15:20
nine Am I the only one to notice the irony of the response arguing against switching to Markdown, while being written in Markdown? :) 15:26
ShimmerFairy I noticed it too :) 15:28
AlexDaniel ShimmerFairy: “The Pod gist doesn't account for new extensions” greppable is stuck in time, there was no .rakupod extension back then 15:32
ShimmerFairy: it's because github.com/moritz/perl6-all-modules is broken
I tried to fix it, made some progress, but then got distracted by something else 15:33
what's .rakupod btw? 15:37
treegrep: \.rakupod
greppable6 AlexDaniel, Found nothing!
AlexDaniel treegrep: \.rakudoc
greppable6 AlexDaniel, Found nothing!
AlexDaniel so, yeah, unless the argument is that suddenly everyone started using rakudoc since the last year… 15:38
nine A rakupod obviously is a species that has pottery legs
ShimmerFairy just the new extension for Pod documents, AFAIK. (It's what I'm using, anyway.)
AlexDaniel ShimmerFairy: github.com/Raku/problem-solving/bl...extensions 15:39
ShimmerFairy I see. 15:40
nine I've got some experimental confirmation that my vertical vs. horizontal repossession distinction might be right. Now where can I make that distinction and how do I communicate it down to the VM? 15:42
15:47 patrickb joined
nine Maybe I can get by with nqp::scwbdisable and nqp::scwbenable. With those I should be able to decide on a case by case basis. 16:00
16:02 sena_kun joined 16:04 Altai-man_ left 16:39 JJMerelo joined 17:45 lucasb joined 17:57 lichtkind joined 18:01 Altai-man_ joined 18:03 sena_kun left
[Tux] Rakudo version 2020.06-7-gf1960baa9 - MoarVM version 2020.06-12-ge5d597d18
csv-ip5xs0.812 - 0.837
csv-ip5xs-207.850 - 7.937
csv-parser23.123 - 25.429
csv-test-xs-200.379 - 0.384
test7.527 - 8.029
test-t1.855 - 1.971
test-t --race0.846 - 0.857
test-t-2030.902 - 33.168
test-t-20 --race9.034 - 10.059
 18:40
18:50 JJMerelo left 18:52 lichtkind left
softmoth AlexDaniel, it should be .rakudoc, according to problem-solving issue 19:07
oh, sorry, I missed that you already have that
19:29 softmoth_ joined 19:31 softmoth left 20:02 sena_kun joined 20:04 Altai-man_ left 20:36 softmoth_ left 20:37 softmoth_ joined, softmoth_ left 20:38 softmoth_ joined 22:01 Altai-man_ joined 22:04 sena_kun left 22:15 patrickb left 23:05 softmoth_ left
AlexDaniel 6c: spurt ‘/tmp/foo’, Buf.new(42), :bin; 23:35
committable6 AlexDaniel, gist.github.com/e88523edb9898c2235...dcdc4b4ae4
AlexDaniel … whaat…
bisect: spurt ‘/tmp/foo’, Buf.new(42), :bin;
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel, Output on all releases: gist.github.com/19d1b9f86f7c1a9aff...dae27c29d4 23:36
AlexDaniel, Bisecting by exit code (old=2020.05.1 new=2020.06). Old exit code: 0
AlexDaniel, bisect log: gist.github.com/c6659c300e61431aa2...83fab6a987
AlexDaniel, (2020-05-17) github.com/rakudo/rakudo/commit/da...776dcddca9
AlexDaniel, Output on all releases and bisected commits: gist.github.com/3b5bb554eae271abb7...7f2bc0a524
AlexDaniel interesting? So :bin doesn't do anything? 23:37
why did I write it whateverable then
timotimo .o( da :bin ich überfragt ) 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!