IronPython, C# 4.0 & Me


IronPython In Action

This week I had picked up a copy of IronPython in Action.
Lately I have been writing or mentioning at least how I am pretty impressed about the .NET framework/Visual Studio/C#. I found things to be extremely fluid, logical and pretty much straight forward using C# (with the nice room to get complicated if you’d like).

Python though has remained outside my scope of knowledge for quite a while. I have friends who swear by it and I’ve been always been meaning to learn properly a scripting language. I had briefly touched Python in one my CS courses, however it was using Jython which is an implementation of Python written in Java. To be honest, at the time of learning Jython (pretty much Python) scared me a little.

Dynamic programming languages scare me a little
The ability to cast on the fly scares me.
The ability to create member variables on the fly scares me.

Data attributes correspond to “instance variables” in Smalltalk, and to “data members” in C++. Data attributes need not be declared; like local variables, they spring into existence when they are first assigned to. For example, if x is the instance of MyClass created above, the following piece of code will print the value 16, without leaving a trace

I can see the benfit of being able to do it and the marvels that it can accomplish; but it seems it might cause a nightmare for debugging someone else’s code. Although I’ve never tried so hopefully I’m wrong.
I think buying this book is a good start. It seems as if Dynamic programming requires rethinking problems in a different way; similar to trying to solve a problem parellelly rather than sequentially.

The real reasons what attracted me to try and learn IronPython is the development cycle to create a sample WinForms application looks to be much shorter and much of it can afterwards be easily ported to straight C#. Finally a good CS professor once told the class that:

All programmers should know at least one scripting language

C# 4.0

Seems as if learning Dynamic programming design pattern and principiles could be useful especially with the upcomming release of C# 4.0 I was recently going over the WhitePaper for C#4.0 and they are heavily entering the forray of dynamic programming it seems especially.

C# 4.0 introduces a new static type called dynamic. When you have an object of type dynamic you can “do things to it” that are resolved only at runtime:

The C# compiler allows you to call a method with any name and any arguments on d because it is of type dynamic. At runtime the actual object that d refers to will be examined to determine what it means to “call M with an int” on it.
Other things which will allow for code refactoring seem to be introduced in C# 4.0 as well such as optional and named arguments. I can finally stop from creating so may overloaded methods.

Anyways in the mean time I will be playing with IronPython. There is something sexy about interacting with a GUI through an interactive interpreter.

I have failed.

Although I love C# and how it does a good job in hiding a lot of the intricasies of pointers that C++ enjoys exposing. I prefer to have things hidden from me only when I know I understand what is going on. Today was a rude wakeup.
I hadn’t thought it had been that long in which I had written any C++; I guess I was mistaken.

Today I had the pleasure of completely implementing a simple linked list in C++ completely wrong.

In my defense, I really only faulted on aspect; however this aspect I guess now seems very silly to have gotten wrong and I am actually not even sure how I become misinformed when the right answer is so obvious.

Passing pointers by reference

For some delusional reason, I was under the impression that the only difference of passing a pointer and passing a value by reference is that the compiler would hide all the *’s and -> for code readibility.
Turns out (like always) apparently there is more at work than I understood.

Passing a pointer is pretty much passing a value and a local copy is made onto the method’s call stack. Where I err’d is in attempting to re-assign pointer values within the method.

What I should have done was clearly too either pass in a pointer to the pointer or in my case I chose to do:

Now to be fair. I decided to implement LinkedLists in such a way so that the head never needs to be reassigned once declared. This is obviously a stupid way of doing it; with the logical solution to always just return the pointer to the new head.

Anyways, at least I can say that I ended up learning the right semantics.

What did you do with my resources?

‘.”n”;
}
add_action(‘wp_head’, ‘mypage_head’);
?>

I spent a good chunk of my day today really trying to learn about .NET Garbage Collection because as I had found I was under a lot of misconceptions/misunderstandings of how it works.

Dispose()

