Another awesome Hardware Group Meetup

 Why I like c4di. 2.4 Gigabytes to download. In a couple of minutes. 

Why I like c4di. 2.4 Gigabytes to download. In a couple of minutes. 

I keep taking my camera to our Hardware Meetups with the intention of getting some pictures of what goes on, and then getting into so many chats about different things that I completely forget to get any pictures. 

It happened again tonight. We had some new members with awesome ideas about projects they want to build. And folks I've seen many times were rocking up with some splendid new stuff that they had made, or were working on. With the LoRa project just around the corner, you really should come along if you've any interest in making interesting stuff. 

The next meeting is on 3rd of May. Sign up here

Midsummer Night's Dream at Hull Truck


There are a few nights left of this performance of Shakespeare's classic play at Hull Truck. You can probably still get tickets. 

And you should. Go here. Buy them. Go see. You'll thank me. 

We went tonight and it was very, very, funny. Some lovely twists on the original, and a bun fight at the end. And that's the most I can say without giving away any spoilers (which is not something you can usually say about a Shakespeare production).

Talking Hull Pixelbots at the new Hull Makerspace

 I stole this picture from  Hull Makerspace . Thanks for that. 

I stole this picture from Hull Makerspace. Thanks for that. 

Today I got my first look at the new Hull Makerspace. 

It's splendid. It's a huge room full of potential; connected to a bunch of other rooms also full of potential. The stuff they are installing is fantastic, including pottery kilns, a CNC machine shop, a paint booth, wood working, sewing and of course frickin' lasers (not mounted on sharks, that would be silly, but for cutting things with). 

I'd been invited to give a presentation at a Code Club meetup. Code Club is an an organisation that does just what it says on the tin. It sets up code clubs, usually as an after school activity, where kids learn the basics of coding. They're getting going in Hull, but they could always use more help - contact them here for more

We also had a talk from Matthew about his efforts putting a Raspberry Pi in the sky, Becky on why we should all be taking part in Code Club and Jon, giving details of the next Raspberry Pi Jam in Hull. 

When it was my turn I showed off the new Hull Pixelbot in perspex,talked a bit about HullOS and we had some fun making robots move via Azure IoT Hub and MQTT. Such fun.

Thanks for the invite folks, I look forward to seeing a lot more of the makerspace in Hull. 

C# Quick Question 2 resolution


Ha. Nobody seemed to know this. Or nobody cared....

Anyhoo, the question was:

"When would a value type be stored on the heap?" And no, the answer doesn't involve boxing.

A value type just holds a value. Not a reference to something. If I have an object managed by reference I have to be careful about removing it from memory, because I need to be sure that nothing in the program is referring to the object. This means that objects managed by reference are stored in a "heap" of objects. It is the job of the "garbage collector" to find objects that are not referred to by anything, and remove these. 

However, value types are easy to get rid of. There can't be any references to them. 

Think of a value type as a book in a library. We can take the book away and nobody can use it any more. That's sad. But we can be sure that nobody is using the book when we take it away. Think of a reference type as a web site. We can't just delete a web site because we don't know how many people out there have made references to the site. 

So, when do we need to put a value type on the heap, and treat it a bit like a reference type? One answer is when we "box" a value type to convert a value type into a into a reference type, but this this is not what I'm after. 

The answer is when a value type is used in a "closure". We see closures when we use lambda expressions. OK, so what's a lambda expression? Lambda expressions are a pure way of expressing the "something goes in, something happens and something comes out" part of behaviours.

The types of the elements and the result to be returned are inferred from the context in which the lambda expression is used. Instead of writing a method and creating a reference to the method, you can just create a lambda expression.

We get into lambda expressions shortly after we start trying to treat lumps of functional code as we would data. Consider the following method:

static int add(int a, int b)
    return a + b;

This method is called add, it takes two integers and returns their sum. Maybe, for some reason, I want to my program to select between adding, subtracting and some other mathematical operations that take in two integers and return an integer result. C# lets me create pointers to methods. They are called delegates and we would make such a delegate like this:

delegate int IntOperation(int a, int b);

A delegate is another type I can use in my program. So I can create a variable of type IntOperation. And I can make my delegate refer to a method. Watch carefully:

IntOperation thingToDo;

This statement has made a delegate called thingToDo that can refer to methods that accept two integers and return a single integer result. Now I can make this delegate refer to a method:

thingToDo = add;

Now, if I call thingToDo, the add method will run:

int result = thingToDo(1,10);

This would set the value result to 11, because thingToDo presently refers to the add method. With me so far? Good. We can create our methods "the hard way", or we can use a lambda function instead. Look at this statement:

thingTodo = (a, b) => { return a - b; };

Don't panic. It wants to be your friend. Let's take a careful look at what I've done. I've made thingToDo refer to a lump of code that will perform a subtract operation. The code that does the subtraction doesn't live anywhere and has no name.  It is a lambda expression .Sometimes called an "anonymous function". The sequence => is the lambda operator and it separates the "stuff goes in" from the "stuff comes out" parts of the expression. In this case the parameters a and b to in, and the result of a-b comes out. Because thingToDo accepts integers and returns integers, inside the lambda expression the types of a and b are integers. 

OK. We can put these anonymous lumps of code in our program and pass them around on the end of references, just like any other object. What about closures? Take a look at this strange code:

    int localValue = 99;
    thingTodo = (a, b) => { return a + b + localValue; };

This is stupid, useless code. The statement inside the lambda function is using the local variable localValue for some silly reason. This is quite legal, compiles fine, and gives the compiler a problem to solve. The problem is that the lifetime of localValue exceeds the block in which it is declared. Remember that local variables are usually stored on the stack and deleted when the program leaves the block of code in which the local variable is declared. However, thingToDo is still referring to a lambda expression that uses the value of localValue. So localValue can't die. It must live on outside the block in which it is declared.

The compiler solves this problem by putting the localValue variable on the heap, rather than the stack. The heap is where we keep stuff that has to stick around for a while. This extension of the life of a local variable is called a "closure". 

Short question. Long answer. Phew. 

C# Quick Question 1 resolution


This was the question:

Can I make some C# that compiles and contains these two statements? What type are d and x?

d = null;
d += x;

I wrote the question as a result of my surprise that you could do this with delegate types. In other words, you could add things to a null delegate.

However, it turns out that it works with other things too, including strings. It seems that a += overload (which is how we get the behaviour that allows us to use += to append strings and add handlers to delegates) is also smart enough to make a new object if it turns out that the original is null. Which makes very good sense I suppose. 



When we had our awful struggle to get to the airport a couple of weeks ago one of the things that sustained me was the knowledge that at least it wouldn't be this bad on the way back. 


Turns out that Mother Nature (tm) had arranged another show of strength just as we got back into the country, with lots of thick snow and the prospect of blocked motorways. 

Fortunately, with jetlag you don't let such trifling things as icy roads worry you. All you want to do is sleep. So we got a train and a taxi back to our snowbound car, loaded it up and shot onto the M62 before fate noticed. And we got home just fine. 

We've had a lovely time away. All the better for not having to be at home.