Es gibt mal wieder ein Projekt...
Wer -- wie ich -- noch kein Smart Meter, sondern einen ganz gewöhnlichen elektromechanischen Stromzähler hat (Fachleute sprechen vom Ferraris-Zähler), hat nur einen recht groben Überblick über seinen Stromverbrauch. Üblicherweise wird einmal im Jahr abgelesen; wer mag, kann in kürzeren Abständen Buch führen, z.B. monatlich. Das versuche ich zwar, aber oft vergesse ich die pünktliche Ablesung, oder in der Hektik des Alltags ist keine Zeit dafür.

Da wäre es doch schön, wenn man das ganze automatisieren könnte -- und damit auch gleich die Ablesehäufigkeit stark erhöht. Martin Kompf hat dafür auf Basis eines Arduino ein Gerät entwickelt, das mir gefällt.

Das möchte ich nun auch in Angriff nehmen. Meine Wahl ist auf den Arduino MKR Wifi 1010 gefallen, der auf ARM-Basis arbeitet. Die Programmierung soll -- zumindest für die eigentliche Funktionalität -- in SPARK erfolgen.

Die ersten -- zugegebenermaßen einfachsten -- Schritte sind schon erledigt:

  • Hardware besorgt: Arduino, Shield (Extraboard) zur Datenspeicherung, externe Beschaltung (im wesentlichen IR-Emitter und Phototransistor)
  • Arduino-Entwicklungsumgebung installiert
  • SPARK-Umgebung und Toolchain für ARM installiert

Als nächstes an der Reihe:

  • Board mit Strom versorgen und per USB mit dem Rechner verbinden
  • ein einfaches SPARK-Programm ausführen
Kommentare deaktiviert für Zählen

von kirjoittaessani


Lange nichts mehr geschrieben -- aber jetzt muss ich mich mal beschweren. Ich stehe gerade in einer Küche, die nicht mir gehört, und kann nur den Kopf schütteln über neumodische Design-Verirrungen: die Unterschränke haben alle Griffe mittig angebracht, so daß nicht ersichtlich ist, was ein Auszug und was eine Tür ist oder in welche Richtung sie sich öffnen läßt. Die Oberschränke verzichten gleich ganz auf Griffe. Und die Bedienelemente der Spülmaschine sind nur bei geöffneter Klappe zugänglich. Meine Güte, das weiß man doch seit hundert Jahren, daß das Unsinn ist!

Kommentare deaktiviert für Form Follows Function

von kirjoittaessani


It has taken me some time, but I have pushed my lox-spark project one step further: the code is now complete up to the end of chapter 5 in Bob's book.

