|
Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
00:19
Pe_Elle left
00:33
Pe_Elle joined
01:36
Pe_Elle left
01:46
Pe_Elle joined
02:29
Pe_Elle left,
Pe_Elle joined
05:28
Pe_Elle left
05:40
Pe_Elle joined
05:45
Pe_Elle left
05:50
Pe_Elle joined
|
|||
| librasteve | that’s a fair point … there are a lot of things going on in the your codebase (database start, for example) that may mean the slow loop has a different cause | 08:03 | |
| tbh my suggestions are simply suggestions since I am it sure if zef / precomp will defeat the crotmp directory compile step and I have not really got my head around that | 08:04 | ||
| otoh, cro (and raku) does not have much track record and i imagine that this is a concern for most devs, so I am sure there is some goodwill from the maintainers to try and improve this … for example crotmp s can be added incrementally to a template repo and maybe it would be possible to refactor the cro run / build code to avoid rebuilding stuff (like a precomp for crotmps) | 08:08 | ||
| ideally you would be kind enough to write that for us an submit as a PR for us to review ;-) | |||
| otherwise, please could you try some primitive profiling as I have described (eg put some say now - $start commands at key places in the code) to (i) pin this down to crotmp compilation and (ii) provide a code benchmark for our testing … let me know when this is done and I can fork your repo and raise it as an issue over at the cro repo | 08:13 | ||
| if my guess is correct this is quite a deep change so it could take some time for enough frustration and tuits to get it done … but my feeling is that this is important factor to make raku and cro more useful to web devs so it will be worth it | 08:16 | ||
| please can you state your hardware / os version and raku version in your issue | 08:36 | ||
|
10:04
Pe_Elle left
10:06
Pe_Elle joined
10:10
Pe_Elle left
10:15
sena_kun joined
10:23
Pe_Elle joined
11:24
Pe_Elle left
11:41
Pe_Elle joined
12:44
Pe_Elle left
13:00
Pe_Elle joined
14:01
Pe_Elle left
14:16
Pe_Elle joined,
sena_kun left
14:18
sena_kun joined
14:20
Pe_Elle left,
Pe_Elle joined
|
|||
| aruniecrisps | @librasteve yea the reason i'm saying this is that rails and phoenix don't have this problem at all, and i was showing cro to a friend of mine who works primarily in ruby/rails and elixir/phoenix, and he basically said the reload times are absolutely unacceptable | 14:50 | |
| like this is going to a be problem if we want web devs to try out raku and cro | 14:51 | ||
|
16:48
Pe_Elle left
17:04
Pe_Elle joined
17:08
Pe_Elle left
|
|||
| lizmat | wondering if it is trying to re-precompile everything at every startup? | 17:10 | |
| aruniecrisps could you try setting: RAKUDO_PRECOMPILATION_PROGRESS=1 | 17:11 | ||
| if it is not re-precompiling, then you shouldn't see a difference | |||
| if it does, it will report what it is pre-compiling (again, potentially) | |||
|
17:36
Pe_Elle joined
17:41
Pe_Elle left
17:55
Pe_Elle joined
18:33
Pe_Elle left,
Pe_Elle joined
19:06
Pe_Elle left
19:22
Pe_Elle joined
19:27
Pe_Elle left
19:56
Pe_Elle joined
20:02
Pe_Elle left
20:16
Pe_Elle joined
20:22
Pe_Elle left
|
|||
| patrickb | lizmat: Do you think doing code gen with RakuAST instead of compiling dynamically created strings would help? (And how much?) | 20:36 | |
|
20:52
Pe_Elle joined
20:57
Pe_Elle left
21:24
Pe_Elle joined
21:28
Pe_Elle left
|
|||
| SmokeMachine | is there a way to, from inside the request handler, access the route-set used to create that handler? | 21:54 | |
| I mean: route { get -> { get-route-itself() }} # is there way? | 21:58 | ||
|
22:01
Pe_Elle joined
22:37
sena_kun left
23:04
Pe_Elle left
23:42
Pe_Elle joined
23:46
Pe_Elle left
|
|||