Shaman, revamped!    Posted:

Upon looking back at my code of Shaman 1.x, I discovered that it was really quite disgusting. It was dense, difficult to read and poorly implemented. Furthermore, many of the conventions I used in the first version were entirely not portable and incredibly inefficient. So, I resolved, a couple of weeks ago, to begin work on the second major release which would fix essentially all of the problems 1.x experienced.

First, and foremost, this means that the non-native C functions I used (namely curl and grep) had to be replaced by their native C counterparts. As a result, the work underway for Shaman 2.x will use a variety of libraries that the 1.x branch did not. Most obviously, this means it will link to libcurl rather than call curl inside a shell. Beyond the native implementations, the 2.x branch will be using much cleaner code conventions to complete the task delegated to it. The improvments in this area are clear everywhere. The following is a short list of all the improvments that users can expect:

  • libcurl for native data fetching
  • C's getopt for more sensible parsing of command-line arguments
  • libxml2 instead of giant, disgusting and essentially obfuscated fscanfs for parsing the fetched data
  • libconfig for sensible configuration parsing
  • General code cleanliness and conventions (like prototypes and declaring variables where needed; not all on the stack)
  • strftime-like format string for simpler and more configurable output according to user-needs

The end-result of this update will mean a few things. First of all, the final binary will certainly be a bit larger than 1.x. Having said that, it will run more efficiently, much faster and the weather data will be formatted exactly how users wish it to be which should mean easier parsing and more flexibility for a greater number of use-cases.

Though the work on updating Shaman has really just begun, a great deal of it has been completed. Because I have never worked with any of the libraries mentioned above before, I suspect that the final project is still a way off. Still, development is active and you can follow my progress on my GitHub. As always, pull requests, suggestions and feature requests will always be appreciated—though I would ask that everyone hold off on bug reports until the testing stage is reached.

Shaman, an adventure with C    Posted:

I have been proficient with scripting languages for a long while now, and once upon a time I knew something about Python (but that has long since been forgotten). Having switched to a very minimalist desktop environment (the whole thing with all my customizations is ~1500 sloc of C), and dealing with several C programs (along with having been made an official contributor to one of the projects written entirely in C), I felt it necessary for me to pick up one of the more universal languages and C seemed the obvious choice. I've messed around with a few small C programs as ways of getting my feet wet (i.e., vulpes, immio). However, a short while ago, I stumbled upon an awesome tool called weatherman, and it inspired me to begin working on an alternative written in C using the NOAA as a backend rather than weatherbug.

Thus was born, shaman. Originally, I really only wanted it to be able to fetch only the current conditions of a given location so that I could use it to display a relevant weather icon on my statusbar (using vulpes). But, as is the way with these projects, it evolved to also fetch temperature, and now, at the time of writing this post, shaman is capable of fetching the following:

  1. Reporter name, location and coordinates
  2. Rudimentary hazardous/severe weather warnings
  3. Current weather conditions
  4. Temperature
  5. Heat Index
  6. Wind reports
  7. Humidity
  8. Dew Point
  9. Visibility
  10. Pressure

It is also capable of printing mesurements in Imperial and Metric units. I am also working on implementing 7-day forecasts.

Currently, there are a couple of C conventions that shaman does not adhere to (these are planned enhancements that I just need to learn before I can implement). These include native use of libcurl rather than calling a shell and executing curl itself, and using offsets in loops rather than using pointer arithmatic. I do, however, want to finish implementing my planned 7-day forecast feature so shaman can be functionally complete for its first version before I go and start messing around with the backends that I don't fully understand.

There is also one other possible feature that I am considering but I do not know if I will ever implement. If you have ever used the date command or the backend which it utilizes called strftime, then you are likely familiar with their format-code printing system. That is, you pass a string to date which tells it what you want to see and how they should be printed and date complies. Currently, shaman prints information in a pre-formatted style that cannot be edited without editing source. After having released my code on github and publishing an announcement for the project on the Archlinux BBS, it has been requested that I add a similar feature (this is something that weatherman actually does too) so that a user may determine the exact output and format of the data which shaman fetches. This would require a great increase of code but would make its use extremely versatile.

