🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left, reportable6 joined 00:16 maettu left 00:18 maettu joined 00:48 maettu left 01:04 maettu joined 01:08 maettu left 01:15 maettu joined 01:26 maettu left 01:38 maettu joined 06:00 reportable6 left 06:02 reportable6 joined 07:40 RakuIRCLogger left 07:58 sena_kun joined 08:22 Xliff left 08:42 Xliff joined 08:45 Xliff left
releasable6 Next release in ≈3 days and ≈7 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
12:00 reportable6 left, reportable6 joined
lizmat TIL that pod parsing creates a Match object for *every* grapheme for the pod 12:06
I guess that explains why pod parsing is relatively slow 12:07
nine Wait, what?! 12:16
lizmat yes 12:27
token pod_string_character 12:29
nine That at least looks somewhat easy to fix 12:38
lizmat fwiw, I'm looking beyond some easy fixes 12:42
m: say "foo" ~~ / o / 13:08
camelia ï½¢oï½£
lizmat m: say "foo" ~~ / o**1 /
camelia ï½¢oï½£
lizmat why would anybody do **1 ??
[Coke] I can only think of something like wanting to match an existing **x elsewhere, but yes, only contrived reasons. 13:12
lizmat luckily it appears the **1 is getting optimized away 13:13
m: "foo" ~~ / o**1 / for ^100000; say now - ENTER now 13:14
camelia 0.212199812
lizmat m: "foo" ~~ / o / for ^100000; say now - ENTER now
camelia 0.217277934
lizmat m: "foo" ~~ / o / for ^100000; say now - ENTER now
camelia 0.214076211
lizmat m: "foo" ~~ / oo / for ^100000; say now - ENTER now
camelia 0.216316567
lizmat m: "foo" ~~ / o**2 / for ^100000; say now - ENTER now
camelia 0.221127665
Nemokosch is there a simple and straightforward reason why use v(oldest) isn't the default for compunits? 13:15
[Coke] be happy if you can speed up POD procesing; we do some caching in raku/doc and it has always seemed a little slow.
Nemokosch with all the stability concerns
[Coke] *I would be happy if...
lizmat [Coke]: understood
lizmat is working on a prototype Rakudoc slang grammar 13:16
13:28 nebuchadnezzar joined
guifa lizmat: isn't it already implemented as a slang? or do you mean just updating the grammar for RakuAST? 13:52
lizmat it isn't. There *is* a slang officially, but it is empty
grammar Perl6::PodGrammar is Perl6::Grammar does STD does MatchPackageNibbler { } 13:53
guifa oh, wow.
lizmat with this as a comment: # place holder for a new slang for Pod
[Coke] is the html entity exposed? (could I search through it for App::Uni) ? 14:00
entity *list*
lizmat [Coke] it was my proposal to expose it, but that appears to have run against a lot of pushback :-( 14:18
github.com/rakudo/rakudo/commit/d9...1258663638 14:19
[Coke] If it's part of pod, it's part of pod - maybe something behind a core lib would be appropriate. 14:57
lizmat "behind a core lib" could you elaborate? 15:09
I thought it would make sense that since we have: 15:11
m: say "FULL STOP".uniparse
camelia .
lizmat and:
m: dd '2023-04-18'.Date 15:12
camelia Date.new(2023,4,18)
lizmat we could also have a:
m: say 'comma'.html-entity-parse
camelia No such method 'html-entity-parse' for invocant of type 'Str'
in block <unit> at <tmp> line 1
lizmat instead we now have: 15:13
m: use v6.*; say RakuAST::HTML::Entities.parse("comma")
camelia ,
lizmat meh
[Coke] for me, I'd want the list to be exposed, not to (only) be able to look up specific phrases. 15:28
e.g. how can I know 'comma' is one of the options
I feel like since it's already already part of pod, adding it to the str isn't bad. I might call it pod-entity-parse, though 15:29
Is there a PR to comment on? 15:30
lizmat there are several commits to comment on 15:46
fwiw I wouldn't call it pod-entity-parse as Pod is just one of the places it would be used 15:47
they are HTML entities, hence the name "html-entity-parse"
[Coke] my question there is are we guaranteeing as part of the spec that it's html entities, or did we happen to use that as our entity list and now it's separate. 16:05
lizmat the code mentions the then standard location of HTML5 entities as the source 16:09
my version uses the current standard location of HTML entities as source
so yes, it's HTML entities only
now: E<> also accepts any numeric representation 16:10
E<65> would be A
[Coke] notes that E<0x6b> also works, nifty 16:15
japhb Related: Cannot even tell you how nice it is that we use val() on arguments to MAIN too, BTW. Constantly using hex arguments to my option flags. 16:19
[Coke] lizmat: code ain't spec. 16:21
but that definitely seems to declare the intent, anyway
[Coke] didn't realize that trick worked on MAIN, nifty 16:32
lizmat well, val will give you an allomorph 16:41
m: dd val "42"
camelia IntStr.new(42, "42")
lizmat but yeah... it's pretty useful
18:00 reportable6 left 18:03 reportable6 joined
nine The things you find when re-implementing something: 18:21
m: { my package A::B::C { }; say MY::.keys } 18:22
camelia (A $_)
nine But:
m: { my $A::B::C; say MY::.keys }
camelia ($A::B::C $_)
nine So for lexical multi-part-named variables, we install lexicals that you cannot even access, as $A::B::C will be compiled to code that traverses the stashes starting at GLOBAL. 18:23
For that package we start traversing at that lexical A
[Coke] can you simplify it in the rewrite, or do you have to do the same? 18:37
18:42 Guest10 joined
nine Not sure I'm smart enough to actually simplify it. 18:45
[Coke] :) 18:58
19:14 Guest10 left
vrurg When I first read somewhere that `require` installs lexically – I was happy about. Then I was disappointed to find out that it is not actually true... 21:05
Geth rakudo/main: 31fb2b9e96 | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
RakuAST: fix double sigil on some indirect name lookups

INDIRECT_NAME_LOOKUP will add the sigil to the last name part, so we don't have to do that and in fact must not if we want to avoid a double sigil.		 21:06
rakudo/main: 027e37ccc9 | (Stefan Seifert)++ | 5 files
RakuAST: fix declaration of variables with multi part names $A::B
nine A few RakuAST tests need followup. Will do that tomorrow 21:14
21:38 Xliff joined 21:55 Xliff left
Geth nqp/fix-alias-backref: 04d3a3ab1e | (Jonathan Worthington)++ | src/QRegex/Cursor.nqp
Fix back-references when there are aliases

Aliases are named-mangled on the capture name into a string of the form
  `foo=bar`. This is handled in the match object construction, but was not
handled in the back-reference code.		 22:31
nqp: jnthn++ created pull request #802:
Fix back-references when there are aliases
22:48 nebuchadnezzar left 23:56 squashable6 left, bloatable6 left, sourceable6 left, unicodable6 left, committable6 left, statisfiable6 left, benchable6 left, tellable6 left, bisectable6 left, nativecallable6 left, linkable6 left, shareable6 left, notable6 left, quotable6 left, coverable6 left, releasable6 left, greppable6 left, evalable6 left, reportable6 left, reportable6 joined, evalable6 joined, bloatable6 joined 23:57 quotable6 joined, bisectable6 joined, coverable6 joined, unicodable6 joined, sourceable6 joined 23:58 greppable6 joined, squashable6 joined, linkable6 joined, releasable6 joined, tellable6 joined, notable6 joined, statisfiable6 joined, committable6 joined 23:59 nativecallable6 joined, benchable6 joined, shareable6 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!