I was mistaking this for something similar to a destructor which in C# is the finalize method. This method is defined for any class that inherits from the IDisposable Interface. Implementing the interface allows you to also declare the object with the “using” keyword.
The purpose of this method is to provide the programmer a chance to “clean up” the object properly before they are released especially if they have references to unmanaged code (Window handles etc..)

The part where I was thrown off and took a long time reading to understand and learn is that in most cases (pretty much all if done correctly) you still don’t need to call Dispose on the object.

For instance, say you have a managed object with an unmanaged member variable. If the Dispose design method is implemented properly there should be a Finalize method that is declared which calls Dispose () anyways.

But remember, C# doesn’t support destructors. Don’t let the identical syntax fool you.

The problems begin to creep up in doing this in a efficient way. Thankfully .NET provides all the functionality needed to properly do this. When a class implements a finalize method, the way in which it gets garbage collected is differently than other items (Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework).In short, it gets put on a different queue which can result in a large performance cost.

The following example from MSDN shows how to properly implement the Dispose pattern:

You can see how using this proper dispose pattern, if Dispose() was called by the programmer the finalize method is suppressed removing the need to call it again which would essential attempt to clean up the resource twice and we reattain the lost performance.

So I am in the woods on when someone would have to or would actually want to call Dispose on an object considering the GC will eventually call it for me anyways and the following:

What doesn’t happen when you call Dispose():

  1. Calling Dispose does not prioritize the object for garbage collection. It simply unloads the object’s (unmanaged) resources from memory.
  2. Calling Dispose does not deallocate the object from memory. Only the GC does that when it performs a collection of the generation in which the object resides.
  3. The CLR does not insert or run any code not in Dispose. The behaviour of Dispose is defined by the developer.
  4. Dispose must be called explicitly by the application. It is never called by the runtime. The only exceptions are when using C#’s using statement (see ShawnFa’s article for a good explanation of what exactly goes on), and the foreach keyword in C# will result in Dispose being called on the Enumerator
  5. Dispose is NOT threadsafe. This means two threads can call Dispose on the same object at the same time. Like for any other synchronization-sensitive method, take steps to make sure this doesn’t happen. I’ll give an example of when this might happen in the next section.

The oddest aspect as well is that the object is still alive after a call to Dispose (can very well be alive for a long while if the GC is in fact not needed to be called) and can be continued to be used unless the class checks in every method isDisposed which they never do.

Who knew being a garbage could be so fascinating…

Trying to get feedback faster than you can say…

I must be tired trying to work on the RGB sliders because I don’t seem to be thinking straight. I’m beginning to think that with only one background thread it may be very difficult to get quick response even with the upgrade to the code using unsafe even with my little test images (forget it for sure working with large ones).

I’m spawning a background thread (don’t mention the overhead 🙁 ) everytime the slider changes which begings the method to alter the red value of each pixel rather than “reset” the single thread which didn’t seem any better.

I have to get some actual times down to see if this is even better than just using one single background thread and cancelling the operation everytime the slider changes.

Anyway here’s some of the code so far of my sort of weak attempt to get fast feedback:

Let there be red
Post any help if you have some.

Side Stuff

I guess I’ve made a lot of posts which are really really software oriented versus rather than some other stuff I’ve been doing lately (squash, ice hockey) I just found this project to be really interesting and on my mind.

Part of what is so interesting is noticing how a project envisoined initially so small can just explode if not checked. I seem to be working just as hard to fight thoughts to add the application than I do actually working on it. I guess that is what the benefit of programming something for an assigment versus than for you is. You tend to not go beyond the scope of the assignment, whereas for yourself you let your thoughts run free.

I feel this is something it is good to get a grip on. It seems to be a big problem some people lack in the software industry especially evidently from my current and previous jobs. People never want to freeze the software and label it feature complete; but rather seem to happy tacking on feature after feature.

Image Manipulation Tool Me Some More

So I had pretty much took on this interesting task of seeing what functionality can I implement (and somewhat well) for the sole purpose of really learning to master C# & .NET Framework & Concurrency. However I seemed to have made some good progress.

