A few problems I came across playing around with my new Teensy development board. Decided to
make a quick post on some solutions I found. Enjoy :)
Problem #1
Teensy USB device wasn’t being recognized. You can see the list of
registred devices on Ubuntu using lsusb
Solution
Loaded program code may interfere with the USB registration process.
Use the RESET button then check the output of lsusb again make sure the device
is being recgonized. NOTE: you may have to hold it down and plug the USB device in then release it.
Problem #2
If that wasn’t enough my USB device was being registered under /dev/hidraw0 which
isn’t recognized by the Teensy Loader Application. It only looks at /dev/ttyACM0
Solution
You can get around this by creating a temporary symlink sudo ln -s /dev/hidraw0 /dev/ttyACM0
Just make sure you delete it when your done! This is really hacky, if someone has a better
solution please post in comments :)
This weekend I decided to checkout ReviewBoard a slick Web 2.0 open source Django app for doing code reviews. Unfortunately, it took me quite a bit of time to set it up from scratch with Nginx. Thus, I decided to do a quick writeup for Nginx users.
ReviewBoard’s setup docs is a good starting point for getting the dependencies you need to setup a ReviewBoard website.
Once you have ReviewBoard installed you can generate a website using rb-site install. I setup my website under /var/www/review.mysite.com but you can set it up anywhere if you prefer another location.
The next step is to launch the FastCGI daemon script bundled with ReviewBoard
Sprockets makes it really damn easy in a few lines of ruby to concatenate and serve your coffee script files.
It supports multiple template engines ERB, JavaScript, CSS, SCSS, etc you can
even add a dash of ERB <%= %> to your coffeescript source files by naming your file source.coffee.erb and sprockets will automagically compile it
down with ERB then CoffeeScript and concatenate it with other dependencies!
For the project I was working on I couldn’t depend on Node.js for dependency management since I was creating a front-end browser game. At first I decided to implement my own hacked up solution in Ruby to substitute and concatenate coffee script source files…
it wasn’t pretty :( After moving to sprockets I was able to refactor a few hundred lines into three :)
For example, suppose you have a file that contains sprockets require syntax called Main.coffee
1234
#= require "src/one"
#= require "src/two"
#= require "src/three"
MyApp?={}
Then all you need to do is create a Sprockets::Environment instance and add the source path
For my Operating Systems class CSCI360 we had to write the classic Producer-consumer problem in C using semaphores.
This is a classic problem/solution to preventing race conditions over a shared resource.
For those of you who don’t know what a semaphore is it’s simply a variable that acts as a counter ( with two operations up/down )
which puts a process to sleep if it tries to down/decrement a 0 valued semaphore.
The process will receive a wakeup signal once the 0 valued semaphore is up/incremented by another process.
In the producer-consumer example below we have a critical region (some shared buffer) that needs to be
controlled using semaphores to prevent race conditions.
We create two semaphores one called EMPTY which represents the number of empty slots available
for the producer and another semaphore called FULL to represent the number of slots occupied with items.
If there are no items in our buffer a consumer will goto sleep since it will try to down the FULL counter which will
be 0 because there are no items occupying any slots for it to consume.
Once the producer creates an item it will down EMPTY and up FULL; vice-versa.
In the case of the consumer when it consumes items it will up EMPTY and down FULL.
This might seem a little confusing at first so I created a diagram to
illustrate the process (note: producer/consumer are NOT running in parallel in this diagram).
It is important to note that EMPTY and FULL alone do not prevent race conditions.
This doesn’t cover the case when the buffer is neither full nor empty.
This means we need a third semaphore to lock the shared buffer to prevent consumers and producers from accessing
the shared buffer at the same time.
We call a semaphore with a single counter (initialized to 1)
a binary semaphore or more commonly referred to as a mutex or lock. Using a mutex initialized to
1 when a consumer wishes to consume an item it simply needs to down the mutex before consuming
the item which will prevent other producers/consumers from manipulating the shared buffer.
There are two main semaphore implementations in UNIX-based systems: System V (available in older-systems) and POSIX.
For my example program I used System V implementation.