Deployment is currently faulty.

In Node 17, the EPUB files produced by streampub are invalid because one of its dependencies is not up to date. An attempt to unzip one of them results in a message such as bad CRC 2cab616f (should be 00000000).

This issue explains where (I think) the issue comes from.

To my knowledge, we have two options:

1. Do not produce the EPUB. This file format might not be popular enough to justify maintaining the EPUB.
2. Maintain our own fork of streampub that repairs the problem, and include it here as a submodule. The change required to fix the EPUBs is actually trivial: Just bump the version number of a single dependency. However, if we run into further problems of this sort, then we will probably be on our own to fix them since streampub does not appear to be actively maintained.

Does anyone have an opinion on how to proceed?

The Writing Reactors part of the website is ready for filling in Cpp implementations of the code snippets. The code snippets can be found here. After providing the .lf files, run the preprocessMarkdown.js script as described here. To view the resulting webpages on your local machine, follow the instructions here to install yarn, then point your browser to localhost:8000.

To guard against broken links on our website, there is tooling available. Should we add stale link checking as part of the CI? Looks like there are some tools that could help:

1. markdown-link-check
2. brok
3. My Broken Link Checker (Github Action)

The developer/Contributing page on the website needs style guidelines for contributors to the code. Also, it should be updated to not necessarily point to Eclipse nor reference xtend.

During the scheduling meeting today, it came up that our swappable runtime schedulers for the C and Python targets might merit their own dedicated page under Reference, similar to Tracing.

#80 added a concise explanation for these schedulers. However, a lot more can be said about each scheduler, including details about their internal structures, execution strategies, how they perform relative to each other, what kind of applications might benefit from each, etc.

This page could also serve as a way to keep a record of our progress on developing these schedulers as we add more of them.

