| 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 | ||
| japhb | .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 :) | ||
| o/ | |||
| 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 | ||
| *modules | |||
| 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 | ||
| lizmat | .oO( .chomp needs an argument: request.target .= chomp("/") ) |
18:05 | |
| 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 | |