🦋 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
01:00
unicodable6 left,
nativecallable6 left,
tellable6 left,
statisfiable6 left,
bloatable6 left,
reportable6 left,
linkable6 left,
committable6 left,
evalable6 left,
sourceable6 left,
notable6 left,
squashable6 left,
greppable6 left,
benchable6 left,
shareable6 left,
releasable6 left,
bisectable6 left,
quotable6 left
01:01
greppable6 joined,
evalable6 joined,
tellable6 joined
01:02
bisectable6 joined,
sourceable6 joined,
squashable6 joined,
releasable6 joined,
nativecallable6 joined,
reportable6 joined
01:03
linkable6 joined,
notable6 joined,
quotable6 joined,
benchable6 joined,
statisfiable6 joined,
shareable6 joined,
unicodable6 joined,
bloatable6 joined,
committable6 joined
03:56
sourceable6 left,
linkable6 left,
committable6 left,
bisectable6 left,
bloatable6 left,
squashable6 left,
reportable6 left,
evalable6 left,
unicodable6 left,
greppable6 left,
releasable6 left,
quotable6 left,
statisfiable6 left,
benchable6 left,
notable6 left,
coverable6 left,
nativecallable6 left,
shareable6 left,
squashable6 joined
03:57
unicodable6 joined,
notable6 joined,
benchable6 joined,
sourceable6 joined
03:58
quotable6 joined,
evalable6 joined,
coverable6 joined,
linkable6 joined,
committable6 joined
03:59
statisfiable6 joined,
nativecallable6 joined,
releasable6 joined,
reportable6 joined,
greppable6 joined,
bloatable6 joined,
shareable6 joined,
bisectable6 joined
04:59
quotable6 left,
committable6 left,
notable6 left,
tellable6 left,
statisfiable6 left,
reportable6 left,
releasable6 left,
shareable6 left,
squashable6 left,
greppable6 left,
benchable6 left,
bloatable6 left,
bisectable6 left,
sourceable6 left,
unicodable6 left,
evalable6 left,
notable6 joined
05:00
squashable6 joined,
statisfiable6 joined,
tellable6 joined,
shareable6 joined
05:01
bloatable6 joined,
sourceable6 joined,
quotable6 joined,
committable6 joined,
greppable6 joined,
releasable6 joined
05:02
benchable6 joined,
bisectable6 joined,
reportable6 joined,
evalable6 joined,
unicodable6 joined
05:57
tonyo left
05:59
tonyo joined
06:00
reportable6 left
06:02
reportable6 joined
07:48
notable6 left,
reportable6 left,
evalable6 left,
releasable6 left,
sourceable6 left,
committable6 left,
unicodable6 left,
shareable6 left,
tellable6 left,
benchable6 left,
squashable6 left,
bisectable6 left,
bloatable6 left,
quotable6 left,
statisfiable6 left,
greppable6 left,
nativecallable6 left,
coverable6 left,
linkable6 left,
linkable6 joined,
tellable6 joined,
benchable6 joined
07:49
bloatable6 joined,
shareable6 joined,
nativecallable6 joined,
squashable6 joined,
unicodable6 joined,
evalable6 joined,
quotable6 joined
07:50
releasable6 joined,
reportable6 joined,
notable6 joined,
sourceable6 joined,
bisectable6 joined
07:51
committable6 joined,
statisfiable6 joined,
greppable6 joined,
coverable6 joined
08:01
samebchase left
08:19
sena_kun joined
08:30
ab5tract left
11:21
MasterDuke left
12:00
reportable6 left,
reportable6 joined
|
|||
Geth | rakudo/main: c4ab78b47d | (Elizabeth Mattijsen)++ | 8 files RakuAST: make $=pod / $=finish actual lexical lookups - introduce RakuAST::VarDeclaration::Implicit::Doc role - introduce RakuAST::VarDeclaration::Implicit::Doc::Pod class - introduce RakuAST::VarDeclaration::Implicit::Doc::Finish class - add two attributes to RakuAST::CompUnit, to keep the RakuAST::VarDeclaration::Implicit::Doc::xxx objects and make ... (6 more lines) |
12:01 | |
lizmat | TIL that Rakudo actually has a complete HTML5 entity table in memory | 12:47 | |
hidden in src/Perl6/Pod.nqp | 12:49 | ||
12:51
bartolin left
13:03
tonyo left
13:05
tonyo joined
|
|||
Nemokosch | How come? 🤫 | 13:31 | |
Bad emoji | |||
lizmat | because of the E< > pod formatting code | 13:35 | |
docs.raku.org/language/pod.html#Unicode | 13:36 | ||
"Raku makes considerable use of the E<laquo> and E<raquo> characters." | |||
Geth | rakudo/main: f040293a91 | (Stefan Seifert)++ | src/Raku/Actions.nqp RakuAST: fix &?ROUTINE lookup in regex, token and rule |
14:29 | |
Nemokosch | Is there even a HTML5 entity list? | 14:32 | |
guifa | yes | 14:46 | |
html.spec.whatwg.org/multipage/nam...cters.html | |||
15:35
notna joined
|
|||
nine | Oh darn, I ran the wrong test file. The latest commit doesn't actually fix that | 15:42 | |
Geth | rakudo/main: 36ec8e33b3 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod RakuAST: properly look up compunit with "attach" nine: "The find-attach-target should be in a method attach. That's the only point where the resolver is guaranteed to be in the right state to find the correct attach target." |
16:08 | |
Nemokosch | oh right, sorry I got confused | 16:11 | |
what I actually missed is a list of valid HTML tags | |||
Geth | rakudo/main: b8763c3552 | (Stefan Seifert)++ | src/Raku/Actions.nqp Revert "RakuAST: fix &?ROUTINE lookup in regex, token and rule" This reverts commit f040293a918775e66bfcb541e214518bbfdc3ca6. |
16:20 | |
rakudo/main: b8e1ba3b4e | (Stefan Seifert)++ | src/Raku/ast/code.rakumod RakuAST: actually add &?ROUTINE to regex declarations Previous fixing attempt wasn't enough |
|||
rakudo/main: 351f053d79 | (Elizabeth Mattijsen)++ | 3 files Introduce Str.htmlparse This will try to interprete the string as an HTML entity, and return the string associated with it, for example: á".htmlparse -> á This introduces a rather large lookup table, which in fact already lives in src/Perl6/Pod.nqp. But since all src/Perl6 files are on ... (11 more lines) |
17:31 | ||
guifa | lizmat: no need to generate an updated list. "This list is static and will not be expanded or changed in the future." | 17:32 | |
Geth | rakudo/main: 262cc42e4a | (Stefan Seifert)++ | src/Raku/Grammar.nqp RakuAST: support local subs overriding quoters |
||
lizmat | guifa: never say never :-) | 17:33 | |
17:37
evalable6 left,
linkable6 left
17:39
evalable6 joined
17:40
linkable6 joined
|
|||
Geth | rakudo/lizmat-Int-html-entity: f36821f227 | (Elizabeth Mattijsen)++ | src/core.c/htmlparse.pm6 Introduce Int.html-entity Attempts to return the HTML entity associated with the integer value (assumed to be a codepoint). Returns Nil if there is no such entity. Lazily builds the lookup hash from the Str.htmlparse lookup table the first time the Int.html-entity method is invoked, so this won't increase build/startup time significantly, while being able to provide a very nice feature when it is needed. |
17:40 | |
rakudo: lizmat++ created pull request #5245: Introduce Int.html-entity |
|||
18:00
reportable6 left,
reportable6 joined
18:11
notna left
|
|||
Geth | rakudo/main: 5feb7f7f4e | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6 Add Str.leading/trailing-whitespace implemementation-detail Returns any leading / trailing whitespace of the string, which would be the empty string if there is no leading/trailing whitespace, or the string itself if it only consists of whitespace or is empty. The Str.leading-whitespace will be used in RakuAST rakudoc block parsing and codegenning. Str.trailing-whitespace added for consistency. Both are marked implementation-detail for now, unless we agree on making it a public API. |
18:28 | |
18:31
MasterDuke joined
|
|||
MasterDuke | hm. do RakuAST nodes/classes/roles/etc have access to methods in src/Raku/Actions.nqp? | 18:34 | |
jdv | i thought we weren't going to commit to main a lot anymore? | 18:35 | |
its making it harder to run blin cause it takes a while for a build to happen | 18:36 | ||
lizmat | jdv: there's constantly work on RakuAST that is on main nowadays | ||
and the above is in support of that | |||
MasterDuke | can you tell blin to just stay on one particular commit? | ||
jdv | yes, blin can take explicit commits endpoints | 18:38 | |
iirc there were reasons that we moved from everyone pushing to main to using PRs or branches or whatever | 18:40 | ||
when will rakuast dev falll into that zone - its a bit confusing and a bit annoying | |||
lizmat | well, there are currently 2 people working quite a lot of hours on getting RakuAST completed | 18:41 | |
jdv | i know that, so? | ||
anyway, not a big deal i guess - just odd | 18:42 | ||
lizmat | I'll make it a discussion point for resolution at the Raku Core Summit | ||
jdv | its going to make releasings, perhaps minorly, more complicated methinks | 18:43 | |
ok | |||
releasable6 | Next release in ≈4 days and ≈23 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 19:00 | |
MasterDuke | ah ha! getting significantly closer to a/the better implementation of github.com/rakudo/rakudo/pull/5242 | 19:20 | |
but likely afk for a while. hopefully final cleanup+testing tomorrow evening | 19:22 | ||
Geth | rakudo/main: 72b8b8b0b6 | (Elizabeth Mattijsen)++ | src/core.c/htmlparse.pm6 Rename Str.htmlparse to Str.html-entity-parse To prevent confusion with regards to the offered functionality |
19:23 | |
vrurg | lizmat: I've left a comment to the commit, but would have it here too. I don't think HTML-related stuff belongs to the core. And I agree to jdv with regard to this kind of changes: these are certainly better be PRs in first place so we can discuss them if necessary. | 19:56 | |
Nemokosch | now that this came up: not to underestimate and banter the work of the few dedicated people who took up on RakuAST work but probably once it works at all, there should be another round of planning for the final interface | 19:59 | |
it's arguably harder to get something working from scratch than to polish the user-facing interface once there is a working foundation | 20:00 | ||
MasterDuke | re html stuff, it feels sort of the same to me as the built-in json stuff. maybe if we were starting over it wouldn't be in the core, but it is now. and if we don't plan to remove it, why not make in accessible somehow? maybe they could/should be moved to a "core" lib, like `Test`? so `use core::JSON` or `use core::HTML` would give you the built-in | 21:22 | |
`(from|to)-json` and `html-entity-parse` | |||
unrelated to the previous comment, but what is a semiarglist? | 21:23 | ||
21:41
sena_kun left
|
|||
lizmat | vrurg: but that's the point: it is already in core | 21:54 | |
MasterDuke: the inside of a signature ? | 22:03 | ||
Geth | rakudo/main: 2d66116b6b | (Elizabeth Mattijsen)++ | src/core.c/htmlparse.pm6 Mark Str.html-entity-parse as an implementation-detail |
||
vrurg | lizmat: am I overlooking something? | 22:12 | |
lizmat | src/Perl6/Pod.nqp maybe ? | ||
vrurg | Documentation-related stuff is an exception here for obvious reasons. But Str? | 22:13 | |
It could even be a module in lib/. But certainly it's not about Str as such. | 22:14 | ||
lizmat | formatting code E<comma> renders as , | ||
because of this table living in src/Perl6/Pod.nqp | |||
vrurg | Let it live there then. | 22:15 | |
lizmat | which is part of the core ?? | ||
the thing is that E<comma> needs to be instantiated as Pod::FormattingCode.new(type => "E", meta => ["comma"], contents => [","]) | 22:17 | ||
so it must be part of the core | |||
vrurg | Yes, in a way. :) As I said, Pod is about documentation and thus can do some HTML-related stuff. But Str is pure data. | ||
lizmat | if you have a source file with pod in it, and the pod has an E<comma> in it, then it *must* do that translation before it winds up in $=pod | 22:18 | |
I didn't make this up, this is what $=pod is | |||
vrurg | Ok, but why should this involve Str and Int? | 22:19 | |
lizmat | in core is just Str.html-entity-parse | ||
the Int.html-entity is a PR | 22:20 | ||
which is now closed | |||
vrurg | Why the method can't be on Pod? | 22:21 | |
lizmat | because it takes a string ? | ||
vrurg | I mean, let's imagine we add support for PostScript or RTF to Pod. Should elements of that support end up in Str too? Why HTML is so exceptional? | 22:22 | |
lizmat | it converts an HTML entity string into a string representation based on its codepoint | ||
vrurg | Many methods take a string. It doean't make them eligible for Str. | 22:23 | |
lizmat | HTML is exceptional because we support that in E< > formatting codes | ||
again, I didn't make this up: this is what the spec for pod is | |||
and it currently lives in NQP in src/Perl6/Pod.nqp | 22:24 | ||
vrurg | Then what if we add other kinds of formatting, as I mentioned? Then we also provide interface in Str? E<> is a Pod thing – let pod handle it. | ||
22:38
nebuchadnezzar left
|
|||
jdv | lizmat: blin fails look like your stuff - let me know | 22:42 | |
lizmat | jdv: which stuff ? | 22:45 | |
jdv | github.com/rakudo/rakudo/issues/5246 | ||
Geth | rakudo/main: d965820269 | (Elizabeth Mattijsen)++ | 4 files Move Str.html-entity-parse to RakuAST::HTML::Entities.parse As per popular demand |
22:50 | |
vrurg | lizmat++ | ||
lizmat | now, later, when people ask if Raku can convert HTML entities to strings, we can tell them to use RakuAST::HTML::Entities.parse instead of Str.html-entity-parse | 22:51 | |
which then makes a lot of sense *sigh* | |||
vrurg | I would first look for a module anyway. | 22:53 | |
lizmat | in Python it's in the standard library: | 22:56 | |
Python 2.6-3.3 | |||
You can use HTMLParser.unescape() from the standard library: | |||
just saying | |||
Geth | rakudo/main: 5310496790 | (Elizabeth Mattijsen)++ | src/core.c/Pod.pm6 Revert "Introduce Pod::Declarator class" This reverts commit ef05ef1e2b46cc16c5b0dcb361ce8c9c2e3a66e2. |
22:57 | |
lizmat | jdv: will look at the other one tomorrow | 22:58 | |
sleep& | |||
vrurg | lizmat: that what I meany by having a module in lib/ | 22:59 | |
*meant |