title

pictures

2011-12-04T00:42:00.000-08:00

Contact list

Settings

Projects. Lots.

2011-09-11T19:30:00.000-07:00

Over the past couple weeks I finished projects. Eeze mounting. Pulseaudio integration. Other things that I don't remember doing.

One thing that I did, mainly over the last couple days, is get some time to work on everyone's favorite XMPP client. Add/remove contacts is implemented, status icons are in, there's toolbars, and everything just looks much nicer overall. Also I finally fixed the big shutdown crash (fingers crossed).

Quick Update

2011-08-26T01:14:00.000-07:00

I keep putting off the giant advanced Azy tutorial entry that I've been writing off and on for the past few months, mainly because I hate how code looks on a blog. It'll be up sometime, but probably not today. Or tomorrow.

Shotgun has gotten a lot of updates and features over the past few weeks. Crashes only occur "sometimes" now, and copying links is possible with right clicking. There's probably other things of import, but it seems to be fairly usable overall. I know there are people out there who have already switched from Pidgin, which is pretty neat for a small hobby project. With some luck, I will get more time to continue work on it soon.

Esskyuehl now compiles with recent versions of MySQL. Hooray!

I have spent the past week working on small bits and tests related to eeze mounting in EFM. All in all, I would say that I have accomplished a net of zero improvements. The main issue is the whackamole-like style of the bugs and my own inability to reproduce them regularly. Frequently, mounts will occur with no issues. Other times nothing will happen. Sometimes I get a crash. I'm getting closer, but the project is very demoralizing since there are no milestones.

Pulseaudio integration is still untouched since my last headaches in July. Once I sit down with it and take some painkillers I can probably bang it out in a few more days of awfulness, though no doubt Lennart has left me plenty more "features" which will hamstring my efforts.

Another project that I will probably use as a "relaxing" item is libarchive integration of lrzip. I have been reviewing the required API, and it seems fairly sane - what a delightful surprise! The downside is that I will likely use the command version of the API instead of directly integrating using liblrzip, meaning that my work there will continue to be unused. The upside is that libarchive will be able to build lrzip support without needing to check for a valid lrzip installation.

In closing, fuck everything about cnp in ELM.

liblrzip is go

2011-08-13T01:45:00.000-07:00

Another day, another project done. Liblrzip is the latest, a full API for the excellent LRZIP for which I wrote a build system way back in March. Straight to the code, here's a VERY simple example of a decompression app using the library:

#include
#include
#include
#include
#include

static const char *suffix_me(const char *file)
{
const char *p;
static char buf[4096];

p = strrchr(file, '.');
if (p && (strlen(p + 1) < 4))
strncat(buf, file, p - file);
else
strcat(buf, file);
return &buf[0];
}

int main(int argc, char *argv[])
{
Lrzip *lr;
if ((argc != 2) && (argc != 3)) {
fprintf(stderr, "Usage: %s file [outfile]\n", argv[0]);
exit(1);
}
lr = lrzip_new(LRZIP_MODE_DECOMPRESS);
assert(lr);
lrzip_config_env(lr);
assert(lrzip_filename_add(lr, argv[1]));
if (argc == 2)
lrzip_outfilename_set(lr, suffix_me(argv[1]));
else
lrzip_outfilename_set(lr, argv[2]);
assert(lrzip_run(lr));
return 0;
}

Yes, I am too lazy to figure out the CSS to preserve whitespaces for indentation.

XMPP: The infinite messaging protocol

2011-08-01T05:21:00.000-07:00

It has been a while since my last post, and I have been extremely busy. There are no shortage of projects to waste time on, and today I'll be talking about one of them. Since a screenshot is best, let's start off with one:

This is a chat client that has been co-developed by Iván Briano (Sachiel) and me over the past month or so. It is still in the very early stages of work in terms of its UI, but it is very usable.
Above you can see a screenshot of the client's contact list window and an empty chat window. The open menu is an early implementation of the status menu, and it allows the user to set the status of the account. The other component of the status menu is the status entry, which allows the user to set status messages; it can be seen at the bottom of the contacts list window.

This is another feature in development which uses a very unfinished Elementary widget called "gengrid." This widget allows a developer to autogenerate a grid view of objects. This view is toggled from a menu, and can be switched to at any time. As I mentioned, this widget is not very polished, and so it does not look as good as the list view :)

Here we see a shot of the chat window, where I am in a deep conversation with Leif Middelshulte (T_UNIX). Since XMPP allows its clients to connect multiple "resources" (devices) to the same account, this client allows for users to determine exactly which resource, or all of them, will receive messages. By default, it will abide by the priority value set by other users' clients, but if I click on this radio button in the menu, Leif will suddenly be receiving a lot of SMS on his phone!

One of the biggest strengths of the EFL is its integration with media. This next shot showcases what is, IMO, the best feature that this client offers:

Any time an image is linked in conversation, its URL is automatically parsed. This URL is then downloaded and cached to be made available as a tooltip on mouseover of the address, as seen above. Any images downloaded using this mechanism are automatically saved to disk using their SHA1 hash, preventing them from being downloaded again in the future and saving bandwidth. We hope to provide similar effects for other types of media as well!

One might ask what libraries I have used to power this client. The following is a list of all components involved:
Non-EFL technologies

