Chris Zelenak netshade

So I tried to find an authoritative source for you on this, but I believe it depends on the vendor.

When it comes to Linux (and iOS, it seems) you can assume that long == machine word size. A machine word is how your architecture addresses memory - on a 32bit machine Linux or iOS system, a long is 32 bits wide. On a 64 bit system iOS or Linux system, it's 64 bits wide. You'll note I hedge strongly here on referring to Linux or iOS. Windows has different behavior, and I've seen enough anecdote to imply that there are in fact many different interpretations of what int and long should be. This wikipedia article is instructive.

In the case of your SO example, on a 32 bit machine it just so happened that UInt32 and unsigned long took up the same number of bits. Hooray! On a 64 bit machine, unsigned long happened to take 64 bits, whilst UInt32, as you might assume, took 32 bits.

Now, where it gets a bit weird is that the unsigned long _(a 64 bit value on y

So this thing has been happening a lot lately as I observe game developers talk about data. They have multiple phases to how data is dealt with, namely:

Data when it must be written to (designed)
Data when it is being read (played)

And they treat the data in very different ways. During the design phase, data is expressly flexible and transformable. Store it in XML? Dynamically allocate all the things? Objects whose properties can be discovered at runtime? All acceptable ideas, because efficiency isn't the /point/ during this phase.

But in the transition from design phase to play phase will traditionally have a baking step, wherein the data as designed is turned into a very efficient (and mechanically simple) representation. What was once a 2MB XML file is now a 200kb packed binary representation that can be mmap'd and read directly from structs.

The efficiency in this case isn't the thing I'm interested in, however. It's the guarantee of representation and the understanding that data as it enters

Here's what's been good so far about React:

As UI components get more complex in JS, there's this inevitable attempt to push state into the actual HTML. Check a DOM node for an attribute, then act off of it. As that pattern begins to increase, more and more code starts deferring a UI's logical state out to the physical state of the DOM. This rarely seems to be what is intended.

What is intended is that the application /knows/ what the right state is, and the HTML is a side effect of reflecting that state. React encourages good practice in making the HTML a side effect of a React component's props, and efficiently handles the tree transitions. Without getting into the mechanics of how I personally structure React components, the set of guarantees you get when pushing as much "immutable properties, reproducible layout" into your components lets you have these really trustworthy, easy to develop UI pieces that don't inherit the bad parts of UI programming where you call out to application and implementation pr

	[
	[39.76086989, -86.09757829],
	[39.7863158, -86.18213742],
	[39.79117821, -86.14879769],
	[39.81917532, -86.10297819],
	[39.79636724, -86.08487503],
	[39.77425791, -86.14833736],
	[39.72851886, -86.1906329],
	[39.80005767, -86.0743134],
	[39.76392219, -86.11534466],

	//
	// PCSingletonExample.h
	// Lab11
	//
	// Created by Chris Zelenak on 12/6/13.
	// Copyright (c) 2013 Bootstrapping iOS. All rights reserved.
	//

	#import <Foundation/Foundation.h>
	#import <CoreData/CoreData.h>

	// to initialize the nsoperationqueue
	NSOperationQueue * queue = [[NSOperationQueue alloc] init];
	[queue setMaxConcurrentOperationCount:4];

	// to add an operation to the context
	NSOperation * op = [NSBlockOperation blockOperationWithBlock:^{
	int i = 0;
	dispatch_async(dispatch_get_main_queue(), ^{
	// update ui
	});

	#include "bloom.h"
	#include <stdio.h>
	#include <stdlib.h>
	#include <assert.h>
	#ifndef DEBUG
	#include "filter.h"
	#include "filter_bytes.h"
	#endif

	#define BUFFER_SIZE 8192

	#!/bin/bash
	if [ -z "$1" ]; then
	echo "Usage: sudo $0 /dev/sdh1"
	exit 1;
	fi

	dd if=$1 of=/dev/null & pid=$!
	while true; do
	ps -p$pid --no-heading \|\| break;
	echo "-- $(date) ------------------";

	# Ruby 2.1, Macbook Pro 2.6 i7, 16GB RAM
	# Only 1 iter, I know i know i know

	irb(main):001:0> require 'benchmark'
	=> true
	irb(main):002:0> h = {}
	=> {}
	irb(main):003:0> 1000_000.times.map { \|i\| h[i] = i }; nil
	=> nil
	irb(main):004:0> Benchmark.realtime { h.dup }

	; /Usr/local/bin/nasm -f macho64 64.asm && ld -macosx_version_min 10.7.0 -lSystem -o 64 64.o && ./64

	BITS 64

	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	; The .data section is for storing and naming constants.
	;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	section .data

	msg: db "Hello, world!", 10