Tag: C

Awesome C Program

May 12, 2010 » Geek

Over lunch today I came across this link on HN: comp.lang.c: For loops help

The request was for a program that would print this:

and the reply was this

I went ahead and compiled it, works like a charm:

So cool.

Move Subversion repository without svnadmin

November 12, 2008 » Geek

Update (2008-11-13)
Okay, so I did actually end up finding a way to move from SF.net for real. It seems they provide read-only rsync access straight to the repository directory. So here is what I did instead.

Update (2008-11-12)
Made a small performance change then ran it on the ClearPass repository. Worked flawlessly.

I have been having a terrible time trying to figure out how I can get the Subversion repository for ClearPass out of SourceForge. I could not find a single reference to svnadmin on the SourceForge and no examples of exporting without it. So I took matters into my own hands. Below is a quick and dirty shell script that exports and imports a repository one revision at a time, using common Linux command line tools and the svn command. I’m going to do more testing before using it for real, but so far it has done well. Hope this helps someone else in my position.

Download it: svncrossload

Better libcurl from C++

October 24, 2008 » Geek

I’ve been a longtime fan of libcurl. But I’m a C++ author and so the c level of that is not where I want to be (and cURLpp looks ungainly for my minor usage).

Firing up google on “libcurl C++” yields “Using libcurl from C++ | Luckyspin.org” as the #1 entry. This article show a good starting example, but it’s not quite there. Here’s a cleaned up snippet:

Now that is a totally legitimate use and it works fine. But do you see the problem?
Yep, the data (buffer) is global, as is the writer but that isn’t as big a deal. This
is not good for many applications and is not good C++.

So let’s encapsulate that bad boy shall we? It’s really not all that hard, so here’s some example code.

Now that example has all kinds of missing things and the object is useless beyond one request but that is not the point, it’s a contrived example. The point is that your buffer is no longer global and it’s protected by your class. You can make multiple requests without having to grab the data off by yourself. That’s the big deal.

I don’t want this to seem like I am putting down LuckySpin. It’s a good example, I feel this is just a step better.

Gtkmm/Glibmm Thread Example

September 30, 2008 » Geek

Heads Up!

This post uses a deprecated API. You can learn more here: https://developer.gnome.org/glibmm/stable/group__Threads.html

After dealing with threads in Qt and seeing how nice and simple it was, I decided to try again with the Gtkmm/Glibmm threading system. I think the crucial piece for me with the Qt threads was the excellent documentation, so I’m going to show you my full example here and document it in detail. As a quick disclaimer, I do not know if this is the 100% “right” way to do threads, but it matches up with everything I’ve read and, more importantly, it works.

Where to start…
I’m going to start with a brief description of what is going to happen. We will develop a threaded worker class, a trivial Gtk::Window class and a trivial main function. Let’s get the first two out of the way early, since they are the easy ones.

int main ()

This is a pretty standard main function, with one notable nod to Glibmm, and that is line 84.

You only ever call Glib::thread_init(); once, otherwise it will abort with an error. So what we are doing is asking Glib “Are you already handling threads?” and if it isn’t we initialize the threading system. This has the additional perk of aborting the program if threads are not supported at all.

If the rest of this function doesn’t make sense to you, walk away from this tutorial and go read the Gtkmm one.

Next we are going to implement that Gtk::Window class that we use in main, ever so imaginatively called MyWindow. There is nothing much special going on, so I’ll show you the full listing then pick out the important bits.

As you can tell, this is a simple Gtk::Window with just a single button (thrashHive) in it. In the constructor we connect this button to a method go() at line 52. go() is important to us because it is where we create and launch our thread, which is represented as the class Worker of which we have a pointer declared at line 78 called bee. Let’s run through go() line by line.

In lines 58 and 59 we are protecting our memory from trying to create multiple instances of a Worker thread, a good idea to stay safe in an asynchronous environment.

At line 61 we instantiate a new Worker class. Next at line 62 we connect the signal sig_done to our beeDone() method, which essentially just undoes everything we do in go(). We do this because this is a non-blocking, asynchronous working thread and we need to know when it is finished running. When we get to the implementation of the Worker class, you’ll see that this “signal” is not a given, but rather something we implement ourselves, and we can have as many “signals” for events as needed. Lastly we start our thread at line 63.

Here we disable our button and change it’s text. Why do this here and not before thread creation? In most cases that would be a good idea, but here we want to demonstrate that the main thread is still working, so we do updates to the GUI after we start the worker thread.

