fermyon / bartholomew Goto Github PK

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• title STRING changes string to Title Case
• untitle STRING removes title casing: HELLO World becomes hELLO world (Not sure if we want this one)
• repeat COUNT STRING repeat the string COUNT number of times
• substr START END STRING. Given a string, start at index START and capture a string that ends at END
• nospace STRING removes internal spaces from a string. h e l l o becomes hello (Not sure if we want this one)
• abbrevboth LEFT_OFFSET MAX_LEN STRING offsets LEFT_OFFSET from the left, and then truncates the string to MAX_LEN, using ... on both sides. (The sprig docs explain this a little better)
• initials STRING take the first letter from each word in a string, and return those letters as a string: Hello World becomes HW
• camel_case, snake_case, kebab_case and swap_case were all useful in Sprig... optional to implement here, too

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• list A B C returns a list of [A, B, C]
• first LIST returns the first item in a list
• rest LIST returns all but the first in a list
• last LIST returns the last item in a list
• initial LIST returns all but the last in a list
• append ITEM LIST appends an item to end of a list (not sure if this one makes sense to add)
• prepend ITEM LIST appends an item to start of a list (not sure if this one makes sense to add)
• concat LIST LIST concatenate two lists into one list
• reverse LIST reverse the order if items in a list
• uniq LIST remove duplicates form a list. uniq [1, 1, 1, 2, 2] produces [1, 2]
• without ITEM LIST removes ITEM from the list
• has ITEM LIST returns boolean true of the item is in the list
• compact LIST removes empty items from a list (I think rhai has a definition of empty that we could use here)
• slice START END LIST extract START-END from a list and return it
• chunk SIZE LIST chunk a given list into a list of lists, each no larger than SIZE

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

Some math functions that we could implement. Not sure if we need int and float variants, or if the JSON numeric type works

• add
• add1
• sub
• mul
• div
• mod
• max
• min
• floor
• ceil
• round
• randInt

We have a logo on Fermyon.com. We just need to drop it in here.

Getting a really annoying compilation error when trying to compile Bart on Ubunto 20.04 WSL:

Command:

jdbohrman@DESKTOP-HSLE200:~/fermyon.com/content/blog$ cargo build --release
...
   Compiling toml v0.5.8
   Compiling handlebars v4.2.2
   Compiling handlebars_sprig v0.3.0
   Compiling bartholomew v0.2.0 (/home/jdbohrman/bartholomew)
...
error: linking with `cc` failed: exit status: 1

         collect2: error: ld returned 1 exit status
          
  = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `bartholomew` due to previous error

I've tried installing things like build-essential and gcc-multilib to no avail.

When cloning & building the Bartholomew Command Line Interface (CLI) on Windows, using the make bart command, the following error is encountered.

error LNK2019: unresolved external symbol __imp_wasi-outbound-http_request referenced in function
error LNK2019: unresolved external symbol __imp_outbound-pg_query referenced in function
error LNK2019: unresolved external symbol __imp_outbound-pg_execute referenced in function
3 unresolved externals
error: linking with `link.exe` failed: exit code: 1120

Had a chat with @itowlson (thanks Ivan) and it appears that we could/should take Bartholomew functionality which is fundamentally designed to compile to Wasm (any features intended to be used within Spin) and create a new [server] feature set in Bartholomew source code.

