OK, now I an officially surprised with life. Years ago I had applied to some tech jobs and was turned down via automated emails sometime later. Fast forward to the present, and I actually hear something from one of those companies lol.

Being more than a wee bit suspicious of things coming in out of the blue. Like seriously, what’s the probability? What personal info that I have revealed, can be found trivially about me by any one doing their home work decently, so I’m not worried. The thing that bought that much level of trust out of me, was being told facts about the app’ I had dropped in (when, to where, to what), that no one but me could know: assuming that such a reputable company didn’t bungle their security, and no one was sniffing packets off our wires at the time.  It’s kind of like having a message from someone with a pre shared key that you trust, enough not to redirect to /dev/null but not enough to drop the deflector screen.

The real question is whether or not it leads to a viable job offer; I’ve no idea whether or not that one job interview will bear fruit. The insane thing, lacking a B.S. I’ve largely given up applying to tech jobs a long time ago, so recently I have focused on finding “Conventional” jobs in my area rather than things worth the effort.

Every thing that has come up in the past few weeks, all of them have been tech related!!! Sometimes I really wonder if someone up there has a sense of humour, one like mine anyway. But interviews, calls, and emails, still isn’t being hired, even if it is an improvement. Computers are one of the things that know the most about out of everything I know, computers are what I’ve spent most of the decade glued to and what I’ve been using most of my life. Wouldn’t it be bloody nice, if someone hired me to do something “Interesting” with them for a change?

  • Having an occasional link on SpiderMonkey’s docs that actually throws you to MDN, is rather tiresome.
  • GDB doesn’t always like dlopen()’ing a library that depends on (p)threads, using LD_PRELOAD fixes.
  • Reading a functions documentation over again is more useful than a debugger, especially when you’re tired.
  • Lua’s C API is really spoiling me.
  • I know better than to git commit without sleep.
  • Hmm, I wonder how long it would take this old laptop to compile V8… heh, can’t be that bad.

For now my plan is grab a quick snack, check the server list, and pass out sometime around dawn, then review the files in the morning. Sometime when I’m fresh, I need to focus on an interface between C++ and the engines loaded by Cassius. The partial SpiderMonkey and unfinished V8 support can largely wait until later.

Of course, the reason why I named the base class for embedding a language ‘Engine’ rather than sometime more conventional, is in order to have a ‘Cassius::V8Engine’ in there, haha!

*groan* today is time for the drop test—dropping things on MSVCs foot and hoping I don’t feel like drop kicking it ^_^.

My life would probably be a lot easier if I just rigged a cross compiler and gave up on using a platforms more ‘native’ compilers, i.e. Visual C++ on Windows. It’s about as much a native compiler as the platform has, and I still consider it insulting that a C compiler isn’t provided as part of a Windows install lol.

Grrr, almost 0400R. I actually had planned to get to bed early but dinner kind of threw the nights schedule for a loop :-/.

Hmm, food and SpiderMonky or food and Z’s. Problem is I’m more hungry than sleeply lol. I really wish I could get work done in my sleep, or that days were at least 36 hours long.

Post dinner notes

One value that this comment has served along with my compiler, is to teach me that default parameters on a template *function* are actually a C++0x feature, and apparently not part of C++03 as I have assumed for ages.



template <typename Num=int> Num square(Num n) { return n * n; }

int main() { return square(5); }

// g++ 4.5.1 reports:
//
//      error: default template arguments may not be used in function
//             templates without -std=c++0x or -std=gnu++0x