The Worker class is actually fairly simple. It has a basic set of steps:

  1. Create and wait to be started.
  2. Get started, create thread and run.
  3. Do work, emit signals, check for being aborted.
  4. Return when done, then wait around until cleaned up.

Just breeze over the full listing then we’ll go over each of those points one at a time.

We don’t have anything to deal with for the first point. In the constructor we just initialize the Glib::Thread to 0 and our sentinel boolean, stop to false.

For the second point, we need to look at start() and run().

start() is our public method, and it creates and runs the actual Glib::Thread. Doing that is fairly straight forward:

The run() method is where our blocking operations go so that we don’t have to worry about gumming up the UI, this is where the work actually happens (i.e. step 3).

In my run() I just wait five seconds and write to stdout, but if you are doing a lengthy process, you should occasionally check the stop variable for an abort condition by using lines 30 – 33. Always put your Glib::Mutex::Lock inside of their own block, it is easier to handle them that way as the destructor does the cleanup work for you.

On line 37 we see a “signal” being emitted. This is actually a Glib::Dispatcher, which uses pipes for asynchronous communication between threads. In practical application just treat it like a sigc::signal . If you need to communicate data, emit the Glib::Dispatcher and have the receiving thread do method calls to get the information from stored values in the sending thread.

One easy to miss caveat when using gthreads, you have to throw in some extra libraries with pkg-config --libs gthread-2.0, here is the command line to compile this demo application.

That is the guts of a simple Gtkmm/Glibmm worker thread, I hope that I was clear if not concise. Here is the complete listing of the program for your reading/borrowing/compiling pleasure.

Tags: , , , ,

KickTweet or Creating a KDE3 Panel Applet

September 18, 2008 » Geek

I started using Twitter again last week and wanted a Linux GUI client. I looked at the standard bunch, but none of them did it for me. I wanted something small and easy. Some had system tray modes, but I decided to make my own that would reside as a panel applet.

Doing the API interaction is easy, it’s just web services and I’ve used libcurl enough before to have that down. It’s the Qt/KDE piece that I wasn’t so sure about. I got started with my good friend Google, and found a few resources. If you are interested in creating a panel applet for KDE 3.5 or so, ignore the Google results they will only serve to lead you in the wrong direction!

Getting Started
I got started by firing up KDevelop and selecting “Project -> New Project” then choosing the “C++ -> KDE -> Kicker Applet” project. This will generate a nice framework for you to start developing your application on. It’s just like creating any other Qt application, but in a smaller space.

There are a few small things that you won’t get unless you poke around a bit. The biggest problems I had were getting the applet to expand properly and getting my input text box to accept focus. Both of these problems were solved by reading the code from “mathapplet.cpp” by Andrew Coles in the KDE source tree.

I’ll start with the expanding issue. The first fix is to change the constructor to pass KPanelApplet::Stretch instead of the default KPanelApplet::Normal, as shown below.

This only fixes part of the problem though. If you load it into the panel as it is now, it will keep resizing until it has pressed all the other applets aside. This is because we need to fix the default implementation of widthForHeight(int height) and heightForWidth(int width). My fix here was to just feed back a standard value regardless of the current size requests. I copied mathapplet in sending back 110 for width and 22 for height. It doesn’t seem to be causing any problems yet.

The next issue is the input box focus. Again, this is taken from the mathapplet code and it is a simple if non-obvious fix. Just add watchForFocus(tweetText); to your constructor, where tweetText is your QLineEdit or derived. This is of course only relevant if you are using a text entry widget.

You can test your applet the easy way or the hard way. I tried it the hard way for quite a while, then when I got fed up I found the easy way.

the hard way is to do “make install” then add the applet to your panel. You will not notice changes if you do this version, because even if you add and remove the applet from the panel, it is not unload from memory. To get it unloaded you must restart the panel, easily done with a call to “dcop kicker default restart” This is slow an unwieldy however, and I recommend you only use it for testing the actual integration into the panel.

The easier way to test your applet is to still do “make install” but then to run your associated desktop file with appletproxy, like so “appletproxy /opt/kde3/share/apps/kicker/applets/kicktweet.desktop“. This lets you do quick and easy debugging and will send your cout and cerr to the terminal if you run it from one.

Creating a kicker applet is not nearly as hard as I thought it might be. After several missteps I now have “KickTweet” which readily scratches my Twitter itch.

KickTweet in action