This project is a tiny compiler for a very simple language consisting of boolean expression.
The language has two constants: 1 for true and 0 for false, and 4 logic gates:
! (not), & (and), | (or), and ^ (xor).
It can also use parentheses to manage priorities.
Here is its grammar in BNF format:
expr ::= "0" | "1"
| #!/usr/bin/awk -f | |
| # This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff | |
| # My copy here is written in awk instead of C, has no compelling benefit. | |
| # Public domain. @thingskatedid | |
| # Run as awk -v x=xyz ... or env variables for stuff? | |
| # Assumptions: the data is evenly spaced along the x-axis | |
| # TODO: moving average |
PlantUML is a really awesome way to create diagrams by writing code instead of drawing and dragging visual elements. Markdown is a really nice documentation tool.
Here's how I combine the two, to create docs with embedded diagrams.
Get the command-line PlantUML from the download page or your relevant package manager.
| (* | |
| WHAT'S GOING ON HERE?! | |
| Sometimes you don't care about a particular type, you're interested in one field only, let's say `EntityId`. | |
| Instead of using interface (which isn't even possible if don't own a type), | |
| we can do structural typing in F# using SRTP and Active Patterns. | |
| Active patterns are not required for this, but they do make code much easier to use. | |
| *) | |
| // So we have 2 types with field `EntityId: string`: |
A few years ago when I read the presentation motivating the design behind Nessos Streams I was struck by the beauty of simplistic push streams.
type PushStream<'T> = ('T -> bool) -> boolLINQ (in .NET) is a pull stream, ie we pull values out of the stream by calling MoveNext + Current. One of the problems with pull streams is the constant checking "Are we done?" at each level in the stream.
https://gitter.im/DataStaxCommunity/Cassandra_Spark
To start communicating with Cassandra like a champ, Cassandra's Query Language (CQL) is your best bet. CQL is an SQL-like language, which makes it warm and fuzzy for those of us used to SQL, but don't let that fool you...
We still have to think about how we "converse" with Cassandra differently. When we model our data, we need to think about how we will access it before we model it. It's important to emphasize this point, because you can get into some very ugly territory if you model Cassandra like a relational database. Data Modeling with Cassandra is purely query-driven.
