Clojurians Log v2

I liked your approach of adding start-watcher-for-changes! to handle more-than-zero argument callbacks.

I have been thinking about a non-inconsistent incremental compilation but I am afraid it would make the code unnecessarily complex. I we simply filter out unchanged posts/pages - which will also affect tags, archives, etc. So I would need not to remove them but keep them but without the parsed content and only later, when they are written, skip that if there is no content. So it is doable but it goes against the current assumptions in the code and could be confusing and a potential source of bugs. So unless people insist it is essential, I would prefer this simple and dirty solution, that requires a full build before publication. I now print this at the end of compilation, in yellow: > generating filtered rss > --> /cryogen.xml > BEWARE: Incremental compilation, things are missing. Make a full build before publishing. > "Elapsed time: 1314.637696 msecs"

The warning is a good compromise. From my limited knowledge, it seems to me that there are 3 disjoint kinds of changes on a page: (1) Only "normal" textual content. Just changing the words on the page. In that case, just recompiling that one page should leave everything consistent. (2) changes in tags. That should only need recompilation of the page and the tags page(s). (3) Linking content (e.g., date, title, file name or URL) changes. All these changes potentially impact how that page is referenced from other pages. In this case, it is likely necessary to find out all the other pages that reference this page and recompile them as well. If I've missed other kinds of changes, or there are flaws in my reasoning, please let me know. If we can easily determine whether the changes are of type (1) or (2) then we can do a limited recompilation and still be consistent. For now, if the changes are type (3) changes, we just recompile everything. That should handle the most common cases of just changing the page content or tags, and still keep the whole in a consistent state. The key, obviously, is whether there is an easy way within the current code of determining whether the change is of type (1) or (2). I don't know enough to say.

It certainly is possible. But is it necessary? The only reason I see for the incremental compilation when you are working on a single page / post (ie type 1 change) with frequent changes and want to see those ASAP. The goal here is not a complete, flawless result (build) but quick feedback on the "unit under work". In other words, it is a development utility, not a faster publication tool.

@carmen can we perhaps get ☝️ merged as is, as a minimal implementation, and improve the algorithm if necessary based on real-world feedback?

Just switched http://corfield.org over from Octopress/Jekyll to Cryogen and I'm loving it so far. I noticed the default RSS feed is feed.xml -- because someone complained that I used to have atom.xml on my old site -- so I changed :rss-name to "atom.xml" but then I wondered about the format... looking at the generated file, it does appear to be RSS2/Atom anyway (good). Is there a reason that the default :rss-name is "feed.xml"?

Also, it would be great if certain parts of the site could be excluded from the sitemap.xml (I have a bunch of legacy HTML content that is linked from other sites that I don't want indexed otherwise). I guess I could add a robots.txt file manually but it would be nice to have Cryogen omit certain directories from the sitemap.xml -- it currently just uses :ignored-files but changing that would affect other parts of Cryogen and also the code only ignores files by .getName so any directories are not considered. Any suggestions for how best to approach that? Override parts of Cryogen locally by copying namespaces, submit a PR to make this more configurable?

(so this channel will get mirrored to Zulip Clojurians -- unless anyone objects?)

@holyjak sounds good to me. Btw I was wondering if you know how to pass extra args to the lein-ring plugin? I was thinking it might be nice to put this feature behind a flag. Personally, I don't need faster compilation because I don't blog very much. I looked around the lein-ring docs and code and I couldn't find a way to do this.

@seancorfield happy to hear the positive feedback! Hopefully the migration was relatively painless? > Is there a reason that the default :rss-name is "feed.xml"? There's is no reason... 🙂 Re: sitemap stuff I'd go with the "make this more configurable" route. The change should be straightforward (new key in config.edn, etc)

Since the sitemap generation relies on find-assets and ignore, it seems like quite a bit of the plumbing would need to be touched.

Oh really? Clearly I haven't looked at the code in a while 😅

Well, I guess sitemap/generate could just filter the result of find-assets which would avoid pushing changes further down the tree...

Yeah, the filtering doesn't necessarily have to happen inside find-assets

I'll set up a PR for discussion, if that's ok @carmen?

Yes, thank you @seancorfield!

I don't. An option are env variables. But existing users will not be affected and new ones may simply replace start-watcher-for-changes! with start-watcher! to opt out. Why would you use serve anyway if not only while writing a post? Notice that the first serve always build everything, as does simple run

https://github.com/cryogen-project/cryogen-core/pull/150

FYI for the asciidoctor users out there, I am going to add support for asciidoctor macros - you will register in config.edn :asciidoctor :macros <name> <macro fn symbol>.