🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 8 June 2022.
japhb Quibono: There used to be other compilers, such as Niecza and PUGS, but they have not been maintained in a very long time. 00:23
Niecza targeted .NET; PUGS targeted GHC
But after a certain point, Rakudo became the compiler getting most of the effort. 00:24
Quibono Do you know why the other compilers kinda died? 00:29
japhb PUGS: Lead developer became quite sick, and henceforth moved on to becoming a government minister. 00:32
Niecza: IIRC, the lead developer got a $day-job that took all their time.
But it's been a while, so my memory may be fuzzy.
Quibono Gotcha. 00:35
Geth ecosystem: 7aee6125dc | (Geoffrey Broadwell)++ (committed using GitHub Web editor) | META.list
Remove Terminal-Print from p6c

  ... it has been moved to the `zef:terminal-printers` in the Fez ecosystem instead.		 00:40
jdv niecza. blast from the barely but fondly remembered past... 00:46
Guest53 hello 07:02
is anyone else here?
Nemokosch Maybe 07:20
53 is my lucky number 07:21
I'm still thinking what makes HTML::Tag so terribly slow 07:54
and there are things I don't understand
github.com/2colours/HTML-Tag/blob/...akumod#L29 07:55
why does this stuff work _at all_
there is no $!id
lizmat has $.id is rw; 07:57
there *is* an $!id
github.com/2colours/HTML-Tag/blob/...rakumod#L7 07:58
Nemokosch well, why? 07:59
lizmat has $.foo defines a $!foo private attribute *and* creates an accessor method 08:02
Nemokosch ~~somebody could have really valued consistency more~~ 08:06
perhaps it would be more readable if stuff declared with $. could only be accessed with $. and it would resolve to the underlying private variable 08:08
anyway...
this time around, I straight-up murdered this do-assignments stuff 08:10
it's not called from the generic render method
and guess what, that wasn't it
there is no improvement at all apparently
I mean, assignments shouldn't be costly but I suspected there might be a ridiculous number of them
that's not the case apparently 08:11
lizmat ok, for the sake of the argument, could you take out the encode_entities bit and see how that affects performance?
Nemokosch I did that once and I immediately realized an 80% performance boost lol 08:14
but I think there might be other places where it can be removed
so that may be even bigger, let's see...
lizmat ok, then lemme focus on that module
Nemokosch okay - this time around, I'm replacing it with a dummy function that just returns the argument 08:16
and I added do-assignments back
anyway, I'm afraid this won't be a win - because I don't let anything be encoded either way 08:18
I made a HTML::Tag::Raw class that renders as its content 08:19
lizmat ok, so "encode-html-entities" is really the only type of encoding that you need, right?
Nemokosch and I'm using that for literally all my data in the given script 08:20
I'd say even that is too much 😅 I'm not sure what you mean
One thing seems sure: XML::Entity::HTML might be horroristically slow - but that's not the only reason this module is embarrassingly slow 08:22
Is there a tool by any chance that can monitor calls? 08:23
lizmat raku --profile
if you could get the code to run for up to a second or so in a single thread 08:24
otherwise the generated HTML becomes too large for browsers to handle
Nemokosch 😂 08:25
then I'm gonna use raku --profile for generating HTML, instead of HTML::Tag
🤣
lizmat hehe
Nemokosch yes, in my current script, encode-html-entities is not called at all 08:27
everything I generate is raw, and this isn't only for performance - the unofficial REST API I'm using gives back HTML fragments (sometimes even XML) because they wanted to help the browser anyway 08:28
of course it would be nice to get encode-html-entities performant, but again, that in itself won't save this module 08:29
and I started suspecting encode-html-entities might be too slow because of Raku's trans method 08:30
it doesn't seem to do much besides calling trans 08:31
lizmat I just had a look at Str.trans, and it could use some TLC now with new-disp developments and all
but that would also be marginal I'd say
Nemokosch is there something I'm missing about XML::Entity::HTML? or is it really just one object allocation and then calling trans, pretty much 08:33
lizmat well, it schlepps in all of XML 08:34
but from a cursory look at the code, yes, pretty much
Nemokosch that's definitely inconvenient but I don't think it should be a cost for every single call made, importing the XML module that is 08:35
lizmat what I see with ,trans is that it is building a hash for *each* call, with the given lookips 08:36
*lookups
Nemokosch I couldn't bet how much that holds the performance back but yes, that's definitely overkill 08:39
that hash might be magnitudes bigger than the string to transform
lizmat indeed
there's also github.com/Mouq/HTML-Entity 08:41
but that also uses trans 08:42
ok, lemme take some code from XML::Entity::HTML and whip that up into a HTML::Entity::Fast
Nemokosch You know, I replaced HTML::Entity 09:20
because it's a pre-christmas module
even the module format is obsolete
it doesn't install with zef 09:21
RaycatWhoDat Hey, all. 10:47
RaycatWhoDat I might have found a bug with set equality but I want to float it by y'all to make sure I'm not crazy. 10:48
RaycatWhoDat glot.io/snippets/gbwxz5e06i 10:48
Given that snippet above, is it correct to expect each assignment to be False? 10:49
RaycatWhoDat condition* 10:49
lizmat m: dd "abba" (==) "abbba" 11:07
camelia Bool::False
lizmat m: dd "abba".comb.Set (==) "abbba".comb,Set
camelia Bool::True
Set
lizmat m: dd "abba".comb.Set (==) "abbba".comb.Set
camelia Bool::True
lizmat m: dd "abba".comb.Set (==) "abbba".comb
camelia Bool::True
lizmat at least the left hand side will have to be made a Set otherwise it will just compare two lists
Nemokosch I think the behavior was nice 11:08
lizmat m: dd <a b b a> (==) < a b b b a> # what is happening effectively
camelia Bool::True
lizmat ah?
hmmm
intriguing 11:09
Nemokosch: github.com/lizmat/HTML-Entities-Fast on its way to the ecosystem 11:10
tellable6 lizmat, I'll pass your message to Nemokosch 11:11
lizmat m: dd "abba".comb (==) "abbba".comb 11:19
camelia Bool::True
lizmat hmmm
RaycatWhoDat: correction, the last one should indeed be True 11:20
it already coerces the left hand side to Set
RaycatWhoDat That's a bit different than my understading of the operator 11:21
Should `(==)` return True if the sets are identical? 11:22
Shouldn't*
OH.
I see what you mean. 11:23
In that case, is there a better, duplicate-respecting way to compare two Seqs?
maybe... 11:25
m: dd "abba".comb.Bag === "abbba".comb.Bag 11:26
camelia Bool::False
RaycatWhoDat m: dd "abba".comb.Bag (==) "abbba".comb.Bag
camelia Bool::False
RaycatWhoDat Those two work, it seems 11:27
Cool, cool. Thanks for the clarification.
lizmat m: m: dd "abba".comb.Bag === "abbba".comb 11:29
camelia Bool::False
lizmat m: m: dd "abbab".comb.Bag === "abbba".comb
camelia Bool::False
lizmat m: m: dd "abbab".comb.Bag === "abbba".comb.Bag
camelia Bool::True
lizmat hmmm
m: m: dd "abbab".comb.Bag (==) "abbba".comb
camelia Bool::True
lizmat m: m: dd "abba".comb.Bag (==) "abbba".comb
camelia Bool::False
lizmat yeah, you don't need to .Bag the right hand side if the left side is a Bag 11:30
it will allow it to shortcut on mismatch
ugexe i wonder if it would be useful to have ENV vars for setting the paths of the named repos i.e. site/home/etc. particularly for doing e.g. RAKUDO_SITE_REPO_PATH="" RAKUDO_HOME_REPO_PATH="" etc (since disabling repos this way effectively allows one to control the entire repo chain to have a totally self contained app module location) 16:47
tbrowder ugexe: +1 22:55
Quibono So is there interest in alternative compilers/more backends? 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!