oss/starmelon
oss/starmelon
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
starmelon/Cargo.toml

55 lines
2.2 KiB
TOML
Raw Normal View History

feat: unix adaptor for elm called 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.
2021-09-15 06:07:28 +01:00
[package]
name = "starmelon"
version = "0.1.0"
edition = "2018"
feat: starmelon reads files or stdin
2021-09-20 07:34:43 +01:00
# I decided to use os_pipe becaues I want to pipe stdout of a subprocess into
refactor: move some setup to elm-project-utils crate
2022-01-11 18:15:16 +00:00
# stderr in real time. I want the output of the process to stderr and stdout
feat: starmelon reads files or stdin
2021-09-20 07:34:43 +01:00
# show up in the original order. I looked an os_pipe uses some unsafe code to
# duplicate file descriptors. I am unfamiliar with the correct way of sharing
# the fds. Therefore I am going to trust that their unsafe code is necessary.
# Then it makes sense to use a battle tested unsafe code rather than implement
# it myself.
feat: unix adaptor for elm called 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.
2021-09-15 06:07:28 +01:00
[dependencies]
ahash = "0.7"
feat: figured out starmelon needs expr types 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.
2021-12-29 14:57:35 +00:00
elmi = { path = "../../../infra/rust-elmi", features = [ "genco" ] }
feat: starmelon reads files or stdin
2021-09-20 07:34:43 +01:00
naive-wadler-prettier= { path = "../../../infra/redwood-lang/compiler/naive-wadler-prettier" }
os_pipe = "0.9"
feat: unix adaptor for elm called 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.
2021-09-15 06:07:28 +01:00
serde = { version = "1.0", features = [ "derive" ] }
serde_json = { version ="1.0", features = [] }
feat: starmelon reads files or stdin
2021-09-20 07:34:43 +01:00
structopt = { version = "0.3" }
refactor: share checksum rebuild logic 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.
2021-10-12 21:00:25 +01:00
elm-project-utils = { path = "../../../infra/rust-elm-project-utils" }
feat: use tracing crate to measure cpu time
2021-12-10 00:18:01 +00:00
tracing = { version = "0.1", features = [] }
rustc-hash = "1.1"
feat: prove elm object cache is complete
2021-12-11 18:28:04 +00:00
home = "0.5"
feat: use tracing crate to measure cpu time
2021-12-10 00:18:01 +00:00
# Required to transpile view functions to Rust
genco = "0.15"
feat: PoC for generating webpage with database
2022-01-12 04:56:15 +00:00
# Required to generate fixture Elm files
refactor: rename elm-quote crate to genco-extra I want to add quoting rules for nginx config language. I decided it would be better to group all the language definitions in the same crate.
2022-04-15 04:29:44 +01:00
genco-extra = { path = "../../../infra/genco-extra" }
feat: PoC for generating webpage with database
2022-01-12 04:56:15 +00:00
feat: unix adaptor for elm called 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.
2021-09-15 06:07:28 +01:00
# All of these are required for deno's javascript runtime. We need to keep the
# same versions as other projects in our cargo workspace. Multiple different
# versions of rust_v8 seem to break its build script.
feat: upgrade v8 runtime crates
2022-03-21 20:07:19 +00:00
deno_runtime = "0.50"
tokio = { version = "1.17", features = ["full"] }
deno_core = "0.124"
deno_web = "0.73"
futures = "0.3"
feat: figured out starmelon needs expr types 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.
2021-12-29 14:57:35 +00:00
feat: add sqlite support to starmelon interpreter
2022-01-07 02:27:33 +00:00
# Required to add sql query support to interpreter. Because deno expects sync
# ops to be synchronous, we have to use a second async executor to run the sqlx
# functions. I read the code for oneshot
# (https://github.com/faern/oneshot/commit/9aa237f185e1b65d61bf92c20350cf7bee0aa88b)
# and it looks reasonable.
sqlx = { version = "0.5", features = [ "sqlite", "macros", "runtime-tokio-rustls", "chrono", "json", "uuid" ] }
oneshot = "0.1.3"
feat: upgrade v8 runtime crates
2022-03-21 20:07:19 +00:00
# required for livetable derive macro
livetable-core = { path = "../../../infra/livetable/core" }
feat: use cargo hakari to reduce crate rebuilds 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.
2022-05-28 18:44:21 +01:00
cargo-workspace-hack = { version = "0.1", path = "../../../infra/cargo-workspace-hack" }
feat: upgrade v8 runtime crates
2022-03-21 20:07:19 +00:00
feat: PoC for generating webpage with database
2022-01-12 04:56:15 +00:00
[dev-dependencies]
aho-corasick = "0.7"
Reference in a new issue Copy permalink