Saturday, November 13, 2010

Embedding Code Snippets in blogger

I have tested 2 methods.

1. Client side JavaScript library called SyntaxHighlighter. I think this is a decent and easy to use method. It allows the line width of the snippet to be much wider then the blog's column. The annoying part of this method is that if you want to use a language not in the mainline you have to find it made elsewhere or DIY. Obj-C is not in the mainline. HowTo for this method.

2. Use vim :TOhtml to create static html chunks formatted and styled as the code appears inside vim, using vim as a WYSIWYG editor. This method is discussed Here. I modified the vim function provided by that HowTo to output inline html styling since it is easier to embed in blog posts. This solution allows me to easily modify the appearance of a snippet inline and the snippet is based on a dark background. This method allows you to leverage vim for syntax highlighting, which is a huge plus. The disadvantage to this style is that it isn't embedded inside of an H/V scrollable document which means blogger will wrap long lines. This could be fixed by wrapping the html chunk in something to provide the scrollable document area.

My Vim function for generating html chunks.

function! DivHtml(line1, line2)
  exec a:line1.','.a:line2.'TOhtml'
  "remove everything up to <body>
  %g/<\/head>/normal $dgg
  "Change Body to <div>
  %s/<body\(.*\)>\n/<div class="vim_block"\1>/
  "Replace the ending it </div>
  %s/<\/body>\n<\/html>/<\/div>
  "remove all <br> tags
  %s/<br>//g
  set nonu
endfunction
command -range=% DivHtml :call DivHtml(<line1>,<line2>)

^ Was generated with this function. Guess my vim color scheme?

Friday, November 12, 2010

Memory Management

I don't understand the modern day fear of having to manage your program's memory allocation and deallocation. I follow these simple rules when defining how my "objects" are allocated and deallocated. My examples are in Obj-C.

1. Clearly identify which object owns an object instance. An instance is responsible for deallocating whatever it owns.

@interface Expedition : NSObject {}
// Expedition owns this string
@property (nonatomic,retain) NSString *name;
// Something else owns this object
@property (nonatomic,assign) ShipType *ship;
@end
@implementation Expedition
-(void) dealloc {
    // release the objects we own
    [name release];
    // Since Obj-C uses reference counting
    // this can lead to strange behavior
    // Other objects can "retain" name and therefore when we release
    // "name" it doesn't guarantee that it will be dealloc'd
    [super dealloc];
}
@end

2. In every program there is 1/or more objects that are singletons that only have one owner, the program itself. Every other object should be owned by these singletons. 3. Objects that have no clear owner should be added to a pool that is periodical cleared, similar to the auto-release pool from Apple's Obj-C library.

These 2 rules handle almost all situations programmers will run into when managing memory.

Setup - Keybinding toggle between Qwerty/Dvorak

On linux it was honestly sort of a pain in the ass to setup a system for switching between 2 different keyboard layouts. At least from the gui's. Gnome's keyboard preferences didn't have a keybinding for it and neither did xfce. Xfce has a panel plugin to display which keyboard layout is current used but on my Fedora 13 netbook this plugin crashs every time you open and close the plugin's settings. << I need to report this bug to xfce team. This plugin has a default keybinding of shift+caps-locks to shift through the list of layouts selected in the desktop environment settings. I assume there is a nice easy way to set the layout from the command line with 'setxkbmap' but I have no idea how that interacts with the desktop environments so I feel that the current setup is fine. I assume that the Gnome/KDE panel plugin equivalents are less buggy.

OS X was a dream to setup. Normal dvorak is part of OS X and programmer dvorak can be found here. For programmer dvorak place the .keylayout file in your $HOME/Library/Keyboard Layouts/ directory and it will show up in the OS X preferences. On OS X 10.6 the preferences dialog you are looking for is in System Preferences->Language & Text->Input Sources. Add a check to any other layouts you would like to use and I highly recommend setting up a hot-key to swap between the one your learning and the one you already use just incase you in get in a fix, or you need to type something out really quickly.

The most painful part of the whole process of learning a new keyboard layout is dealing with all the application's keyboard shortcuts. Oh I wish there was an OS layer that provided the bindings to Cut, Copy, Paste, Etc so that this would be easier. Until then I will just continue dealing with the Qwerty world as best I can.

Thursday, November 11, 2010

I am learning Dvorak