This page would also be a great place to explain the task set generator tool (lf-lang/playground-lingua-franca#3).

Page URL:
docs/handbook/composing-reactors

Issue:
The coloring in the syntax highlighting seems to be inconsistent at times.

Examples:

Recommended Fix:

Improvement Idea: Allow developers to add themselves onto a map for contributors, but only have their information displayed if they meet an objective threshold (in the form of # of commits in the history of the lingua-franca repository)

Why: At the moment, the community page is designed so that any Lingua Franca developer can simply add themselves to a map and have themselves show up on the website. As the project grows bigger, we should control who we allow on the community page based on their global commit history on lingua-franca and lf-specific reactors.

The tools section of the website needs instructions for getting started with VS Code, Epoch, and the command-line tools. See tools directory.

We can use the same layout as the "Meetups" panel, and use photos or GitHub icons instead.

Improvement Idea: Implementing Code Syntax Highlighting for Lingua Franca Code Snippets using PrismJS

Why: VS Code already implements Code Syntax Highlighting for .lf files. Remark-PrismJS is the standard Gatsby Plugin used to highlight code on Gatsby websites, and it's possible to create a custom language that Prism can process for code snippets

Dependabot reports security issues in our website.

While the colors weren't optimal in the first place, they are now rather weird, particularly in the dark theme. I think the change was brought about in this commit: 1ded45c, but I'm not sure.

Suggested by @edwardalee.

Each page of the handbook should have a link to the corresponding GitHub page so that readers can suggest improvements to that page in the form of a pull request.

For example, the troubleshooting page has the following text:

If you have suggestions for additions to this page, please submit a pull request.

This could be included in the footer or side bar of each page. For example GitHub docs has this in the footer of every page:

Clicking on the provided link will bring you directly to the edit mode of that page. For example, the homepage link will get you to https://github.com/github/docs/edit/main/content/index.md (note the edit word in the link). GitHub will then guide you through the process to edit this page. If it requires creating a fork, GitHub will guide you through that process all on the web. This is a nice built-in feature of GitHub that would make it easy to suggest improvements for each handbook page. For example, here is a direct link to modify the "A First Reactor" page:
https://github.com/lf-lang/website-lingua-franca/edit/main/packages/documentation/copy/en/topics/A%20First%20Reactor.md

The changes to the main menu bar don't translate well to the mobile view. Either we have to revert these changes or have a special case with a smaller logo.

Why: When generating the epub/pdf copy of the LF Handbook, it's cover uses cover.jpg located in packages/handbook-epub/assets/cover.jpg which says TypeScript Handbook. We would need a replica cover for Lingua Franca

• separate PDFs for each target
• code highlighting
• include images (currently not working)

The C runtime allows for swappable runtime schedulers. Each scheduler offers different performance benefits and useful features. We should dedicate a subsection on, perhaps, the "Target Language Details" page for the C and Python targets.

The Writing Reactors section of the website is ready for review for the C target.

The Writing Reactors part of the website is ready for filling in Python implementations of the code snippets. The code snippets can be found here. After providing the .lf files, run the preprocessMarkdown.js script as described here. To view the resulting webpages on your local machine, follow the instructions here to install yarn, then point your browser to localhost:8000.

The packages/documentation/topics/Distributed Execution.md page has a notation at the top saying "The information in this page is outdated, and will be updated soon". This needs to updated.

It would be useful to be able to list example LF code in the docs smaller than an entire file. To make sure that the file still compiles, we'd have to surround it with additional code. We could use "magic" strings in the comments to delimit the code segment of interest.

With the use of the LSP syntax highlighting, the LF keywords in code blocks no longer match the LF keywords in the text. I had previously had LF keywords in bold and what I've been calling "Lingua Franca orange", which is the orange in the logo. Currently, that is what we have in the text. In the code blocks, we have light blue (which should probably be darker in light mode) and not bold. In the C bodies, functions are bold and have a color that looks a bit like LF orange, but not quite. Maybe the functions should be bold blue and the LF keywords should be bold orange?

Adding ?targetSelector=lf-* to a handbook URL can be used to select a particular target, but the target selector remains unaffected (meaning it could point to the wrong target).

On a related note, we might want to make the selected target part of the URL because otherwise it becomes difficult to share handbook URLs. If I'm looking at the Python documentation and copy the URL to a friend, and they happen to have selected C as the current target language, they will see a different page when they follow my link.

• Make sure all .lf files compile
• Make sure that all tests pass

I mean this shade of blue:

This color already "belongs" to TypeScript: It's recognizably a TS color.

I'm posting this as an issue rather than trying to solve it myself because I do think it is a little complicated and important. To my knowledge, LF has specific shades of orange and dark blue, respectively, but no light blue. We could add another color, but maybe that would be excessive. And if we restrict ourselves to the existing colors, which are too strong and dark to use in large quantities, then our front page might require some redesign.

With TypeScript as the selected target, the following content is shown:

In the packages/documentation/copy/en/reference/Target Language Reference.md file, there is a FIXME that says:

FIXME: Give a list of schedule() functions with descriptions.

Can someone add that list or point me to where to find it? The examples show schedule() and schedule_int(). Others?

The Writing Reactors part of the website is ready for filling in TypeScript implementations of the code snippets. The code snippets can be found here. After providing the .lf files, run the preprocessMarkdown.js script as described here. To view the resulting webpages on your local machine, follow the instructions here to install yarn, then point your browser to localhost:8000.

I noticed that the current text introduces preambles only on the reactor level and not on the file level. For C the distinction is probably not so important as all preambles end up in the same file/scope, but for languages that restrict the scope the distinction is important.

There are number of dead links that I'm not sure how to deal with:

In packages/lingua-franca/src/templates/pages/publications-and-presentations.tsx, there are pointers to a number of "assets" (mostly in the presentations section) that do not exist. Anyone know where these are? The problems are these:

• https://www.lf-lang.org/publications-and-presentations/assets/slides/Lohstroh_etAl_CyPhy19.pdf
• https://www.lf-lang.org/publications-and-presentations/assets/slides/Lohstroh_etAl_EMSOFT19.pdf
• https://www.lf-lang.org/publications-and-presentations/assets/slides/Lohstroh_Lee_FDL19.pdf
• https://www.lf-lang.org/publications-and-presentations/assets/slides/Lee_ActorsRevisited_CyPhy.pdf
• https://www.lf-lang.org/publications-and-presentations/assets/slides/Lohstroh_etAl_FDL20.pdf

In packages/lingua-franca/src/components/layout/fonts.scss there are URLs for the following fonts that all yield 404s:

• leelawadeeui-light.woff2
• leelawadeeui-light.woff
• leelawadeeui-semibold.woff2
• leelawadeeui-semibold.woff

There are also a number of dead links in the Distributed Execution page, but this page needs a complete overhaul, so I'm not worried about those yet.

You can check for dead links using this website: https://www.deadlinkchecker.com/website-dead-link-checker.asp

The Writing Reactors part of the website is ready for filling in Rust implementations of the code snippets. The code snippets can be found here. After providing the .lf files, run the preprocessMarkdown.js script as described here. To view the resulting webpages on your local machine, follow the instructions here to install yarn, then point your browser to localhost:8000.

Link looks like: https://github.com/lf-lang/website-lingua-francatree/main//packages/documentation/copy/en/reference/Tracing.md
But should be: https://github.com/lf-lang/website-lingua-franca/tree/main/packages/documentation/copy/en/reference/Tracing.md

Page URL: https://www.lf-lang.org/assets/lingua-franca-handbook_lf-c.pdf

Issue: LF diagrams not rendered in PDF. See below.

Page URL: https://www.lf-lang.org/docs/handbook/target-declaration

The TypeScript documentation describes how parsers for custom types can be added, such that we can use those types as parameters to the main reactor and automatically parse them. The C++ solution should be discussed accordingly in the C++ view.

Page URL: throughout the website

Issue: I don't think we should use info_print (soon to be lf_print) in most of the examples. Except for federated execution, the only difference is the addition of \n. This is not worth the extra unfamiliarity.

Recommended Fix: Replace all info_print in code examples and markdown files with printf with \n manually added.

We need to add modal models documentation to the web page. I think this can be done after publishing the page.

For federated execution, there are three possible serialization methods for connections: native, ros2, and proto. However, this is not explained in the handbook.

• serve placeholder until ready
• fix gradient in svg logo
• write instructions for editing the handbook (former wiki content)
• restructure and edit handbook
• create content for landing page
• include/refer to developer documentation (create landing page for reactor-c to steer people away from internal docs)

Maybe we should consider introducing a dedicated landing page for Epoch. Maybe a section in the handbook? Would be nice if there are some Epoch specific pointers for users to get started.

Originally posted by @cmnrd in lf-lang/lingua-franca#1237 (comment)

It appears that syntax highlighting for non-LF code is not supported.
For example, there is no syntax highlighting for the following:

```bash
cd foo
```

But it could appear as

cd foo

To achieve some consistency in how we name public-facing repositories in our lf-lang order, I would suggest to rename this repo to website-lingua-franca. The advantage of this naming scheme is that 1) it starts with a w, so auto-completion with tab is fluent, and 2) it features the name lingua-franca in it, so that it is easily identifiable outside of the scope of the organization.

