Greg Heartsfield

Version Control Diagrams with TikZ

2009-05-26T00:00:00+00:00

Version Control Diagrams with TikZ

When discussing branching and merging, it can be useful to illustrate common patterns with version control diagrams. A convenient method for making these is with the PGF/TikZ package within LaTeX. The following are some simple examples with source code.

Feature Branch

A simple feature branch, that is merged back into the trunk. Source Code.

Feature Branches with Synchronization

A couple of feature branches that are synchronized with trunk, and one is shown being merged back into trunk. Source Code.

Release Branches

Multiple release branches, with changes merged to trunk. Source Code.

Introducing cabal2doap

2009-01-04T00:00:00+00:00

Introducing cabal2doap

Hackage is a fantastic resource for developers, but one disadvantage is that non-Haskellers rarely get exposed to the great software that is being developed in Haskell. Hackage lists nearly 1,000 projects currently, but checking on freshmeat.net, there are only 73 Haskell projects. As a developer, I don’t want to have to submit and maintain project pages at Hackage, Freshmeat, Sourceforge, etc., but of course, I still want the largest audience possible.

One way to spread knowledge about software projects is to publish description-of-a-project (DOAP) files. These are formal descriptions of project stuff: homepage, maintainers, contributors, language, versions, and much more. There is a large overlap between the DOAP vocabulary and Cabal, the packaging system used for all Hackage projects. So, for the past few days I’ve been toying around with making a Cabal to DOAP converter, which is now ready for others to use.

Running the program in the root of a cabalized project will output XML-RDF. If the project is a Darcs repository, the commit history will be scanned, and developers will be noted in the output as well.

I hope that this will lead in the near future to Hackage generating DOAP data every time a new project is uploaded. There is lots of important data that is best gleaned directly from Hackage, such as the past releases, and download locations. I plan on making future improvements to aid in Hackage-cabal2doap integration, especially in the area of processing multiple Cabal files to build up release history. Before that though, I’d like to see if/how my projects become more accessible by virtue of having DOAP data published. For example, how well aggregation services like Doapspace and doap:store function.

A neat way to understand some of the power of representing data formally in RDF is to view it in graph form, such as that provided by the W3C RDF Validation Service. For example, the following is a representation of the DOAP data published for cabal2doap itself.

You can start with the official project homepage, or its home on Hackage. If you have Firefox and Tabulator or Semantic Radar, you can browse to a couple projects I host, which have linked DOAP data generated from cabal2doap.

hS3, with ByteString

2008-12-23T00:00:00+00:00

hS3, with ByteString

Galois has released an updated haskell HTTP module, supporting ByteString requests and responses, instead of just String. This provides a significant performance improvement, and dramatically reduces memory usage. Since hS3 uses HTTP for all network communication, it wasn’t really usable for files larger than a few megabytes. I’ve pushed a new released of hS3 (0.4), and did some quick measurements to see the improvements.

I generated a 1MB file of random data, and uploaded it to S3 using HTTP-3000 (String), and HTTP-4000 (ByteString.Lazy). Real time was limited by network bandwidth, so there was no improvement in that regard. User (CPU) time was greatly improved:

HTTP-3000 (String):         35.859s
HTTP-4000 (ByteString.Lazy): 0.072s

Using the GHC profiler, I also uploaded a 5MB file using the old and new libraries, which demonstrates the reduced memory requirements. The vertical axis is the same on both graphs, but I’ve had to reduce the scale of the horizontal (time) axis on the second graph, since the ByteString version only required about 1/500th CPU to execute.

Euler's Line in MetaPost

2008-08-31T00:00:00+00:00

Euler’s Line in MetaPost

Euler’s line, showing that the orthocenter, centroid, and circumcenter are collinear. Created with MetaPost.

This was all defined in MetaPost parametrically, so it’s trivial to create the line through any (non-equilateral) triangle. Showing the center of the 9-point circle is collinear as well is easy too.

Source here.

ICFP '08 Contest

2008-07-20T00:00:00+00:00

ICFP ’08 Contest

I gave the ICFP contest a try again this year, and had a really good time. The task was to write a controller for a martian rover, capable of avoiding basic obstacles like boulders, as well as enemy martians of unknown intelligence. Telemetry input streamed from a network socket to the controller, and basic control commands such as accelerate or turn left, had to be sent back.

