Drafts
[DRAFT] Integration a FSM in CastleCode (experimenting)
- Draft
As demanded by Castle has generic FSM synt... (U_FSM_Syntax), we need a syntax to define FSMs directly in CastleCode.
The behavior of a FSM is defined by the its “rules”. But to use a FSM we need to “call” that FSM; it needs to proces events,
either by single stepping or in a for-ever-loop. This is typically a details that most developers like to
controll.
And so we need a bit of syntax (and semantics) for it.
Workshop Tools
- Draft
A compiler will translate your source into executable code. Yet many more tools are needed to work effectively with the ‘Best-Language, Ever’ – and we are not talking about debuggers! The Castle workbench can do so much more to make your code outstanding.
Probably you have many questions about the software. About its metrics: like the Fan-Out of a given class or its Cyclomatic-Complexity. Or merely like to k Often this isn’t too complicated. But the amount of error-prone work is dramatic. Castle comes with tools that provide the answer.
Structure the md-content
- Draft
Within the concept as described in Revealjs + Markdown, and with The html-template composed as given, we can start autoring webslides in md. Aside of standard-md, some extra “structure” is are available, to split the md-file into (sub)slides, and animate its components.
Pre/In/PostFixes in generated CC2Py code
- Draft
The CC2Cpy compiler generated C-code, using a lot of pre-, in- and postfixed.
They are documented later ..
Modeling & Rendering Components & Friends
- Draft
Any compiler will read & parse the source, convert it into an abstract natation (like the AST) and write the result back in a lower-language, or “binary format”. We have spend several posts on the parsing phase. This one focus on the last part: rendering the model into “generated C code”.
The goal is not to design “all & everything”. We pick some details, do some experiment (typically in Jupyter/IPython Notebook), and the lessons-learned are documented here.