Installing Eclipse Luna on Debian

A really quick guide on installing Eclipse Luna on Debian.

If you’re on a fresh machine, and you’re downloading/installing Eclipse for the purposes of Java development, you’ll want to install the JDK. To get this going, I install the openjdk-7-jdk out of the apt repository.

$ sudo apt-get install openjdk-7-jdk

After that finishes, or while, grab a copy of the Eclipse version that you need from the download page. Once it’s down, I normally extract it and then put it in a system-wide location (as opposed to just running it from my home directory).

$ tar -zxvf eclipse-*.tar.gz
$ sudo mv eclipse /opt

One little oddity before starting Eclipse up, I’ve had to apply a GTK setting. Prior to making this setting, Eclipse would crash!

Add the following lines to you /opt/eclipse/eclipse.ini file. Make sure it appears before the --launcher.appendVmargs directive.

--launcher.GTK_version
2

Flask deployment with nginx and uwsgi

Taking your applications from the development web server into a full application server environment is quite painless with nginx, uwsgi and virtualenv. This post will take you through the steps required to get an application deployed.

Server Setup

First of all, you’ll need to get your server in a state where it’s capable of serving HTTP content as well as housing your applications. If you’ve already got a server that will do this, you can skip this.

$ sudo apt-get install nginx uwsgi uwsgi-plugin-python python-dev python-setuptools build-essential
$ sudo easy_install pip
$ sudo pip install virtualenv

This will put all of the software required onto the server to house these applications.

Application setup with uWSGI

Each uWSGI application’s configuration is represented on the filesystem as an ini file, typically found in /etc/uwsgi/apps-available. Symlinks are established between files in this directory into /etc/uwsgi/apps-enabled to tell the uwsgi daemon that an application needs to be running.

The following is an example uWSGI configuration file that you can use as a template:

[uwsgi]
vhost = true
chmod-socket = 666
socket = /tmp/app.sock
plugins = python
venv = /path/to/proj/env
chdir = /path/to/proj
module = modulename
callable = app

This will get our application housed by uWSGI. You can now enable this application:

$ sudo ln -s /etc/uwsgi/apps-available/app.ini /etc/uwsgi/apps-enabled/app.ini
$ sudo service uwsgi restart

Web server setup

Finally, we’ll get nginx to provide web access to our application. You may have specific web site files that you need to modify to do this, but this example assumes that you’re in control of the default application.

Add the following section to /etc/nginx/sites-available/default:

location /app {
        include uwsgi_params;
        uwsgi_param SCRIPT_NAME /app;
        uwsgi_modifier1 30;
        uwsgi_pass unix:/tmp/app.sock;
}

Reload your web server config, and you’re ready to go:

$ sudo service nginx restart

PhoneGap Setup on Arch Linux

Here’s a few notes to getting PhoneGap up and running on an Arch Linix installation.

Dependencies

PhoneGap itself relies on some java tools, so you’ll need a jdk and ant.

$ sudo pacman -S jdk7-openjdk
$ sudo pacman -S apache-ant

In order to run your applications in an android simulator, you’ll need the android sdk installed. For the next steps, you’ll need to ensure that multilib is enabled in your /etc/pacman.conf file.

You’ll need the following packages installed from AUR:

• android-sdk
• android-sdk-platform-tools
• android-sdk-build-tools
• android-platform

After these have been successfully installed, using the suggested installation procedure guidance on the wiki, you’ll need to put these tools on your path:

$ export PATH=$PATH:/opt/android-sdk/tools:/opt/android-sdk/platform-tools:/opt/android-sdk/build-tools

PhoneGap is installed using npm which is part of the NodeJS suite, so you’ll need to have it installed as well:

$ sudo pacman -S nodejs

Installation

From the PhoneGap installation guide, installation should be just:

$ sudo npm install -g phonegap

Device Setup

Before you can run any applications, you’ll need to setup a device. No cpu images are installed by default, so you’ll need to install these first using the android command.

After installing the appropriate images, you can create a device using android avd.

Getting istream to work off a byte array

Introduction

The C++ Standard Library provides an extensive library for working with streams. These are abstract classes designed to work with data that is in a stream format. There are comprehensive concrete implementations for working with files and strings, however I’m still yet to find an implementation that will take a plain old c-array and allow you to treat it as a stream.

