Today I had lofty plans of doing many things. But instead I learned Erlang. Someone approached me with a potential project, and thinks Erlang is the solution to the problem; how to achieve real time behavior with a flat process space in an application level program on a standard OS.

To my dismay, Python 3K won’t be offering this set of features, often referred to as concurrency. Very concise reasons are linked here, and actually make good sense:

http://ifacethoughts.net/2007/09/12/python-3k-discussions/#primary

But as an aside, that dreaded Global Interpreter Lock, which has bitten many of us in the ass, is unfortunately here to stay. The good news is that Python, even in it’s current form, allows you to recompile it and link directly to the OS thread libraries. What then happens to thread safety in Python with this configuration? It’s in your hands to lock and unlock semaphores or mutexes as you see fit, the way it should be.

Erlang is, well, an interesting alternative. It supports POSIX threads (now called pthreads since the last time I used them) and timer-based interrupts, which place most thread control in the developer’s hands. And like VxWorks, it offers a flat process space with a global method and variable name space.

Now, notice I compared VxWorks, a Real Time Operating System (RTOS) to Erlang, a language running on almost every operating system. Therein lay the power and intrigue of Erlang.

It also supports what are called green threads, which is essentially a way of running multiple interruptable tasks in the same process, without using OS resources to do the low level context switch. It’s neat, but I wonder if it’s necessary on a POSIX-based, lightweight process compliant OS such as LINUX. On Windows it seems like a necessary, handy tool, but it is not unique to Erlang, and is a bit of a tangent here.

Erlang’s quirky syntax seems to be, to some extent, a side effect of it’s features. For example, an Erlang programmer has to specify a module and function name when calling it. Similarly, one has to export what modules and functions one wishes to make visible. Parameters seem to be strictly positional, and overloaded functions are prevalent for this reason (not a bad thing).

In this example chunk, copied from here:


