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. |
|||
06:58
patrickb joined
|
|||
Geth | cro-http: 47fabdddec | (Jonathan Worthington)++ | 2 files Warn if a `route` block is sunk I recently helped track down a routing problem that was a result of writing one `route` block inside another and forgetting the `include` or `delegate` before it (it was actually an `openapi` block, but same deal). Add a warning to provide a hint, rather that silently ignoring those routes. |
10:01 | |
cro-http: 6f0bcb8495 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files Merge pull request #143 from croservices/warn-on-sunk-route-block Warn if a `route` block is sunk |
|||
cro-webapp: 4237fe7755 | Altai-man++ | 4 files Present the simplest way to handle comments Do not rely on considering things that are not `<` and `>` being literals, instead provide an alternative to parse "-- everything non-greedy before closing `-->`" after the opener `<`. |
10:06 | ||
cro-webapp: 9c03234fb1 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 4 files Merge pull request #49 from croservices/handle-comments Present the simplest way to handle comments |
|||
12:38
ecocode_ joined
|
|||
ecocode_ | Hi. I'm playing with Cro and was asking myself if Cro can generate an openapi yaml file from the routers code ? | 12:40 | |
jnthnwrthngtn | Not *yet*. We can't figure out enough to do that. But...when RakuAST lands and we can inspect the `route` block contents and look inside the handlers to find their `request-body` calls and similar, then it should be possible. | 12:43 | |
Currently it'd only be able to generate a very incomplete openapi spec | |||
ecocode_ | Ok. Thanks for the info. | 12:50 | |
jnthnwrthngtn | I'm quite keen on such a thing because I'd much rather write Raku than a YAML spec :) | 12:51 | |
ecocode_ | Since Cro supports importing routes from openapi, I was thinking that you were doing this the other way around.. | 12:53 | |
So I even started looking for tools to create an openapi spec 😜 | 12:54 | ||
jnthnwrthngtn | At the moment I am doing it that way around, yes | 12:56 | |
There's editor.swagger.io/ which is an online editor for openapi specs | |||
oh, grr, that looks like it's for an old spec version though | |||
oh no, it supports both, yay :) | |||
ecocode_ | Do you use a tool to create the openapi spec? Or you just do it in an text editor ? | 12:58 | |
jnthnwrthngtn | I've used the think I just linked you to, since it at least makes sure the syntax is right | 13:00 | |
*thing | |||
ecocode_ | 👍 | 13:02 | |
jnthnwrthngtn | editor.swagger.io/ | ||
ecocode_ | For now I don't really need the openapi support. But it might be useful later.. so my best option for now is to start from raku routes | 13:05 | |
14:41
ecocode joined
15:26
patrickb left
|
|||
Altreus | hmm raku would be a great target for an openapi module | 15:47 | |
working with specs programmatically doesn't seem to be a highly represented problem in the perl family | |||
jnthnwrthngtn | There already is OpenAPI::Schema that does the parsing of the spec into an object model, which is probably a good start | 15:49 | |
16:38
ecocode_ left
|
|||
Altreus | it does sound good | 17:30 | |
19:01
ecocode_ joined
21:18
ecocode_ left
23:40
japhb left
23:44
japhb joined
|