MavEtJu's Distorted View of the World - Coding

Some kind of image viewer...
GreaseMonkey versus Citrix Online Web Deployment Plugin
Coding Styles
iPhone / iPad development
Apple iPhone guidelines train lazy programmers
I got an iPhone!
Exchange / Outlook compatible ICal files
Funny GCC error messages
Interesting numbers
Perl voodoo
DHCPDUMP 1.6 released

Back to index

Some kind of image viewer...

Posted on 2013-07-15 08:00:00
Tags: Coding

I am looking for some kind of image viewer... Wow, great description :-)

The background is that I need a way to collect and manipulate various images, screenshots of graphs of other applications like Wireshark and various other graphers, and then be able to easily resize these images (so the size of the data matches the size of the data of the other images) and move them around on the area.

So I need an infinite zoomable canvas with on it freely resizeable and freely moveable image objects.

If you know anything like this, and preferably cross-platform, please let me know!

No comments | Share on Facebook | Share on Twitter

GreaseMonkey versus Citrix Online Web Deployment Plugin

Posted on 2012-11-16 08:00:00
Tags: Broken software, Coding

GreaseMonkey has a function named "GM_registerMenuCommand()", which adds a menu to the GreaseMonkey "User Script Commands". This menu could be used to creat for example a configuration menu for that script.

However, if you have a plugin called Citrix Online Web Deployment Plugin installed (where did that one come from???), then it doesn't register properly and you end up with a greyed out "User Script Commands" menu.

Disabling that plugin resolved it.

No comments | Share on Facebook | Share on Twitter

Coding Styles

Posted on 2010-12-01 23:00:00
Tags: Coding, Rant, FreeBSD

Recently I stumbled over this piece of code:

if(pinfo->cinfo) {
	if (pinfo->cinfo->col_first[COL_INFO]>=0){
		for (i = pinfo->cinfo->col_first[COL_INFO]; i <= pinfo->cinfo->col_last[COL_INFO]; i++) {
and it nearly made me cry. How many different coding styles can you find in here? This inconsistent coding style drives me craaaaaazy! I am so glad that the FreeBSD Project has a consistent coding style for their own source code.

No comments | Share on Facebook | Share on Twitter

iPhone / iPad development

Posted on 2010-08-19 18:00:00
Tags: iPhone, Coding

Until the release of the iPad the world was very easy for an iPhone programmer: The screen was 480 x 320 pixels. You substract a number of pixels for the banner at the top with the carrier, time and battery level on it, and depending of the style of your application substract some for the menus at the top and bottom. The leftover area is for you! Oh, if you hold it landscape, you end up with a screen of 320 x 480, minus a couple of pixels for everything described before.

Then came the iPad with a muuuuch larger screen and the iPhone4 with a little bit bigger screen. And all the hardcoded values of the screen size, banner, menu areas etc were suddenly invalid! Oops.

To be honest, that are easy things to fix. Instead of using hardcoded values (which should have been #define's in the first place anyway), you just call a function which return the values based on the environment you are living in. Problem resolved. Maybe...

Not only were the dimensions of the screen wrong, also the look-and-feel of the screen now looks wrong. On a small iPhone screen, this is how for example a list entry looks: A three word name, plus an > to indicate that if you touch this that that there is more to see about "Foo bar quux".

| Foo bar quux          >  |

Now we increase the dimensions to the iPad:

| Foo bar quux                                              >  |
Instead of a nicely filled line, it is now a short text on the left, a lot of white in the middle and an > at the end.

How can we overcome this? Maybe we shouldn't try to get iPhone applications directly ported to the iPad... The iPad has a iPhone compatibility mode for iPhone apps: Instead of using the whole screen it uses only a middle part of the screen, with the same dimensions of the iPhone. Hardware compatibility via software, everything still works!

That works fine for the old apps, but what about the new apps? Before the iPad came out, the SDK version was 3.1. To make programs work on the iPad, you need to use the SDK version 3.2 which supports programs on both the iPhone and the iPad. To make programs which work on the iPhone4, you need to use the SDK version 4.0, which only supports programs on the iPhone and iPhone4.

So, the questions these days are: Which SDK do we use, which hardware do we develop for and how do we make it look good?

No comments | Share on Facebook | Share on Twitter

Apple iPhone guidelines train lazy programmers

Posted on 2010-05-20 08:00:00
Tags: Apple, iPhone, Objective-C, Rant, Coding

As stated before, I am pretty new to Objective-C programming. Normal C? Not a problem at all! But this object memory management process in Objective-C still gives me a hard time.

The first attempt was simple: I added a lot of NSLog() messages in my dealloc() methods and see which ones I expected to see were not showing up. That were for example all my inherited UIViewControllers... They were not released after they were closed. It is a hard way to do it like this, but it gives you a feel of what you are are really doing wrong.

Then I had a look at the "Leaks" analyze tool in Objective-C (Run -> Analyze -> Leaks) and ran my program. At the end, after a couple of refreshes, it consumed 5 Mb of memory. 5 Mb, is that such a deal? Yes, it is when all the program does is retrieve an XML feed and extracts some data. Oh, and every time it refreshed it lost another huge chunk of memory. Yes, that is a big deal. Luckely the "Leaks" analyze tool tells me which kind of objects it is leaking and when, so you might be able to plug them if you go methodically through the features of your program.... Checking the retainCounters is the way to go.

The next step was to implement a button which terminates the program. Apple doesn't permit you to have apps in their AppStore which have this feature, their usability design is: "If you want to terminate a program, you press the big round Home button at the bottom of the screen.". This breeds lazy programmers, there is no way to properly deallocate all the objects you have. And the excuse you read on the forums about it is "When you terminate your program, the operating system will take care of that.". Absolutely correct, but with some-form-of-multitasking around the corner the current system of "Short living apps won't be able to hog a lot of memory" is over. Plus that it will not show the lazy programmer that he has a serious problem in his code!

And the last tool I thought about was something like a static analysis tool, like Clang (I didn't know this at that moment, and have not used it yet, but it is included in XCode these days). I found a front-end for it called the Analysis Tool at and ran my code through it. Four hundred warnings, and most of them related to objects not being freed.

What I learned from this was: Always "autorelease" the local objects. Assignments increase the retainCounter. Check the retainCounters of the objects you release in your dealloc() methods. Don't trust yourself. And wait for the day that you will be able to see at termination of your program what you have leaked.

To be continued.

No comments | Share on Facebook | Share on Twitter

I got an iPhone!

Posted on 2010-05-04 08:00:00
Tags: iPhone, Apple, Objective-C, Coding, L-Space

And so do 50 million other people on this planet. So far nothing exciting :-)

The first impression is good (just as everybody else says): Works intinutive, apps are great. Addiction factor: High. Very high unfortunately.

As a hardcore tinkerer, of course I'm interested in how to make apps for it. And so the drama began: You need an iMac, and one one with an Intel chip in it (the one we have here has a PowerPC), so I needed to buy a Mac mini. And then I needed to buy a digital certificate from Apple so I could store the programs on the physical iPhone instead of on the iPhone Simulator (great piece of software BTW!). And then I needed a book, so I got Erica Saduns 'The iPhone Cookbook' (after taste-testing a downloaded copy). And then I had to learn Objective-C...

Objective-C, according to Wikipedia, is "a reflective, object-oriented programming language which adds Smalltalk-style messaging to the C programming language.". Although never used C++, I can handle object-oriented programming from my history with TurboPascal in a previous life and PHP and Perl from more recent lives. Smalltalk messaging is, as far as I use it but in reality much more, a way to call functions in other objects.

Compared with C++, I like the style of the Smalltalk message passing to call an other object's function: It makes the difference between the properties of an object ( and the functions ([foo bar]) clearer. Also the nested way of messaging makes the code simpler ([[[[ClassFoo alloc] init] randomfunction] release]).

The way functions in objects in Objective-C are defined and called is a large improvement over C++ (unless I've totally missed this feature in C++): A function definition is like (void)displayString:(char *)text withStyle:(int)style centered:(bool)centeredText and function calls to it are like [displayString:"Foo" withStyle:UNDERLINED centered:FALSE]. That makes it easy to make sure you a. have all the parameters in the right order and b. you can have multiple functions with the same order of types (char *, int, bool) but with different names for the arguments.

Good, now the things which don't work out so well yet... Memory management! It is a drama in every language, although I had it pretty much under control in OO-Pascal and C, here it goes a little bit further with garbage collection. I don't mind garbage collection for the things that Apple provides inside the iPhone SDK, but I like to keep track, and the clean-up afterwards, of my own garbage: The following initializes a string and automatically releases it when nobody is using it anymore: NSString *s = [[[NSString alloc] initWithString:"Foo"] autorelease]. Every object, in this case the NSString object, has a counter which keeps track of the amount of references to it. Once the counter is zero, the object gets cleaned up. So the option "autorelease" used earlier, that feature should automatically release, unless there are other references to it, the NSString object when the function has ended (at least that is how I see it). But does this magic really happen? There is no way to check it, we just have to believe the system wrks. For the simple NSString object here it is not so much of an issue, except when I believe it should be still there and it has been released. In pure C you would get a segfault if you do something on invalid or NULL pointers, but in this messaging system you can easily send messages to nil objects without things falling apart. So the protection I had as a C programmer during the development (when you run the program and something doesn't initialize properly, it aborts the moment you try to do something with that piece of data) is now gone because the place it goes wrong might only show up in the output to the user instead of as an interruption of the program.

So, how am I going so far? With regarding to the GUI objects that the iPhone provides (views, input fields, scrolling), I have most of it under control. The rest is learned when required: Thanks to the power of the Google search engine and the various iPhone development communities, all the questions I come up with are already asked and answered.

Right now I have released one app called L-Space. I use it to keep track of collection of Discworld books, to find out which ones I already own and which ones I haven't read yet. You can find it in the iTunes store or in the iPhone Apps program. A bigger version will allow more book-series and maybe the option to edit them.

The next one I'm working on is an aggregator (more an advocacy thingie) for information about the FreeBSD Project: It shows the YouTube videos, the Planet FreeBSD feed, the News Flash and the location of FreeBSD Commiters in the map.

Oh, and about the addiction: I manage to keep it quite well under control, except for the Words with Friends (a non-realtime version of scrabble) and Bridges (Also known as Hashiwokakero), with which I waste hours and hours on in the train.

No comments | Share on Facebook | Share on Twitter

Exchange / Outlook compatible ICal files

Posted on 2006-03-11 17:03:15, modified on 2006-03-11 17:04:37
Tags: Coding, ICal

Just finished a project on which we needed to have Exchange / Outlook compatible ICal files. My experiences, with full code to reproduce it, are written down at

No comments | Share on Facebook | Share on Twitter

Funny GCC error messages

Posted on 2006-02-16 22:27:51, modified on 2006-02-16 22:28:58
Tags: Coding

This is while compiling zaptel on a FC4 linux machine with gcc 4.0.0.

No comments | Share on Facebook | Share on Twitter

Interesting numbers

Posted on 2005-03-24 16:38:41, modified on 2006-01-09 16:29:23
Tags: Coding, Numbers

If you're coding, interesting numbers will show up sometimes!

This application stops running after 49 days

49 days = 49 days * 24 hours per day * 60 minutes per hour * 60 seconds per minute * 1000 ms = 4,233,600,000, or 0xFC579C00, or close to 0xFFFFFFFF. In other words, some unsigned 64 bit millisecond counter just overflowed.

This application stops running after 24 days

Same story here, except that is an signed 64 bit millisecond counter.

86400Number of seconds per day

No comments | Share on Facebook | Share on Twitter

Perl voodoo

Posted on 2004-01-19 22:55:53, modified on 2006-01-09 16:29:21
Tags: Coding, Perl

A friend of me came up with this piece of code: (click on URL later). If you run it (with 5.6.1 or 5.8) it will complain that $c isn't specified. But then, if you rename the *c and $c to *b and $b, the program suddenly works.

This is even worse than black magic....

#!/usr/bin/perl -w
use strict;

package testexport;
sub testing {
    my $KEY = shift;
    print "KEY=[$KEY]\n";

    my $a = $::TEST_SINGLE;
    print "a=[$a]\n";

#   my $b = eval "\$::$KEY";
#   print "b=[$b]\n";

    no strict 'refs';
    local *c = $::{$KEY};
    use strict 'refs';
    print "c=[$c]\n";

package main;
$main::TEST_SINGLE = "hallo";
#my $TEST_SINGLE = "hallo";

(now rename the "local *c" to "local *b" and "$c" to "$b"...)

Show comment | Share on Facebook | Share on Twitter

DHCPDUMP 1.6 released

Posted on 2003-11-21 23:47:26, modified on 2006-01-09 16:29:20
Tags: Coding, Networking, DHCP, DHCPDUMP

DHCPDUMP version 1.6 is released.

Fixed are:
- display of pad options
Added are:
- display of option 83 (and others)
- flushing of stdout after printing one packet.

Available via

No comments | Share on Facebook | Share on Twitter


Posted on 2002-07-18 19:07:15, modified on 2006-01-09 16:29:21
Tags: Coding

[@lire.gif@@alt="lire.gif" width="94" height="96" border="0" align="right"]]

In the past I've setup a project called LogReport. It's for analyzing logfiles from mail-servers, DNS-servers, web-servers etc. Actually all what is producing logfiles.

In the last year I haven't really helped them, more because I wasn't really in a position for it: I didn't have access to real systems, only small logfiles of myself. And that doesn't really help.

But times are changing! I do contract work for BarNet, an ISP for barristers and chambers in Sydney. With about 14 class C networks, they transport a lot of email, do lots of DNS requests and have lots of traffic on their websites. It looks like the good days are coming back again!

Right now I've created two new super-services (see the LogReport website for explanation on what a super-service is): dnszone for DNS logfile analysis and radius for Radius logfile analysis. They are not submitted to Lire yet (see the LogReport website for explanation on what Lire is), but I have faith!

No comments | Share on Facebook | Share on Twitter