Unlike previous years, where it took some time (several hours of implementing an interpreter spec) to really understand the scope of the problem, you knew what you were getting into after reading the very concise task description. I immensely enjoyed the previous formats, but change is good.

Haskell seemed as sensible a choice as anything else, so I went with it. Sending and receiving formatted data (a sample server was provided) over a network socket was the first task, and that was thankfully straightforward. 4 lines (connect, unbuffer, receive, send), and no more I/O to bother with.

Parsing messages from the server was a bit clumsy, I have promised myself I will learn Parsec soon. Sending messages was nicer though, since I just had to define the datatype, and make a simple instance of Show.

I was somewhat familiar with Yampa before the contest, but I could probably spend a whole weekend just fully understanding how it works, so I decided to stick to a simple turn-based strategy. For every telemetry message sent by the server, I would compute the command sequence to send to the rover, and then wait for new telemetry. The server latency was small enough (~100ms) to make this acceptable.

The biggest challenge was deciding how to structure the event loop, and create composeable strategies for the rover. Given the initial message, and a telemetry message, the controller could probably do a satisfactory job of deciding what commands to send. I had some grand plans of updating a global view of the map, as well as tracking acceleration/braking constants, so I wanted to keep track of some changing state for each turn. My simple solution, which I think was the right choice given the time constraints, was to create a datatype for the rover/world state, and write strategies as transformers of that state. The natural choice to handle this was the State monad. The world (init message), the rover (acceleration/turning state), and the current and past telemetry were encapsulated inside the monad, and the return value was a list of command messages. Each strategy would be able to inspect the telemetry and current rover state, and make changes, or do nothing. By ordering these strategies, I was able to make a rover that charged ahead towards the goal, until it detected something in its path (causing it to turn), or detected it was going to overshoot its goal (causing it to slow down). Strategies could be combined in order, with the last one able to override any previous decisions.

Strategies manipulated the desired state of the rover, which was represented as a state machine. Commands had to be sent that took the rover from its previous state (described in telemetry messages) to the desired state. Making each of the state components an instance of Enum made this transition simple. I just had to count how many applications of the succ or pred functions were necessary to move the state to the goal.

Finally, in the main program, the state transforming function was mapped over the parsed network input, and the result was evaluated, and sent back over the wire.

You can view my solution here: Darcs repo of icfp08

Cheers to the organizers, who did a really fantastic job creating the task (crazy difficult, but very approachable), manning IRC, and keeping track of issues/FAQ.

Byteflow

2008-05-26T00:00:00+00:00

Byteflow

Wordpress is out, Byteflow is in. I was primarily looking for a small, fun codebase to hack on, and WP/PHP was anything but that.

I spent the past few days getting up to speed with Django, and in fact I’ve already submitted several patches against byteflow, so it is definitely quick to get going with.

I’ve also spent quite a while learning how to get around within Mercurial. Maybe i’ll change my mind after doing some more work with it, but I find the usability very poor compared to Darcs. Mercurial Queues are probably the neatest feature, but that too seems to regularly lead to disaster.

I’ve written a WordPress importer as well, which I used to import all the content from my old blog: WXRImporter.py.

QuickCheck Love

2007-10-22T00:00:00+00:00

QuickCheck Love

If you actually want to get started with QuickCheck, check out the HaskellWiki. The following is just meant to give a simple motivating example for using QuickCheck.

We’ve implemented some simple symmetric block ciphers in Haskell, all of which have encryption/decryption functions with types like the following:

tea_enc :: Int                              -- Cycle count
        -> (Word32, Word32, Word32, Word32) -- 128-bit key
        -> (Word32, Word32)                 -- Input block
        -> (Word32, Word32)                 -- Output block

For these ciphers, we want to verify the very simple property that when using the same key, encrypting and then decrypting a block will yield that same block. That property is represented with the code below (which takes the encryption/decryption ciphers, a key, and an input block as arguments):

test_identity enc dec key input =
    input == dec key (enc key input)

Now, we want to use QuickCheck to randomly generate keys and input blocks, and check the identity property. To do that, we’ll change the function to just take the cipher algorithms as arguments, and use QuickCheck to generate the rest.

test_identity enc dec =
    quickCheck (\key input ->
                input == dec key (enc key input))