Somehow, I always figured if you could do it on template classes it would be legal on template functions as well. Guess that’s what I get for never reading the ISO C++ 2003 standard, and it having been a number of years since I last RTFM so to speak o/. About 95% of the times I use templates, it’s at the class level anyway, and most queries I have on C++ are easily solved by reading a header file. To be honest, while the drafts for C99 make for a very nice read, I’ve always worried that digging into the C++ standards might melt my brain or put me soundly to sleep. Frankly, C standards are helpful along side SUS, but the standards for C++, well all I can say is that I’ll be happy when 0x becomes as omnipresent as C89 capable C compilers. I’m just not sure I will live that long though :-(.

What I’ve done is implemented Engine::Call() as a sequence of template functions that use the vaguely normal method overloading semantics to cope with the arguments through Push(). Nothing else has been able to maintain the desired level of type safety. Basically if Call gets 0 arguments = use the current class state, and successive versions of Call(funcname, …) doing the obvious manipulations to generate the correct state and than run it. I would rather a recursive variadic template but life sucks and C++0x isn’t every where just yet. Having to supporting late model GCC 3.x is a real possibility for Cassius to bear fruit without thinning a few hedges.

Push() is just done as a set of virtual member functions for logistical reasons. Since each Engine instance is tagged with it’s language and implementation details (as an insurance policy), the same effect could be done through a set of template  specializations and a little static_cast magic to forward it to the correct subclass without any inheritance tricks. At the price of a more stringent contract with subclasses, that would also allow for getting rid of other virtual members in the base class. I’m not what instructions a C++ compiler is likely to generate for a static_cast from parent to child class compared to what C++ virtual methods and casting things in C land will produce, but I could really care less about the cost of using virtual Push()’s versus templated Push()’s here: Call() is the one that matters at the template level. Why virtuals are used for Push() in point of fact, is to avoid a build time dependency against the backends (to be loaded at runtime), which obviously would be a circular dependency. So templated Call(), virtual Push() works more convineantly than a purely templated driven solution.

Being sublimely lazy, rather than write out a set of similar template functions for each version of Call() that’s needed to handle these successive amounts of arguments, I just wrote a Lua script to do it for me: then shoved that into the projects build scripts and adjusted the headers to include that auto generated file as needed. One of my favourite Boost libraries actually does something similar for handling a variable number arguments for a functor type class, but I’ll be damned if I’m writing them by hand!

Lately I’ve been relying on a mixture of rake (Ruby) and premake (Lua) based build systems, so it is rather nice to be able to do such things: and not kick myself later (make, vcbuild).

I love it when someone nudges my brain back into programmer mode 🙂

Spent yesterday trying to get back into the swing of things, first time I’ve actually logged on comms in a few days lol.

Last night I was watching The Others and Surrogates. The others might make some people feel creeped out but I only found its plot a bit overly clichéd. If the ending isn’t obvious by first leg of the  movie, it is by the half way point o/. It does pose an interessting thought though. What if “Disturbances” that people feel are ghosts and hauntings and all that sort of stuff, is really just a conflict of matter? Where the living and the dead have crossed paths but nether know one is dead, or perhaps it’s not death but something whacko in the space time continuum. Who knows, I still maintain that if ghosts exist, you’re more likely to die in the bath tub than experience something like Poltergeist. I don’t rule out the possibilities of ghosts, I just don’t expect to ever see one ^_^.

The surrogates on the other hand, is an interesting sci fi flick. Basically people no longer “Go out” but instead control an avatar via remote. It follows a detectives hunt for a weapon that is able to kill the human operators behind their “Surrogates”.  While not exactly a spectacular movie, it explores an interesting concept, well interesting in light of the modern Internet. Being able to do anything without risk of life and limb, is an interesting idea, but I would argue that’s part of what makes life worth living. After all, if you’re going to go sky diving , what good is it, if you can’t *really* experience it? It’s only a facsimile of the real thing. For something like a fire fighter, IMHO it would be perfect but the ideal of living every day life through a surrogate, just, doesn’t feel right to me.

Currently Lua and Python are in the works, because Lua’s API is different from what I’m used to, and Python is well, not fun to embed but simple enough. Conceptually there is no major difference between a parameter list and a stack, it’s just a sequence of data at heart, and Python functions basically use sequence objects.

What would be awesome, is if the calls are defined in terms of stack manipulation, is to create a template method called Push, that users template specialisation in order to wrangle plain old data types and callables to the right scripting language types, so we would have something like this:

e->Run(SourceString("function f(a, b) print(a); return b * b end")
e->Push(/* instance of some type representing f() */);
e->Push("header message");
e->Push(2);
e->Call();

and rely on the compiler to Get It Right in figuring out the relevant overloads, e.g. Push. Somewhat probmatic is the issuance that Push needs to be part of the abstract base class but can only be defined by a concrete implementation of the interface; normally it would just be defined as a virtual method. That means it works like you would expect a class method to work by default o/. Only thing with that is templates cannot be virtual, so we would have to sidestep the whole vtable thing.

That’s a piece of cake thanks to C++ allowing the abuse of inheritance and casting:

/* An example */

#include <iostream>

template<class Impl> class Base {
public:
template <typename T> void Push(T arg)
{
static_cast<Impl *>(this)->Push(arg);
}
};

// implementation
class Impl : Base<Impl>
{
public:
template <typename T> void Push(T arg);

};

template <> void Impl::Push (int arg)
{
std::cout << arg << std::endl;
}
template <> void Impl::Push (const char *arg)
{
std::cout << arg << std::endl;
}

// subclass that just overrides one method
class X : Impl {
public:
template <typename T> void Push(T arg);
};

template <> void X::Push (int arg)
{
std::cout << arg * arg << std::endl;
}
template <> void X::Push (const char *arg)
{
static_cast<Impl *>(this)->Push(arg);
}

int main()
{
{
Impl test;
test.Push(2); // 2
test.Push("string");
}
{
X test;
test.Push(2); // 4
test.Push("string");
}
return 0;
}

Because the parent class is templated against the derived class, it’s possible to get jiggy with it at compile time. Namely enough is known by the parent about the child to invoke the correct method. Where it becomes somewhat annoying is when you want to continue with subclasses, like X in the above example.

A year or two ago I learned that people call this the “Continually Reoccurring Template Pattern (CRTP)”. Being lazy, I just think of it as the poor mans way of doing something similar to what “virtual template <…> …” would logically imply, if only the effing compiler was that smart. For what I need, just mating instance method overloading with virtual method calls is good enough.

Now all that is trivial, the real gripe however is how do you properly make a “Convenience” method, let’s say one we can do like e->Call(/* variable number of parameters */); and have it do the appropriate magic for us based on the type.

Well, sadly we can’t so easily. To use a va_list, there has to be a way to access the type of the argument. Normally this is done the same way that printf() and scanf() work in C, taking a format string saying what type to cast each parameter to. Pythons embedding API actually does this to convert from C data types to Python objects. Someday I need to open up a C library and look at how va_arg() actually works, I’ve always assumed it’s some sort of hack around a block of memory and type casting. It’s trivial to implement that kind of thing, already have done it for testing purposes (rather than templated Push()’s) but using a format string to describe the specifiers breaks down on type safety, where as at least with the template thing, the compiler can help some.

We can’t rely on Push() overloads to do the right thing because va_arg() is needed to access the arguments if Call() takes a variable number of arguments in the C++ 2003 compliant way. Obviously the easist solution is to find a smarter way of doing va_arg(a_va_list, a_type). Life would be a piece of cake with templates that can take a variable number of parameters, right? Well there’s few  vendors out there who seem to know how to do that <_>.

So how the fuck do you do a smart va_arg() like behaviour? The only thing I can think of at the moment is to make them all the same templated type, so it’s known how to cast them; then try and work some sort of char_traits<> like magic to figure out which Push() is appropriate but binding the necessary info creates more of the same. That and looking up in the C++ standard how many template parameters (if any) compilers are required to allow, and generating every possible permutation of arguments using a script to make the necessary template code before calling the compiler.

Either way, I’m just taking a break for a few minutes to enjoy how peaceful the quiet has been for the last twenty minutes lol.

Despite being interrupted almost every five to fifteen minutes, I managed to get the backends for embedding Lua and Python sorted. Today I would like to start getting into making it useful for something besides evaluating scripts.

Cassius needs to allow two things in order to be useful to me: invoking the embedded languages procedures from C++, and a way to export code to the embedded language. My interest, is whether or not it’s actually possible to accomplish that using fairly standard C++.  I’m kind of hoping, to see just how far that can be pushed.

From experience, I’ve learned that you can expect something vaguely C89 compliant anywhere in the world but expecting C++ compilers to agree on all things template related, can be like asking a goldfish to walk on air – a bad idea! That’s why I rarely do more with templates than I have to. With how much compilers have changed in the last four years, I reckon it’s time.

Out of everything traditional C++ offers, most of it is just sub standard compared to newer languages. A lot of the code I’ve read over the years, I would hardly even count as C++ so much as C with classes, but people have developed reasons I guess. IMHO how C++ can interface with C code is a killer feature, that could be just as readily solved by adapting a C compiler to generate JNI glue code or some shit like that. Throwing on inheritance based OOP isn’t that killer in my books, when you look at languages like Ruby and Python. The real killer feature of C++ is what you can do with templates. While supporting simple generics are part of it, that could be done in C by (abusing) the pre processor and adjusting your Makefile. It’s the opportunities to get creative at compile time that make its it worth while, someday I really should see if any good books have been written on TMP in C++.

The way I look at it, macros make Common Lisp stand out from it’s younger peers, C++ templates make you drool, or curse compilers more frequently lol. Leveraging languages is why more than one programming language should exist.

Relaxation time

One thing spending almost my entire life around computers has taught me, is that rarely is anything impossible, so much as it may just be a pain in the ass to get done. For R&R, my interest is in exploring whether or not a wrapper around scripting languages can really work without heavy introspection or SWIG style code generation.

Principally, embedding a scripting language amounts to initializing it, feeding it with code, and stitching together an interface between it and the desired parts of your C/C++ code. In my experience most time is spent on writing code to bridge C with the script language. It’s kind of like an adaptor for calling conventions, but in C rather than native code.

The question that interests me, is whether or not C++’s standard issue functors and binders, are good enough that it could be done without having to to cuddling up to much to a specific scripting engines embedding API, for each one being embedded. In most dynamic languages the manipulations needed are pretty trivial, but C++ is rather, more traditional. Because of that curiosity, I’ve had an idea on my mind for ages, which I dub “Cassius”. The idea is, to have an interface that knows how to embed several scripting languages, and use that to interface with the scripting languages, in a way more agnostic to which scripting language you’re using.

I thought of the name as a reference both to the Roman name and to Cassius Clay, better known as Muhammad Ali—because after adding support for a embedding a few scripting languages, it might very well knock me out ^_^. The part that I’m not sure, is whether or not, it is technically possible to do it in straight C++, or if the APIs would require more than is possible without using something like SWIG.

Sometimes for a change, it’s fun to ride an idea to the end of a tunnel without trying to speculate what’s waiting there.