21 Jan 2022
jnthnwrthngtn What's the problem? 17:04
I'm pretty sure curl is a bigger codebase than Cro :P 17:05
And also, if you're doing many queries to the same server, you can't take advantage of keepalive and so forth
Also if you need headers etc you'd need to parse stuff. If you want many folks to run it then curl it's universally installed. And so forth. 17:08
I suspect most Cro users aren't reinstalling their Rakudo so regularly as you are, so don't really feel the recompilation pain. :) 17:09
oops, curl *isn't* universally installed
Pretty sure it's one of the first things I end up installing on new Ubuntu installations :) 17:10
lizmat yeah, it's that really... I have no other performance issues... but each rakudo compile takes now well over a minute to re-precompile Cro::HTTP::Client
jnthnwrthngtn *nod*
lizmat which really breaks the flow for me :-(
I guess that just boils down to: we need to make parsing faster 17:11
jnthnwrthngtn Right. I'm not sure there's not to be done on the Cro side about that, really; the dependency chain looks reasonable to me for a fairly full-featured HTTP client 17:12
lizmat It's just that I don't need a lot of the features ?
also, if we could have in process pre-compilation again, that would save already 82 * .15 = 12.3 seconds 17:14
jnthnwrthngtn Maybe not, although a chunk of it is for example because of HTTPS, which these days most folks need
The Log::Timeline bit is maybe the most "why am I paying for this"
It should perhaps lazy-load CBOR for example 17:15
.oO( Why do my modules always end up getting noticed in the wrong ways? )
lizmat also: it feels that any modules at the same top-level should in principle be pre-compilable in parallel ? 17:16
e.g. from Cro::HTTP::Body: 17:17
Precompiling Cro::HTTP::Body
Precompiling Cro::HTTP::Header
Precompiling Cro::MediaType
Precompiling Cro::HTTP::MultiValue
feels like Cro::HTTP::Header / MediaType / HTTP::MultiValue could be done in parallel ?
I guess we need more meta info in the precomp "database" 17:18
jnthnwrthngtn Probably they can be but one maybe has to know the whole tree to know what to do, etc. 17:22
Or at least it's easier to avoid wasted work in-process
lizmat right, and we can't atm
jnthnwrthngtn Home time for me 17:23
lizmat safe travels!
jnthnwrthngtn Yeah, hopefully the snow hasn't turned to ice :)
Skarsnik_ lizmat, http::useragent is not enought? 20:29
lizmat possibly, but then I'd just settle for even less Raku dependencies by calling curl :-) 21:03
Skarsnik_ and yes, precompile time being slow is super annoying, especially if you change a rakumod used by other rakumod. 21:05
lizmat even worse if you recompile the setting... then *everything* needs to be re-pre-compiled 21:06
which is still better than before, because there has been a time when a re-compilation of the setting meant you had to *re-install* all modukes 21:07
Skarsnik_ I also remember pre 6.c with no precomp x) 20 sec when changing a module file? 21:12
or even when chaning nothing but using lot of modules ^^
24 Jan 2022
andinus can i make cro respond to both 'page' and 'page/' ? 16:45
jnthnwrthngtn andinus: I guess you could write a bit of middleware that strips a trailing / off or similar 18:02
before { request.target = request.target.chop if request.target.ends-with('/') } or some such 18:03
before { request.target .= chop if request.target.ends-with('/') } # a bit less repetitive 18:04
.oO( .chomp needs an argument: request.target .= chomp("/") )
andinus thanks that will work 18:53
i'll probably setup a rdirect instead, dicsussion in #raku paste.debian.net/hidden/631747b2/
jnthnwrthngtn Yes; can use a similar approach, just call `redirect` in the `before` with the tweaked url :) 21:32
25 Jan 2022
andinus thanks :) 06:51
say i want to return a specific page on 404, i set `after { content('text/html', $404-page) if .status == 404 };` 07:51
oh, never mind, it works as expected, i thought `content` would eat up the status 07:52
jnthnwrthngtn Yeah, content does something like response.status //= 200, it won't replace an existing status 08:23