Deprecated: Function set_magic_quotes_runtime() is deprecated in /home2/creabros/public_html/creabros.fi/textpattern/lib/txplib_db.php on line 14
CreaBros Oy: Kalles blog

Difference between bike and train

1839 days ago

Somewhere in Finland
My wife and I biked from Helsinki to Kokkola along the baltic sea, which is about 950 Km. It took us two and half weeks.

We came back by train. It took little over five hours.

I think we enjoyed the biking more, even though the train had more comfortable seats.

It not about getting there, it's about being here

Kalle Kuismanen

Random,

Comment

---

Winter wonderland

2817 days ago

I’ve been too busy doing projects to implement new software for the larger audience. Finland is now enjoying more snow than ever not counting the last ice age.

The stopwatch has been downloaded few thousand times and dice game about ten thousand. Hopefully you’ve enjoyed them. I have an improved version of the dice rolling, but it has bugs and I don’t like to release it until I’m happy with it. So here is some snowgear instead:
Bikes in snow

Kalle Kuismanen

Random,

Comment

---

StoreL & RestoreL in Symbian UIKON

3096 days ago

One interesting thing about Symbian is the application framework UIKON, which is recommended or pretty much pushed on the developers. I won’t go into detail what are the components of UIKON, search UIKON core overview or reference for more info, but I will write about a funny problem that I ran into. Last weekend when I was timing the kids games with my nifty Stopwatch application I clicked exit by accident.
On any other application that would be fine, but since it was something as important as how many seconds more/less has coaches daughter has played compared to others, it wasn’t a joking matter. So I decided that the stopwatch needs to save state.

That brings us back to UIKON where every application creates a document instance, which can be persisted. This means that when application starts it calls documents overridden function CEikDocument::RestoreL, which should read the contents of the saved file and restore state. When application exits it should save it’s state using documents override of CEikDocument::StoreL function. Writing these functions was easy enough, bit of streaming of integers and other data, but when I started my application it nothing happened. What now? My framework of the application was generated using Carbide and uidesigner, so I hadn’t really looked at the resource files except to add my icon file to the application definition.

I started by looking at the examples, what is the difference between working and non-working code. It turned out to be very simple, but took me half an hour to find. Text r_default_document_name wasn’t in the generated textfile and the framework didn’t trigger the restore function. (But I was wrong, this wasn’t the cause)

RESOURCE TBUF r_default_document_name
	{
	buf = "LBCD";
	}

Actually things were worse. I first added the whole block behind the empty RESOURCE TBUF declaration and the whole application crashed at startup and all I can see in the debugger is assembly gibberish, nothing that I would really want to start looking through. Another thirty minutes of life wasted.

After this moment of genius, the application started, but I ran into second problem. Instead of calling RestoreL the application crashed with EIKON 44, which means EEikPanicProcessNoStore, defined in eikpanic.h. So for some reason my application isn’t creating a store? Or is there something else going on. Debugging problems like this is like a really boring part of a really boring detective story. The moment in the movie when it’s time to go to the fridge. (This is how far I got when I started to write this blog entry).

It turns out that if the file doesn’t exist then the framework will first call the StoreL function.

After all the problems I did find the error, first I thought had to override the OpenFileL method and all would be well. The CAknDocument overrides the function so that it doesn’t open a file since most people don’t use the persistence. Would be nice, if this was mentioned in the CAknDocument reference.

Here is the fix:

CFileStore* CLBChronometerDocument::OpenFileL(TBool aDoOpen,
                               const TDesC& aFilename,
                               RFs& aFs)
	{
// skip CAknDocument call it's base class function
	return CEikDocument::OpenFileL(aDoOpen,aFilename,aFs);
	}

But no, it still didn’t work. Finally it turned out I had looked wrong at the StoreL function declaration. Function is const and I had left the const declaration from the end and that is why the framework never called my store function. I guess if there was a compiler warning I would have noticed, but not this time.