Notice how it’s almost identical to our original function that tests a single instance of the property. The only change was moving the arguments that we want to vary into a lambda function, and handing it off to the quickCheck function. QuickCheck figures out how to generate the required arguments, pumps out arbitrary values, and tests them against the given property.

Finally, we can run some tests on our cipher (using 32 cycles):

TEA> test_identity (xtea_encode 32) (xtea_decode 32)
OK, passed 100 tests.

Let’s deliberately cause the property to be invalidated by changing just the encoding function and re-running the test:

TEA> test_identity (xtea_encode 32) (xtea_decode 32)
Falsifiable, after 1 tests:
(3,4294967295)
(2,1,0,4294967295)

Which tells us after the very first test, it was able to find an input block and key that make the property false. Notice the numbers QuickCheck selected for its first test, they do not appear random, and in fact, QuickCheck doesn’t necessarily generate random values for types. In this case, it is starting with what look like typical corner cases (very large numbers, zero, small numbers).

Note: QuickCheck isn’t natively able to generate arbitrary values for the type Word32, so we had to tell it how to do so, with the following code, which maps arbitrary integers onto Word32 values (courtesy of a haskell-cafe post by Sebastian Sylvan):

instance Arbitrary Word32 where
    arbitrary = do c <- arbitrary :: Gen Integer
		   return (fromIntegral c)

By making any user-defined type an instance of Arbitrary, you can have QuickCheck automatically generate tests for properties that take that type as an argument.

xUnit tests definitely have their place. Some ciphers have sets of test vectors for instance, which exploit very specific corner cases in the algorithm. But for testing general properties of code, the quickcheck style can be very intuitive.

Pre-signing URIs for expiration with S3

2007-09-30T00:00:00+00:00

Pre-signing URIs for expiration with S3

This is a neat feature of S3 that I wasn’t aware of until after digging through the API docs. You can generate URIs to S3 resources, which expire after a given time. It’s in the latest release of hS3, which includes an example for generating a URI valid for a certain number of seconds in the future.

Instead of making an object public via an ACL, you create a signature of the resource and an expiration date. This signature is added as a query element to the URI, and then given out to users. The end result looks like the following:

http://s3.amazonaws.com:80/hS3/LICENSE
?AWSAccessKeyId=09MD8BAR1GEXCERHT1R2
&Expires=1191208823
&Signature=bY6Luynk8mxbzaO8yv2Pcd3kd1U%3d

Which is generated by code like:

do uri <- publicUriForSeconds connection object exp_seconds
   putStrLn uri

Haskell S3 Library

2007-09-23T00:00:00+00:00

Haskell S3 Library

Amazon says:
Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers.

After hacking away for most of my evenings this week, and the weekend, I’ve got something that I don’t feel terribly bad about releasing. Still needs a good deal of work, but the fundamental operations work. I’m sure there will be some API changes in the future to accomodate some of the missing features.

What works:

Bucket creation, listing, and deletion.
Object creation, retrieval, searching, and deletion.
Setting ACLs.

Issues:

It’s slooow. The HTTP library doesn’t use ByteStrings, so sending multi-megabyte files is painful.
Requires the absolute latest Crypto and HTTP libraries, since I submitted patches for HMAC-SHA1, and HTTP DELETE during the course of writing the library.
To use the more advanced features, such as ACLs, metadata, hierarchical listings, you’ll probably have to spend some time with the Amazon docs.

Coming Soon:

Better documentation, examples, and test cases.
Other Amazon Web Services, in the order that they interest me (SQS, EC2, FPS…)

Here’s how you get started. The latest version is available via darcs:

darcs get http://gregheartsfield.com/repos/hS3/

Or, get the official release from Hackage.

Documentation here, the AWSConnection, S3Bucket, and S3Object modules are where you’ll want to begin.

Haskell HMAC

2007-09-16T00:00:00+00:00

Haskell HMAC

A necessary part of the Amazon S3 library I’m planning on putting some effort into is HMAC-SHA1, for authentication. It is missing from any public Haskell libraries I could find, so I put one together during my weekend in Austin. Hopefully it will make a nice addition (after some cleanup) to the excellent Crypto library, on which it depends for message digest functions.

