The way extensions are injected into the Isolate changed dramatically
between Sept 2021 and Jan 2024. Now ops are available in the virtual
module ext:core/ops.
Large workspaces end up with a very large number of possible build
configurations.
Even worse, the feature set of a package affects everything that depends
on it, so syn being built with a slightly different feature set than
before would cause *every package that directly or transitively depends
on syn to be rebuilt. For large workspaces, this can result a lot of
wasted build time.
To avoid this problem, many large workspaces contain a workspace-hack
crate. The purpose of this package is to ensure that dependencies like
syn are always built with the same feature set no matter which workspace
packages are currently being built. This is done by:
1) adding dependencies like syn to workspace-hack with the full feature
set required by any package in the workspace
2) adding workspace-hack as a dependency of every crate in the
repository.
cargo-hakari manages a workspace-hack crate for you.
Perform a single pass so the work of doing `m` replacements in a string
of length `n` is O(m + n) instead of O(m * n)
For the yogalogy template this change improves the script munging step
from ~2.5ms to 0.5ms [release] (from ~17ms to 3ms [debug]).
Prepare for adding a second radically different fixture by creating a
module to hold the different fixtures. When I only had one fixture it
was ok to have the module be a single file.
Factor out the content code from the supporting editor. The next step is
to derive the visual CMS editor from the content codebase. In theory the
system will work like this:
A user would edit the view functions in src/Components/* with a Figma style
editor and write the changes back to the source Elm file.
A second tool will inspect the source directories looking for modules
that expose (route: astrid-pages/core/Astrid.Pages.Route). It will allow
a user to visually define and edit routing rules that decide which
module should handle each request. This tool compiles the routing rules
and source files into a standalone binary.
A third tool will generate a visual CMS that modifies the view functions
of each route to insert clickable targets on components. These targets
will open database record editor modals for the rows that generated that
specific HTML. This is achieved by engineer cooperation via annotations
rather than static analysis. This visual CMS can hot reload itself when
the view functions are changed by the first tool.
A fourth tool will generate an AirTable style database editor from the
type definitions found in src/Database/* modules.
The automated operation of these tools allows a non technical user to
edit the appearance and data of a website in cooperation with software
engineers define the data structures. The simple nature of Elm prevents
the engineers from being so creative the tools cannot understand what is
going on. And Elm checks the work of non technical contributors for any
conflicts with the engineers' design.
To generate partial application boxed closures I need to know the arity
of the expression to tell if more args will remain after the given args.
Right now I think I can recalculate the types if I have a symbol table
where I can look up every variable. I think this will be a lot of work
because I have to reimplement most of unification to deal with
collections, patterns, and type variables. And I currently don't know
how unification works.
Move some of the caching logic (source file checksum) out of Starmelon
into a shared infra crate.
I have 4 similar tooling use cases for working with elm projects in
Rust.
1. Starmelon needs to create a modified copy of an existing elm
application with extra dependencies and source directories. The
extension elm application points to the source directories of the
parent
2. Elm reactor needs to compile an elm module into javascript with
caching.
3. SQL reactor needs to generate an elm application for each database,
generate elm source code and compile that elm code with caching. It
uses Starmelon to run derive macros written in Elm.
4. AstridLabs needs to create a heavily modified copy of an existing elm
application with tons of generated code. It uses Starmelon to run
derive macros written in Elm.
For 3 and 4 I could speed up the code generation step by using
part of starmelon as library. A proc-macro could include the Elm derive
macro javascript at crate build time and reuse the same v8 isolate over
and over for every web request.
My plan for 1,2,3,4 has a lot of shared functionality. I am thinking
that I should consolidate all the components into one library crate.
infra/homer/examples was the start of my work on macros for Elm. I have
greatly refined these ideas in starmelon. Delete the multi step build
process and replace it with a single call to starmelon.
Introduce starmelon, a program for executing elm functions with input
from files and writing the output back to files.
Support evaluating 4 types of values and 12 types of functions.
```elm
x : String
x : Bytes
x : VirtualDom.Node msg
x : Json.Encode.Value
f : String -> String
f : String -> Bytes
f : String -> VirtualDom.Node msg
f : String -> Json.Encode.Value
f : Bytes -> String
f : Bytes -> Bytes
f : Bytes -> VirtualDom.Node msg
f : Bytes -> Json.Encode.Value
f : Json.Encode.Value -> String
f : Json.Encode.Value -> Bytes
f : Json.Encode.Value -> VirtualDom.Node msg
f : Json.Encode.Value -> Json.Encode.Value
```
My target use case for starmelon is generating html files. It is nice
to be able to write parameterized framgents of markup in multiple
modules and then compose them into a final value. I also have in mind
attempting to replace helm (kubernetes pacakge manager) because I hate
how error prone its string based templating language is.
