Sometimes it can be useful to capture information about your environment at build time, and have this information injected into the binary that you’re building. Some examples centre around versioning, where it might make sense to capture git commit hashes or build serials.
Two variables in this module gitCommit, and buildSerial are going to hold some version information for us. Running this program yields some rather uninteresting results.
go run main.go
git hash: , build serial:
-X switch
While building a program, you can use the -X linker switch which will allow you to supply information into module variables from the build process.
We can obtain the latest build hash using git with the following:
git rev-list -1 HEAD
We can even synthesize a build number involving the date, perhaps?
date +%s
Using the -ldflags switch, we can now specify these at the console.
Sometimes you may need to investigate the contents of binary files. Simply using cat to view these details in your terminal can have all sorts of random effects due to control characters, etc. The utility hexdump allows you to look at the contents of these files in a sane way.
From the hexdump manpage:
display file contents in hexadecimal, decimal, octal, or ascii
In today’s article, we’ll walk through some example usages of this utiltiy.
Examples
For all of these examples, we’ll be using a 256 byte file of random binary. I generated this data on my system with the following command:
head-c 256 /dev/urandom > example
The initial view of this data now looks like this:
Using _a[dox] we can control how that offset down the left hand side looks. %07_ax pads the offset with a width of 7. 16/1 "%_p" will print 16 bytes using _p which prints using the default character set. The output of which looks like this:
Game of life is a cellular simulation; not really a game that is played, but more a sequence that is observed. In today’s article, I’ll walk through the rules and a simple C implementation.
How to play
There are some simple rules that the game must abide by.
The universe that it is played within is an orthogonal cartesian grid of squares that define if a cell is dead or if it’s alive. The lifespan of the cells is determined by the following rules:
Any cell that’s alive with fewer than two live neighbours dies (underpopulation)
Any cell that’s alive with two or three live neighbours lives on to the next generation
Any cell that’s alive with more than three live neighbours dies (overpopulation)
Any dead cell that has three live neighbours becomes alive (reproduction)
And, that’s it.
Implementation
The pitch where the game is played would be a pretty simple buffer of 1’s and 0’s. 1 would define “alive”, and 0 would define “dead”:
For every cell, we’ll get a random number from rand. If that number is divisible by 9, we’ll mark the cell as alive.
There are much more clever ways to seed the universe, in such a way that the rules of the game keep the generations running for ever with very clever patterns.
Permute
Actually making the universe kick along between frames, is simply applying the rules to a buffer of states. This buffer of states needs to be considered all in the same move; so we can’t mutate the original buffer sequentially.
Here, we see the overpopulation, underpopulation, and reproduction rules in action.
The number of neighbours, is counted with a difference:
intcount_live_neighbours(unsignedchar*u,intwidth,intheight,intx,inty){/* clip the bounds */intx1=(x-1)%width;intx2=(x+1)%width;inty1=(y-1)%height;inty2=(y+1)%height;returnu[x1+(y1*width)]+u[x1+(y2*width)]+u[x2+(y1*width)]+u[x2+(y2*width)]+u[x+(y1*width)]+u[x+(y2*width)]+u[x1+(y*width)]+u[x2+(y*width)];}
The x and y values are clipped to the width and height values. This means that if you fall off the right-hand side of the universe, you’ll magically appear back on the left-hand side. In the same way - top to bottom, etc.
A neighbour check must look at all 8 cells that surround the cell in question. If a cell is alive, it’s value will be 1; this gives us a really simple hack of adding all of these values together. This now tells us the number of neighbours to this cell.
Rendering
To the terminal.
Always, to the terminal.
You can render anywhere you want. For my example implementation, I’ve used the console.
As you can see, this is basically a CREATE TABLE statement, with a SELECT query at the end of it.
The new table is loaded with data defined by the query in the command. The table columns have names and data types associated with the output columns of the query. The CREATE TABLE AS (CTAS) command creates a new table and evaluates the query to load the new table.
RATIO_TO_REPORT(quantity::decimal * unit_cost) is what gives us the value that we’re working with in terms of ratio; the PARTITION BY sale_date then gives us the window; these ratios need to be calculated for the day.
sale_date
salesperson
?column?
ratio_to_report
2018-05-02
Bob
26
1.0
2018-05-13
Sally
60
0.2777777777777778
2018-05-13
June
156
0.7222222222222222
2018-05-14
John
96
1.0
2018-05-25
Bob
192
0.5962732919254659
2018-05-25
Sally
130
0.40372670807453415
2018-05-26
John
156
1.0
2018-05-27
John
52
0.0962962962962963
2018-05-27
June
20
0.037037037037037035
2018-05-27
June
468
0.8666666666666667
2018-06-02
Sally
26
1.0
2018-06-03
John
60
0.2777777777777778
2018-06-03
John
156
0.7222222222222222
2018-06-12
John
96
1.0
2018-06-13
Bob
192
0.5962732919254659
2018-06-13
Sally
130
0.40372670807453415
2018-06-15
John
156
1.0
2018-06-24
Bob
52
0.7222222222222222
2018-06-24
Sally
20
0.2777777777777778
2018-06-29
John
468
1.0
ROW_NUMBER
ROW_NUMBER is a utility function that simply gives the row an ordinal value, counting up from 1; over the window.
We count the sales for the day, by applying ROW_NUMBER over the sale_date.