Posts tagged Castle
A Heisenbug in the Sieve
- 2024/03/27
In Castle, one can dynamically connect components and send events over those connections. Typically, this is an action on an incoming message (see: The Actor Model). And depending on ‘The Machinery (ToDo)’, those events can be queued. It is this combination that can result in a beautiful Heisenbug.
First, let’s explain the Heisenbug, before we give an example. Then we analyze it, show how to improve the code, and finally formulate a requirement to prevent & detect this kind of bug in Castle.
The Sieve (basic variant)
- 2024/03/25
To show some features of CCastle, I use ‘the Sieve’, short for the Sieve of Eratosthenes. An old, well-known, algorithm to find prime numbers; with implicit concurrency.
With an almost trivial implementation, many “CC concepts” can be shown; in only a handful of lines….
Generics: Parameters, Wrappers and template-specialisation
- 2023/10/10
Castle supports Generics (a bit like Templates in C++) but with a twist. For example, in (the improved version of)
“The Sieve (basic variant)” we use the SlowStart (base)protocol as a Generic protocol.
It becomes generic as we pass an Argument to the base class. Only that makes SlowStart a generic!
It is not visual in the definition.
As this differs from other languages, it gives some questions. We will explain how to use it. And make some (high-level) hints on the implementation.
QuickNote: typedParameters in Event?
- 2023/10/02
The RPy compiler backend needs to ‘fill-in’ some data structures, like CC_B_Protocol – there is one for every
protocol. It contains the name of the protocol, its kind (like Event, as we assume here), and a list of
events. That event list contains the (event) name, it’s sequence-number (see: Modelling the Event Index), and a backlink
to the protocol.
The question is: Should the Event (dataclass) contain the typedParameters?
This question affects both the runtime (for this backend) –the RPython implementation of
CC.buildin.CC_B_P_EventID– and the (jinja templating) to generate the code to fill those
data-structures.
QuickNote: Jinja Templating for rPY
- 2023/09/17
With a working RPython implementation of The Sieve (basic variant), it’s time to find the patterns to automate: generating RPython code from Castle-Code.
Like in QuickNote: Jinja Events (templating), part of the CC2Cpy: CCastle to C compiler in Python backend, we focus on the essential Jinja templates.
QuickNote: The Sieve in RPython
- 2023/09/14
Before implementing an RPython backend, a short study of RPython is made, including implementing The Sieve (basic variant) in RPython. It’s like a hand-compiled RPython variant, following the approach as described in the Jinja rendering study), for the CC2CPy backend.
Writing RPython isn’t too complicated for someone with a C-background. But making the code pass the RPython compiler
can be tricky, however. Both, as just added statements can interfere with existing code – when that isn’t “static
enough”, new code can trigger compile errors in old, tested code! And, because the RPython compiler isn’t that great
in giving helpful info.
It feels like old-style debugging: try-and-error, remove-and-enable-lines, one-at-a-time until one
understands and it becomes easy to fix…
This blog is both to share some RPython experience and to study the patterns that are needed to generate RPython code to implement the Castle-Compiler.
QuickNote: Connecting two ports
- 2023/08/01
Like in QN: Sending Events, we collect here some lines/fragments about connecting two ports in the handCompiled code to find similarities, and to design the (Jinja) templates.
QuickNote: Sending Events & Machinery
- 2023/07/27
Depending on the The Machinery (ToDo), the generated code to send an events will alter. However, only a little bit as we will see in this study.
QuickNote: Jinja Events (templating)
- 2023/07/26
As we have seen in the recent Workshop blog: QuickNotes a lot of code (to send/handle events) is always the same, but for some details. A template engine, like Jinja, can help in that.
Let’s study how those templates can help us.
QuickNote: Sending Events (generated code)
- 2023/07/25
The handCompiled, generated to send an event is about 4 to 6 lines; depending on the The Machinery (ToDo), with a lot of similarity. It is however buried in lot of other code, notes, ect. And therefore hard to see the difference.
Here, we collect al those pieces, and see which lines/fragments are common – and can go into a template. And which parts we have to fill-in.
rPY: Use (r)Python as backend
- 2023/06/25
When designing a Castle-Compiler with a C-backend, we found some nasty details unrelated to CCastle
but to the C-language. For example, C has no namespaces (see No Name Collisions); we can simulate them, but
that is extra work. Likewise, we need to generate many (data)classes that are very similar. Again, it is
possible, but it takes a lot of work: to write the code that generates those almost codes.
Therefore, I started to think about how we can automate that. Or: who has done it before, and what can we borrow?
PyPy –an alternative Python implementation– has developed a concept for
that! They have built a translator to convert (r)Python into C and
compile that into native machine code.
Can we re-use that? And can it help to realize the “first (bootstrap) compiler” faster?
Concurrent Computing Concepts
- 2022/09/30
Sooner as we realize, even embedded systems will have piles & heaps of cores, as I described in
“Keep those cores busy!”. Castle should make it easy to write code for all of them: not to keep them busy, but to maximize
speed up [useCase: In Castle is easy to use th... (U_ManyCore)]. I also showed that threads do not scale well for CPU-bound (embedded)
systems. Last, I introduced some (more) concurrency abstractions. Some are great, but they often do not fit
nicely in existing languages.
Still, as Castle is a new language, we have the opportunity to select such a concept and incorporate it into the
language.
In this blog, we explore a bit of theory. I will focus on semantics and the possibilities to implement them efficiently. The exact syntax will come later.
Keep those cores busy!
- 2022/07/06
I always claim that most computers will have 1024 or more cores before my retirement. And that most embedded systems will have even more, a decade later. However, it’s not easy to write technical software for those “massive-parallel embedded computers”, not with the current languages – simple because a developer has to put in too many details. Accordingly, the “best, ever” programming language should facilitate and support “natural concurrency”.
In Castle, you can easily write code that can run efficiently on thousands of cores.
FSM syntax, an evaluation
- 2022/06/10
As described in FSMs are needed Finit State Machines are great and needed – even tough no (main) programming
language has syntax support for it. But there are other (computer) language that (more-or-less) support the
corresponding State pattern.
By example plantUML –very populair by mature developers– has a syntax to draw them.
What can we learn from them? That is the topic of this post, before we define the Castle syntax.
FSMs are needed
- 2022/06/04
Finit State Machines (FSMs) are great to model behaviour and control flow. Probably it is one of the most used design patterns; some developers are not even aware they are using it (when using the State pattern). And non of the well-known system-programming-languages does support it directly – it’s a shame;-)
This leads to sub-optimal, often hard to maintain code. In Castle, you can use define a FSM directly. Let’s see why that is essential.
No inline actions
- 2022/05/21
In Grammar is code we have mentioned that many compiler-compilers reuse the Yacc invention “actions”. And we hinted already that Castle prefers an alternative.
Let’s see why the old concept is outdated … And what is easier to use.
Grammar is code
- 2022/05/14
In Compiler Compiler we have seen that we can define a grammar within a Castle-program. And we have argued that each grammars-rule can be considered as a function.
In this post, we look into de details of how this works. And will confirm grammars is code …
Compiler Compiler
- 2022/05/07
In Castle, you can define grammar(s) directly in your code. A Castle compiler will translate them into functions, using the build-in (PEG) compiler-compiler – at least that was it called back in the days of YACC.
How does one use that? And why should you?