----------------------------------------------------------------------
-- |
-- Module      :  Data.HMAC
-- Copyright   :  (c) Greg Heartsfield 2007
-- License     :  BSD-style (see the file ReadMe.tex)
--
-- Implements HMAC (hashed message authentication code)
-- as defined in FIPS 198
-- <http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf>.
--
----------------------------------------------------------------------

module Data.HMAC(
   -- * Function Types
   hmac, hmac_sha1, hmac_md5,    sha1_hm,key_from_user,
   -- * Data Types
   HashMethod(HashMethod, digest, input_blocksize),
   ) where

import Data.Digest.SHA1 as SHA1
import Data.Digest.MD5 as MD5
import Data.Word(Word32)
import Data.Bits (shiftR, xor, bitSize, Bits)
import Codec.Utils (Octet)
import Debug.Trace

-- | HMAC works over any hash function, which is represented by
--   HashMethod.  A hash function, and input block size must
--   be specified.

data HashMethod =
    HashMethod { -- | An arbitrary hash function
                 digest :: [Octet] -> [Octet],
                -- | Bit size of an input block to the hash function
                 input_blocksize :: Int}

--Some useful digest functions for use with HMAC.

sha1_hm = HashMethod (w160_to_w8s . SHA1.hash) 512
md5_hm = HashMethod MD5.hash 512

-- | Compute an HMAC using SHA-1 as the underlying hash function.

hmac_sha1 :: [Octet] -- ^ Secret key
          -> [Octet] -- ^ Message text
          -> [Octet] -- ^ Resulting HMAC-SHA1 value
hmac_sha1 = hmac sha1_hm

-- | Compute an HMAC using MD5 as the underlying hash function.

hmac_md5 :: [Octet] -- ^ Secret key
         -> [Octet] -- ^ Message text
         -> [Octet] -- ^ Resulting HMAC-SHA1 value
hmac_md5 = hmac md5_hm

w160_to_w8s :: Word160 -> [Octet]
w160_to_w8s w = concat $ map w32_to_w8s (w160_to_w32s w)

w160_to_w32s :: Word160 -> [Word32]
w160_to_w32s (Word160 a b c d e) = a : b : c : d : e : []

w32_to_w8s :: Word32 -> [Octet]
w32_to_w8s a = (fromIntegral (shiftR a 24)) :
               (fromIntegral (shiftR a 16)) :
               (fromIntegral (shiftR a 8)) :
               (fromIntegral a) : []

-- | Generalized function for creating HMACs on a specified
--   hash function.

hmac :: HashMethod -- ^ Hash function and associated block size
        -> [Octet] -- ^ Secret key
        -> [Octet] -- ^ Message text
        -> [Octet] -- ^ Resulting HMAC value
hmac h uk m = hash (opad ++ (hash (ipad ++ m)))
    where hash = digest h
          (opad, ipad) = process_pads key
                           (make_start_pad bs opad_pattern)
                           (make_start_pad bs ipad_pattern)
          bs = input_blocksize h
          key = key_from_user h uk

-- Create a key of the proper size from the user-supplied key.
-- Keys greater than blocksize get hashed and returned.
-- Keys same as blocksize are used as is.
-- Keys shorter than blocksize are padding with zeros.

key_from_user :: HashMethod -> [Octet] -> [Octet]
key_from_user h uk =
    case (compare (bitcount uk) (input_blocksize h)) of
      GT -> fill_key ((digest h) uk)
      LT -> fill_key uk
      EQ -> uk
    where fill_key kd =
              kd ++ (take (((input_blocksize h) - (bitcount kd)) `div` 8)
                     (repeat 0x0))

-- Create the inner/outer pad values by XOR'ing with the key.

process_pads :: [Octet] -- Key
             -> [Octet] -- opad
             -> [Octet] -- ipad
             -> ([Octet], [Octet]) -- new opad, new ipad
process_pads ks os is =
    unzip $ zipWith3 (\k o i -> (k `xor` o, k `xor` i)) ks os is

-- Create padding values for a hash of a given bit size.

make_start_pad :: Int -> Octet -> [Octet]
make_start_pad size pad = take (size `div` (bitSize pad)) $ repeat pad

-- Padding constants, per the spec.

opad_pattern = 0x5c :: Octet
ipad_pattern = 0x36 :: Octet

-- Bit count of byte array.