The insanely fast PugiXML parser. I use this in all of my projects involving XML because of its amazing speed, concise API, and very friendly+helpful author :)

LibB64. If it uses base64 encoding, you'd better be using this or you're just wasting memory and CPU cycles.

EFL

ECORE: The networking API here makes connecting to XMPP servers a snap, and it also handles the STARTTLS mechanism of the protocol with ease.

Elementary: The EFL widget toolkit. Despite being under heavy development and containing lots of potentially unwanted "features," ELM still packs a punch and gives the developer a lot of freedom and control over how an app looks, feels, and acts.

This client is not yet available in the public E svn repository, but it is LGPL licensed and will be moved there once it is ready for public use. Keep your eyes peeled!

blogging is hard

2011-06-19T21:17:00.001-07:00

I haven't forgotten about this. Must...blog...more...

Azy has competition?

2011-04-14T20:27:00.000-07:00

I was recently informed that Azy has competition as a web service framework in C. The initial announcement for the other project seems to be here and the source on github here. For those too lazy to click, it's called "Raphters" and stands for:

Resources include things served up to clients like a database or API.
Actions provide ways to interact with a Resource.
Processors transform data.
Handlers provide the entry point for a request.
Templates render data.

Upon examination, it seems that RAPHT is a library which allows you to take small bits of pseudo-code and turn them into regex handlers for http requests. If a match is found for a request, it gets passed off to a handler which creates linked lists of both headers and response text which eventually get printfed to stdout and are then picked up by fastcgi for all the socket and network handling.

In a word, "neat." Assuming you have fcgi running, your web services get scaled down to a series of macros with corresponding add() calls for each one. This reduces planning/coding time considerably and allows you to easily implement a simple web/rpc server.
There do seem to be a number of features still missing:

No general callbacks for client connect/disconnect
No way to set HTTP response codes other than 200
Inability to support binary data transmission

Additionally, RAPHT requires synchronous execution around the fcgi loop, preventing use with any kind of main loop to handle events/jobs. As it uses CGI, it must spawn processes to handle requests even if the number of such processes is greatly reduced through the use of fcgi.
Perhaps the biggest downfall of RAPHT is its naive O(n) regex matching system. For each type of method (GET, POST, etc), it tries to regex match against every single service of that type. This means that every URL has its own regex and every RPC method has its own regex. For a server with very few services that is not a problem, but it is definitely not scalable.

Azy has none of these shortcomings, but the biggest benefit that it has over RAPHT (imo) is the ability to simultaneously generate client bindings (in C) for all of your server web services. This means that for zero additional effort, you get conversion functions for the structs that you use and functions to send those structs to your server, allowing you to save considerable time implementing a client.

I don't really have a closing to this, so instead I will post this picture:

Recursion

2011-03-31T13:01:00.000-07:00

I have a natural tendency to write libraries which provide unusual functionality. Libraries that I write always start out simple. I want to do X, so I write function Y.

Inevitably, this turns out to not be enough for whatever I am working on. I need function X to check for condition C, and IF(C), run X again. When working with event/state-based programming as I do, this quickly becomes a huge issue. If the inner loop free()s data still being used on the outer loop, at best I can hope for something simple going wrong, an IF(FREED_POINTER) evaluating as true or the like. At worse, crash. At absolute worst, extremely complex crash that takes hours to successfully debug and fix. Other problems appear as well, such as failures in maintenance of scheduled tasks and losing track of objects allocated in the inner loop.

This has recently become more relevant in my work to convert Zentific's backend daemons from using threaded and synchronous design with Glib and tons of mutexes to an asynchronous one using EFL. Both of the libraries which I use, Azy and Esskyuehl (esql), run recursively.

Azy uses recursivity to implement state-based rpc method calls which can be dynamically "rewound" to simulate a synchronous environment. However, in the course of the rewind action, Azy initially was unable to track the correct state of objects used in both inner and outer loops, and users were incorrectly allowed to manipulate objects which had either been freed or should not have existed to begin with. This is fixed now with the addition of more aggressive type checking and blocking free()s from the inner loop, but it has reminded me of the recursive main loops previously added to ecore for webkit compatibility. More on this in another entry.

Esskyuehl had other issues. In order to function properly, it maintains a list of queries for each database connection, sending the queries in order after the previous one has completed. Normally, only a very small amount of recursing is done: a query completes, the connection object updates its query list, and if there are more queries it runs the connection function again from within the completion function.
With a connection pool, this becomes trickier. When a query returns, the connection object updates its lists, then checks the rest of the pool to see if any connections need to have their queries rebalanced to other objects for optimal query speed. Thus, the completed query will rebalance the pool, sending any rebalanced queries on other connection objects and then sending queries for itself.
The problem here arises when a connection does not update its query accounting properly. A stale accounting list here will lead to a permanently occupied pool connection, or, if things get really out of control, callbacks/events used with the wrong query data. I have fixed more than one bug which resulted from such an error.

The common thing that I have noticed here is that most of the issues I have run into are the result of lack of recursion "glue", or an api to manage such things. This begs the question, is it possible to write an api for recursion?

Intro

2011-03-26T16:20:00.000-07:00

Hi.

I'm discomfitor aka Mike Blumenkrantz. I currently work for Zentific. I do development on Enlightenment and frequently break lrzip. This is my blog for talking about code.