JarrettBillingsley

void doStuff(int[] array) {
	for(int i = 0; i < array.length; i++) {
		System.out.println(array[i]);
	}
	
	if(array.length > 1) {
		array[0]++;
		array[1]++;
	}
	

JarrettBillingsley

; Schematic
; (stick a potentiometer between GND and VCC into PB2 for fun!)
;
;   ATTiny85
; -------------
; |VCC     PB0|
; |GND     PB1|                                10uF
; |        PB2|                         +-------|(------ to headphone jack
; |        PB3|         1K              v      +
; |RST     PB4|-------/\/\/\---+------/\/\/\-+

JarrettBillingsley

(This guide is based on my following this other guide: https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe)

If you have a BMP or some other device with the BMP firmware already, flashing the ST-Link processor (the F103) on a Discovery board is straightforward. But if all you have is one Discovery board - like me - it's possible, but has to be done in a roundabout way.

Discovery boards are really two different parts. Right next to CN1 - the mini-USB connector - is the ST-Link section, which is powered by a small STM32F103 MCU. It has its own bootloader and firmware, separate from the device under test. This ST-Link section is normally responsible for loading, running, and debugging programs on the device under test (DUT).

The DUT is the larger STM part in the middle of the board. I have an STM32F4 Discovery board which has an F407 as the "test" MCU. What we're going to take advantage of is a feature called the DFU bootloader which will allow us to bypass the ST-Link section and instead direct

JarrettBillingsley

macro_rules! vertex_format_inner
(
    (($a: expr, $b: expr), $(($a_rest: expr, $b_rest: expr)),+) =>
        (
            ($a, $b), vertex_format_inner!($(($a_rest, $b_rest)),*)
        );

    (($a: expr, $b: expr)) =>
        (
            ($a, $b)

JarrettBillingsley

#[feature(globs)];
#[feature(macro_rules)];
#[allow(dead_code)];
#[allow(unused_mut)];
#[allow(unused_variable)];
#[allow(unused_imports)];

extern mod gl;
extern mod glfw;
extern mod cgmath;

JarrettBillingsley

// #[link_args = "-ffast_math"];

use std::os;
use std::unstable::intrinsics::sqrtf64;
use std::f64;
use std::from_str::{from_str};
use std::vec;
use std::path::{Path};
use std::io::{File, Open, Write};
use std::io::buffered::{BufferedWriter};

JarrettBillingsley

use std::rc::{Rc};
use std::gc::{Gc};
use std::cell::{RefCell};
use std::vec;
use std::iter::range_step;

type ValNum = int;
type ValStr = Rc<~str>;
type ValArray = Gc<RefCell<~[Value]>>;

JarrettBillingsley

type ValNum = f64;
type ValStr = Rc<~str>;

#[deriving(Clone)]
enum Value
{
	Null,
	Bool(bool),
	Num(ValNum),
	String(ValStr),

JarrettBillingsley

module anagramgen;

import tango.core.Array;
import Path = tango.io.Path;
import tango.io.Stdout;
import tango.io.stream.DataFile;
import tango.io.stream.TextFile;

const ulong[] primes = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101];
const Min = 12;

JarrettBillingsley

Motivation:
	C has long been the king of "systems" languages, but it has problems. It is a relic of a past age, one where memory
	was limited and programs were small, where there were as many computer architectures as there were companies that
	made them, where complex program analysis was too computationally expensive to be practical.

	C and its ABI have become the lingua franca of computing, for better or worse. The C ABI has become the virtual
	machine which virtually all hardware now implements. However, the language is old, creaky, and burdened by decades
	of legacy compatibility issues. Language development has slowed to a crawl due to a design-by-committee development
	model, and compared to most of the other languages that are popular today, it feels very, very limited.