bitcount :: [Octet] -> Int
bitcount k = (length k) * (bitSize (head k))

edited to fix bugs and incorporate suggestions from comments
And… test cases
This is now incorporated into the latest version of the Haskell crypto library (later than 4.0.3).

Show and Destroy Whitespace

2007-08-22T00:00:00+00:00

Show and Destroy Whitespace

Unnecessary whitespace at the end of a line is my pet peeve, especially since darcs makes it so obvious at record time. This is a pretty straightforward way to highlight these characters in any emacs buffer containing haskell code (use a hook like first-change-hook if you want it to show up everywhere). Add the following to .emacs and enjoy:

(add-hook 'haskell-mode-hook
          '(lambda ()
             (setq show-trailing-whitespace t)))

And don’t forget M-x delete-trailing-whitespace for automatic cleanup.

Uncurry

2007-07-05T00:00:00+00:00

Uncurry

My last post had me thinking of some of the ways the function uncurry is useful in Haskell. Let’s first look at the type:

uncurry :: (a -> b -> c) -> (a, b) -> c

Usually the results are obvious, transforming a given function by simply taking a couple of its arguments and replacing them with a single tuple argument. But sometimes we can get something a bit more interesting:

uncurry (flip (,)) :: (a, b) -> (b, a) — swap tuple elements around.
uncurry (flip (,)) ("hello", "world") ==> ("world", "hello")
uncurry ($) :: (a -> b, a) -> b — function application within a tuple; second element applied to the first.
uncurry ($) ((+3), 4) ==> 7
uncurry const :: (a, b) -> a — oops! we’ve un-optimized ourselves back to the equivalent of fst.
uncurry (flip const) :: (a, b) -> b — and we can duplicate snd by adding a flip.
map . uncurry :: (a -> b -> c) -> [(a, b)] -> [c] — apply function over a list, getting arguments from within tuples in that list.
(map . uncurry) (+) [(1,1), (2,3), (5,10)] ==> [2,5,15]

So basically, uncurry is a heavy-duty higher-order tool for working with tuples.

Currying Versus Partial Application

2007-07-05T00:00:00+00:00

Currying Versus Partial Application

I’ve noticed what seems to be a growing inclination to confuse currying functions, with partial function application. The recently updated HaskellWiki pages (currying, partial application) are helpful in understanding the difference.

I think the reason for this confusion is that functions in Haskell are curried by default, making it rare for someone learning Haskell to need to explicitly curry a function. Explicit partial application is pervasive though, so the error is almost always using “curry” when you mean “partial application.”

Quoting HaskellWiki: “Currying is the process of transforming a function that takes multiple arguments into a function that takes just a single argument and returns another function if any arguments are still needed.”

Since Haskell functions are already curried, we simulate standard non-curried functions by using tuple arguments. A non-curried addition function would look like:

add :: (Int, Int) -> Int
add i = (fst i) + (snd i)

We can’t immediately partially apply a single argument of “1” to this, in order to get an “increment” function. Using the curry function from Standard Prelude, we can transform this (poorly written) function, and immediately take advantage of partial application by giving it an argument (1):

increment :: Int -> Int
increment = curry add 1

The HaskellWiki Currying page has a couple quick puzzles at the end, which I’ve solved in a ghci transcript below:

Simplify curry id

Prelude> :t curry
curry :: ((a, b) -> c) -> a -> b -> c
Prelude> :t curry id
curry id :: a -> b -> (a, b)
Prelude> :t (,)
(,) :: a -> b -> (a, b)

Write the function \(x,y) -> (y,x) without lambda and with only Prelude functions

Prelude> :t \\(x,y) -> (y,x)
\(x,y) -> (y,x) :: (t, t1) -> (t1, t)
Prelude> :t flip
flip :: (a -> b -> c) -> b -> a -> c
Prelude> :t uncurry
uncurry :: (a -> b -> c) -> (a, b) -> c
Prelude> let switch = uncurry (flip (,))
Prelude> switch (1,2)
(2,1)

Grad School

2007-06-21T00:00:00+00:00

Grad School

Some exciting news for me, I’ve been accepted into the Software Engineering Master’s program at UT Austin. I’ll be starting in August.