The separation of these features will allow the implementer of Bartholomew server to specify the use of the [server] feature set when building the Bartholomew.wasm. But will also allow the user of the CLI to build the CLI (without the CLI build process linking features not essentially to the CLI's intended operation).

Hope this makes sense.

Once this is done, we can go ahead and build the binary executable for Windows and close out #94 as well.

Please let me know if you need any more error messages or info.

I'm seeing the following when I run make in this project:

$ make
cargo build --target wasm32-wasi --release
error: failed to parse manifest at `/Users/vdice/go/src/github.com/fermyon/bartholomew/Cargo.toml`

Caused by:
  namespaced features with the `dep:` prefix are only allowed on the nightly channel and requires the `-Z namespaced-features` flag on the command-line
make: *** [build] Error 101

Not sure if an update/upgrade to my local rust/cargo env is necessary -- or if an update to this project's Makefile/Cargo.toml is due.

@rajatjindal mentioned setting up a goodfirstissue bot. He pointed to these: https://github.com/rajatjindal/goodfirstissue, https://github.com/apps/goodfirstissue and https://twitter.com/goodfirstissue

I created the label, but we would also need to set up a bot.

Currently, the documentation for the functions provided by handlebars-sprig does not seem to be sufficient. I think a new section must be added to either the templates page or a new page must be created for these helper functions.

wasm-opt from https://github.com/WebAssembly/binaryen/releases can be used to optimize the size of the resulting binary — in my local tests, from 4.8M to 4.1M.

We should perform the default optimization pass before uploading the asset.

Can we add an option to support Content-Encoding with gzip support?

This shouldn't require a change to Wagi. But it might require a fairly major rewrite of Bartholomew. Instead of printing directly to STDOUT, we'd have to print to an output stream that is wrapping a gzip writer. Then we would have to flush the gzip writer to stdout.

We'd also have to write the extra Content-Encoding: gzip header.

Right now, we don't have a lot of themes that are compatible with Bartholomew.

There is the Bartholomew site template, and the Fermyon docs template, but trying to refactor a site to change the theme can be tricky.

We could reorganize the Bartholomew directories to allow pulling a submodule in a say themes/ directory, then controlling the used theme from site.toml.

This would mean allowing both user- and theme-defined templates and scripts, and there should be a pre-defined lookup order.

The documentation website contains information about features not part of the current release (eg) themes, and request headers in the template. There are currently no breaking changes. Should a new release be created?

The 'fermyon/bartholomew' repository doesn't contain the 'static/bartholomew-screenshot.png' path in 'main'.

It would be very useful to have an implode(list<string>) command.

Example:

implode ", " page.head.tags

Above would produce tag1, tag2, tag3

We should probably add badges to this repo to things like:

• Discord
• Youtube
• Twitter
• Build Status
• Software Security Status
• Etc

Currently, every page has the access to site.pages which provides a list of pages on the site. This indexing leads to considerable performance hits on pages that do not use site.pages. Based on some initial testing, just making the indexing optional leads to considerable performance gains on pages that do not index it.

Two potential options to enable indexing

1. A new field index_site_pages is added to the page head and must be set in documents for pages that would need access to the site.pages list.
2. Use site.toml in configs to list templates that would require the site.pages list. This option would potentially be easier for the user as they just need to set it once per template.

Without indexing

Bombarding http://localhost:3000/ with 1000 request(s) using 1 connection(s)
 1000 / 1000 [========================================================================================================================================================] 100.00% 293/s 3s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec       300.64      22.59     360.33
  Latency        3.33ms   296.84us     8.22ms
  HTTP codes:
    1xx - 0, 2xx - 1000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     6.79MB/s

With indexing

Bombarding http://localhost:3000/ with 1000 request(s) using 1 connection(s)
 1000 / 1000 [========================================================================================================================================================] 100.00% 199/s 5s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec       206.64      27.21     263.35
  Latency        4.84ms   752.72us     9.33ms
  HTTP codes:
    1xx - 0, 2xx - 1000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     4.66MB/s

This would again cause a breaking change but is easily addressable by just adding a tag on either site.toml or the content files.

Any thoughts?

Let's update the current release workflow to add automated generation of the checksums file which we can include on the created GH release.

Then we can slim down the release process doc.

Potentially silly question but where is the pre-built bartholomew.wasm located?

Per the discussion in fermyon/spin#426, Bartholomew currently has trouble with relative links in Markdown content. Making them non-relative fixes Bart but breaks browsing those links in GitHub and elsewhere, whereas making them relative fixes GitHub browsing but breaks Bart.

Therefore, Bart should handle relative links correctly, translating them to the appropriate HTML URIs automatically instead of expecting a certain format in the source Markdown file.

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• wrap COUNT STRING Wrap text at a particular length (line ending: \n)
• wrap_with COUNT ENDING STRING Wrap STRING using ENDING as the line ending. e.g. wrap_with "<br>" some_text will use <br> instead of a line break
• contains SUBSTRING STRING returns boolean true if SUBSTRING is contained within STRING
• has_prefix PREFIX STRING returns boolean true if PREFIX is found at the beginning of STRING
• has_suffix SUFFIX STRING returns boolean true if SUFFIX is found at the end of STRING
• cat STRING... Concatenates the given strings with spaces in between. cat "hello" "world" becomes hello world
• indent COUNT STRING indent the string COUNT characters
• nindent COUNT STRING add a new line and indent the string COUNT characters, (might not need this... it was originally really for YAML formatting)
• replace TARGET REPLACEMENT STRING Replace all instances of TARGET with REPLACEMENT in the STRING
• shuffle STRING randomly reorder the characters in STRING

Currently the bart cli release asset is for linux amd64 but its name doesn't signify this. Consider updating the name to add the arch extension... and perhaps add other arch combos 😉

When running the .wasm module compiled from head with spin compiled from head as well, using tweet in templates leads to a crash.

Bartholomew commit

$ git log --pretty=format:'%h' -n 1
fe4a8f0

Inserting tweet embed in templates using

{{{ tweet "fermyontech" "1504846517571489794" }}}

results in

2022-08-25T13:34:20.417519Z ERROR spin_http_engine: Error processing request: wasm trap: wasm `unreachable` instruction executed
wasm backtrace:
    0: 0x2f86a6 - panic_abort::__rust_start_panic::abort::h7e7eb72c39986e70
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/panic_abort/src/lib.rs:84:17
              - __rust_start_panic
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/panic_abort/src/lib.rs:37:5
    1: 0x2f8141 - rust_panic
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:746:9
    2: 0x2f80be - std::panicking::rust_panic_with_hook::h5af4a166307aff48
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:716:5
    3: 0x2f7324 - std::panicking::begin_panic_handler::{{closure}}::h42a9871ead2de5e8
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
    4: 0x2f7263 - std::sys_common::backtrace::__rust_end_short_backtrace::h42a6bde96d4a4a1f
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
    5: 0x2f7a0e - rust_begin_unwind
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
    6: 0x303aa8 - core::panicking::panic_fmt::h33d7d4c3033d60da
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
    7: 0x30c9c7 - core::result::unwrap_failed::h5d36bed23403009b
                    at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/result.rs:1805:5
    8: 0x6eb0e - <unknown>!<handlebars_sprig::tweet::addhelpers::tweet as handlebars::helpers::HelperDef>::call_inner::hfa56b93483603fc2
    9: 0x6dda2 - <unknown>!handlebars::helpers::HelperDef::call::hd2e59b5adfe7095f
   10: 0xa059e - <unknown>!handlebars::render::render_helper::h8b63e1640a9bc7b4
   11: 0x9f1e3 - <unknown>!<handlebars::template::TemplateElement as handlebars::render::Renderable>::render::h833a9e76d78f6162
   12: 0x9ec5f - <unknown>!<handlebars::template::Template as handlebars::render::Renderable>::render::h5e70041664eb9743
   13: 0x46abf - <unknown>!handlebars::registry::Registry::render::h171ee92c86c34fc1
   14: 0x4c088 - <unknown>!bartholomew::template::Renderer::render_template::h34889982b6d70190
   15: 0x346c4 - <unknown>!<bartholomew::bartholomew::SpinHttp as bartholomew::bartholomew::spin_http::SpinHttp>::handle_http_request::h496cf62464b95d45
   16: 0x22dae - <unknown>!handle-http-request
   17: 0x315738 - <unknown>!handle-http-request.command_export

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• default DEFAULT_VALUE TEST If TEST is not truthy, return the DEFAULT_VALUE. https://masterminds.github.io/sprig/defaults.html
• empty TEST if TEST is "empty", return boolean true, otherwise return false
• all_empty A B C returns boolean true if all of the varargs are empty (OPTIONAL. Not sure if we need)
• all A B C returns boolean true if all of the varargs are non-empty (OPTIONAL. Not sure if we need)
• any A B C returns boolean true if any of the varargs are non-empty (OPTIONAL. Not sure if we need)
• coalesce LIST return the first non-empty item in the list. Extra good: if we can do Sprig's coalesce A B C.... with varargs, returning the first non-empty arg
• ternary TRUE_VAL FALSE_VAL TEST If TEST is true, return TRUE_VAL, otherwise return FALSE_VAL

Considering it is embeddable in Rust, can I use Gluon instead of Rhai?

https://github.com/gluon-lang/gluon

cc @flynnduism

Hi,
A couple of tasks which can be achieved now that the official Bartholomew documentation is live (public).

• Reduce the amount of pre-existing technical documentation in Bartholomew's README.md file.
• Transfer technical content like commands, instructions on how to install/use and so forth, to the official docs site [1].

This will provide a single-source-of-truth approach for us and reduce effort (only update documentation in 1 place, as the software evolves). Thanks @vdice for the feedback/comment @ #77 (comment)

I have assigned myself buy please anyone feel free to jump in with any ideas/comments/feedback i.e. thanks @karthik2804 for pointing out the binary release point the other day @ #93 (comment) that comment was useful and thought provoking.

I have been meaning to ask this question since I started looking at bartholomew. Leaving my imposter syndrome behind, I thought i will ask this question anyways.

Is there a preference of css framework that we use?

tailwindcss is really popular these days and I personally use it as well and love it.

is that something we want to consider changing in bartholomew or just leave it to users to use what they like?

Add a step on contribution guide to run tests using make test to make sure that the build tests pass.

A recent note from @karthik2804 spoke about config.

"The enable_shortcodes is defined only on each .md file but not in the site.toml file. The corresponding entry in the code block above needs to be deleted as well. Those entries actually belong on markdown.md."

I believe this means removing the following lines from the site's overall configuration documentation (the configuration.md)

I am then wondering should the above configuration then be added to the markdown.md's page where the TOML is mentioned for pages and posts. Not 100% sure, @karthik2804 perhaps you can chime in.

Also if there are any other config related changes, please let me know and we can do a single PR for config.

Thank you
Tim

I miss the concepts of shortcodes from Hugo and others. I think it would be straightforward to implement this in Bartholomew by running the markdown through the handlebars rendering engine before running it through the markdown rendering engine.

as an example I might want an alert in my blog post warning people of a potentially destructive action.

{{ alert "danger" "This might eat your data" }}

This would execute the script called "alert.rhai" with the two strings as parameters. The execution of the script would return html that would then be passed through to the markdown renderer.

Thoughts:

• The output would have to have no html entity escaping.
• We can share the script directory used by the templates, or for more clarity, create a new markdown-only script directory

Security considerations:

• This introduces all sorts of dangerous injection vectors. Should it be disabled by default? Caveat Emptor?
• we could manually strip out <script> tags, but that might be a useful bit of functionality to keep too
• It might end up being a case where documentation is the best option and we trust the end user to inform themselves and protect against untrusted content sources

I have a prototype of this functionality that works today I'll be sending as a PR. It needs careful review.

Thanks for building Bartholomew!

It could be very helpful if content could be rendered from a remote host. I'm imagining something like:

content_url = "https://raw.githubusercontent.com/fermyon/bartholomew/main/docs/content/"

We've had a few distinct errors parsing the date field in the page header:

• for date = "2022-03-14":

TOML parsing error: input is not enough for unique date and time for key `date` at line 3 column 8

• for date = "2022-03-14T00:22:56Z" (on Windows, not exactly sure what the issue is here, the error is very NOT helpful):

`Error rendering "content_top" line 30, col 54: date_format helper: Couldn't convert parameter date to type DateTime < Utc >. It's Null as JSON. Got these params: [PathAndJson { relative_path: None, value: Constant(String("%Y-%m-%dT%H:%M:%SZ")) }, PathAndJson { relative_path: Some("page.head.date"), value: Context(Null, ["page", "head", "date"]) }]`

While working on #91, I noticed that the content body of every .md file is parsed on every request. This induces a potential performance hit. I feel like this could be an area for performance optimization of the rendering process as I think it is unnecessary to parse the markdown content of files other than the one that is requested. The required details for the post can be obtained from the header.

I realize that this would disrupt the way in which the posts in a blog would be listed where the content appears below the title but I feel like it is a problem that can be solved by using the description in the head. One compromise would be to only parse the markdown if the head.description is empty.

Any thoughts?

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• until COUNT generate a list of integers from 0 to COUNT.
• until_step COUNT STEP generate a list of integers from 0 to COUNT incrementing by STEP
• seq described here OPTIONAL... not sure we need it. Or maybe we need this and not until...

I'm trying to build the bart binary from source but the prescribed make command fails, and it's unclear what is going wrong that I need to fix.

The docs state the following steps for building:

% git clone https://github.com/fermyon/bartholomew.git
% cd bartholomew
% make bartholomew

which results in

make: *** No rule to make target 'bartholomew'.  Stop.

I don't think make bartholomew is the right make command based off this previous [issue comment https://github.com//issues/61#issuecomment-1092467847] by @radu-matei . I'm pretty sure it should be make bart. However the results there are still odd.

% make bart
cargo build --release --manifest-path=bart/Cargo.toml
    Finished release [optimized] target(s) in 0.55s

Calling bart obviously results in the following:

zsh: command not found: bart

It strikes me as odd that the cargo commands from make bart build so quickly. Also, is the build target supposed to be a bin or a wasi file? I'd think it would be a bin since i need to execute that, but i cant find the bin in the target directory after calling make.

In case it helps with debugging here's a little information on the host I'm running this from

Linux version 5.19.2-arch1-2 (linux@archlinux) (gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39.0) #1 SMP PREEMPT_DYNAMIC Sat, 20 Aug 2022 16:11:19 +0000

And I do have spin installed from main.

% spin --version
spin 0.5.0 (c3bbfeb 2022-09-02)

when we run make serve, it uses docs/spin.toml, which points to the bartholomew.wasm under docs/modules/bartholomew.wasm

we should probably have it use target/wasm32-wasi/release/bartholomew.wasm

Attempting to load test Bartholomew results in an IO error because of the too many files opened:

$ make serve
Ready: serving on 127.0.0.1:3000
Jan 09 22:24:35.879 ERROR hyper::server::tcp: accept error: Too many open files (os error 24)

$ bombardier http://localhost:3000/blog
Bombarding http://localhost:3000/blog for 10s using 125 connection(s)

  Errors:
       timeout - 77
    dial tcp 127.0.0.1:3000: connect: connection reset by peer - 25
    the server closed connection before returning the first response byte. Make sure the server returns 'Connection: close' response header before closing the connection - 22
    write tcp 127.0.0.1:58154->127.0.0.1:3000: write: broken pipe - 1

The actual Hyper error doesn't happen all the time, but the increased latency is noticeable even with fewer concurrent connections.

(Update: this might also be an issue with my local setup, which might very well be the case, I'm getting all sorts os weird errors after an update...)

We currently have a bart CLI release binary for Linux — we need to add for Windows and macOS as well.

Should we align versioning between the bartholomew.wasm module and the bart CLI?

Currently the former is at 0.3.0 while the latter is at 0.1.0.

Confusion can result since both are currently included as artifacts for a given release of this repo, eg v0.3.0, yet the bart CLI will give a different version. So, when a user is checking their CLI version to see if it is the latest, the signal is muddied.

Per @rajatjindal's suggestion, it would make a lot of sense to implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• trim STRING removes whitespace off both sides of the string
• trim_all SUBSTRING STRING trim SUBSTRING from both sides of the string. Example: trim_all "$" "$4.00$" should return "4.00"
• trim_suffix SUFFIX STRING trim SUFFIX string off of the back of a string.
• trim_prefix PREFIX STRING trims PREFIX from the front of the string

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

• explode SEP STRING (or we could call it split and change implode to join) Separate a string into a list of strings by splitting at the SEP
• explode_n SEP COUNT STRING Split string on separator, but only up to COUNT times
• sort_alpha VEC<STRING> sort a list of strings in lexicographic (alphabetical) order

The information on using the CLI doesn't really show people how to actually use and install the CLI. I can take a stab at it also once there's a broader discussion.

Spin removed support for wasi-experimental-http in fermyon/spin#699.

I believe Bartholomew needs to do the same for compatibility with Spin.

(To be clear, the last v0.4.0 release of Spin is compatible)

For instance, when I try to run the docs site with Spin built from HEAD, I see:

$ spin -V
spin 0.4.0 (232567f 2022-08-22)

$ spin up
Error: unknown import: `wasi_experimental_http::close` has not been defined
Error: exit status: 1

Per #25, implement the Sprig functions for Bartholomew. Rather than file an issue for each function, I figured I'd break these down into small batches. (Note: I am not entirely sure all of the functions can be done with the same syntax. I am no pro in writing the Handlebars functions.)

Extra warning: I don't know if I've ever tried using random functions within WASI.

• rand_alpha Random from set [a-zA-Z]
• rand_numeric Random from set [0-9]
• rand_alphanum Random from set [a-zA-Z0-9]

The env object is missing data about the HTTP request, the path of this resource, and other Spin information in contradiction to the documentation. The only key-value pairs present in it are the environment variables set if any.

Steps to reproduce:

• Fresh copy of Bartholomew.
• replace docs/templates/main.hbs to just print the env object
• run spin up -env PREVIEW_MODE=1

main.hbs:

<ul>
    {{#each env}}
    <li><code>{{@key}}</code>: <code>"{{this}}"</code></li>
    {{/each}}
</ul>

expected result:

{
    PREVIEW_MODE: "1"
    HTTP_REQ: "..."
    PATH: "..."
    SPIN: "..."
}

obtained result:

{
    PREVIEW_MODE: "1"
}

The lack of HTTP request and PATH data limit the amount of dynamic generation that can be done. For example, Pagination of content would require path information.

I was thinking it will be nice to have predefined templates to be able to embed social media posts such as twitter, instagram etc.

What do u think?

When a runtime error occurs with Rhai, we almost always get the same largely uninformative error:

For example, say we have this content/borken.md:

title = "Example of broken page"
template = "borken" # <-- uses borken.hbs
date = "2021-12-23T17:05:19Z"
---

And this templates/borken.hbs:

{{ borken }} <-- invokes the `borken.rhai`

And this scripts/borken.rhai:

// Note that msg is undefined, but this will parse.
// So it will generate a runtime error instead of a parse error.
"hello " + msg;

The result of executing the above would yield:

Rendering "/content/borken.md": Template 'borken': Error rendering "borken" line 1, col 1: Cannot convert data to Rhai dynamic

I can't figure out how to get a better error message out of the Handlebars engine.

Note that a parse error is much easier to debug, and it would be nice to have something closer to this:

Script "/scripts/borken.rhai": ParseError(ParseError(MissingToken(")", "to close the arguments list of this function call 'f'"), 5:3))

Following the docs to run bartholomew and I hit the following:

$ wagi -c modules.toml
No log_dir specified, using temporary directory /var/folders/5h/_7jqb5nn5fz7vfcc9zhwn7nc0000gn/T/.tmpK049o3 for logs
Error: Not all routes could be built: failed to read input file

Am I correct in assuming it is because of the following hardcoded path to the fileserver module in the modules.toml file?

[[module]]
module = "/Users/technosophos/Code/Grain/fileserver/fileserver.gr.wasm"
route = "/static/..."
volumes = {"/" = "static/"}

Wondering what the best approach is for updating the path/location per the host system? I'm new to the wagi project... can a module reference a hosted URI? Or do they currently need to exist relative/locally to the host system?

It would be very helpful to have a CLI that simplifies working with Bartholomew projects.
Specifically, it would contain functionality for:

• creating new sites
• creating new posts
• listing and displaying the content and a post calendar (see https://github.com/fermyon/bartcal)

I started implementing the latter two features, here is the current state:

 ➜ bart calendar ./content
Wed, Dec 22, 2021 - 'Documentation' index.md
Thu, Dec 23, 2021 - 'First Post!' 2021-12-23-first-post.md
Thu, Dec 23, 2021 - 'What Is Markdown?' 2021-12-23-what-is-markdown.md
Thu, Dec 23, 2021 - 'Markdown examples' markdown.md

 ➜ bart new post content/blog --author "Radu Matei" --template abc --title "Writing a new post using Bart"
Wrote new post in file content/blog/untitled.md

If this looks good, I will open a PR soon.