Lesson, never underestimate the time that a project will take, because it takes a long time to find a needle in the haystack.

Well now I can “run” my timer even if the phone is off. I’ll add another feature, which is storing the results into separate file and perhaps a possibility of adding notes to times.

Kalle Kuismanen

Mobile, Current Projects

---

New downloads section

3103 days ago

Looking at the logs, I noticed that people are downloading older versions of the few applications we’ve posted here. Reason seems to be, that old links lead to older articles, which have a link to the first or second implementation. To make life easier for everybody all the latest versions are now listen under downloads.

See the downloads in the section menu on the left or follow this link there.

Kalle Kuismanen

Random,

Comment

---

Improvement

3132 days ago

Last Thursday I had the pleasure of substituting as a coach for a girls soccer team. I used to coach them when one of my daughters played with that team and now got called back when their current coach had other engagements.

We practiced shielding and passing under pressure, some fitness and few other common things that are done in soccer practice. I think that the girls enjoyed the practice. For me it was fun to see how they had progressed after my departure.

I have a habit of procrastinating in the morning and let my alarm snooze many times before getting up. I usually think about what I’m going to do that day or next few days or if I’m working on a problem that needs to be solved with logic instead of persistent trial and error. This morning I started first to think about Trie search trees, that are one solution to the problem I’m working on, and how they could be packed fairly efficiently so the memory consumption would be reasonable but we wouldn’t lose all of the efficiency. In Wikipedia there are few links to such solutions such as DAG where we make a directional acyclic graph of the nodes etc. Other solution is to take the hardware architecture into account and design the iterations so that they fit into processor cache.

Anyway after a while I got tired of trying to imagine data structures, algorithms that iterate them and O values for them and started thinking about the practice I had held. The drill was simple, one player has a ball and shields it from second one that tries to take it from the first and third one is free. When the first player is able she plays the ball to the free player and now the free player shields the ball and second player tries to take it. It started to bother me that the player who shielded the ball is in a way out of the game after the pass and also that there was no direction to the drill. So even though the kids liked to wrestle each other for the ball and everybody got a good workout the drill could have been much better. Difficulty is that when we increase complexity it is easy to lose track of what we are measuring, but when we make things too simple it has no correlation in the real world.

So the drill now taught not to let the opponent get the ball. Free player was taught to move so that ball could be passed to her and the defender was taught to wrestle ball to herself. This drill lacked a basic element, however. What should happen after the free player receives the ball? My original thought was that well the free player passes the ball back and we try to shield again and then rotate. Girls found this unnatural and changed the drill autonomously so that the defender moved to pressure the player with the ball. This made the drill work much better, but still it lacked the basic element of the game, which is progression towards the goal. In a way the girls modified the drill to typical ineffective passing that happens in intermediate and beginner games i.e. ball is passed, because coach told us to pass and that person happened to be in my view. Usually situation after the pass degenerates, because pass is not accurate, player is too close and receivers ability to get the ball moving is not high enough to improve the situation.

In a way the problems weren’t that different from my original thought how to improve the algorithms with all the trade offs. If I make the algorithm more complex do I still understand it so I can run tests on its efficiency? On the other hand if I make simple algorithms does it actually represent the real solution and do my measurements reveal how the final implementation will work? I like to experiment so I think I’ll write a more complex version and see how it fares against the fast but memory hog. I will have to make few versions. In the end it might be best to use sorted vector and quick search.

I didn’t come to any conclusions how the practice with the girls should be solved or how my search should be done. Many ideas some good some bad. The main thing is actually the process of thinking how I could have done more with same effort. Perhaps the players could have played a wall pass. Then the first attacker would have had to sprint past the defender after the pass. Would that have worked? With my minds eye I can see how I think it will work, but I won’t know until I test it in practice.

Kalle Kuismanen

Random,

Comment

---

« Older