MavEtJu's Distorted View of the World - 2010-05

PDA addictiveness
Apple iPhone guidelines train lazy programmers
FreeBSD TFTP server and client updated
I got an iPhone!

Back to index

PDA addictiveness

Posted on 2010-05-31 08:00:00
Tags: Apple, iPhone, Mobile phones, Addiction, Words with Friends

As described earlier, I am now owner of a Apple iPhone. So far nothing new. The thing which was new for me is the portability of addictiveness.

The first, and until recently, last pocket computer I had was a Palm III which was great: Two AAA batteries which lasted months, brilliant input method, simple screen (plus a software development kit available, which ran under Linux and FreeBSD). It lost its attractiveness when after a cold day outside it didn't want to turn on anymore and lost all the contents in it. Oops.

Fast forwarding to twelve years later. In the mean time I've only had simple telephones and faster more capable computers, nothing which stands in between or merges the capabilities of each other.

Long term addiction to computer games has so far for me been limited to playing MUDs in the early 1990s, after that it had not touched me much. True, I've played games like Bejeweled on Yahoo! Games for a couple of afternoons, but the realization that I wouldn't get anywhere near the global Top 1000, let alone the global Top 10, nor that anybody would care me being there, that made me give up pretty fast. The other factor of success is that my machines were not running MS Windows nor MacOS/X and therefore successfully limiting the amount of addictive programs capable of running on it.

But with the purchase of the iPhone that layer of protection had gone and now I've wasted most of the train trips towards and from work and the walking towards and from the trainstation with looking at the little screen and wondering when the next opponent in Word with Friends (a non-realtime multi-opponent version of the Scrabble game) will lay their word so I can place my next set of tiles.

I couldn't remember what was happening between the moment I stepped on the train in Townhall till I got off at Caringbah. And I could't remember what was happening between the moment I started walking at the station till I was home. There are two big roads to be crossed and I couldn't remember if the light on the crossings was red or green when I crossed. Etc.

That was my state of mind until my wife started to play the game on my iPhone and the game wasn't fully mine anymore. Is it the being dragged back to reality? Is it jealousy? I don't know but I'm glad she did.

Except that she now owns my iPhone with her games of Words with Friends from the moment I'm back from work till we go to bed. Until the next addictive game comes up on my iPhone, then it's all mine again.


Show comment | 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 http://www.karppinen.fi/analysistool/ 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

FreeBSD TFTP server and client updated

Posted on 2010-05-05 08:00:00
Tags: FreeBSD, tftp

Thanks to the bravery (or the despair, I am not sure) of Warner Losh aka imp@, the FreeBSD base system now comes with a much needed upgrade of the TFTP server and client.

Although the code has been available for a two years already as the net/freebsd-tftp port and I used successfully and extensively in my previous job at BarNet, I never maneged (dared?) to commit it into the FreeBSD base system.

The import of the new code was announced as such:

Go ahead and merge the work edwin@ on tftpd into the tree. It is a lot better than what's in the tree now. Edwin tested it at a prior employer, but can't test it today. I've found that it works a lot better with the various uboot versions that I've used in my embedded work.

It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option.

My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet.

Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver.

At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers:

  • Itself (yay!)
  • The standard FreeBSD tftp client and server
  • The Fedora Core 6 tftp client and server
  • Cisco router tftp client
  • Extreme Networks tftp client

It supports the following RFCs:

  • RFC1350 - THE TFTP PROTOCOL (REVISION 2)
  • RFC2347 - TFTP Option Extension
  • RFC2348 - TFTP Blocksize Option
  • RFC2349 - TFTP Timeout Interval and Transfer Size Options
  • RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)

It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm:

  • blksize2 - Block size restricted to powers of 2, excluding protocol headers
  • rollover - Block counter roll-over (roll back to zero or to one)

From the tftp program point of view the following things are changed:

  • New commands: "blocksize", "blocksize2", "rollover" and "options"
  • Development features: "debug" and "packetdrop"

If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.


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 (foo.bar) 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