Analytics Tracking Code

Thursday, April 15, 2010

CoApp and Visual Studio

I have begun work on the Common Opensource Application Publishing Platform or CoApp.

Before I get too carried away, I'll say a few words about CoApp and why it is important. First, there is a figurative mountain of Open Source Software out there in the world. On a day to day basis we interact with some of it in applications like Firefox, Thunderbird, Google Chrome. In many situations, the OSS is hidden underneath a commercial application. For instance, WinAmp, Lotus Symphony and others certainly fit into this category.

So many of us are already using open source software on a regular basis and many times we aren't even aware of it.

However, if you ever take the moment to use a Linux desktop computer or a recent version of Solaris, you will know that there is much more os software "out there" than is currently available on the typical windows desktop computer.

There are number of reasons for this, and Elizabeth Marie Smith gave a couple not too long ago

Projects who don't care.
Projects who don't have the developers who know Windows.
Projects who don't have the tools to develop for Windows.
Or don't want to learn the windows API - who expect windows to work exactly like unix or linux


I would personally like to add one more to this list

It's really hard

When it comes down to it, bringing an the typical OSS application to windows requires an enormous amount of cajoling and sometimes magic. For instance, if you want a headache, look at what it takes to bring something a straight forward as the gedit text editor to windows.

The library dependencies are where we fall down. Much of the software was written for the linux environment, and although it has been somewhat ported to work on windows, there is an awful long way to go. Most of the libraries do not compile under Visual Studio C++ (the Windows native compiler for C/C++ ) without significant effort.

This is where CoApp will step in; the project intends to produce tools which greatly ease the porting process, and to provide a software repository and package management system to install the dependencies as needed.

Most importantly is the developer end of the story.

CoApp will develop an extension to Visual Studio which which will allow developers to choose which open source dependencies they want to link to. On build time, these will be downloaded, and installed on the developers machine in a common reliable location and linked against the developers binary in a safe and redistributable fashion.

Friday, March 12, 2010

On Managing Email

I run a small computer and communications company, and most of my interactions with the world seem to go through email. I arrange meetings, send documents, plan schedules, and sometimes even do some work.

Well, today I took a serious look at my inbox. At 10:30 this morning I had 730 threads, many of which are just simple questions like "When can we meet?" to much more complicated conversations. In those 730 threads were a total of 4,271 distinct emails. Of those 4,271 emails were 306 unread emails that I simply never got to over the past 6 months, most of which I was not a direct participant in anyways.

For some reason I decided that today was the day that I would deal with, read and otherwise handle everything that was left incomplete in my inbox, and by midnight I would have nothing left in it.

Many emails, although they aren't exactly junk, are no longer relevant. For instance, a schedule someone sent me for November doesn't have a lot of relevance to my life today. So delete it.

Delete it?

Yes. Delete it.

I know all about the wonders of archiving and the palaver about keeping things around "just in case". Well... my inbox is not a storage location.

So I took anything with attachments that I felt I might need and saved the attachments to appropriate locations, and deleted the emails.

Anything with "When will you be here", "I'll be there at 8:30" style of content got wiped.

And anything that I have decided to just never handle also landed in the bin.

And I wasn't gentle, everything in the trash has been permanently shredded.

And yes yes, I archived a couple things in out of the way places.

So here we are, as I type this the clock just clicked past midnight and after a full day of managing my email I now have the following: 61 emails in 37 threads.

Those 37 are the only things that I couldn't just ignore, and I am now waiting for the other ends of those messages to get back to me. ahhhh

What a day, I feel like my eyes are bleeding.

Saturday, January 9, 2010

Family, Ojibwa Art and story telling

As an Ojibwa elder in her own right, my mother maintains a website relating to native art in Canada and the Ojibwa/Anishnabe culture. As an adept story teller, her website is a well crafted series of stories and histories so I suggest that you read what she has to say about herself and her life and the culture of our (hers and mine) mutual ancestors.

Thursday, October 8, 2009

Intel C Compiler, GTK and OpenBSD on Windows

I am currently working on the windows port of the Volume Management application that has consumed my waking moments for the past several months.

I wrote the application using GTK+ for a number reasons:
  • Wanted to learn GTK
  • Portabilty (Although a LOT of this is on my shoulders)
  • I wanted to learn to apply the Gnome HIG
  • I wanted to
  • I don't want to write it in
  • Because I can
This is all well and good while running on my linux desktop, however, as I knew from the beginning, I would need to port the application over to Microsoft Windows. Since I imagine that nearly ALL the target audience of this application uses Windows, this is REALLY important.

To make this happen, I have written a decent initial implementation of the application for my linux desktop, copied it to the Windows partition and opened it up inside of Visual Studio (with nice project files and all). Now comes the really quite hard part.

GTK is not native to Windows. So looking at the the GTK site, it is moderately evident that one is expected to build their Windows apps from within a linux(y) environment via some sort of cross-compiler voodoo.

Hmm, what to do.

