Profile cover photo
Profile photo
Phil Hord
Phil's interests
View all
Phil's posts

Post has attachment
Phil Hord commented on a post on Blogger.
I like the idea of this algorithmic approach to problems.  I see far too many students who just memorize the method without understand the reasons.  Maybe an algorithmic representation would still leave most of them with a weak understanding, but a rigorous and complete algorithm should present just the bare essentials to the method and may lead to a deeper understanding of the reasons for it.

On the other hand it could be dangerous for teachers to produce these algorithms with their own unique styles and abilities.  It is frustrating when someone uses ambiguous language to describe a precise process.  It could be worse when a non-programmer tries to produce a precise algorithm for students to follow.

But with the right resources and training, I'm optimistic this approach would be helpful.

I'm trying to reason about Futures, the wrapper for asynchronous programming coordination found in many modern languages. Here's the understanding I've got so far based on C++.

Simple explanation

A `Promise` represents accounts payable: I promise to put some thing in here
A `Future` represents the accounts receivable: I am owed a thing and will show up here

It's not very useful to be both the AR and AP for a single promise. In practice these belongs to two different threads.

Going deeper

A Promise-Future pair represents an interthread communication pipe. The sender puts some thing into the Promise, and the receiver gets the thing from the Future.

Client perspective

A client receives `Futures`.

A function which can complete asynchronously will return a `Future`. The `Future` is used to handle the result when it is finally ready, but in the meantime the caller can go about doing other things.

API perspective

An API or service makes `Promises`. The `Promise` maker also keeps the `Promise`. That is to say, it does not return the `Promise` to the caller. It returns the `Future` to the caller.

The `Promise` is the "handle" to the `Future` the API needs to fulfil. When the asynchronous operation completes or fails, the result is delivered to the `Future` by way of fulfilling the `Promise`.


The [Folly Futures library] ( supports composition of `Futures` like many functional languages do now. This mechanism lets you "react" to a Future event naturally and in a concise, readable style. It lets you say "when this event happens, do this with the result", but you can skip the part where you wait for the result to happen. Instead you code the reaction to event and trust that it will happen someday.

Future<int> battle = Invade( Normandy ) ;
battle.then( Paratroopers(Lisle) )
.onError( Retreat() );

This defines a battle which may happen in the future (Invasion of Normandy) and the action to take after it succeeds (drop paratroopers behind the front lines). Or if it fails, we can retreat and regroup. Code in our thread can continue without waiting for the battle to occur.

Composition lets us chain reactions together. Maybe we want to push forward from the coast once we have ground troops in Lisle.

Future<int> battle = Invade( Normandy ) ;
.then( Paratroopers(Lisle) )
.then( PushInland(Normandy) )
.onError( Retreat() );

Conveniently any reaction which results in an error (raised exception) will break the chain and result in onError being called.

These chains turn out to be a useful future contract of their own, all reacting to the promise fulfilment of their predecessors, running in a thread separate from where we created the code, and completing asynchronously from us as well, though synchronized with each other.

Maybe a more familiar sequence would be useful:

Future<string> page = GetUrl( "" ) ;
.then( GetImages )
.then( DisplayImages )
.onError( DisplayError );

Bask in the warm glow of simple imperative code which in fact results in asynchronous execution with understandable results.

Now, let's look at the definitions for GetImages and DisplayImages.

Future<vector<Gif>> GetImages(string);
int DisplayImages(vector<Gif>);
DisplayError(const std::exception& e);

Two things are curious here. First, the arguments to these functions are the results of the prior `Future` in the chain; it really works like a chain. The return value and type are given to the next Future before the next `then` reaction.

Second, `GetImages` is asynchronous, returning Future, but `DisplayImages` is synchronous, returning an int. I didn't have to treat them any differently in the composition chain.

You might wonder when the asynchronous things (then(...)) actually occur. The answer is, "it depends". It might happen on the same thread where it's defined, or it might happen on the thread where the `Promise` was fulfilled. It might even happen on a special thread spun up just to handle it (see boost::future). If you do things in just the wrong way, it might not happen at all (deadlocks).

Moving to Silicon Valley. Hoping I don't end up in Erlich Bachman's incubator. 

Post has shared content

Post has shared content

Post has attachment
That was a tough one.

Post has attachment
My hobby: collecting screenshots of scrabble words I didn't get to use.

Post has shared content

Post has attachment
Seems legit.

I used gitolite briefly several years ago when it was brand new and quite liked it. But we were also using Gerrit which has its own ACL interface, and our IT group eventually took over management of the networked git storage (inventing their own ACL system in the process). I haven't used gitolite since then.

Now my new company (+Technicolor recently acquired my BU) is using gitolite all over the place to manage local repo stores at each site and then replicating between sites. It's funny seeing so much discussion now in my email every day about "gitolite". It used to be something I only thought of when I saw a post from +Sitaram Chamarty. Now it seems it will become a daily tool again for me.

At least I know where to turn for support. :-)

(yes, that's right.
Wait while more posts are being loaded