The wiki is currently missing details about banks and multiports in the C++ target. This should be added either as a separate article or by extending the existing article about banks and multiports.

We should be able to provide a one-click "try me out on GitPod" button that let's visitors fire up VS Code in their browser and write Lingua Franca right away. More info: https://www.gitpod.io/docs/vscode-extensions

The Algolia Doc Search functionality does not yet work. We've temporarily disabled it and will need to apply with Algolia to get approved. Their requirements are as follows:

To have your request validated, we'll ask that you check all the following points. You must be the owner of the website, or at least have the permissions to update its content. You'll need to include a JavaScript snippet to your frontend to implement DocSearch. Your website must be publicly available. We do not host search indices for websites that are only available after authentication or are hosted on a private network. Your website must be a technical documentation of an open source project or a technical blog. We do not index commercial content. Your website must be production ready. We won't index empty websites nor those filled with placeholder content. Please, wait until you have written some documentation before applying. We would be happy to help you as soon as you have a steady design. If in doubt, don't hesitate to apply and we'll figure it out together. Even if we cannot accept your request, this does not mean that you cannot enjoy great search on your website.

• Tooling > VS Code plugin ((@lhstrh , @petervdonovan)
• Tooling > Epoch IDE (@revol-xut, @edwardalee )
• Tooling > CLI tools (@lhstrh, @cmnrd)
• Tooling > Setup for Rust (@oowekyala)
• Tooling > Setup for Cpp (@revol-xut, @cmnrd)
• Tooling > Setup for TypeScript (@lhstrh, @hokeun)
• Tooling > Setup for C (@revol-xut, @cmnrd)
• Target Specification