Wrong Way

Seems like I stepped on a wrong path. Things are getting too complicated. I'm not ready to support full objects hierarchy in plain C. I don't want a lot of automatic actions. The code should be much simpler.

Some things learned from what have been done are useful. I'll keep the experience and continue hacking source in some other way. It's time to think. :)

New API Structure

As I already noted, I have played a little with valgrind and kcachegrind, and measured some new code against ideal, hand-written code. The first thing I noted is amount of time spent in malloc and free functions. Another thing is that time spent in single wrapper function became significiant when that function is called about millions of times. Let's look closer at WMCreateObject function. It is simple wrapper over malloc with few checks. In the nearest future this function will be called everywhere. Why not make it inline?

Another issue, that eats time on many calls is checks for null-pointers. I don't like the idea of terminating application once I got out of memory. It's application's job to decide what to do. Construction functions return NULL if memory allocation fails. If it doesn't fail they're filling allocated memory with some data. And those checks are really taking time. Generally I don't need more than one check for single object construction call.

The solution I came is to divide API. Internal API will be set on small, mostly inline functions, mostly without any checks. This doesn't mean it would call malloc and than unconditionally write something in returned pointer. Memory allocation and filling object with data is just different functions. With this structure I will be able to allocate memory, check for NULL, and call multiple filling functions without penalty for additional checks.

Naming Conventions

I'm changing the project name. The name WindowMaker will be held by original project. It's possible that original development team will wake up at some day and produce something. I doubt that they will, but it's possible anyway. Since I'm practically forking original project, it's good idea to change the name. NextMaker seems like a good name for my project. I thought it out in times of first attempt to fork, and I think, I'll keep it now.

Now, to the style. I don't like pascalish names used everywhere in WindowMaker. I'll make them all lowercase and with underscore as word separator. The shorter name is better the longer one. Prefix change reflects change in project name. Now all function names will start with «nm» instead of «WM». Prefixes and suffixes of names will have some meanings: «nm_» stands for ordinary exported functions, «nmi_» is for internal functions, which is usually inlined, «nmt_» is for type-tags in object system and so on. For example WMReleaseObject function will become nm_release after change, and WMString will be nmt_string.

I won't do that all at once. Changes will be made only in parts of code I'm touching. There's also some plans on changing file layout and structure of API, but those are things I'll think about a little bit later.

Testing

Nobody will argue that code needs testing. Testing can be performed in numerous ways. Sometimes testing is not enforced by project conventions (which happens at work mostly, because no-one is willing to spend time to create something that don't provide any cool features). In those projects I usually create bunch of files named a.c, b.c and so on in a root directory of a project. These are «tests». I compile and run them by hand. I never commit those files, and often forget what are they for. I'm always afraid to delete them by some mistake.

In my home projects I have a freedom to do whatever I want, including writing «useless» code solely for testing purposes. And I feel good. Whenever I want to know if my recent changes break something I can type «make sure» and check that everything is ok (or not ok :) ). I would like to do such things with WINGs too, but no-one before me cared to write any tests for WINGs. Few small programs in WINGs/Tests directory can't be counted as real tests. They're just like my ?.c files in projects at work with one small exception: they are commited in cvs.

I use cunit package to test the code written in C and valgrind to detect memory leaks. Usually, I just run cunit program under valgrind. I'm starting writing tests for parts of WINGs I touched. Tests won't be compiled by default. I don't want to force everybody to install cunit at their systems. To start testing go to WINGs/Tests directory and type «make sure».

Quest Description

WindowMaker is dead. Admit it. Website is half-alive, cvs is down, mailing lists are down, last release was more than two years ago. About three years ago, in previous stale period I have tried to start hacking it. The results were creation of new development team, creation of WM2 branch, and new release of main branch. Now the project staled again for a long time already.

I'm starting hacking it again. This time I work alone, privately, without any team. I am doing this for my own amusement and I fell free to change anything I want, even if what I change is a minor, unimportant, or low-priority improvement. I have source of the last release, and the cvs snapshot I was able to catch before servers went down. I don't care for «official releases», but at some point I'll make my git repository publicly available. I don't accept any patches. I don't want your code, please don't spoil my hacking fun. :) But I would be thankful for ideas and code reviews.

This blog is attempt to document the way I was thinking while changing code. Everyone can check what was changed, and how it was changed using version control tool. With some discipline from committer, it's even possible to see why something was changed. I thought that writing a blog can be a good way for describing decisions not directly affecting the code. And it can show what I was thinking about when decided to make some change.

Tags are filenames in repository. May be I will use some additional tags when appropriate. When my git repositary go public, I'll write commit ids to related postings.