Why has this taken so long, even though the new code is still unproven (i.e. the proof hasn't progressed beyond chapter 4)?

The Visitor pattern turned out to be quite​ a nut to crack. Bob has used templated accept() methods. This means a concrete visitor can choose to return whatever type it needs -- the example AST printer returns a string, but later in the book, other types might come in handy. Unfortunately, in Ada generic functions cannot be overloaded, so I couldn't copy this approach. I tried to code around this restriction only to discover I didn't really understand the Visitor pattern (which I hadn't encountered before).

After some searching, I found an Ada implementation by Matthew Heaney. He, too​, uses generics, but in a different way. The gist is that instead of returning a value, the Visitor type ("object") stores the data internally -- this is not a problem because the abstract visitor type is extended (subclassed) anyway -- and can then be queried by the caller. There seems to be a bit more boilerplate code, but most of this is written by Lox's source code generator, so this is no real problem.

The second nut stems from a shortcoming in current prover technology: Gnatprove cannot deal with aliasing (i.e. writing to one variable changes the value of another), and therefore access variables (pointers) are not allowed in SPARK. This is not as large a problem as it may seem since Ada programmers use access variables very sparingly. But the abstract syntax tree has nodes containing other nodes, so some kind of reference is needed.

I have decided to store all Exprs in a Formal_Indefinite_Vector (a container supplied by the standard library) and refer to them by their index in the vector.

I am quite satisfied with how far lox-spark has come, this is a good way to start the weekend.

What's next? Obviously, the new code needs to be annotated and proven. Also, chapter six has been out for almost two weeks, so there's still more code to be written. I haven't yet decided on where to start, so maybe I'll take advantage of git and do both in parallel.

Kommentare deaktiviert für Visited

von kirjoittaessani


My current pet project is coming along quite well: the implementation is complete up to chapter four (Scanning). More importantly, the AoRTE proof (absence of runtime errors) is also completely done. The only shortcomings are a handful of package bodies that are compiled with SPARK_mode => off: Ada.Command_Line and SPARK.Text_IO come to mind.

A few days ago, Bob has published the fifth chapter of his book. It is mainly about theory, and the only code it contains is a tool that generates source code for a part of the interpreter (the type hierarchy of the abstract syntax tree).

I thought about this for a while, and came to the conclusion I would not follow his path. Instead, I planned to write the types by hand. Here is why: generating source code is not really a problem, and since the generator would not be part of the final program, I would write it in plain Ada (without proving anything). The resulting code, however, would be part of the interpreter and thus needs to be proven. I could add the necessary annotations by hand, but that would defeat a big advantage of the generator: one can make changes at a high level (namely, change the input to the generator) and regenerate the sources. This is fine for ordinary languages, but it will kill my hand-written annotations.

Meanwhile, about a dozen Lox ports have appeared on github. I looked at all those I could find, but nobody seems to have written code related to the new chapter. Either the other developers have not yet found the time to implement the generator, or they, too, have their doubts.

Somehow, this lack of activity has prompted me to revise my decision: I will implement the generator, and I will generate annotations as well. After all, this project was meant to help me learn something new, and to be a challenge. But what good is a challenge unless it is challenging?

This should keep me busy in the coming days (I have not yet written any code for the generator). A quick Google search tells me that I can build multiple executables from the same project with GNAT, so that simplifies things on the organisational side.

Watch this site (or better yet, github) for updates!

Kommentare deaktiviert für Generation Lox

von kirjoittaessani


For some time, I've taken an interest in software engineering. With that, I mean robust software. After learning about Ada (my first project is from 2011), I haven't looked back (at C/C++, that is); Since then, I've learned a little about formal methods. So far, a few half-hearted attempts at SPARK/Ada have been the only results.

Now, I have stumbled across a project of Bob Nystrom's: He has designed a simple programming language, Lox, and is writing (and continuously publishing) a book on how to implement it. He has chosen Java and C, but quite a few folks have taken his code and re-implemented it in various languages: Alejandro Martinez (Swift), Ivan Katanic (C++), Paul Jackson (Go), Sasha Matijasic (Python).

So, why not do a SPARK port? I have some past experience with various parsers, so writing the bare code should not be that hard. Once that is done, annotations could be added and proofs done. The advantage of this project is that Bob is doing it now, chapter by chapter; I expect to follow at more or less the same pace, so if SPARKifying means I have to change something fundamental, I do not have to do that to the complete program. Instead, I can deal with problems as they crop up in the early stages.

I should add that SPARK can be used in different ways (or maybe I should say intensities). In the simplest case, only absence of runtime errors is proven. However, it is also possible to prove functional correctness at various levels: For example, one might set out to prove that a sorting subroutine actually returns a sorted list. This approach can be extended to more and more routines and eventually encompass the whole program. I do not know how far down this path I will (manage to) go, and in any case I have no idea how to prove functional correctness for a compiler.

Time will tell, I guess. Back to writing code now.

Kommentare deaktiviert für Sparkling Lox

von kirjoittaessani


Gestern habe ich festgestellt, daß Traktor auf K2-isch gar nicht (oder nicht mehr) /'bagwa/ heißt, sondern /'bagBa/, also mit bilabialem R.

Kommentare deaktiviert für Pronunziiert

von kirjoittaessani


Öfter mal was neues: ich habe jetzt ein Studientagebuch.

Kommentare deaktiviert für Go

von kirjoittaessani


So ein 25x25-Go-Brett sieht, wenn man erstmal angefangen hat zu spielen, ganz schön furchteinflößend aus.

2 Kommentare

von kirjoittaessani


Here's a solution for a problem I have been unable to find anything about on the net, so I would like to share it with you.
It results from a particular combination of choices that are not exactly mainstream, so it is probably quite rare:

Setup

First, I use the i3 window manager. Like many of the more usual window managers, it supports the notion of work spaces. I also use multiple monitors, and this is where i3 is different: instead of building up a huge desktop stretching over all monitors (and changing its contents via workspaces), each monitor is taken seperately; and each can be assigned one or more workspaces.You start working on a different workspace either by moving the mouse pointer, or by a key combination.

Here's where factor number three comes in: I use an absolute pointing device, namely a Wacom Intuos3. By default, the tablet maps to the whole screen area -- treating it as a single desktop,
conceptually very diferent from i3's approach.

Culture Clash

This shows: when I switch to a different screen, i3 has the ability to warp the mouse pointer, i.e. make it jump to the newly focused window. This is a nice touch for an ordinary (relative) mouse, but an absolute mouse will jump right back. You have to manually move it over.
It might seem like a good idea to switch screens using the mouse instead, but this does not work well if you need a workspace that lingers at the back of your other monitor -- you have to click on a tiny icon at the bottom. Besides, using the mouse to switch workspaces does feels wrong with keyboard-centric i3.
I ended up using a key combination and moving the mouse over, which feels redundant and annoying.

I looked for a way to confine my Intuos to just the active monitor, but have been unsuccessful until recently. Here's my setup:

Solution

First, bund workspaces to monitors:
workspace 1 output HDMI-0
workspace 2 output HDMI-0
workspace 3 output HDMI-0
workspace 4 output HDMI-0
workspace 5 output HDMI-0
workspace 6 output DVI-I-1
workspace 7 output DVI-I-1
workspace 8 output DVI-I-1
workspace 9 output DVI-I-1

Then, replace the ordinary workspace-switching key combinations by extended ones that also remap the input device:

bindsym $mod+1 exec --no-startup-id " i3-msg workspace 1; exec $HOME/bin/wacom-left"
bindsym $mod+2 exec --no-startup-id " i3-msg workspace 2; exec $HOME/bin/wacom-left"
bindsym $mod+3 exec --no-startup-id " i3-msg workspace 3; exec $HOME/bin/wacom-left"
bindsym $mod+4 exec --no-startup-id " i3-msg workspace 4; exec $HOME/bin/wacom-left"
bindsym $mod+5 exec --no-startup-id " i3-msg workspace 5; exec $HOME/bin/wacom-left"
bindsym $mod+6 exec --no-startup-id " i3-msg workspace 6; exec $HOME/bin/wacom-right"
bindsym $mod+7 exec --no-startup-id " i3-msg workspace 7; exec $HOME/bin/wacom-right"
bindsym $mod+8 exec --no-startup-id " i3-msg workspace 8; exec $HOME/bin/wacom-right"
bindsym $mod+9 exec --no-startup-id " i3-msg workspace 9; exec $HOME/bin/wacom-right"
bindsym $mod+0 exec --no-startup-id " i3-msg workspace 10; exec $HOME/bin/wacom-right"

Note the double quotes -- single quotes get messed up in some internal shell call and lead to weird error messages.
The remap scripts apply a coordinate transformation matrix that depends on your monitor setup and sizes.
#!/bin/bash -x
xinput set-prop "Wacom Intuos3 6x8 stylus" --type=float \
"Coordinate Transformation Matrix" 0.6 0 0 0 1 0 0 0 1

For some hints on how to calculate the proper matrices, see the linuxwacom wiki.

Kommentare deaktiviert für Focus

von kirjoittaessani


Nach meinem Systemwechsel auf dem Desktop habe ich mich mit meinem iPhone immer ein bißchen wie ein Außerirdischer gefühlt: so richtig Spaß macht es nur auf dem Planeten iTunes, und iTunes ist weit weg. Als das iPhone den Geist aufgab, lag es also nah, auch hier einen Systemwechsel zu vollziehen. Das heißt fast automatisch Android  (nur mit Jolla habe ich kurz geliebäugelt). Das erst Problem war, in der Fülle der Hersteller und Geräte etwas passendes zu finden. Gelandet bin ich schließlich beim Galaxy A3, das eine angemessene Ausstattung in einem nicht allzu großen Gerät unterbringt.
Etwas in den Abmessungen des iPhone 4 wäre mir lieber gewesen, ich habe aber nichts passendes gefunden.
Die erste große Überraschung mit dem neuen Gerät war, daß es um die Konnektivität nicht so gut bestellt ist wie gedacht. Das Android-Lager setzt genauso auf Cloud-Dienste wie die Firma Apple, und eine lokale Datensicherung oder die Verwaltung des Smartphones vom Rechner aus ist nicht vorgesehen. Zum Abgleich von Musik gibt es MTP, aber das erwies sich also so gruselig instabil, daß es nicht sinnvoll nutzbar ist.
Wenn der neurotische Kram nicht funktioniert, helfen meist Standard-Tools. In diesem Falle ist das ein Android-sshd namens SSHDroid,mit dem ich meine Plattensammlung bequem und sicher aufs Telefon bringen kann. Damit sie dort dann auch erkannt werden, ist derzeit noch ein Reboot vonnöten, ich bin aber guter Hoffnung, das noch verbessern zu können.

1 Kommentar

von kirjoittaessani