Oak is an interesting Golang game engine written with a goal of minimal dependencies.
20190924/https://github.com/oakmound/oak
Do you want to create an empty branch on an already existing repository? There is a fairly simple way to do this.
git checkout --orphan <branchname>
git rm --cached -r .
20190923/https://stackoverflow.com/questions/13969050/how-to-create-a-new-empty-branch-for-a-new-project/13969482#13969482
My previous article on Details on how to develop a Macintosh dd made a few mis-statements in the details. Here, here I must clear them up.
The “Disk Driver” from the Device Manager API is a misnomer. The
“Disk Driver” accesses logical blocks from a volume, i.e. a
partition, not a full disk. Likewise, GetDrvQHdr() gets a list of
volumes, not drives. This name oversight was perfectly fine in the
era of floppy disks since a volume and a disk were one-in-the-same,
but it did not extend well once partitioned hard disk drives were
introduced. Additionally, please note that only Macintosh file
systems will be listed by the Disk Driver. Volumes/partitions with
foreign file systems must be read using Apple File Exchange to get a
block-by-block copy.
Therefore, if you want to take a full disk image of a hard disk drive, including the “partition map,” you must use one of the newly introduced low-level APIs. In the case of the Macintosh Plus and newer compact Macintoshes, this will be the SCSI Manager:
20190921/https://web.archive.org/web/19991116003046/http://developer.apple.com/techpubs/mac/Devices/Devices-119.html
However, please note that the Monster Disk Driver Technote states that the Macintosh 128K and 512K do not support partition-based drivers. That means that early hard disk drives like the Macintosh Hard Disk 20 do not have a such thing as a partition map hiding away outside the volume visible to the Macintosh Device Manager. So, if your goal is to make a hard disk image of a really old hard disk drive like Hard Disk 20, you’re all set with the Disk Driver from the Device Manager API.
While I was tracking down a bug in either one of our Jenkins plugins or a defect in the configuration of one of our slaves, I needed a way to run jobs only on particular slave nodes to see if the issue was isolated to appearing on only certain nodes. Again, like many things with Jenkins, the solution is simple if you know how to find it in the documentation. One of the things that makes Jenkins more troubling to understand is how its plugins were used to evolve the methodology over time, but we can wade through the maze they’ve built.
The primary trick is to assign labels to slave nodes and jobs. Jobs with labels will only be run on slave nodes with matching labels. Assigning labels to slave nodes is easy, simply go to the node configuration and type in the labels you please.
For jobs, however, the story is harder. Historically, in the old
non-pipeline Jenkins project methodology, you could edit the project
configuration to restrict jobs to only run on nodes with the matching
labels that you type into the web UI. Alas, those methods are
obsolete, so don’t be fooled by the info you see online about them and
steer clear to find more info on the newer methodologies. In the new
style of pipeline-as-code, you perform this configuration inside the
Jenkinsfile, of course. Namely, each time you declare the agent
statement, you can specify the matching label to use. Conversion
examples:
CRC is reasonably easy and fast to compute in software with the use of a lookup table, not that much worse than XOR checksumming.
So, here’s the algorithm given on Wikipedia…
Function CRC32
Input:
data: Bytes //Array of bytes
Output:
crc32: UInt32 //32-bit unsigned crc-32 value
//Initialize crc-32 to starting value
crc32 ← 0xFFFFFFFF
for each byte in data do
nLookupIndex ← (crc32 xor byte) and 0xFF;
crc32 ← (crc32 shr 8) xor CRCTable[nLookupIndex] //CRCTable is an array of 256 32-bit constants
//Finalize the CRC-32 value by inverting all the bits
crc32 ← crc32 xor 0xFFFFFFFF
return crc32
This is really good to know. So it means it will be reasonably easy for me to implement a full TCP/IP over serial stack on my own, in software using standard C.
In the process of writing a serial communications program for Macintosh Classic, I’ve thought it would be nice to include built-in support for MacBinary and BinHex, rather than relying on the user going to a separate program. So, how I do go about doing this? Let’s see if I can find more information on these file formats online.
I found the specifications for MacBinary, MacBinary II, and BinHex, the main challenge is computing some CRC checksums. But, as I cover in the next blog article, those are also reasonably easy to computer.
20190919/https://en.wikipedia.org/wiki/MacBinary
20190919/http://files.stairways.com/other/macbinaryii-standard-info.txt
20190919/https://en.wikipedia.org/wiki/BinHex
20190919/http://files.stairways.com/other/binhex-40-specs-info.txt
Okay, so after review and working with some of my test code for my classic Macintosh serial disk imager, this is the verdict on how I should build things out. In the end, I might as well go pretty all out on the Macintosh GUI side of things, as the options for my software are quite native and well suited to the provisions of the Macintosh GUI.
We need a main text window display.
First, we list all of the available information on the disk hardware, and display a window that we are ready for the user to configure choices. We also display default or actively configured choices: disk drive, serial configuration, source device, destination device.
We should also support source and destination files, changing type codes, and selecting data versus resource forks.
The menu actions:
- Select source device for reading.
- Select destination device for writing.
- Configure offset and data size for copying.
- Configure serial settings.
- Set RAM buffer size.
How do you get the branch name of a commit hash in Git? Easy, just run this one command:
git rev-parse --abbrev-ref <COMMIT>
And another way to know which branch is the current branch:
git rev-parse --abbrev-ref HEAD
Looking for more choice on what software you could use for monitoring, the eternal classic DevOps problem to solve? Look here for yet more solutions: Omnidistro.
20190917/https://labs.consol.de/omd/
Alas, I am at loss as to why or how the check.com link could have
been of any use, but apparently it was somehow relevant.
20190917/http://check.com/
MacTerminal had limitations in its handshaking support. Hardware handshake, and maybe support for no handshake. Why? This probably would have stemmed from the use of the ROM serial driver rather than the RAM serial driver.
Unfortunately, the Wikipedia article does not include information on this detail, but I’m pretty sure I thought I read it from elsewhere.
20190917/https://en.wikipedia.org/wiki/MacTerminal