Coder's Log

After reading/watching Stuart's nice slides on Closures in the context of JavaScript, I have started to like JavaScript. Personally, I don't accept any language as a high-level scripting language if it doesn't support closures. Python is therefore straight out of my window. Although Vala isn't a scripting language, it would be nice to have such support in there as well. It already supports lambda functions with no restrictions and Jürg has concrete plans to support closures, it's more a matter of when rather than why or how. When that support is there, just try and stop me from loving Vala. :) UPDATE : Thanks to Anonymous, I now stand corrected that Python does fully support closures. Although I still don't like the fact that it restricts lambda functions to be one-liner but at least it's not straight out of the window anymore. :) UPDATE#2 : Andy Wingo informs me that python doesn't really fully support closures. He even put up a small code fragment to

Since I totally agree with last two blog entries of Havoc, I originally started to write this entry to get them to the planets I am on and he is not (yes, there are some) but then I couldn't resist adding my own thoughts. :) Regarding "embeddable" scripting languages, I came-up with the exact same conclusion 4-5 year ago. When I looked around at that time, I realized that GNU had realized that long time ago and had a nice embeddable implementation of the easiest yet powerful language, Scheme. Guile was the name of that implementation. I soon became a firm believer of "Most of the implementation in C, while the highest-level (only) logic written in Scheme/Guile". While I was acting on my belief, I couldn't help but notice that the only other person in the whole GNOME community that had similar vision was Andy Wingo. Many (if not most) had been going for Python. Some of them even took this scripting language as far as coding complete frameworks in it. As

When I wrote GUPnP Network Light, I thought of it as just a simple example application that demonstrates how easy it is to implement UPnP devices and services using GUPnP. However there is one man, Mr. Hugo Baldasano Calleja who being an electrical engineer is very much interested in light bulbs and has recently been writing control point for Network Light. While discussing about his code with him on IRC , I started to wonder how would a simple control point GUI for Network Light look like. I realized that it would look exactly the same as the Network Light itself. Since Hugo had already made it possible for multiple instances of Network Light to co-exist happily on the same network/machine, I decided to turn Network Light GUI to be a Control Point that controls all the Lights on the network, not just itself. The change is already in the trunk and will be released soon. Here is a screenshot:

Jorn made minor releases of GSSDP and GUPnP today. The main purpose of which is to fix the build on Rawhide. Here is the release announcement: GSSDP 0.6.2 =========== - Reannounce resources after max_age / 2 - 1 instead of after max_age. [Peter Christensen, Jorn Baayen] - Remove unnecessary call to g_thread_init(). [Zeeshan Ali] GUPnP 0.12.2 ============ - Support returning actions outside of the 'action-invoked' signal handler in service implementations. [Zeeshan Ali, Jorn Baayen] - Add explicit dependency on gthread. [Zeeshan Ali, Jorn Baayen]

Ever since I started to IRC from my Linux machine, not only I had been a happy (almost) user of XChat for years but also I wrote an XChat plugin for Guile. All that changed when I moved to Finland three years ago and was educated about the benefits of the combination of irssi + screen +ssh, the biggest (perhaps the only one) of them being the persistence connection to IRC. Since then I had been using that combination. After three years, I am having doubts about the choice I made at that time. XChat might not be able to provide me with a persistent connection to the IRC world but it still provides lots of small features that irssi does not (and in some cases can not) provide that really does matter in the end and one would expect in a modern IRC client, e.g hard-to-miss notifications when I get new messages, saving of logs and DCC-sent-files directly on my local-machine etc. I switched to back to XChat a few days ago. I mostly feel good about coming back to it but still miss the persi

Peter Robinson had made RPMS for GUPnP package for a while now but it was until recently that someone got a chance to review them. The first (and IIRC the only) issue that came out was that the build was breaking for all our apps. Here is what was happening: We call g_thread_init() in each of the application because libsoup requires us to do that. If I understand correctly, libsoup needs the threading system to be initialized for locking stuff that is actually a part of glib. While we don't mind putting this call in each of our app, we assumed that libsoup requiring us to make this call will itself link to libgthread-2.0. That assumption is true about libsoup-2.4 built/installed from vanilla release tarballs, subversion repo and debian/ubuntu packages but on Rawhide, it turned out to be false. I (and a bunch of other developer hanging out on #gnome-hackers) had a chat with Dan Winship about this and in the end he agreed to put gthread-2.0 in libsoup-2.4 pkg-config. He said that it

Just pushed my commits to gupnp-media-server SVN trunk . Now we support plugable media providers, which can be written either in Vala or C. Also included in these commits is gstreamer-based metadata-extractor. Still not done (due to lack of time :() is a standalone media provider based on this extractor, GIO and SQLite.