ring(_, N, _, _, _) when(N =
io:format(”Empty ring~n”),
erlang:error(emptyRing);
ring(_, _, M, _, _) when(M =
io:format(”No messages to send~n”),
erlang:error(noMessagesToSend);
ring(N, N, M, First_process, Main_process) ->
io:format(”Ring process ~p (~p) created~n”, [N, self()]),
io:format(”Sending ~p messages through the ring~n”, [M]),
First_process ! {send, main_process, Main_process},
loop(M, N, N, First_process, Main_process);
ring(I, N, M, First_process, Main_process) ->
io:format(”Ring process ~p (~p) created~n”, [I, self()]),
Next_process = spawn(fun() ->
ring(I+1, N, M, First_process, Main_process) end),
loop(M, I, N, Next_process, Main_process).

Notice the lack of if-then-else or case statements to evaluate parameters. It either matches the prototype or it does not. It has assert() functions to evaluate parameters and anything else. And it has an exception handler, but throwing and catching exceptions is discouraged, for good reason. If the process control is at the thread level, threads should be conceptually treated like mini processes, and therefore should be cleanly exited.

Some level of type checking is done during compile time (yes, it’s compiled, not interpreted), which is definitely a nice alternative to the run time errors in Python which cause print statements to crash your entire program. But there’s something so quirky about having to specify


function(object)


instead of


object.function()


or


object->function()


And why does the global name space cause one to have to type:


spawn(fun() -> ring(1, N, M, self(), Main_process) end)


Can’t Erlang figure out that ring() is a function, and complain if there is an overload/name space violation when it occurs? Why must I tell Erlang: “ring is a function”?

And why, when importing a module, do I have to specify how many parameters the incoming functions expect? Again, another side effect of the global name space, or just quirky design?


-import(erunit, [test/2, assertEquals/2, run/1]).


I don’t remember having to do this in VxWorks, or any other language, for that matter. In C, the onus of prototyping functions was usually left to to creator of the module, and comes for free to the user via an #include statement. Erlang is quite odd in this way, but the good news is that it is also explicit. It is not an obscure oddity, and is easy to intuit.

I guess the bigger question is, in exchange for such a robust, neat idea of bringing the power of interrupts, flat name spaces and thread-level control to a programming language which runs on most operating systems, does it really have to be so quirky?

Should we be writing Erlang generators in Python? Maybe this is the answer (it’s nice to dream of simple answers).

This is what I have gathered in the span of about seven hours of Erlang study. I am sure I’m missing some finer details, but this is the jist of it from what I have seen so far. It leaves me with a feeling of hoping for more, yet being foolishly optimistic.

I can’t help but hope that Parallel Python could come to the rescue, but even it is limited for a certain scope of problem. All objects passed to the running job must be able to be pickled and unpickled. This makes passing of methods impossible, since they need to be instantiated on the “other side”, in the scope of the separate running process. For non-serializable complex objects, you’re stuck. For mutually exclusive manipulations of non-persistent serializable data, it is a good solution. So, essentially, Parallel Python could be used to circumvent some, but not all, threaded limitation problems which do not require persistence (or, which use a database to resolve their persistence needs). This isn’t very real-time-OS-like in any way, but resolves a subset of problems which out-of-the-box Python threading does not resolve.

One thing seems to be true, is that it’s nice to have choices, and to be able to compare and contrast the vast amount of freeware out there. The power of Erlang lay in it’s ability to provide RTOS-like features and functions on top any OS through a language interface. That in and of itself is a major leap forward for developers.

What I’d like to see in Erlang is an example of how to have event driven interrupts (where is the signal handler in this language? Am I stuck with just timers?), and how to interface/wrap functions from other languages, and pull them into Erlang.

Gloria

Binding data from windows controls to objects is easy in C#.NET.  Here is a basic introduction: 

Step one:

Create a class named Employee in C# and add a get property for each field you want to bind to a windows control.

public string getLastName {

      get { return mStrLastName; }

} 

Add a set property for any fields that you want two-way binding to occur. For example:

public string firstName {

      get { return mStrFirstName; }

      set { mStrFirstName = value; }

} 

Step two:

Add a form to your project and throw some controls on the form.  For this example, add a list box and a textbox. Also, create an array of objects that you want to bind to this list box.

arrayOfEmployees = new ArrayList();

arrayOfEmpoyees.Add(new Employee(“Doe”,”John”,”SoftwareEngineer”,”ServerTeam”));

arrayOfEmployees.Add(new Employee(“Smith”,”Jane”,”SoftwareEngieer”,”ClientTeam”));

Step three:

Bind the data from the object to the list box and textbox

listBoxLastName.DataSource = arrayOfEmployees;

listBoxLastName.DisplayMember = “getLastName”;

txtBoxForFirstName.DataBindings.Add(“Text”, arrayOfEmployees, “getFirstName”);

Step four:

Run the project and notice that the data is bound to the list box and the textbox. 

First, notice that the textbox is an example of two-way binding.  If a user changes the values in the textbox then the object is updated with a new first name.  To change this to one-way binding, just remove the set property from the object bound to the textbox.

Secondly, simple binding is done to controls like textboxes that only have one possible value.  Complex binding is done to controls like list boxes, that have multiple values to display at once. 

This example shows both simple and complex binding as well as one-way and two-way binding. More advanced data binding topics in C#.Net Visual Studio 2005 would cover the DataGridView class.

Cheers,

alex

The way girls are viewed in the gaming world is about the closest I have seen to how women in development are seen. We simply don’t exist. I am often asked why there is a need for something like DevChix and I think the article “OMG Girlz Don’t Exist on teh Intarweb!!!!” by Whitney Butts describing what it is like for her to be a girl in the gaming world kind of explains it. Its slightly different for women in development but its not that far off. The reason for DevChix?? we (women) need to know there are others so that we don’t fall into the trap of believing that we aren’t here or that we don’t belong here and everyone else needs to get use to us being here. Its our way of talking over Ventrilo. There is power in numbers.

Thanks for the article Whitney.