Posts in rough

Generics: Parameters, Wrappers and template-specialisation

Castle supports Generics (a bit like Templates in C++) but with a twist. For example, in (the improved version of) “The Sieve demo (start/DRAFT)” 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.

Read more ...


QuickNote: typedParameters in Event?

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.

Read more ...


QuickNote: Jinja Templating for rPY

With a working RPython implementation of The Sieve demo (start/DRAFT), 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.

Read more ...


QuickNote: The Sieve in RPython

Before implementing an RPython backend, a short study of RPython is made, including implementing The Sieve demo (start/DRAFT) 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.

Read more ...


QuickNote: Connecting two ports

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.

Read more ...


QuickNote: Sending Events & Machinery

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.

Read more ...


QuickNote: Jinja Events (templating)

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.

Read more ...


QuickNote: Sending Events (generated code)

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.

Read more ...


rPY: Use (r)Python as backend

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?

Read more ...


QuickNote: Arpeggio

In this short QuickNote, we give a bit of info on Arpeggio; a python package to implement a (PEG) parser. Eventually, the parser is written in Castle – like all Workshop Tools. To kickstart, we use python and python-packages. Where arpeggio is one of the options.

As Arpeggio is quite well documented this is a short note. We also describe some differences with the Pegen package.

Read more ...


QuickNote: PEGEN

To implement CCastle we need a parser, as part of the compiler. Eventually, that parser will be written in Castle. For now, we kickstart it in python; which has several packages that can assist us. As we like to use a PEG one, there are a few options. Arpeggio is well known, and has some nice options – but can’t handle left recursion – like most PEG-parsers.

Recently python itself uses a PEG parser, that supports left recursion (which is a recent development). That parser is also available as a package: pegen; but hardly documented.

Read more ...


kwargs als argument

Elke python-programmeur kent het kwargs concept, waarmee een variabel aantal named- (of ‘keyword’) argumenten ontvangen kan worden in een functie. Soms wordt dit concept echter onhandig gebruikt.

Read more ...