Documentation Channel for #raku | This channel is logged | Roadmap:
Set by [Coke] on 23 May 2022.
04:09 rf left 09:31 sena_kun joined
tbrowder can someone please show the link for the test doc site? 12:36
my table maker prog has been added to PR #4207 12:39
sena_kun tbrowder, I believe is it 12:49
[Coke] that is finanalyst's personal setup. is the one that is now on CI and will eventually go live 13:06
I think it had a 30m update window.
13:24 rf joined
tbrowder thnx, i see it. 13:50
[Coke] tbrowder: in the script, can the HLL::Grammar contents be pulled dynamically from the running raku ? 13:52
tbrowder no, not yet, but if pulling from the static 13:53
[Coke] also added a note on ticket about inserting a pod comment when building the page 13:54
Looks good, can probably pull in before go live.
coleman: Anything left on infra blocking go live?
tbrowder you mean pulling from the static src file? or via a live grammar?
[Coke] I think syntax highlighting was the one big thing.
tbrowder: I meant the running raku, not the source, but we already have an xt/ test that uses RAKUDO_SRC, so we can do the same if that makes it easier. (if we pull from source, then it's less worth it, because we still have to *save* the list somewhere... and we are already saving it in the script) 13:56
so if it's hard to do live, probably not worth automating pulling from source.
tbrowder [Coke]: i'm not sure what the "running raku" is. finanalyst's running process? 14:00
i think the script can fairly easily be made to read and use the HLL src without saving the data except in the table src file. or is everything to be dynamic? 14:04
14:15 rf left
[Coke] ... no, the script *running* the utility 14:16
this has nothing to do with the website. 14:17
You have the data hardcoded in the script to generate the page. I'm asking if we can pull the data when running the script instead. The result is still a generated page in the doc repo. 14:18
that generated page is static.
hopefully that's clearer, sorry!
14:19 rf joined
tbrowder yes, i should be able to do that fairly easily. 16:35
um, just to be clear and get my paths correct, you plan to call the script from the doc Makefile? or? 16:48
[Coke] Don't assume the run dir - look at the xt/* tests that have a 'use lib $*PROGRAM...' line that is relative to the raku file. 16:52
You can walk up from util/foo over to doc/.... to get the path you need.
tbrowder ok 16:53
[Coke] (I am doing this right now for some $DAYJOB scripts, so it's fresh in my mind. :) 17:03
17:28 cfa joined
tbrowder so how will the table builder script be launched? by an added execution line to the in a target in the Makefile? 17:44
*to an existing target in the Makefile? 17:50
[Coke] no, someone will run it manually 17:51
so, target in the doc makefile can work for "regen all generated documents"
but doc-website will just get whatever the last generated version is
18:56 sena_kun left 19:21 sena_kun joined
[Coke] I suspect we'll kadd that to the "do this after each release" list 19:55
added to track latest release. 21:20
tbrowder ok, ‘scuse my old brain for not being sure of the final work flow, but i’ll first get the current script working, in its current location, with the HLL::Grammar source instead of the embedded source. then i can fix it for its final planned use case as needed. 21:24
[Coke] yup, that's great- no worries, sorry. 22:32
Geth doc/Unicode_V15: b1e4d99509 | thundergnat++ (committed using GitHub Web editor) | doc/Language/unicode.pod6
Change supported Unicode version

It's kind-of dependent on the VM it's running on though.
doc: thundergnat++ created pull request #4210:
Change supported Unicode version