“There is plenty of interesting work to be done in applying software methodologies to functional languages, and it is disappointing that there is virtually no effort in this area.”
—Philip Wadler (Why no one uses functional languages)

Fractal-hs

2007-04-21T00:00:00+00:00

Fractal-hs

I was reminded last week by Adam about a project I had worked on with him in calculus, creating fractal images using Newton’s method in C++, and picked that as my weekend haskell project. Although this time starting with the Mandelbrot set for variety. My real motivation was to possibly start work on an image library, but GD bindings had already been created, so that was unnecessary. I had to expose a function to set individual pixels to the bindings, ~~so if you actually want to run the code below, you’ll need to either pull haskell-gd from my copy, or just apply these patches to the official release from hackage.~~ (GD now includes my patches)

Full source here.

It’s fortunate I enjoy mundane programming tasks, because the “real” work of calculating the Mandelbrot set took only a few minutes. Adding the necessary setPixel function to GD, and even transforming coordinates from an image to the complex plane took far more time. It was much easier to translate the actual mathematical definition of the set, rather than to try and convert from optimized code that used mutable variables.


-- recursive mandelbrot
mandelbrot :: Complex Double -- Coordinate to test
           -> Complex Double -- Iterating Z value
           -> Int -- Current iteration count
           -> Int -- Iterations before diverging
mandelbrot c z iter
    | iter > maxIter = 0
    | otherwise = let z' = z^2 + c in
                  if magnitude(z') > 2
                  then iter
                  else mandelbrot c z' (iter+1)

It needs to be reworked with a high-precision floating point library to make more interesting images, but Doubles are good enough for the following (Mandelbrot, Julia Set, Newton’s Method, Burning Ship):

A Simple Game with StateT

2006-11-28T00:00:00+00:00

A Simple Game with StateT

I think I first “got” monad transformers after reading the wonderful article Grok Haskell Monad Transformers by Dan Piponi. But it wasn’t without some frustration, and I think that was due to the use of arbitrary functions (test1, test2, go1, go2…). I found it hard to wrap my mind around the bigger issue of the transformer mechanics when I didn’t have a firm grasp on what the purpose of these individual functions were.

So, I wrote the ubiquitous “Guess a number” program, that many probably first wrote in BASIC, using Haskell and a State Transformer instead.

guess_a_number.hs, or improved version with error handling (submitted by tphyahoo@gmail.com).


module Main where
import System.Random
import Control.Monad.State

main = do answer <- getStdRandom (randomR (1,100)) -- think of a number
          putStrLn "I'm thinking of a number between 1 and 100, can you guess it?"
          guesses <- execStateT (guessingSession answer) 0 
          putStrLn $ "Success in " ++ (show guesses) ++ " tries."

guessSession :: Int -> StateT Int IO ()
guessSession answer = 
    do gs <- lift getLine    -- get guess from user
       let g = read gs       -- convert to number
       modify (+1)           -- increment number of guesses
       case compare g answer of
              LT -> do lift $ putStrLn "Too low"
                       guessSession answer
              GT -> do lift $ putStrLn "Too high"
                       guessSession answer
              EQ -> lift $ putStrLn "Got it!"

It illustrates a few things rather nicely I think, especially given it is only 20 lines long.

Moving a function argument into the State monad (It is easy to see how guessSession might take two arguments, the answer, and number of guesses made).
Incorporating state and IO into the same function, by use of StateT.
Recursive StateT/IO “Just Works”
Highly imperative, state changing, I/O code can be written in Haskell in much the same way as other languages. That is to say, it’s not the pain you might expect given Haskell’s goal of purity.

Much thanks to Don and Cale from #haskell for showing me how to write a proper case statement!

Calando

2006-10-08T00:00:00+00:00

Calando

I often fall asleep listening to music, but don’t want it playing full volume all night. So, Calando is a small OS X application I wrote to gradually fade my volume down to some preset level. Universal Binary, Requires OS X 10.4.

Download Calando 1.1.1. (GPG Signature)

Related Software:
Awaken is an alarm clock application that can do volume fading as well.

V-22 Touch-and-Go

2006-02-25T00:00:00+00:00

V-22 Touch-and-Go

3 Marine V-22’s flew into Alliance Airport Friday evening, and spent Saturday doing flight tests. Bell employees and their families were allowed to come out in the chilly, drizzly weather to observe. More photos.