One of my reasons for starting a blog was so I would have something that I could force myself to type in Dvorak. I recently spent 250 hours in the past 3 weeks working on a educational iPad Game, European Exploration. I have never written as much text on a keyboard before and for the first time ever I experienced typist pains in my hands. I Recently forced myself to learn Vi so taking the leap into learning a new keyboard layout doesn't seem very daunting.

So far I can almost always remember where the new key is at as I'm typing, but I can barely type 20 wpm. I setup key-bindings in my XFCE so I can toggle between Qwerty and Dvorak so I'm not locked in to either if I really need to type something out.

Monday, March 15, 2010

Someone That Dove in Already

Here is a good Throw down of Go's difference's from mainstream languages and an introduction to its shiny new Stuff.
Dove in First

Setup the Vim Editor for Go in Linux

1. Complete Go Installation

2. After completing the installation of the Go code base and building you need to copy the vim syntax file into your vim syntax file directory. There are many other places you could put the go.vim syntax file. This is the way I did it.

sudo cp $GOROOT/misc/vim/go.vim /usr/share/vim/vim72/syntax/

3. Now we have to tell vim what kind of files to use the go syntax for. There are many ways to do this, this is what I did.

mkdir ~/.vim/ftdetect
echo "au BufRead,BufNewFile *.go set filetype=go" > ~/.vim/ftdetect/go.vim

Now you should be setup to begin writing your Go code in vim with syntax highlighting.

EDIT: This is all irrelevant. The readme inside of $GOROOT/misc/vim explains one of the best ways to do this.

There is also a file in the $GOROOT/misc/bash directory that enables bash tab completion for the go compilers and linkers. Copy this into /etc/bash_completion.d/

sudo cp $GOROOT/misc/bash/go /etc/bash_completion.d/

Classic Inheritance in Go Lang

Tar of this Project, extract and run make. Creates binary ChangeMe.app
BasicGoProject.tar.gz

Package and Imports

package main

import (
"fmt"
)

Interface that our Inheritance chain will implement. Analogous to an abstract Base Class in classic Object Oriented Terms.

// Declare an Interface to a 3d Solid
type Solid interface {
Volume() float
SurfaceArea() float
}

This is the base class for this chain of inheritance.

// Contains the Fields for defining a Rectangular Prism's Dimension's
type RectPrism struct {
l, w, h float
}

Implement the Solid Interface for RectPrism.

// RectPrism implements the Solid Interface
func (this *RectPrism) Volume() float {
return(this.l * this.w * this.h)
}

func (this *RectPrism) SurfaceArea() float {
return(2 * (this.l * this.w) + 2 * (this.l * this.h) + 2 * (this.w * this.h))
}

Here is Our first subclass of RectPrism. It inherits all the Fields and Methods attached to RectPrism by listing RectPrism as an anonymous Field. CardboardBox adds a Field aswell since CardboardBoxes can be Soggy.

type CardboardBox struct {
// An anonymous field, all fields of RectPrism are promoted into CardboardBox
RectPrism
isSoggy bool
}

An Open Topped Cardboard Box has to Reimplement the SurfaceArea Method of the Solid interface.

type OpenCardboardBox struct {
CardboardBox
}

We get to reuse the parent class's implementation of SurfaceArea and tack on the new Areas. This is how we use inheritance in Go for code reuse.

func (this *OpenCardboardBox) SurfaceArea() float {
return(this.CardboardBox.SurfaceArea() + 2 * (this.l * this.h) + 2 * (this.w * this.h))
}

And now we get to use an Open Cardboard Box and an Cardboard Box. They both implement the Solid interface so we can use interface's like in any other OO language.

func main() {

fmt.Printf("\n\n");

cbox := new(CardboardBox)
cbox.l = 2
cbox.w = 4
cbox.h = 2
cbox.isSoggy = true

obox := new(OpenCardboardBox)
obox.l = 2
obox.w = 4
obox.h = 2
obox.isSoggy = true

var rprism Solid = cbox
fmt.Printf(" Volume: %f\n", rprism.Volume())
fmt.Printf("Surface Area: %f\n", rprism.SurfaceArea())

rprism = obox
fmt.Printf(" Volume: %f\n", rprism.Volume())
fmt.Printf("Surface Area: %f\n", rprism.SurfaceArea())
fmt.Printf("\n\n");
}

One of the Main Differences between this and a true inheritance based implementation is that there is NO "is a" relationship in our chain. In the situation where we would need to check whether (OpenCardboardBox is a RectPrism) we would have to implement the "is a" relationship ourselves. The code might not be as pretty as that of a classic OO based language, but then again how often do we need the "is a" relationship?