vipyne

Syndicated from Medium

Webster’s dictionary defines cryptography as… I’m just kidding. This blog post is about cryptography, though just an intro.

Just to start somewhere, let’s go over the Diffie-Hellman Public Key encryption method, which uses a symmetric key algorithm. That means that the same cipher is used to encrypt and decrypt a message. In the feature film National Treasure, the cipher on the back of the United States constitution is an example of a symmetric key.*

A lot of digital cryptography is based on what is known as a trapdoor function. The function is difficult to reverse engineer when given just the result of said function. For the purposes of illustration we are just going to use a “door function” (not a real thing). I’m making up that terminology for the purposes of this example. We will pretend that our function is difficult to reverse engineer (but you will see that it is not).

Example trapdoor function (a real thing):

You know there are two numbers that when multiplied, result in 17,078,781,140,149. Without the hint that one of those numbers is 1,766,021, it would be time consuming, if not fairly difficult to determine which two numbers were multiplied to result in 17,078,781,140,149. That ‘hint’ is the trapdoor. (The other number was 9,670,769. With the trapdoor you can divide 17,078,781,140,149 by 1,766,021 and figure that out for yourself).

Example door function (again, not a real thing):

You know there are two numbers that when multiplied, result in 15. No hint is required to determine that the two numbers were 3 and 5. Technically this is still a trapdoor function, we are just calling it a “door function” because it is easy to reverse engineer just by looking at it. Just to repeat, I made up “door function”. I thought it was vaguely humorous and I appreciate whimsy.

I manage to wrap my head around Public Key cryptography like this: multiply a Public Key and a Secret Key to get a common cipher, aka a Shared Secret. Your Public Key and Secret Key are both different than the other person’s Public and Secret Key, but both sets of keys, when multiplied, result in the same shared secret. This is way simplified and the actual math involves Totients and a Modulus but this is Cryptography 101, The Intro Lesson.

Let’s get a cast of characters together to illustrate an example. Meet Ajay, Beyonce, and Christina. Each person’s Public Key is generated by multiplying their Secret Key by 5. Again, in real life, the math in that calculation is sliiiiightly more complicated, but suspend your disbelief with me for then next few paragraphs. It might go without saying but everyone’s Public Key is known by everyone else. It’s public.

Behold, a handy chart to keep it all straight:

Now for the fun part. Ajay writes a message “Hi Beyonce, have you seen the movie Speed?” This message is for Beyonce’s eyes only, so Ajay multiplies his Secret Key by Beyonce’s Public Key and uses the result to encrypt it.

Multiplying those keys results in 75. This is the shared secret between Ajay and Beyonce. For demonstration purposes, our encryption method is to interleave the shared secret between every character of the message, and decryption is removal of all instances of the shared secret. It is quite elementary, but just pretend that on the internet, this makes it impossible to read.

When we apply this totally believable encryption method to the message, this gives:

“H75i75 75B75e75y75o75n75c75e75,75 75h75a75v75e75 75y75o75u75 75s75e75e75n75 75t75h75e75 75m75o75v75i75e75 75S75p75e75e75d75?”

Look at how difficult it is to read now, Internet!

Ajay sends that encrypted message and no one can read it (are you still pretending?!), because they don’t know the shared secret (75). Even if some unnamed nefarious character had Beyonce’s and Ajay’s Public Keys, 25 and 15, neither of these numbers alone help to decrypt the message.

Beyonce receives the message, but due to a Shakespearean misunderstanding, she thinks the message is from Christina. So she uses Christina’s Public Key, 10, with her Secret Key, 5, to decrypt the message. She computes 10 * 5 and gets 50. But when she uses this shared secret and removes all the 50s from the message, it remains encrypted.

Further confusion continues, and now Christina thinks Ajay sent the message to her. Christina uses her Secret Key, 2, and Ajay’s Public Key, 15, to get a shared secret of 30. This too, fails to decrypt the message.

After a bit of hilarity and hijinx, the misunderstanding is resolved. Beyonce knows the message is from Ajay and is intended only for her. She multiplies her Secret Key, 5, and Ajay’s Public Key, 15, to get, wait for it… 75. Their shared secret. Removing all 75s from the message gives:

“Hi Beyonce, have you seen the movie Speed?”

Boom.

Because only Ajay & Beyonce’s shared secret worked to decrypt the message, Beyonce knows for sure that the message was intended for her and that it was sent by Ajay. Ajay “digitally signed” the message because he used his Secret Key.

Needless to say, but I’m saying it anyway, we used easy numbers, easy algorithms (multiplication), and an insanely simplistic “encryption” method. But this is the essence of the Diffie-Hellman Public Key encryption method, symmetric key cipher. Wikipedia has the real math if you are interested.

There are other encryption methods and even other Public Key exchange encryption methods. Search the web for PGP and RSA if you want to venture out of the kiddie pool.

That concludes today’s lesson. Below is optional homework. Be sure to keep an eye out for Cryptography 101, Lesson Two: Asymmetric key algorithms or How to explain coprime numbers succinctly to kindergarteners.

If you would like to play along at home, dear reader, use your browser console to play around with the concept.

The console can be accessed the following ways —  Chrome: View > Developer > JavaScript Console Firefox: Tools > Web Developer > Web Console Safari: download Chrome or Firefox Edge: download Chrome or Firefox

And the code…

const ajaysSecretKey = 3 const beyoncesSecretKey = 5 const commonFactor = 5

function createPublicKey(secretKey, commonFactor) { 

  return secretKey * commonFactor }

function signPublicSecretKey(publicKey, SecretKey) {   let commonCypher = publicKey * SecretKey   return commonCypher

}

function encryptMsg(message, commonCypher) {   let encrypted = Array.from(message).join(commonCypher)   console.log(message)   console.log(`when encrypted becomes:`)   console.log(encrypted)   console.log(``)   return encrypted }

function decryptMsg(message, commonCypher) {   let re = new RegExp(commonCypher,`g`)   let decrypted = message.replace(re, ``)   console.log(message)   console.log(`when decrypted becomes:`)   console.log(decrypted)   console.log(``)   return decrypted }

const ajaysPublicKey = createPublicKey(ajaysSecretKey, commonFactor)

const beyoncesPublicKey = createPublicKey(beyoncesSecretKey, commonFactor)

const sharedSecret = signPublicSecretKey(ajaysPublicKey, beyoncesSecretKey)

console.log(``)

let ajaysMsg = `hi Beyonce, have you seen the movie speed?`

let ajaysEncryptedMsg = encryptMsg(ajaysMsg, sharedSecret) let ajaysDecryptedMsg = decryptMsg(ajaysEncryptedMsg, sharedSecret)

The arguments object in Javascript is odd. It’s literally listed under “Other” in MDN web docs Global Objects. It is not an Array, but is instead Array-like. Cool, Javascipt.

I was reviewing some `gotcha` JS trivia and this always comes up. It dovetails nicely into the more widely known JS trivia of the difference between call and apply. The slice function must be called on Array’s prototype (ie, Array.prototype or [].prototype if you are feeling obtuse). And for the call/apply bit:

From MDN “While the syntax of this function is almost identical to that of apply(), the fundamental difference is that call() accepts an argument list, while apply() accepts a single array of arguments.”

So which do you use on the arguments Array-like object? It is an arguments list, but we’re treating it like a true Array. I think the following exemplifies it:

> function argsFunc(a, b, c) {        var a = Array.prototype.slice.apply(arguments)        var c = Array.prototype.slice.call(arguments)        console.log("a[0]:", a[0])        console.log("a[1]:", a[1])        console.log("a[2]:", a[2])        console.log("c[0]:", c[0])        console.log("c[1]:", c[1])        console.log("c[2]:", c[2])        console.log("Array.prototype.slice.call(arguments)  typeof c[0]:", typeof(c[0]))        console.log("Array.prototype.slice.apply(arguments) typeof a[0]:", typeof(a[0])) } > > argsFunc(1, 2, 3) a[0]: 1 a[1]: 2 a[2]: 3 c[0]: [ 1, 2, 3 ] c[1]: 2 c[2]: 3 Array.prototype.slice.call(arguments)  typeof c[0]: object Array.prototype.slice.apply(arguments) typeof a[0]: number

