zen
SysML-v2-Release
| zen | SysML-v2-Release | |
|---|---|---|
| 2 | 2 | |
| 114 | 379 | |
| 0.0% | 5.5% | |
| 5.2 | 6.1 | |
| 24 days ago | about 1 month ago | |
| Clojure | Batchfile | |
| - | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
zen
-
[ANN] London Clojurians Talk: Model-driven systems with zen-lang (by Nikolai Ryzhikov)
We all use a lot of fantastic data-based DSLs in Clojure. What if we describe the whole system as a composable meta-data with zen-lang (https://github.com/zen-lang/zen)
-
How do you draw the functions?
We are chasing model driven system as well. The key idea in our approach to use composable data dsls to describe a model and configuration of the system - https://github.com/zen-lang/zen. I came up to idea of system operation (procedure, service) as a fundamental component of the system - (op system config params) => result, events, effects - other models are just parameters for such operations. And I'm looking a way to drawn it. The whole system can be described and implemented a set of generic (configurable) operations.
SysML-v2-Release
-
Requirements
I like the personas and journey features.
In formal systems engineering, a common mistake (including for the 737MAX[1]) is failing to model system users, and treating system users as completely external and separate to what is being designed.
I'd love to play with an Inform 7[2] like language for capturing "operational scenarios"[3] (systems engineering jargon for roughly a combination of "personas" and "journeys"). In many fields of systems engineering (e.g. aviation), vocabulary has to be tightly controlled and syntactically unambiguous language used. As is the case with Userdoc, an LLM could propose operational scenarios, but they'd need to be converted to a syntactically unambiguous language, and be vetted by humans. Of current approaches to formally capturing operational scenarios, and I don't think any of these do a particularly good job of it, I prefer Object Process Methodology[4] (text representation only) over SysMLv2[5] (again text representation only, and this is R&D/draft). I'd only mention SysMLv1 or UML use cases as something I'd forever avoid.
[1] https://www.incose.org/docs/default-source/enchantment/21031...
[2] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la...
[3] https://sebokwiki.org/wiki/Operational_Scenario_(glossary)
[4] https://en.wikipedia.org/wiki/Object_Process_Methodology
[5] https://github.com/Systems-Modeling/SysML-v2-Release/blob/ma...
- How do you draw the functions?
What are some alternatives?
petastorm - Petastorm library enables single machine or distributed training and evaluation of deep learning models from datasets in Apache Parquet format. It supports ML frameworks such as Tensorflow, Pytorch, and PySpark and can be used from pure Python code.
clograms - Clojure[Script] source code diagrams