Sunday, 29 July 2012

Code Kicker

This evening, I've relived the good old days, I've spent a lot of time (about five hours) coding... This is no big deal, but... I've done this late at night, I've done it after a few drinks... and I've achieves a massively impressive (at least to myself) amount of work, changing the whole underlying strata of a project I'm working on... and it all worked first time... (well apart from spelling progress without an r, its done).

And this is the good old days, because it was just like being back at Uni... I loved coding at uni, I think I picked a degree with too little actual coding within it... But tonight I relived that feeling of achieving something.

Thursday, 26 July 2012

Charlotte Blackman

I'm going to keep this one short and sweet... My thoughts, sympathy and condolences go out to all of Charlottes immediate Family, close friends of ours.

Such a wonderful family, such nice people, we're absolutely devastated for you and only wish that things were different.


My wife is devastated by the news, she recalls only how wonderful Charlotte was, remembering her coming and doing some cleaning around our house years back.  Only a fortnight ago we had a meal out with Rach and she was telling us how proud she was of Charlotte getting a first in her degree.

It is so unfair for this to have happened, so unkind of the world to have thrown this burden of grief at such undeserving people, and I can only imagine doubly so for Matt.

As I understand it the family won't return until they can bring Charlotte with them, and until we see them I can only hope they know our thoughts are with them.

Monday, 23 July 2012

Why....

Why do people not phone me (I have a phone folks which tells me I have missed calls, it in fact logs all my calls in and out) and then say "I've tried to get you, but it just rang and ran".... No it didn't, you have not tried to get me at all, you've waited for me to call you you shady sod.

Why do people post videos on YouTube, of what might be interesting material, and.then.they.talk.in.a.monotone.drone.so.you.stop.the.video.and.don't.listen.to.them... I mean, look around people, look at how the BBC or Sky, how interviewers present information in the form of the spoken word and emulate them!.... Don't just sit and drivel on... Also... Don't... please don't just put yourself as the focus of the camera... If you're on YouTube talking about code, then for christ sake put some code up, don't let us see your pimply stub nosed shit eating grins.

Why do people not look at road signs?... I mean, they're up there for a reason, telling  you to merge from the right, or give way to the left, or that cows are crossing... all very useful information... Not to mention, lanes have arrows in them saying where they go, if you are at an island going right and there are two lanes going right... think "Hey directly after this island I need to take a left"... and get into the left most of the right flowing lanes... don't be right, go right and then cut everyone up going left and look at the other people like they're morons, you're the moron!

Why do people not accept factual presentations from me?... Now, I don't know what it is, but I can be stood holding up a white piece of paper and declaring "This is white"... and my audience will stroll off... Yet someone I'm sat looking at right now can just say "This white paper, see it.... its fucking blue dude"... and they go... "Oh yes, blue blue blue..."...


Sunday, 22 July 2012

Using boost::signal Example

From my previous post you maybe aware I had a problem integrating two different modules, produced separately and in isolation, which when brought together instigated a compile time error... Well, over the day I've spent a few hours... well about four... trying to work out what to do...

I had thought I needed some mechanism to be connectionless - hence my use of boost::asio for its UDP operation - which could deliver the messages with as little programmer (or rather code dependence on the programmer) as possible.

I spent sometime looking at message exchange via some web technology, looked at named pipes, shared memory, and even gave up on the connectionless ideal and went for a network topology of TCP/IP Connections... None came up as acceptable to my needs, they were either so complex in code as to need very significant amounts of testing, or they brought into my code base so many external files as to swamp the project and blur the line between multiple licenses.

However, late in the day I stumbled; and I feel a fool for stumbling so late; over boost::signals.  Initially I ran through their simple tutorial and was happy to see a function being invoked after connection from another location.

After a little thinking I also stumbled over a pattern of thinking via which I was able to replace my asio use of UDP as a message transporter to send a message to multiple locations through my code.


My pattern is to have one class control a copy of the signal, and to pass pointers to this to each outlying class, these outlying classes can then connect to receive the signal into local functions bound with boost::bind and viola... A signal sent to the central, and only, copy of the signal can be propagated extremely quickly throughout the other classes.

Here is my code:


#include <iostream>
#include <string>

#include <boost/signal.hpp>
#include <boost/bind.hpp>


using namespace std;

typedef boost::signal<void(const string&)> Func;
typedef Func* FuncPtr;

class A
{
private:

FuncPtr m_Signal;

boost::signals::connection m_Connection;

void OnSignal (const string& p_Message)
{
cout << "A::OnSignal [" << p_Message << "]" << endl;
}


public:

A (FuncPtr p_Signal)
:
m_Signal (p_Signal)
{
m_Connection = m_Signal->connect(boost::bind(&A::OnSignal, this, _1));
}

~A ()
{
m_Signal->disconnect(m_Connection);
m_Signal = nullptr;
}

};

class B
{
private:

Func m_Signal;

public:

B ()
{
}

FuncPtr Getsignal()
{
return &m_Signal;
}

void Transmit (const string& p_Message)
{
m_Signal(p_Message);
}

};


int main ()
{
B* b = new B();
A* a = new A(b->Getsignal());

b->Transmit("Hello World");

delete a;
delete b;

cin.get();
return 0;
}


This easily provides a simple framework upon which I can wrap a single instance of a signal, or different signals into a single class, in this example "B" and then pass out the pointer to that instance, in this example to "A".  And then the transmit is sent to all listeners.

One can register multiple instances of the "A" class and the transmit of the call goes to all the handlers for it.

I believe I may be able to turn what I had represented as an Event raised from many places, into a single Signal instantiated in one location.

I admit I will end up with multiple signals, one for each Event I had before, but the transmission system drops to zero lines of code, and all the lines of code I am using in the boost library have been very very well tested, unlike the code one would employ from ones own hand...