Should 7-day forecasts go well, and the migration to libcurl and pointer arithmatic go well, then this may very well become the last thing to implement before considering shaman to be essentially feature-complete. In the meantime, I have plenty to keep me busy on this project.

Man Pages, a How-to    Posted:

One of the projects I have come to work with the most during my tenure using Arch Linux is Alopex. It is an extremely lightweight Window Manager (~1500 sloc, with no edits). It is, in many ways, similar to dwm. Like dwm, Alopex is written entirely in C and, as a result, essentially all its configuration options (of which there are plenty) are sourced at compile time. This leads to the whole window manager being in the neighborhood of 70 KiB (74 with all my customizations). When I first became interested in Alopex, the only documentation available was the generously-commented config.h (the file inside which almost all user customizations reside). Partially to help contribute to this project as best I could, and partially to get comfortable editing and contributing to the (fabulous) ArchWiki, I created Alopex's ArchWiki page. This, I would like to think, is a very helpful resource (particularly for Arch users). But, much of it is very focused on Arch Linux alone, and since Alopex is not a project explicitly meant for Arch (though all of its contributors are Arch users at the moment), I wanted to help provide documentation that would benefit anyone that might use Alopex.

Thus, I began looking into writing man pages. For anyone who isn't aware, man is a utility for reading "manual" pages provided by upstream projects. The ArchWiki might be nice, but it can be edited by anyone and there is no guarantee that it will stay up-to-date. Man pages, on the other hand, come directly from upstream (or from dedicated contributors), so they should always be the first source to consult. To accurately document Alopex, I felt I needed to create three pages.

  1. alopex.1
  2. alopex.icons.5
  3. alopex.config.5

The first is a simple and relatively short page that gives a very wide and concise overview of what Alopex is. The second is an even shorter page documenting how Alopex creates its icons and giving some guidance on how a user might add their own custom icons. In the future, the icons page might become a themes page and also include documentation on Alopex's color-schemes. And, the final page is a much larger page which documents, in-depth, all the features of the config.h.

Man pages are written in a language called groff, but for the most part, they are just plain-text with various formatting modifiers to reflect convention. The basic modifiers you'll need to know to setup the most basic of man pages are as follows:

.TH Creates the Page Header
.SH Creates a Section Header
.RS Indents following text
.RE Dedents following text

While there are conventions for formatting various things (bold for commands and environment variables, italic for files, etc.), these are largely up to the man page author (though you should make sure that you're use of formatting is consistent throughout your writing, and following convention is a good idea). There are also various ways to format text, there are simple modifiers like .TH and .SH which will only affect text that follows on the same line, and there are also more complex modifiers that allow you to add them in-line to a paragraph. Personally, I tend to prefer the in-line versions so I do not have to deal with the disjointed nature of all the extra line-breaks.

For a fabulous, in-depth walk-through of everything you could ever want to know about man pages, take a look at this page by Jens Schweikhardt. And feel free to take a look at the pages I wrote and linked to above and use them as a starting point for your own projects.

An Introduction    Posted:

Having used various GNU/Linux distros for several years, I have a rather hefty set of dotfiles which you are more than welcome to clone/copy/share/etc. I maintain a few packages for Arch Linux on the AUR and several others (including some works in-progress) on GitHub. I also do a bit of editing and contribution, when I can, to the Arch Wiki and I am a moderator for the Arch Linux Community on Google+.

You can follow me on Google+ though I only post occasionally. And feel free to add me on Steam (I won't accept blind invites; please message me first).

This page will serve as a home base for whatever personal projects I am working on (and any professional ones should they ever overlap with the tech-focused paradigm of this site). I will do my best to keep it as up-to-date as possible, but I make no promises with respect to that. Eventually, who knows what it may become?

Creative Commons License BY-SA Contents © 2013 Sam Stuewe - Powered by Nikola