Skip to content

Cache generated documentation #717

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Altai-man opened this issue Jul 18, 2016 · 13 comments
Closed

Cache generated documentation #717

Altai-man opened this issue Jul 18, 2016 · 13 comments
Labels
big Issue consisting of many subissues meta RFCs, general discussion, writing style, repository organization, etc. pod issues affected by Raku pod processing

Comments

@Altai-man
Copy link
Member

Figure out a way to cache and update the documentation registry, and when to or not to regenerate individual pages.

This seems not so hard. We can just take a hash(even simple will be fine, faster is better) for every file, gather it in something like hashes.txt, then while building we check every page for a change of hash and re-generate/pass. We must, of course, update hashes.txt if some page was re-generated.

This issue is a part of TODO.

@Altai-man
Copy link
Member Author

I thought about it for some time, so if my description above is good enough, I'm ready to assign myself for this issue.

@zoffixznet
Copy link
Contributor

zoffixznet commented Jul 18, 2016

Is there a way to do it cleanly, though? For example, I see /todo.html page is generated during build and it's not a separate file in the source.

So, if we add the cache and I go and modify /testing POD. Will it now be smart enough to know to remove /todo.html?

@Altai-man
Copy link
Member Author

I suppose - no.
If we have dynamic pages(and we have them, obviously), then we should keep something like dependency graph, which is not so simple.

But plain hash system(without dynamic pages) will cover many cases when you just want to change, for example, Operators.pod and re-generate only Operators.html, not all in the world types/exceptions/etc.

If someone willing to help with dependency graph, it's great, of course.

@AlexDaniel
Copy link
Member

Sounds like a good start.

@Altai-man Altai-man self-assigned this Jul 19, 2016
@Altai-man
Copy link
Member Author

Basic implementation can be seen and tested here - #725

@JJ
Copy link
Contributor

JJ commented Mar 15, 2018

#725 was rejected. Is this going to to proceed in any way?

@Altai-man Altai-man removed their assignment Mar 15, 2018
@Altai-man
Copy link
Member Author

Not sure about this one. The main idea is that you do not want to re-generate all pages if you fixed a typo in a single one.
With dynamic site / documentation database, this ticket seems redundant to me(but we do not have one yet).

@JJ
Copy link
Contributor

JJ commented Mar 15, 2018 via email

@Altai-man
Copy link
Member Author

Re-open if needed.

@JJ JJ reopened this Jan 19, 2019
@JJ
Copy link
Contributor

JJ commented Jan 19, 2019

I'm reopening this since, as part of the #2392 , this is probably one of the most important things to do.

@JJ
Copy link
Contributor

JJ commented Feb 3, 2019

See also #2542

@JJ JJ added the site label May 28, 2019
@JJ JJ added big Issue consisting of many subissues meta RFCs, general discussion, writing style, repository organization, etc. pod issues affected by Raku pod processing labels May 28, 2019
@Altai-man
Copy link
Member Author

@JJ the Pod is already cached with help of Documentable++, I am somehow sure this can be closed now. Is there anything preventing closing?

@JJ
Copy link
Contributor

JJ commented Jan 3, 2020

Let me check and find a suitable thing to do so that it can be closed from a commit.

@JJ JJ closed this as completed in 107da69 Jan 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big Issue consisting of many subissues meta RFCs, general discussion, writing style, repository organization, etc. pod issues affected by Raku pod processing
Projects
None yet
Development

No branches or pull requests

5 participants