My new task therefore is to turn this reverse concept of a message to better meet my implementation of a state machine.

Saturday, 21 July 2012

Working Alone Together

I've just gotten myself through a hell of a problem, you know one of those things you don't see coming, but which utterly brings your project to a halt.  My problem resulted in my rather large C++ application project creasing to compile...

I'll just take a moment to explain the problem, and solution, because I want to record it somewhere and as its past 1:10am and I've not got my notes near me, I'll just make a note here for the world and myself to read tomorrow.  The problem was including boost asio.hpp after you've included windows.h results in the boost socket type header reporting a compile time error that the WinSock API has been defined, where as the boost asio systems want to use the WinSock2 types.  The error is not very helpful, but the solution is simple, either go through all headers you've added before the one using asio and where ever you include windows.h you also ensure you have #define WIN32_LEAN_AND_MEAN.

Defining WIN32_LEAN_AND_MEAN results in the windows header file not automatically including Winsock.h, which in turn means later asio.hpp is able to include winsock2 without any conflicts of interest.

A neater solution, in any project using asio, is actually what I did.... Go into the compiler settings and define the WIN32_LEAN_AND_MEAN name in the preprocessor directives for the whole project you're building...

Your asio includes now work and compile, anything broken was using Winsock, or some other header excluded from Windows.h by the lean and mean setting, you can fix those yourself (*grin*).

This whole problem was very poorly understandable, certainly I consider myself very much a boost newbie, I'm not terrible with the libraries and I love them, but I find sometimes their requirements poorly documented... Indeed the boost asio library documents don't mention any conflicts with WinSock already having been included.. *sob*

The problem was also only compounded by the fact that the only thing I had added to the project was something which seemed to be wholly unrelated to asio, and utterly devoid of references to winsock.  It just happened to be including windows without the LEAN and MEAN directive...

And this brings me to the problems root cause, it was not really an effect of including said new item, nor was it really a problem with how asio enforces the use of WinSock2... It was actually caused by "Working Alone Together".

The code which was brought into the project was not actually tested as part of the project beforehand, it was developed alone, with the intention of moving itself into my project locally later, and being developed alone it compiled fine, it passes its NUnit tests, it matches its design and specification... This resulted in a very dire situation my end.

If this were a few years ago (and not many) I'd have been roaring at the supplier of the new item, complaining and urging them that they'd made some fatal mistake.  I'd have been ranting about how bad their work is, or how terrible they've got things working.  And all of us whom work in Software know what we do when our code gets criticised, that's right we get utterly defensive, we object to being put down, and we respond by pointing to measured results - in this case I'm sure I'd have had the passed NUnit tests as an insurmountable obstacle to my getting any of my grievances addressed.  Luckily I'm a little older and wiser, and I've been on the receiving end of such tirades.

Therefore I did the simple thing, I assumed I had something wrong and started to pick at the problem.  Admittedly this took me two hours to unpick, but I know now what is wrong, I know what the problem is, and I can comment my co-worker that their effort has not been for naught but ask them to look at porting to WinSock2.

I can also submit to them a new specification, or rather an update to my specification, stating that WinSock2 is the minimum requirement for the system.

And because I've not ranted, and I've pointed out all the foils involved, I've documented the problem clearly enough for them, they will most likely not throw their rattle out their pram, instead they'll just look at what's wrong and take my advice as that and get on with the work.

However, if our communication, and integration points had been closer, rather than twining these two items together at the deadline hour, then... well then we'd have seen this problem earlier... And its been a harsh lesson in this internet enabled age that really we needed to have worked more closely, rather than sticking to our own ring-fenced areas of the specification alone.  We spoke daily about the progress, we swapped notes on using new things as they came up, but this fundamental difference of libraries at the platform level has resulted in one almighty cock up.

A lesson learned, and a lesson to carry forward... "Don't Work Alone, when you should be working Together".

Monday, 16 July 2012

ERm.. LXF....

I got my moaning mail about that chap totally missing the point of the Assembler Language series in LXF printed this month... So, to any/all LXF readers finding my blog... welcome... and... Sorry about the mess.

But, If I get a few hits on the C++ CPU posts I might make them into a dedicated webpage somewhere.

Wednesday, 11 July 2012

SF stop buying Apple


I was looking at the news that San Fransisco was to stop buying Macs for local officials... Not that I considered this piece of information news worthy, but that a figure stuck me....

"It noted local officials spent $45,579 (£29,365) on Apple equipment in 2010."

The BBC state... Take a look at the Apple store... $999 for a MacBook Air... £1199 for a MacBook Pro... $600 just for a Mac Mini, and $2500 for a Mac Pro... So... on average, we can point a very rough finger of $1000 for a Mac...

Let us assume a generous 25% government discount, $750 per machine... This means San Franscico buys about 60 machines a year?  I think my employer, a much smaller, entity than the local authorities in SF... Buy more than 60 machines a year...

Their reason for not buying Macs any more is also something trivial, rather than think about the cost to their tax payers (because lets face it for $750 you can have a banging hot specification machine put together far in excess of the specification of a mac of the same price) but their reason is in fact because Apple, those Chinese Labour Sweat Shop Using Elegant Style bastards that they are, won't have a cat in hells chance of getting the Green Certificiation for their production methods for a Mac, all that industrial effluent pouring into the Yanghtze River does show up somewhere after all, so Apple are not going to bother.  But the SF liberal, Berkley corps, want to see them be green, so cut off their 60 machines a year order... Boo hoo says I.

Apple do have an interesting page about their Green Credentials... Which, despite using the colour green, only ever show seemingly low numbers... "We're 50% effective"... but its green, so it must be good enough!!?!?!?!... WOOT!