The results are similar enough in most ways that using call when expecting that apply was used could hide knarley bugs. But now you know this, so you won’t make this mistake. And you know to check for it next time you are troubleshooting.

I got curious how much more efficient it is to compare boolean vs. !boolean. Spoiler alert- it’s one assembly code instruction. Adding a bang to an if statement compare adds an exclusive or (EOR) instruction. Behold the test Swift 3.2 code and complimentary disassembly:

var myBool = arc4random() % 2 == 0

if myBool { print("true") }

->  0x1054a0bec <+264>: ldur   w8, [x29, #-0x2c]

   0x1054a0bf0 <+268>: tbz    w8, #0x0, 0x1054a0ca0     ; <+444> at myfile.swift:176    0x1054a0bf4 <+272>: orr    w8, wzr, #0x1    0x1054a0bf8 <+276>: mov    x0, x8    0x1054a0bfc <+280>: bl     0x105882200               ; symbol stub for: blah

if !myBool { print("false")}

->  0x104ca8ca0 <+444>: ldur   w8, [x29, #-0x2c]    0x104ca8ca4 <+448>: eor    w9, w8, #0x1         ; ADDED WHEN YOU !    0x104ca8ca8 <+452>: tbz    w9, #0x0, 0x104ca8d58     ; <+628> at myfile.swift:179    0x104ca8cac <+456>: orr    w8, wzr, #0x1    0x104ca8cb0 <+460>: mov    x0, x8    0x104ca8cb4 <+464>: bl     0x10508a200               ; symbol stub for: blah

Now let me google that for you. Here are the mnemonic definitions for an ARM (honestly not sure which ARM... arm64 maybe?) instruction set:

LDUR Wt, [base,#simm9] Load (Unscaled) Register: loads a word from memory addressed by base+simm9 to Wt.

EOR Wd|WSP, Wn, #bimm32 Bitwise exclusive OR (immediate): Wd|WSP = Wn EOR bimm32.

TBZ Xn|Wn, #uimm6, label Test and Branch Zero: conditionally jumps to label if bit number uimm6 in register Xn is zero. The bit number implies the width of the register, which may be written and should be disassembled as Wn if uimm6 is less than 32. Limited to a branch offset range of ±32KiB.

ORR Wd|WSP, Wn, #bimm32 Bitwise inclusive OR (immediate): Wd|WSP = Wn OR bimm32.

MOV Wd|WSP, Wn|WSP Move (register): alias for ADD Wd|WSP,Wn|WSP,#0, but only when one or other of the registers is WSP. In other cases the ORR Wd,WZR,Wn instruction is used.

BL label Branch and Link: unconditionally jumps to pc-relative label, writing the address of the next sequential instruction to register X30.

Complete PDF on instruction set here.

Let’s talk about texels, baby.

Yesterday Lyn and I repurposed our bubble shader code texture to handle the data coming from the LeapMotion.

A Texel is a unit describing the pixel (usually color) information at a specific coordinate of a texture (usually an image). These UV coordinates are normalized (that is, no matter what the actual size, the coordinates range from 0 to 1). GPUs are really good at handling textures fast so instead of sending a bunch of separate float uniforms to the shader, we can fill a texture with said floats and send that texture to the shader. I think of a texture like an array, but it’s a little different because it can’t be accessed by index, it must be accessed by UV coordinates and this is where my brain just fills in some GPU magic to make it make sense. The information-is-just-raw-data-not-actually-an-image texture use case is why there is such thing as a Sampler1D or a one dimensional texture.* Except in WebGL, there is no Sampler1D, so we just used Sampler2D and ignored the y coordinate part (or more accurately, semi-arbitrarily set it to 0.5). Getting the correct x coordinate value can be tricky, as one wants to get the value of the center of the texel and not the actual start of the texel. The size of one texel is computed as:

By sizeOfTexture here, we mean the length of the data (like the length or size of an array). Half a texel is one texel divided by two or:

We take the index of the value we want and divide by texture size to get the start of the texel. We then add half a texel size to get the coordinate of the center of the texel:

We use that coordinate to access the value of the texel in the texture. Like using an index to access a value in an array. But not exactly. Because GPU and floating point magic.

Now that one texture is under your belt, its time to learn GL universal truth number #57: If you are using two textures in a shader, the second one is probably not actually getting sent to the shader and you won’t know it for several hours.

On the Berlin front, Spektrum is cool and Sudanese food is delicious and affordable.

This blog is usually fairly technical (and hilarious, right... RIGHT!?) but the next bit is a little touchy feely.  You can skip to after the gif for regularly scheduled programming.

“If you are an artist and you are honest, you are never good enough.”    -Jenny Holzer

This quote is resonating with me right now. The awesome Rachel Uwa at the School of Machines, Making & Make Believe (where RC pop up Berlin is HAPPENING) has been encouraging us to incorporate personal meaning into our work here.  As an engineer with an art background, I very much understand the need for accessibility in art, especially art forms generated with code.  I think a lot of why I code what I do has to do with going deeper into the stack.  It’s not enough to just make pretty images in AfterEffects, I have to write the code that makes the pretty images.  Or even write the code that makes the AfterEffects.  I probably won’t be satisfied until I’ve soldered all the circuits on the computer that runs AfterEffects that makes the pretty images.  But if I’m honest, even then, probably not.

I did get a long time personal project kind of off the ground today.  moshpyt has been rattling around in my brain and filesystem for a while.  Someday it will be a CLI to datamosh videos using ffmpeg.  For now, I got the above silly Proof Of Concept to work.

In other news on the shared-dream front, I got the Leap Motion recorder working.  And I learned that every lzipped file starts with the “magic” bytes "LZIP" (0x4C, 0x5A, 0x49, 0x50).  I learned this because I think there is something wonky with all the lzipped json examples.   They all start with “N4Ig...” and when I try to decompress them:

$ lzip -d example.json.lz $ lzip: example.json.lz: Bad magic number (file not in lzip format).

TODO: give you, dear reader, background on what an ‘RC pop up Berlin’ is.

The cataloging of beautiful f ups has begun.  We didn’t get quite as far as we would have liked today, but in spite of jet lag, we still made some pretty bad ass progress on our shared dream.  In revitalizing some fragment shader code we had worked on last year, Lyn had the foresight to mention that we should go back at some point and put a mirror effect on this pretty broken commit.  This could turn into a bit of a snow(meta)ball.  Some pretty f ups:

Sometimes, you want to break things. And I don’t just mean that feeling of wanting to break actual physical things when xcode gives one of its Sound and the Fury-like riddle errors. I mean sometimes you want to break your app to test things.

Here’s a handy little thing to throw to break what you want to break:

enum myIntentionalError: Error {  case UhOh(String) }

do {  throw myIntentionalError.UhOh("my super original error message") } catch myIntentionalError.UhOh(let message) {  print(message) } catch {  print("sumpin' else went wrong") }

Forgive the lack of clever double entendres in this straight forward post about iOS development with GLKit / Swift.  I know next to nothing about Xcode and even less about Swift.  My background is in Javascript, C, and AfterEffects, so given that, some things are very intuitive, others, not so much.  As I embarked on my google learning journey, I discovered what Ken observed: there is a lot of GLKit documentation out there... but its all in Objective C.  Shout Outs for this post also go to Ray and Swiftly as this “tutorial” is basically just a mash up of those resources.  

Without further ado, here is a hello world, if your world is iOS / GLKit / Swift.

Assumptions: - You know enough to be dangerous with an object oriented programming language.   - You have Xcode and all that command line tools crud installed. - You have some vague knowledge of {Open,Web}GL.

1. open Xcode 2. choose Single View Application 3. make sure language is set to `Swift` 4. in “ViewController.swift” change "UI"s to "GLK"s:

import GLKit class ViewController: GLKViewController { 

5. inside the "viewDidLoad()" function add:

var view: GLKView? = (self.view as? GLKView) view?.context = EAGLContext(api: .openGLES2)

6. after the "viewDidLoad()" function, add this new function:

override func glkView(_ view: GLKView, drawIn rect: CGRect) {    glClearColor(1.0, 1.0, 0.0. 1.0)    glClear(GLbitfield(GL_COLOR_BUFFER_BIT))  }

7. click on “Main.storyboard” and delete the default view

8. drag a "GLKit View Controller" from bottom right Object Library to the storyboard.  Should be looking like this about now:

9. click on buttons `1` and `2` in that order to make this new view the entry point. the arrow circled by `3` should appear

10. click on the top left yellow icon (GLKit View Controller) and change the custom class to "ViewController"

11. hit Command R (or Product > Run if you’re not into the whole brevity thing) to build and test run your code.

12. if the screen on your iPhone / simulator is orange, celebrate!  if not, go through your normal troubleshooting shame spiral.

Here is some copy pasta code that adds in a button to toggle background colors. (Watch this 3 min youtube video to see how to link the button to the GUI.)

import GLKit

class ViewController: GLKViewController {    var cc = [Float](arrayLiteral: 0.0, 1.0, 1.0, 1.0)

   override func viewDidLoad() {

       super.viewDidLoad()

       // open a GL context        var view: GLKView? = (self.view as? GLKView)        view?.context = EAGLContext(api: .openGLES2)    }

   @IBAction func buttonClick(_ sender: AnyObject) {        toggleClearColor()    }

   func toggleClearColor() {        if 0.0 == cc[0] {            cc[0] = 1.0            cc[2] = 0.0        } else {            cc[0] = 0.0            cc[2] = 1.0        }    }

TL;DR: skip all the steps and advance to go with this gist.

FUN FACT: if you already have a README file in your repo, the npm init utility will use that to populate “description” in the package.json.  kinda cool.

step 0. anything “cli_prompt $ in italics” is a command line command and

anything in blockquote is code to be copy pasta-ed into a file

step 1. create a repo on Github. extra credit: initialize with a Node flavored .gitignore

step 2. clone the repo and cd into the directory.

step 3. cli_prompt $ touch README.md

# My Module

## This is the rockin’ description of my module.

step 4. cli_prompt $ npm init extra credit: have a command handy to run a test of your module (ie. `tape test/index.js` or something)

step 5. cli_prompt $ touch index.js

'use strict' module.exports = {     MyModule: require('./my_module')     // ,... }

step 6. cli_prompt $ touch my_module.js

'use strict' module.exports = MyModule function MyModule()  {    // baller code. or you know, just javascript }

step 7. cli_prompt $ mkdir test                                $ touch test/my_module.js                                $ mkdir example                                $ touch example/index.js                                $ touch example/index.html                                $ touch example/my_module.js

You should now have a directory structure that looks something like this:

This gist contains code that you can copy pasta into the test/ and example/ files. (I was going to put it here but code syntax here is less than optimal.)

There you have it. Step by step. Oh baby.

Tale as old as time: WebGL code that works in Chrome & Firefox but not in Safari.  

We lay our scene at Littlstar, while working on Axis3D (built on top of Regl). The lead in this story is an error called: “webgl_e35709c900000017.webgl_95afddc00000015.webgl_78e80f8800000014[0].webgl_61b75b530000000f.”  

What in the samhill is “webgl_e35709c900000017.webgl_95afddc00000015.webgl_78e80f8800000014[0].webgl_61b75b530000000f”?

The investigation begins. The “webgl” bit is fairly self incriminating. That combined with Safari being the offensive browser, webgl is definitely the issue.  “bad data or missing for uniform”... something is wonky with the uniforms, that means we’re dealing with the shadiest of webgl characters: shaders. The error only occurs in Axis3D Phong and Lambert material examples, so the Lambert shader becomes the code of interest. There are three types of lights Directional, Ambient, and Point in this shader.  Of the three, Ambient is the simplest so I rendered the scene with only that light. The error persisted. I was getting closer.

Next I lowered the MAX_AMBIENT_LIGHTS of lights to 1 to rule out a “too many uniforms” error.  Still happening. 

Here are the code snippets that touch Ambient light:

struct AmbientLight {  vec4 color;  bool visible; };

struct AmbientLightsContext {  int count;  AmbientLight lights[MAX_AMBIENT_LIGHTS]; };

struct LightContext {    DirectionalLightsContext directional;    AmbientLightsContext ambient;    PointLightsContext point; };

And here is a modified visualization of the nested structure:

Anything referring to any light in the array, even simple variable initiation, resulted in the same error.  

I am joined by PIC and we tried moving all attributes to one struct and the error disappeared! But why? We looked to see how webkit handles shaders.  @jwerle* started digging through source code. The issue was recreated to ensure it was really the cause of the error.  The moral of the story is confirmed:

One cannot nest an array of structs inside another struct in glsl in Safari. 

And there you have it, folks: another Safari idiosyncrasy exposed. Not the typical end to a fairy tale investigation, but hopefully it saves you an afternoon of cursing Safari.

Say you’ve got a bunch of SVG icons.  Browser compatibility is spotty with those, but scalability is like, the biggest part of “responsive websites.”

One solution is to create a font out of said icons.  Then they are just like the letters you are reading right now.  Plus they’re all in one file.  No fuss, no muss.

All the letter characters here are in Unicode.  For example, a whitespace character will always have the unicode value of 0x20.  There is something called the Unicode  Private Use Area- This is a range of codes set aside that anyone can assign to their own character.  These codes start at 0xF101. (And by default, this the code where grunt-webfont starts.)

The two parts of this process I was spotty on were A.) creating a font from separate svg files and B.) actually getting these things to show up on a web page.

Short Answers:

A.) grunt-webfont

B.) css psuedo element with content: <PUA hex code> and src: url(<to/my/font.woff>)

Longer Answer:

If you are hungry and would like some Copy Pasta, you are in luck.  Here is the interesting stuff:

$ npm install grunt -g

$ npm install grunt-webfont -g

    // gruntfile.js     module.exports = function(grunt) {       'use strict';

      grunt.initConfig({         webfont: {           input: {             src: 'svgs/*.svg',             dest: 'output/font',             options: {               types: ['woff'],               hashes: false,             }           }         }       });

      grunt.loadNpmTasks('grunt-webfont');     }; $ grunt webfont         /* CSS */       @font-face {         font-family: myCustomIconFont;         src: url(/iconFont.woff2);       }

       .icon::before {         font-family: myCustomIconFont;         content: '\F101'; /*1st icon in font*/       }        

      /* HTML */       <meta charset="UTF-8">       <div class="icon"></div>

I love watching the green squares on my Github page turn green.  But sometimes you want the squares to turn green, but whatever you have been working on doesn’t count as a contribution.  If you are working on a branch other than master, commits do not count as contributions.  One could argue that these commits from that day would retroactively turn a square green once that branch is merged with master.  This is true.  But if you are like me sometimes you go on a tangent, and said branch never ends up in master.  To address this I decided to automate a rewritten history.  I turned this:

into this:

$ git commit --amend --no-edit --date "whatever date you want*"

This changes the AuthorDate and not the CommitDate.  AuthorDate is presumable what Github looks at to determine square color.  This line also only works if you are changing the date of the last commit.  But what if you want to change dates from commits long ago?  [ACHTUNG: The following will create a new SHA for the commit.  It will tooooootally mess with your git history.  I highly recommending only playing around with this in a repo exclusively created for messing around with this.]  Ok, with the disclaimer out of the way:

$ git filter-branch --env-filter \    'if [ $GIT_COMMIT = <your FULL commit SHA here> ]     then         export GIT_AUTHOR_DATE="New Date Formatted like:"         export GIT_COMMITTER_DATE="Sun Jan 1 12:00:00 2017 -0500"     fi'

You don’t have to export the committer date as well, but it’s nice to know you can.  --no-edit stops the text editor from asking you if you would like to change the commit message.  Thanks to Maia for that tip!  Also, after running this command but before you make any new commits, double check that $GIT_AUTHOR_DATE (and $GIT_COMMITTER_DATE) are set to nothing.  If

$ echo $GIT_AUTHOR_DATE

returns a date, you can set it back to blank ala:

$ export GIT_AUTHOR_DATE=

Here is the script I wrote to make all my contribution squares green (and thus the impetus behind this post).  It’s not real pretty at the moment, but it gets the job done.  As long as its Jan. 10, 2017.  But we can fix that in the future.

Javascript will cast a string to an integer with parseInt( "345" ) => 345 Javascript will cast a string to a float with parseFloat( "345.68" ) => 345.68

parseInt("float") will drop all numbers after the decimal point. (see purple circles) parseInt("int") === parseFloat("int") parseInt("float") !== parseFloat("float")

One can also use Math.floor("float").  This seems to produce the same result as Math.floor(parseFloat("float")).

Thanks Javascript.  That is exactly how I would want and expect you to act. I am amazed.

One could always parse all number strings with parseFloat() and this would preserve float and integer types OR one could add a + in front of said number string and still preserve float and integer types.

I’m not necessarily advocating this. It’s not ideal for readability and dynamic typing is not a super “good” thing in my opinion. But if for some reason you needed to coerce number strings into both ints and floats, then this might be better than always using parseFloat() (which suggests that all the strings are floats). It’s a mildly cool party trick if nothing else.

This last screenshot sums it all up:

it all comes down to memory addressing. 

sometimes you write a program in C that produces the fourth point on the axis of evil: segmentation fault: 11. most times you can put a breakpoint in your code and debug. except for the times you can’t.

enter the Heisenbug - an error that occurs in normal runtime but is not reproduced when said program is run through a debugger, such as lldb. a few possible reasons why this could happen:

- race condition.  More likely if program is multi-threaded.  Or written in Javascript and makes HTTP requests.  BuDumChing.

- accessing uninitialized memory.  Spoiler, this was my program’s issue. The program was reading the value from an address I had not explicitly written.  Sometimes that memory’s value is innocuous and happens to work for your program. This is more likely when one is running said program through a debugger. I like to think of debuggers as running your program in a garage: there’s lots of room everywhere and it’s less likely something occupied that space before your program.  Without a debugger your program runs in the junk drawer: there is much less space to work with and you almost definitely have to take old stuff out to put your program’s stuff in.  If you forget to do that, your program may barf.

let’s take a second and review lldb debugging.  this is the order of commands i generally go through:

$ lldb (lldb) target create your.exe (lldb) breakpoint set --line 123 // set breakpoint at suspicious line (lldb) r <args> // run program with arguments your program needs

// when paused in breakpoint:

(lldb) frame variable // show variable values currently in scope (lldb) po  // “Evaluate an expression on the current thread.”  1: <expression>  2: <expression result> (lldb) register read // list addresses currently in all general purpose <registers...values> (lldb) x <address> // show values of each bit starting from <address> (lldb) disassemble // show list of machine instructions and corresponding addresses (lldb) bt // backtrace - show frames, addresses, and instructions

(lldb) n // step to next line (lldb) c // continue running program

Pro Tip:  when your program spits out “Segmentation fault: 11 (core dumped)” this is where it dumps in OSX: `/Users/username/Library/Logs/DiagnosticReports/`

this .crash file will tell you cool things like the Thread State by printing all the values in each register.  and Binary Images. what are Binary Images? i have no idea, but this will give you a crash course on .crash files. no. i have no regrets about making that pun.

valgrind was more explicit in telling me the problem. --tool maps to the Conditional jump statement and the --track-origins maps to the value was created by stack statement.

$ valgrind --tool=memcheck --track-origins=yes ./your.exe [arg1] [arg2] 

==42299== Conditional jump or move depends on uninitialised value(s) ==42299==    at 0x100000B19: main (llcoolstack.c:109) ==42299==  Uninitialised value was created by a heap allocation ==42299==    at 0x100009ABB: malloc (in /usr/local/Cellar/valgrind/3.11.0_1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) ==42299==    by 0x1000008FC: push (llcoolstack.c:47) ==42299==    by 0x100000ACC: main (llcoolstack.c:101) ==42299==

the third member of the C debugging holy trinity is Xcode. if you are into the GUI thing, nothing tops it. i mean, this visualization of linked lists is perfection:

you can immediately see that last pointer address is not like the others.  here is the same after the bug was fixed:

I’ve been keeping this running list of apps/languages/frameworks I have installed since I’ve been at the Recurse Center.

this post chronicles the issues one runs into when playing with CUDA and OpenGL on a Mac.  the former may cause you to ask what C compiler will work with nvcc. (skip to middle of post for the answer.) developing with the latter may lead you to ask the question: what version of OpenGL am i using? hints :   --version and printf(GL_VERSION) don’t work :/

this is a perfect time to take a timeout and go over how to tell what GPU your Mac* computer (and thus OpenGL) is using in the first place. the information you seek can be found here: System Preferences > System Report > Graphics/Displays.

i have two GPUs; Intel and NVIDIA/the man. how do i know which card is being used? great question. the answer can be found here: chrome://gpu

go ahead type chrome://gpu into a Chrome browser window. it goes without saying that this trick doesn’t work in Safari or Firefox. also, you might be a little scared that Chrome knows all the things about the machine you are using.

Chrome not only knows i have two GPUs (GPU0 and GPU1) it knows which one i am using (*ACTIVE*) and the type of GPU (GL_RENDERER). and GL_VERSION reveals that we are using OpenGL 2.1 (note this is different than WebGL version)

but what if the Intel card was set to active? then may i direct you to System Preferences > Energy Saver > Automatic graphics switching

great. we are definitely using the NVIDIA for our OpenGL program development. to get your Mac to use a higher version of OpenGL 2.1 is a little complicated.

honestly, let me just Stack Overflow it for you: http://stackoverflow.com/a/26981800/3191800

that isn’t meant to be passive aggressive. it took hours to find and i’d like to save you the frustration. the answer is basically use GLUT (if you aren’t already) and add the magic GLUT_3_2_CORE_PROFILE constant to glutInitDisplayMode params. more specifically bitwise or it like so: glutInitDisplayMode(GLUT_RGBA | GLUT_3_2_CORE_PROFILE). fun fact: the | (single pipe) is a bitwise OR, similar but definitely different from || (double pipe) boolean OR.

that’s all i have to say about that. for now.

this actually started out as a post about my hello world experience with CUDA. its just another API to interface with your GPU. i feel like i need to mention OpenCL along side CUDA. OpenCL is like Betamax and CUDA is like VHS. they both accomplish the same things. i don’t actually know if the former is better in a performance or usability way, but it is better simply by being a hardware-agnostic open standard. the latter is an API that only works with NVIDIA graphics cards. unfortunately, more people are using CUDA, so it seems to be eclipsing OpenCL. thus vhs/betamax dynamic. side-note: a list of graphics cards that support OpenCL is available on Khronos’ site. i’m not trying to throw too much shade; CUDA is cool if you have an NVIDIA GPU. but it feels a little dangerous to use an API that only works with one brand of graphics cards. (from here on out, NVIDIA will be referred to as “the man”). but i don’t want this blog to get political.** here are the steps to say hello world via CUDA-

step zero, have an NVIDIA graphics card.

step one, install CUDA.

$ brew install Caskroom/cask/cuda

ensure that /usr/local/cuda/bin/nvcc is in your $PATH. if you get an error like “nvcc fatal   : The version ('80000') of the host compiler ('Apple clang') is not supported” the easiest thing to do, imo, is to install a different C compiler and pass in a flag to use that one when compiling with nvcc. so:

$ brew install clang++-3.7

then compiling your hello_world.cu file would look something like:

$ nvcc hello-world.cu --compiler-bindir $(which clang++-3.7)

i’m lazy and haven’t put nvcc in my $PATH yet so i do this:

$ /usr/local/cuda/bin/nvcc hello-world.cu --compiler-bindir $(which clang++-3.7)

run your program and you have successfully and explicitly made your GPU do something. nice job.

*sorry Linux and PC*** users.

**jk, i make little effort to make this blog objective.

this icon was the inspiration for my site revamp. here are some of my in progress screen captures because i take all the screenshots and i need to feel like there is a reason for doing it. thus this post.