I happen to own a rather expensive license to Visual Studio 2005 Professional. Shall I just leave it and head back to linux or, shall I try to get my program built against the mish-mash of binaries available from gtk.org or should I go for broke and setup a complete build system for all of GTK and its dependencies?

Hmm....

A number of years ago I tried to do the whole dependency tree thing in an attempt to get FreeOrion built in Visual Studio. A great deal of time later and I was never able to get a binary which would actually start. Then again idea of compiling windows software in linux seems a bit silly, kind of in the realm of "just because you can does not mean you should". And this has me wondering about the quality of the binaries available at gtk.org, they are probably fine except I have no real auditing trail for their construction.

So after an hour or so of deliberation, I have concluded that come hell or high water, I shall make my application run from the ground up building all the necessary binaries from scratch along the way. Visual Studio really shines here with built-in dependency management. If I change a dependency, it triggers a rebuild of all the dependent components right the way up the tree.

Next problem though is the compiler. While the C++ compiler in Visual Studio is getting markedly better with each release, the C compiler is rather out of date and is likely going to remain this way for ever and ever. Also the C runtime is currently missing a lot of the new goodness available these days. For instance asprintf (which gets rid of a lot of head aches, especially when customizing SQL calls).

The C runtime is something relatively easy to work with, as I can just create my own DLL of any missing functionality. OpenBSD provides what I consider to be the most desirable implementations for this kind of stuff, so I have pulled strlcpy, strlcat, asprintf and others into what is now bsdc.dll

And lastly is the compiler. I thought about this long and hard, and finally concluded that I really want to be able to use the latest innovations in C, so I bit the bullet and bought a license to the Intel C compiler. The installation is easy and switching compilers is straightforward from inside the IDE.

Assembling the project is nearly 50% complete at the time of this writing, and I will post with an update as to how it all goes together when I get my app finally running.

Also I will publish the build environment when it is ready as well in case there is anyone else out there who wants to do the same thing (inkscape? pidgin? evince? gedit?). It would really be nice to have a serious development environment available for this kind of thing.

Wednesday, September 23, 2009

Hamster and further topics

I am thoroughly disappointed in the Gnome folks for posting a pic of the new time tracker applet in 2.28 with the title "Hamster". Why should a project with that name be allowed into gnome proper. That said I do quite like the applet. I think.

Anyways, the much anticipated Gnome 2.28 was released a while ago. I have been running the development version of OpenSUSE for the past while, which has been more or less tracking the development of Gnome so by this point, all I have to say on the matter is, meh.

It's a desktop environment, and for somethings it meets my needs, and for others, I couldn't care less.

In unrelated news, I have recently filed a shwack of bugs against opensuse factory in an attempt to stabilize the desktop for myself. I have not been terribly happy with the overall stability of the development versions of opensuse, and am constantly running into stability problems an a variety of quirks.

That said, I am strongly considering moving to OpenBSD for precisely this reason. While I like to be on the bleeding edge of things, I have had quite of enough actual bleeding thank you very much.

So, in conclusion, hamsters should be shot, instability = bad, and my laptop is burning my tummy.

Tuesday, September 15, 2009

Posting to blog from links

Well, here is the first time that I have done anything like this. The latest milestone from OpenSUSE is broken. Apparently they patched HAL with a crummy patch or something and now when you boot the OS hal crashes and you cannot access your mouse or keyboard while X is running....

Not the slickest thing that I have ever seen.

Anyways, I booted to the commandline rather than start X and am posting this comment from the links browser.

I couldn't tell you if I like the experience, but it is definitely a first for me.

Anyways, this is not meant to be a profound or indeed informative post, I just wanted to see if I could actually do it from the commandline line in text mode, and it turns out that I can.

Now I am going to go to bed just because it is that time of day.

So long.

Ted

Wednesday, September 9, 2009

Accuracy of a GPS in a Car

So I have been having fun the past two days driving around Canyon Meadows (here in Calgary Alberta) with my GPS collecting information to post to Open Street Map. Although I have used the GPS for most of the summer as I scooted across the country with my bike, I have not done much with it in terms of actual mapping.

Now that I am officially back in town, I figure that a little bit of mapping would be fun to do, after all there is hordes of information missing even from the community within which I live. So last night, one of my boarders and I hopped in the car and drove the alleys of NW Canyon Meadows. I was slightly disappointed to discover that when I plugged the data in JOSM, the track was jagged and in areas, clearly wrong. What could be the problem? I have used this before to map the town of Empress Alberta without much difficulty.

It occurred to me while lying in bed that maybe the problem had to do with where the GPS was stationed in the car. On our midnight saunter, the gps was held in my passengers hand somewhere around or below his lap. Could this cause the problem? Maybe the unit needs better line of site to the satellites, and even the moderate amount of flesh and metal in the way was interfering with this.

Perhaps this is bang on because I just got back from another little jaunt where I had the GPS sitting on the dash. The result is considerably better and dramatically smoother. So the moral of the story is that the best place for your GPS while in a car is somewhere near the dash or somewhere with more or less clear access to a large chunk of sky. I suppose the more sky, the better.

As a side note, the unit was reporting on average +- 3 m the second time around.