In today’s post, I’ll present a small std::istream implementation that will consume these plain old c-arrays so that you can keep the rest of your APIs uniform to using stream objects.

A brief explanation

We’ll actually be developing two classes here. We’ll need a class to derive from std::istream which is what we’ll pass around to other parts of our program, but internally this std::istream derived object will manage a std::basic_streambuf<char> derivative.

Looking at the definition of a std::basic_streambuf we can see the following:

The class basic_streambuf controls input and output to a character sequence.

It would appear that most of the work here has been done for us. basic_streambuf will take care of the I/O from our character sequence, we just need to supply it (the character sequence, that is). I did say byte array in the title of this post, so the actual data type will be uint8_t* as opposed to char*.

Implementation

class membuf : public std::basic_streambuf<char> {
public:
  membuf(const uint8_t *p, size_t l) {
    setg((char*)p, (char*)p, (char*)p + l);
  }
};

Our implementation of basic_streambuf must abide by the char_traits type definition, so we get as close to our byte definition as possible with char. You can see that the constructor has a little bit of cast work going on to get setg to operate correctly.

Finally, we just create an istream derivative that uses this membuf object under the covers:

class memstream : public std::istream {
public:
  memstream(const uint8_t *p, size_t l) :
    std::istream(&_buffer),
    _buffer(p, l) {
    rdbuf(&_buffer);
  }

private:
  membuf _buffer;
};

We set the internal buffer that memstream will use by making a call to rdbuf. The constructor performs some initialisation of the stream itself (to use a membuf) implementation.

In Use

You can now treat your plain old c-arrays just like an input stream now. Something simple:

uint8_t buf[] = { 0x00, 0x01, 0x02, 0x03 };
memstream s(buf, 4);

char b;

do {
  s.read(&b, 1);
  std::cout << "read: " << (int)b << std::endl;
} while (s.good());

That’s all there is to it. From the snippet above, you can pass s around just like any other input stream, because, well, it is just any other input stream.

Basic Aeson Usage

Introduction

JSON is a common interchange data format used across the web these days. It’s so popular because it’s easy to work with, marries directly with Javascript (really helping out the web guys) and its structure allows you to specify complex information in a simple, readable format.

In today’s post I’m going to walk through some basic usage of the Haskell library aeson which provides some tools for working with JSON.

Getting started

First of all, you’ll need the aeson library installed locally to work with it. You can install this with cabal:

$ cabal install aeson

While that’s installing, take a look at the examples up in the repo for aeson.

Defining your data structure

The first example, Simple.hs starts with defining the data structure that we’re expecting to work with:

data Coord = Coord { x :: Double, y :: Double }
             deriving (Show)

This is pretty simple. Just a 2d co-ordinate. The example goes on to define instances of ToJSON and FromJSON to facilitate the serialization and deserialization of this data (respectively).

instance ToJSON Coord where
  toJSON (Coord xV yV) = object [ "x" .= xV,
                                  "y" .= yV ]

instance FromJSON Coord where
  parseJSON (Object v) = Coord <$>
                         v .: "x" <*>
                         v .: "y"
  parseJSON _ = empty

The only really curly bit about this, is the use of the (.=) and the (.:) operators. These will pair-up or extract data in context of your JSON object.

Simplify

With all of this said, now take a look at Generic.hs. This file makes use of the DeriveGeneric language extension to write the ToJSON and FromJSON implementations above. Those type class instances now read as follows:

instance FromJSON Coord
instance ToJSON Coord

The type of Coord needs to be augmented slightly to include the Generic type class.

data Coord = Coord { x :: Double, y :: Double }
             deriving (Show, Generic)

Pretty easy.

Reading and writing

Finally, we need to actually poke a string into this thing and pull built objects back out of it. The main covers this:

main :: IO ()
main = do
  let req = decode "{\"x\":3.0,\"y\":-1.0}" :: Maybe Coord
  print req
  let reply = Coord 123.4 20
  BL.putStrLn (encode reply)

You can see that we can turn a string into a Coord object with little effort now.

Extending this a little further to read values off of disk, we can lean on readFile from Data.ByteString.Lazy:

λ> x <- (eitherDecode <$> B.readFile "coord.json") :: IO (Either String Coord)
λ> x
Right (Coord {x = 3.5, y = -2.2})

eitherDecode was either going to give us an error message on the Left, or the built object on the Right.

That’s it for today.