picking at the fringes of reality
Aug 04 2008
So, I revoked my Enlightenment CVS access today. With the recent license flamewars and the sudden switch from Bugzilla to Trac I’m sick of the politics surrounding the project. It isn’t fun anymore.
To that end, I’m giving Nathan the authority to do what he sees fit with my code in CVS (including changing the license if he so desires).
It’s been a long strange trip. Now to figure out what to poke at next.
Dec 05 2007
We made a release of Ewl last night. This is our yearly release (we really have to get these out quicker). Given its been a year there is a pretty big list of changes. The diff file was almost the same length as the code base itself. Below is the summary of changes.
Give it a try. If you find any bugs they can be logged to Bugzilla.
Jul 11 2007
There is an excellent article in the ACM Queue on API Design. Having given it a read through, what it’s describing is similar to how we’ve been working with Ewl.
We’ve sent a lot of time on the APIs. Nathan and I have exchanged countless emails, prototypes and test header files describing what we’re looking to do. We’ll often write test source files that use the interfaces to see how the ‘feel’ when being used. We spent a good couple of months working on the current MVC code that Ewl is using.
We spent a lot of time looking to get the most flexible design but not having it being terribly painful to use. I think we’ve struck that balance but it’s a test only time will tell.
With careful design of types and parameters, errors can often be caught at compile time instead of being delayed until runtime. Making the effort to do this is worthwhile because every error caught at compile time is one less bug that can incur extra cost during testing or in the field.
Catching errors early is a big one for us. Anything found at compile time can’t be a bug. Anywhere we can we use enumerations for your paramateres. The values are laid out with detailed names so you can see what’s going on just by reading the caller code.
The APIs are designed to be consistent (and inherit from other widgets as much as possible). We setup a naming structure and have religeously stuck to it (spending the extra time to break all the APIs that didn’t conform to the conventions).
The big convention that Nathan had in place before I join is that all callbacks have the same signature. void cb(Ewl_Widget *w, void *ev, void *data). No matter what you’re doing that’s the signature. It makes it very easy to write out function headers and fill in the bodies later. You never have to look up and see what the signature is for a given callback. (The callbacks are, of course, an enumeration so any errors there will be compile errors.)
Anyway, if you’re doing any API design I’d recommend the article. It gives a lot to think about and a few good examples of how things can go wrong and the cost to fix it when it does.
Jun 29 2007
There was an interesting utility mentioned on IRC the other day
Pahole. What’s Pahole? Well, it’s an application that can tell you about holes in your structures. (And yes, if you’re not a programmer you probably really don’t care and can stop reading, heh.)
There’s an LWN Article about the initial release of Pahole and Nathan point to another excellent article. So, between the two of these I managed to get it working.
I’m using Ubuntu here and had to install a few utilities/libraries for everything to run successfully. I installed:
After that following the instructions everything compiled fine. I ended up with the libdwarf stuff in /usr/local which I didn’t like, and pahole didn’t like either, so I moved it to /usr/local/lib and re-ran /sbin/ldconfig. Everything seems to be working as expected.
With everything installed I ran it on ewl:
pahole -V ewl_widget.o
and got…..nothing. After a bit of fiddling I realized I had removed the -g last time I compiled Ewl. Once I’d re-compiled Ewl with -g and re-ran the above command I got the expected output:
struct Ewl_Widget {
Ewl_Object object; /* 0 76 */
/* --- cacheline 1 boundary (64 bytes) was 12 bytes ago --- */
Ewl_Widget * parent; /* 76 4 */
Ewl_Callback_Chain callbacks[25]; /* 80 200 */
/* --- cacheline 4 boundary (256 bytes) was 24 bytes ago --- */
Ewl_Attach_List * attach; /* 280 4 */
void * smart_object; /* 284 4 */
void * fx_clip_box; /* 288 4 */
void * theme_object; /* 292 4 */
const char * theme_path; /* 296 4 */
const char * theme_group; /* 300 4 */
const char * theme_state; /* 304 4 */
const char * appearance; /* 308 4 */
const char * inheritance; /* 312 4 */
int layer; /* 316 4 */
/* --- cacheline 5 boundary (320 bytes) --- */
int toplayered; /* 320 4 */
Ecore_Hash * theme; /* 324 4 */
Ewl_Pair_List theme_text; /* 328 8 */
/* size: 336, cachelines: 6 */
/* last cacheline: 16 bytes */
};
Which, surprisingly , had no holes in it.
After that I ran it on /usr/local/lib/libewl.so.1.0.0 to see what everything looked like and came out with this. There are a few structs with holes in them, but nothing that we can actually fill.
If you want pahole to give you information on filling holes you can run:
pahole -RC Ewl_Widget /usr/local/lib/libewl.so.1.0.0
and it would try to fill any holes in the Ewl_Widget structure.
All in all, a pretty cool little utility. I’ll have to keep it around and check Ewl every now and then to make sure we aren’t wasting any memory.
May 17 2007
Well, Nathan has done it again and sucked me back into doing Ewl work. I’ve been taking a break for a week or so as I was getting annoyed with various aspects of the Enlightenment project.
I’ve been off playing with OpenSolaris and submitted my second patch. We’ll see if it gets committed.
I’ve also been spending a lot of time playing Crackdown for the 360. It’s a lot of bloody fun. There is just something satisfying about running down criminals at high speeds and tossing grenades on their heads from the rooftops.
Anyway, as I said before, I’m back playing with Ewl. Nathan has been looking at a patch I created to split the Ewl_Text widget into several smaller source files. I commited one part of this previously, the Ewl_Text_Context code. The second part of the split is getting the formatting information into Ewl_Text_Fmt and hide the implementation a lot better. The code is all written, we’re just in the debug state. Nathan has been poking at it and asking me questions over the last week.
Tonight he managed to suck me back in. He tracked down the likely cause of the position counters going negative and I’ve got that part fixed. Other stuff still needs to be fixed up.
The longer you work on a project the more code you invest and the more mental state you invest. That investment makes it hard to sit back and watch as everything gets re-invented over and over again. Poisonious people pop up and drive the desire to work right out. On the other hand, the code’s still there, there are still bugs to fix, and some of the people are really cool. I think, every now and then, you just have to say ‘toss it’ and go away for a while. Just ignore the project. Wait for something to draw you back in and make it interesting again.