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"
Datatypes in the Formality programming language are built out of an unusual
structure: the self-type. Roughly speaking, a self-type is a type that can
depend or be a proposition on it's own value. For instance, the consider the
2 constructor datatype Bool:
In this article, I'd like to explain why I think The Elm Architecture is fine for small components, but quite harmful for websites based on pages.
First, let's clarify what I mean by "The Elm Architecture".
The Elm Architecture's webpage describes it pretty well.
| Why do compilers even bother with exploiting undefinedness signed overflow? And what are those | |
| mysterious cases where it helps? | |
| A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but | |
| I think it's useful to know what compiler writers are accomplishing by this. | |
| TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all | |
| major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some | |
| fairly common cases. The signed overflow UB exploitation is an attempt to work around this. |
| #pragma config(I2C_Usage, I2C1, i2cSensors) | |
| #pragma config(Sensor, I2C_1, , sensorQuadEncoderOnI2CPort, , AutoAssign) | |
| #pragma config(Motor, port2, Motor_FW1, tmotorVex393HighSpeed_MC29, openLoop, encoderPort, I2C_1) | |
| #pragma config(Motor, port3, Motor_FW2, tmotorVex393HighSpeed_MC29, openLoop, reversed) | |
| #pragma config(Motor, port4, Motor_FW3, tmotorVex393HighSpeed_MC29, openLoop) | |
| //*!!Code automatically generated by 'ROBOTC' configuration wizard !!*// | |
| /*-----------------------------------------------------------------------------*/ | |
| /* */ | |
| /* Copyright (c) James Pearman */ |
| // change this to a recognizeable piece of your audio output | |
| // e.g. setAudioOutput("AirPlay"); or setAudioOutput("VoilaDevice"); | |
| // returns true on success / false on beef | |
| // as always, all thanks to StackOverflow for the amazing | |
| // enumerate devices script: | |
| // http://stackoverflow.com/questions/1983984/how-to-get-audio-device-uid-to-pass-into-nssounds-setplaybackdeviceidentifier | |
| // Note: if you change "kAudioDevicePropertyScopeOutput" to "kAudioObjectPropertyScopeGlobal" in line 62, | |
| // you can set the output for your whole system... |
I will maybe someday get around to dusting off my C and making these changes myself unless someone else does it first.
Imagine a long-running development branch periodically merges from master. The
git log --graph --all --topo-order is not as simple as it could be, as of git version 1.7.10.4.
It doesn't seem like a big deal in this example, but when you're trying to follow the history trails in ASCII and you've got several different branches displayed at once, it gets difficult quickly.
There are people out there who claim that merge-based workflows (that is, workflows which contain non-fast-forward merges) are bad.
They claim that git bisect gets confused by merge-based workflows, and instead advocate rebase-based workflows without explicit feature branches.
They're wrong.
Furthermore, the "advantages" of their workflows are in fact disadvantages. Let me show you.
