Posts

Showing posts with the label GObject

My journey to Rust

As most folks who know me already know, I've been in love with Rust language for a few years now and in the last year I've been actively coding in Rust. I wanted to document my journey to how I came to love this programming language, in hope that it will help people to see the value Rust brings to the world of software but if not, it would be nice to have my reason documented for my own sake. When I started my professional career as a programmer 16 years ago, I knew some C, C++, Java and a bit of x86 assembly but it didn't take long before I completely forgot most of what I knew of C++ and Java, and completely focused on C. There were a few difference reasons that contributed to that: Working with very limited embedded systems (I'm talking 8051 ) at that time, I quickly became obsessed with performance and C was my best bet if I didn't want to write all my code in assembly. Shortly before I graduated, I got involved in GStreamer project and beca

libvirt-glib 0.0.1 is out!

The first public release of libvirt-glib is out! libvirt-glib wraps libvirt to provide a high-level object-oriented API better suited for glib-based applications. Daniel wrote nice release notes so I'll save myself some time and quote it for more details: I am pleased to announce the first release of the libvirt-glib package, version 0.0.1 is now available from ftp://libvirt.org/libvirt/glib/ The packages are GPG signed with Key ID: 15104FDF Daniel P. Berrange Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF libvirt-glib comprises three distinct libraries: - libvirt-glib - Integrate with the GLib event loop and error handling - libvirt-gconfig - Representation of libvirt XML documents as GObjects - libvirt-gobject - Mapping of libvirt APIs into the GObject type system As of this release only the event loop integration and some basic APIs for managing domains are provided. The representation of XML as GObjects is a major work

Introducing libosinfo

The first release of libosinfo is out! What is libosinfo? libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies Required: gobject-2.0 gio-2.0 libxml-2.0 Optional: gobject-introspection Vala (build-time only) Download http://fedorahosted.org/ releases/l/i/libosinfo/ Homepage http://fedorahosted.org/ libosinfo/

We want MiniObject

My last blog post managed to attract the attention of some of our beloved GNOME developers, especially the ones working on/with embedded systems. That made me realize that I am not (at least completely) on crack and decided to file a nice big bug for addition of something similar to GstMiniObject to core gobject library. Lets see what happens next. :)

Think before you create GObjects

I had always been hearing that GObjects are slow and it's not always a good idea to use/write them but I never saw any evidence to support that. I had this desire to write a test application to get this evidence but felt too lazy to do it in C. I realized a few days ago that I can write such an app very easily in Vala without giving up much on my laziness. :) So here is an app that I wrote last evening after returning from vacation. Here are the results on my laptop: $ ./test-perf 0.000182 seconds taken in creating 10000 structs. 0.001598 seconds taken in creating 10000 instances (compact). 0.003522 seconds taken in creating 10000 instances. 0.090455 seconds taken in creating 10000 instances (GObject). The ranking is exactly how I expected it to be but didn't expect such a big difference between them all.

Why Vala?

When I told some people that I will write (which involves re-writing existing code first) the gupnp-media-server in Vala, their question was "Why Vala? Why not Python, Java or C#?". So here are the strong points of Vala, not all of which are found in these languages: Statically-typed Back in the days, when I was hacking on Gazpacho I found the lack of types on variables and function/method parameters really annoying in Python. This can become quite a pain when you are reading other's code and that is exactly what I was doing most of the time. The fact that Johan and Kalle wrote very nice and readable code, helped a lot though. No runtime dependency/overhead This might seem like a small point to many developers but as an embedded-systems developer, this is a big plus for me and I am sure to many (if not most) of the embedded-systems developers out there. Easy integration with C/GObject A big plus for all the GObject/C developers out there. Besides, there are situations