My search online to see how I can speed up my background worker thread lead me to this website which really demonstrates (most likely to the joy of C++ fan boys) how much managed code can really slow down performance. Pretty much by having direct access to the memory we can alter it faster than through .NET runtime. The author explains it nicely:

Locking the bits keeps the .NET runtime from moving them around in memory. This is important because we’re going to use a pointer, and if the data is moving around the pointer won’t point to the correct thing anymore. You’ll need to know the pixel format of the image you’re trying to convert. I’m using jpeg’s, which are 24 bits per pixel.

Not everything however was nicely explained or perhaps they are thought to be trivial. I was for some reason under the assumption that ARGB would be stored in that order. Such that every byte follows that pattern as I increase in memory address.
With a little debugging I discovered how the order is in fact in reverse (BGRA) and perhaps some head scratching makes me think it’s probably that way since the file was written in Little Endian

How everything comes to together

I guess it’s funny how things relate and pop up so qiuckly. It has been perhaps only a week since I had read and written the splash code that makes use of the Invoke() method so that methods can be run on the same thread as the Window and yet during this side project I forgot totally about it (for a little bit at least). I was trying to update the Image in a PictureBoxControl in the background worker thread and wasn’t sure why the image wasn’t updating. It only took a few mins to remember that I needed to marshall into the proper thread.

The speed has already greatly improved and this is performing the calculatoins on a single thread which leaves the possibility to come back to the threadPool class which I might need to do if I want to get the RGB sliders as responsive as I’d like.

Splash Screens

The computer at my current job is pretty slow and compiling the WinForms application we are developping not only takes forever to compile but to load as well since there are so many asm files to be loaded.
I decided to write up a nice splash screen for the application which will show the current asm being loaded. There is a lot of resources on the net however I found this to be the best article . Other people were placing the splash screen on the same thread or using it to report on initializatoin of the actual application whereas I was looking to have a splash just for the asm loading.
I had initially started with a really stripped version of my current implementation seeing a lot of what the original poster had done as being too complicated. However I either rushed my implementation or it wasn’t explained properly the reasons behind certain code choices.

One issue of the code I was confused about was the Invoke() and delegate creation for something as simple as setting the Controls.Text proprety. It was interesting learning how a Control’s propery are thread locked which after reading a bit seems to be a feature added in 2.0. The Invoke() command executes the method on the thread that created the Control. The result of using the delegate in this manner is thread-safe UI modifications. Pretty neat feature, otherwise might have needed to add Locks to the property for thread safety.

Things I would like to add to my splash screen:
I was looking into not only adding a label of the asms’ being loaded but displaying a progress bar. I was wondering if it’s possible to build the asm reference list of asms to be loaded so that upon each load I can make an accurate step in the progress bar.

Locked in for life?

My first real foray into world of programming was through the use of Java (I had done some Turing but that doesn’t count). Therefore I would say my initial teachings of computer science are heavily object oriented with principles in design patterns. I remember first learning of the most well known design patterns (observer, singleton etc…) and thinking to myself what a great a tool I know have at my disposal.
However did I fall into the pit trap of seeing every problem as a nail now that I have found my hammer?

Its corporations and business who want you to think in design patterns, so that they can make money. In functional style a design pattern is simply a higher order function. Everything is much much much more light weight. Design patterns are not extensible and often non composable. One you choose to use one of them you are stuck, for the rest of the life of the application. Design patterns are top-down approach and therefore they “claim” they know the “future” of the application. Since no one can predict how an application will evolve, forget about top-down design and software architects. Software arichtects means incompetence. Use bottom-up and no-patterns.

The above quote I read while looking into ideas for an undo framework for an application I am developing at work. Although I understand/comprehend the point of view I’m not sure I have been swayed. I have not written much in large scale applications but if there is a point where the design pattern used no longer fits the application it would seem that the application itself has evolved into something quite different.

Not sure how far to go into the subject; but rather stick to the point of “Is heavy OOP always the right way to go ?. For now I never mind setting up the overhead that is OOP.