Advogato: Blog for zeenix

10 Apr 2017 »

GNOME ❤ Rust Hackfest in Mexico

While I'm known as a Vala fanboy in GNOME, I've tried to stress time and again that I see Vala as more a practical solution than an ideal one. "Safe programming" has always been something that intrigued me, having dealt with numerous crashes and other hard-to-debug runtime issues in the past. So when I first heard of Rust some years back, it got me super excited but it was not exactly stable and there was no integration with GNOME libraries or D-Bus and hence it was not at all a viable option for developing desktop code. Lately (in past 2 years) things have significantly changed. Not only we have Rust 1.0 but we also have crates that provide integration with GNOME libraries and D-Bus. On top of that, some of us took steps to start converting some C code into Rust and many of us started seriously talking with Rust hackers to make Rust a first class programming language for GNOME.

To make things really go foward, we decided to arrange a hackfest, which took place last week at the Red Hat offices in Mexico city. The event was a big success in my opinion. The actual work done and started during the hackfest aside, it brought two communities much closer together and we learnt quite a lot from each other in a very short amount of time. The main topics at the hackfest were:

GObject-introspection consumption by Rust.
GObject creation from Rust.
Better out of the box Rust support in GNOME Builder
GMainLoop and Tokio integration
D-Bus bindings

While most folks were focused on the first three and I did participate in discussions on all these topics (except for Builder, of which I don't know anything), I spent most of my time looking into the last one. D-Bus is widely used in automotive industry these days and I serve that industry these days so it made sense, aside from my person interest in D-Bus. We established (some of it before the hackfest) that to make Rust attractive to C and Vala developers, we need to provide:

Syntactic sugar for making D-Bus coding simple

Very similar to what Vala offers. Antoni already had a project, dbus-macros that targets this goal through the use of Rust's (powerful) macro system. So I spent a lot of time fixing and improving dbus-macros crate. Having Antoni and other Rust experts in the same room, greatly helped me get around some very hard to decipher compiler issues. I found out (the hard way) that while rustc is very good at spotting errors, it fails miserably to give you the proper context when it comes to macros. I complained enough about this to Mozilla folks that I'm sure they'll be looking into fixing that experience at some point in near future. :)

We also contacted the author of dbus crate, David Henningsson over e-mail about a few D-Bus related subjects (more below) including this one. (I was surprised to find out that he also lives in Sweden). His opinion was that we probably should be using procedural macros for this. I agree with him, except that procedural macros are not yet in stable Rust. So for now, I decided to continue with current approach of the project.

During the hackfest, I became the maintainer of the dbus-macros crate since the first thing I did was to reduce the very small amount of code by 70%. Next, I created a backlog for myself and worked my way through it one issue at a time. I'm going to continue with that.

Asynchronous D-Bus methods

While ability to make D-Bus method calls asynchronously from clients is very important (you don't want to block the UI for your IPC), it would be also very nice for services to be able to asynchronously handle method calls as well. Brian Anderson from Mozilla was working on this during the hackfest. His approach was to hack dbus crate to add async API through the use of tokio crate. I spent most of the second day of hackfest, sitting next to Brian for some peer-programming. The author of tokio, Alex Crichton, sitting next to us helped us a lot in understanding tokio API. In the end, Brian submitted a working proof of concept for client-side async calls, which will hopefully provide a very good bases for David's actual implementation.

Code generation from D-Bus introspection XML

With both GLib and Qt providing utilities to generate code for handling D-Bus for a decade now, most projects doing D-Bus make use of this. My intention was too look into this during the hackfest but just before, I found out that David had not only already started this work in dbus crate but also his approach is exactly what I'd have gone for. So while I decided not to work on this, I did have lengthy (electronic) conversations with David about how to consolidate code generation with dbus-macros.

Ideally, the API of the generated code should be very similar to one you'd manually create using dbus-macros to make it easy for developers to switch from one approach to another. But since David and I didn't agree with current dbus-macros approach, I kind of gave-up on this goal, at least for now. Once macro procedures stabilize, there is a good chance we will change dbus-macros (though it'll be a completely new version or maybe even a different crate) to make use of them and we can revisit consolidation of code generation and dbus-macros.

A few weeks prior to the event, I decided to create a new project, gps-share. The aim is to provide ability to share your (standalone) GPS device from your laptop/desktop to other devices on the network and at the same time add standalone GPS device support into Geoclue (without any new feature code in Geoclue). I decided to write it in Rust for a few reasons, one of them being my desire to learn enough about the language before the event (I hadn't wrote any serious/complicated code in Rust before) and another one was to have an actual test case for D-Bus adventures (it's supposed to talk to Avahi on D-Bus). I'm glad that I did that since I encountered a few issues with dbus-macros when using them in gps-share and the awesome Mozilla folks were able to help me figure them out very quickly. Otherwise it would have taken me a very long time to figure the issues.

On the last day of hackfest, after a delicious lunch, we decided to go for a long stroll around Mexico city and hang out in the park, where we had more interesting conversations, about life, universe and everything (including Rust and GNOME).

After the hackfest, I stayed around for 3 more days. On Saturday, I mostly hung out with Federico, Christian, Antoni and Joaquín. We walked around the city center and watched Federico and Joaquín interviewed by Rancho Electronico folks. I was really excited to see that they use GNOME for their desktop and GStreamer for streaming. The guy handling the streaming was very glad to meet someone with GStreamer experience.

On Sunday, I rented a car and went to a hike at Tepoztlán with Felipe. Driving in Mexico wasn't easy so having a Mexican with me, helped a lot.

And on Monday, we drove to the Sun pyramid.

I would like to thank both GNOME Foundation and my employer, Pelagicore for sponsoring my participation to this event.

Syndicated 2017-04-06 11:31:00 (Updated 2017-04-06 15:28:44) from zeenix

7 Mar 2017 »

GDP meets GSoC

Are you a student? Passionate about Open Source? Want your code to run on next generation of automobiles? You're in luck! Genivi Development Platform will be participating in Google Summer of Code this summer and you are welcome to participate. We have collected a bunch of ideas for what would be a good 3 month project for a student but you're more than welcome to suggest your own project. The ideas page, also has instructions on how to get started with GDP.

We look forward to your participation!

Syndicated 2017-03-07 18:11:00 (Updated 2017-03-07 18:11:57) from zeenix

10 Aug 2016 »

Life is change

Quite a few major life events happened/happening this summer so I thought I blog about them and some of the experiences I had.

New job & new city/country

Yes, I found it hard to believe too that I'll ever be leaving Red Hat and the best manager I ever had (no offence to others but competing with Matthias is just impossible) but I'll be moving to Gothenburg to join Pelagicore folks as a Software Architect in just 2 weeks. I have always found Swedish language to be a very cute language so looking forward to my attempt of learning Swedish. If only I had learnt Swedish rather than Finnish when I was in Finland.

BTW, I'm selling all my furniture so if you're in London and need some furniture, get in touch!

Fresh helicopter pilot

So after two years of hard work and getting myself sinking in bank loans, I finally did it! Last week, I passed the skills test for Private Pilot License (Helicopters) and currently awaiting anxiously for my license to come through (it usually takes at least two weeks). Once I have that, I can rent Helicopters and take passengers with me. I'll be able to share the costs with passengers but I'm not allowed to make money out of it. The test was very tough and I came very close to failing at one particular point. The good news is that despite me being very tense and very windy conditions on test day, the biggest negative point from my examiner was that I was being over-cautious and hence very slow. So I think it wasn't so bad.

There are a few differences to a driving test. A minor one is is that in driving test, you are not expected to explain your steps but simply execute, where as in skills test for flying, you're expected to think everything out loud. But the most major difference is that in driving test, you are not expected to drive on your own until you pass the test, where as in flying test, you are required to have flown solo for at least 10 hours, which needs to include a solo cross country flight of at least a 100 nautical miles (185 KM) involving 3 major aeorodromes. Mine involved Estree, Cranfield and Duxford. I've been GPS logging while flying so I can show you log of my qualifying solo cross country flight (click here to see details and notes):

I still got a long way towards Commercial License but at least now I can share the price with friends so building hours towards commercial license, won't be so expensive (I hope). I've found a nice company in Gothenburg that trains in and rents helicopters so I'm very much looking forward to flying over the costs in there. Wanna join? Let me know. :)

Syndicated 2016-08-10 13:24:00 (Updated 2016-08-10 13:25:42) from zeenix

5 Feb 2016 »

FOSDEM & Dev-x Hackfest 2016

Last week I travelled to Brussels to attend and present at FOSDEM. Since I was going there anyway, I decided to also join 2.5 days of GNOME Developer Experience Hackfest.

Travelling to Brussels is usually pretty easy and fast, thanks to Eurostar but I turned it into a bit of nightmare this time. I had completely forgotten how London public transport is a total disasters in peak hours and hence ended-up arriving too late at the station. Not a big deal, they put me on the next train for free. I decided to go through security already and that's when I realized that I have forgotten my laptop at home. :( Fortunately my nephew (who is also my flatmate) was still at home and was going to travel to city centre anyway so I asked him to bring it with him. After two hours of anxiously waiting, he managed to arrive just in time for train staff to let in the very last late arriving passenger. Phew!

While I didn't have a particular agenda for the hackfest, I had a discussion with Alexander Larsson about sandboxing in xdg-app and how we will implement per-app authorization to location information from Geoclue. The main problem has always been that we have no means of reliably identifying apps and turns out that xdg-app already solved that problem. Each xdg-app has it's ID (i-e the name of it's desktop file w/o the .desktop suffix) in /proc/PID/cgroup file and app can not change that.

So I sat down and started working on this. I was able to finish off the Geoclue part of the solution already before the hackfest ended and now working on gnome-shell (currently the only geoclue app authorizing agent) part. Once done I'll then add settings in gnome-control-center so users can change their mind about whether or not they want an app to be able to access their location. Other than that, I helped test a few xdg-app bundles.

It's important to keep in mind that this solution will still involve trusting the system (non-xdg-app) application as there is no way to reliably identify those. i-e if you download a random script from internet and run it, we can not possibly guarantee that it won't access your location without your consent. Let's hope that xdg-app becomes very ubiquitous and becomes a de-facto standard for distributing your Linux apps in the near future.

FOSDEM was a fun weekend as usual. I didn't attend a lot of talks but met many interesting people and we had chat about various different open source technologies. I was glad to hear that a project I started off as a simple proof-of-concept for GUPnP, is now a days used in automobiles.

My own talk about Geospacial technologies in GNOME went fine except for the fact that I ran out of time towards the end and my Raspberry Pi demo didn't work because I forgot to plug-in the WiFi adaptor. :( Still, I was able to cover most of the topics and Maps demo worked pretty smoothly (there was weird libchamplain bug I hit but it wasn't very critical at all).

While I came back home pumped with a lot of motivation, unfortunately I managed to catch the infamous FOSDEM flu. I've been resting most of the week and today I started to feel better so I'm writing this late blog post as the first thing, before I completely forget what happened last week.

Oh and last but not the least, many thanks to GNOME foundation for sponsoring my train tickets.

Syndicated 2016-02-05 17:19:00 (Updated 2016-02-05 17:19:33) from zeenix

19 Oct 2015 »

Lessons on being a good maintainer

What makes for a good maintainer? Although I do not know of a definite answer to this important but vague and controversial question, maintaining various free software projects over the last many years, I've been learning some lessons on how to strive to be a good maintainer; some self-taught through experience, some from my colleagues (especially our awesome GNOME designers) and some from my GSoC students.

I wanted to share these lessons with everyone so I arranged a small BoF at GUADEC and thought it would be nice to share it on planet GNOME as well. Some points only apply to UIs here, some only to libraries (or D-Bus service or anything with a public API really) and some to any kind of project. Here goes:

Only accept use cases

There are no valid feature requests without a proper use case behind them. What's a proper use case you ask? In my opinion, it's based on what the user needs, rather than what they desire or think they need. "I want a button X that does Y" is not a use case, let alone a proper one. "I need to accomplish X" is potentially one.

Even when given a proper use case, does not necessarily mean that you should implement it. You still need to consider the following points before deciding to accept the feature request:

How many users do you think this impacts?
What's the impact of having this feature to user?
What's the impact on users that do not need that feature?
How does the expected number of users who need this feature compare to ones that do not.
How much work do you think this will be and do you think you (or anyone else in the team) will have the time and motivation to implement it?

Get a thicker skin

Everyone wants software to be tailored for them so unless you have only a few users of your software, you can not possibly satisfy all users. Sometimes users even demand contradictory features so if you are going to be a slave of user demands, you'll not last very long and your software will soon look like my bedroom: random stuff in random places and hard to find what you are looking for.

So don't be afraid of WONTFIX bug resolution. I do agree that this sounds harsh but I think the most important thing is to be honest with your users and not to give them false hopes.

A good API maintainer is a slave of apps

Your library or D-Bus service is as useful and important as the applications that use it. Never forget that while making decisions about public APIs.

Furthermore, if possible, try your best to be involved in at least one of the applications that use your API. Even better if you'd be maintaining one such application. There has been a few occasions where I had to had long debates with library developers about how their API could do much better and I felt that the debate could have been avoided if they had more insights about the applications that use their API. Also, they'd likely care more if they'd experience the pain of the problematic part of their API first hand.

History is important!

VCS (which translates to git for most of us these days) history, that is. I think this is something most developers would readily agree on and some readers must be thinking why do I need to even mention this. However, I've seen that while many would agree in principle to this, in practice they don't care too much. I've seen so many projects out there, where it's very hard or even impossible to find out why a particular line of code was changed in a particular way. Not only it makes maintenance hard, but also discourages new contributors since they'd not feel confident about changing an LOC if they can't be sure why it's how it is and not already what they think it should be like.

So kids, please try to follow some sane commit log rules. We have some here and Lasse has created an extensive version of that document with rationale for each point, for his project here.

Quality of code

This is a bit related to the previous point. To be very honest, if you don't care about quality enough, you really should not be even working on software that effects others, let alone maintaining them.

How successful you are at maintaining high quality is another thing, and sometimes even not in your hands entirely, but you should always strive for highest quality. The two most important sub-goals in that direction in my opinion, are:

Simplicity

[Insert cliché Einstein quote about simple solutions here.] Each time you come up with a solution (or receive one in the form of patches), ask yourself how it can be done with fewer lines of code. The fewer lines of code you have, the fewer lines of code you'd need to maintain.

Consistency

Come up with a (or adopt an existing) coding style with specific set of rules to follow and try your very best to follow them. Many contributors would simply dive directly into your project's source code and not read any coding style manual you provide and there is nothing wrong with that. If you are consistent in your code, they'll figure out at least most of your coding style while hacking on your sources. Also chances are that your coding style would even grow on them and that'll save you a lot of time during your reviews of their patches. That's unlikely to happen if you are not very consistent with your coding style.

Conclusion

None, what so ever. Do what you think is right. This blog post is nothing more than my personal opinions so take it or leave it, it's all up to you!

Syndicated 2015-10-19 11:00:00 (Updated 2015-10-19 11:00:04) from zeenix

14 Oct 2015 (updated 15 Oct 2015 at 19:29 UTC) »

Geoclue convenience library just got even simpler

After writing the blog post about the new Geoclue convenience library, I felt that while the helper API was really simple for single-shot usage, it still wasn't as simple as it should be for most applications, that would need to monitor location updates. They'll still need to make async calls (they could do it synchronously too but that is hardly ever a good idea) to create proxy for location objects on location updates.

So yesterday, I came up with even simpler API that should make interacting with Geoclue as simple as possible. I'll demonstrate through some gjs code that simply awaits for location updates forever and prints the location on console each time there is a location update:

const Geoclue = imports.gi.Geoclue;
const MainLoop = imports.mainloop;

let onLocationUpdated = function(simple) {
   let location = simple.get_location ();

    print("Location: " +
          location.latitude + "," +
          location.longitude);
};

let onSimpleReady = function(object, result) {
    let simple = Geoclue.Simple.new_finish (result);
    simple.connect("notify::location", onLocationUpdated);

    onLocationUpdated (simple);
};

Geoclue.Simple.new ("geoclue-where-am-i", /* Let's cheat */
                    Geoclue.AccuracyLevel.EXACT,
                    null,
                    onSimpleReady);

MainLoop.run('');

Yup, that easy! If I had chosen to use the synchronous API, it would be even simpler. I have already provided a patch for Maps to take advantage of this and I'm planning to provide patches for other apps too.

Syndicated 2015-10-14 17:30:00 (Updated 2015-10-15 16:45:46) from zeenix

9 Oct 2015 »

New in Geoclue: Location sharing & convenience library

Apart from many fixes, Geoclue recently gained some new features as well.

Sharing location from phones

If you read planet GNOME, you must have seen my GSoC student, Ankit already posting about this. Basically his work enabled Geoclue to search for, and make use of any NMEA providers on the local network. The second part of this project, involved implementation of such a service for Android devices. I'm pleased that he managed to get the project working in time and even went the extra mile to fix issues with his code, after GSoC.

This is useful since GPS-based location from android is almost always going to be more accurate than WiFi-based one (assuming neighbouring WiFi networks are covered by Mozilla Location Service). This is especially useful for desktop machines since they typically do not have even WiFi hardware on them and have until now been limited to GeoIP, which at best gives city-level accurate location.

This feature was included in release 2.3.0 and you can download the Android app from here.

Conveniece library

Almost since the beginning of Geoclue2 project, many people complained that using the new API is far from easy and simple, as it should be. While we have good reasons to keep D-Bus API as it is now, the fact that a lot of time passed since I got around to doing anything about this, meant that it was best if D-Bus API was not changed, Geoclue being a system service.

So this week, I took up the task of implementing a client-side library, that not only exposes gdbus-codegen generated API to communicate with the service but also added a convenience helper API to make things very simple. Basically, you just have to call a few functions now if you simply want to get a location fix quickly and don't care much about accuracy nor interested in subsequent location updates.

I only pushed the changes today to git master so if you have any input, now would be the best time to speak up. I wouldn't want to change API after release.

Syndicated 2015-10-09 19:45:00 (Updated 2015-10-09 19:45:19) from zeenix

10 Oct 2014 »

Life update

Like many others on planet.gnome, it seems I also don't feel like posting much on my blog any more since I post almost all major events of my life on social media (or SOME, as its for some reason now known as in Finland). To be honest, the thought usually doesn't even occur to me anymore. :( Well, anyway! Here is a brief of what's been up for the last many months:

Got divorced. Yeah, not nice at all but life goes on! At least I got to keep my lovely cat.
Its been almost an year (14 days less) that I moved to London. In a way it was good that I was in a new city at the time of divorce as its an opportunity to start a new life. I made some cool new friends, mostly the GNOME gang in here.

London has its quirks but over all I'm pretty happy to be living here. One big issue is that most of my friends are in Finland so I miss them very much. Hopefully, in time I'll also make a lot more friends in London and also my friends from Finland will visit me too.

The best thing about London is the weather! No, I'm not joking at all. Not only its a big improvement when compared to Helsinki, the rumours about "Its always raining in London" are greatly (I can't stress on this word enough) exaggerated.
I got my eyes Z-LASIK'ed so no more glasses!
Started taking:
- Driving lessons. Failed the first driving test today. Having known what I did wrong, I'm sure I wont repeat the same mistakes again next time and will pass.
- Helicopter flying lessons. Yes! I'm not joking. I grew up watching Airwolf and ever since then I've been fascinated by helicopters and wanted to fly them but never got around to doing it. Its very expensive, as you'd imagine so I'm only taking two lessons a month. With this pace, I should be have my PPL(H) by end of 2015.
  
  Turns out that I'm very good at one thing that most people find very challenging to master: Hovering. The rest isn't hard either in practice. Theory is the biggest challenge for me. Here is the video recording of the 15 mins trial lesson I started with.

Syndicated 2014-10-10 17:53:00 (Updated 2014-10-10 18:09:31) from zeenix

22 Jul 2014 »

GUADEC

So its that time of the year! GUADEC is always loads of fun and meeting all those the awesome GNOME contributors in person and listening to their exciting stories and ideas gives me a renewed sense of motivation.

I have two regular talks this year:

Boxes: All packed & ready to go?
Geo-aware OS: Are we there yet?

Apart from that I also intend to present a lightning talk titled "Examples to follow". This talk will present stories of few of our awesome GNOME contributors and what we all can learn from them.

Syndicated 2014-07-21 23:12:00 (Updated 2014-07-21 23:12:07) from zeenix

24 Jun 2014 »

oFono? Its dead jim!

Soon after I mentioned the need for an oFono-backend in Geoclue in my blog, Sri kindly helped me get in touch with oFono developers. What started as a nice friendly discussion soon was turned into a not so nice discussion. I won't get into details and blames but here is what I found out about the project:

oFono developers claim that its is still a maintained project while rest of the world think its a dead project, even people who love the project. Last release being in 2012 and loads of missing essential features (see rest of the points below) and link to mailing-list broken (even though I pointed it out 3 weeks ago and its been broken for much longer) on the homepage all points to the fact that its essentially a dead project.
No proper D-Bus introspection nor any client libraries. This already makes it extremely difficult to work with oFono but wait there is more hurdles on the way.

No online cross-references documentation: The documentation link on the home-page leads you to an architecture diagram and gives you no information about the API. Searching through google doesn't yield any results either. The developers pointed out that all documentation lives in the source tree in the form of plain-text documents and hence not very appropriate for the web.

It does not implement the standard D-Bus Properties interface. This combined with the fact that their D-Bus API is heavily based on properties makes it yet even harder to work with OFono, not to mention very weird.

None of the modern 3G modems supported, at least out of the box. I tried both Option and Qualcomm Gobi that I have and they both didn't work.

While rest of the issues can be overcome, the last makes it impossible for me to test any code written against oFono. So I'm giving up on this.

With a nice alternative that is well-maintained, and with which most modems work out of the box, has a nice OO, well-documented and introspectable D-Bus API and also provides a nice client library, I don't understand why phone vendors insist on supporting oFono interface. Could it be because the name makes it sound like its *the* solution for phones? Well, they do have the right to use whatever they like. I'm just curious.

Having said all that, I did make it easy for anyone to add oFono support to Geoclue as promised in my last blog post. Patches to add that are more than welcome!

Syndicated 2014-06-24 00:28:00 (Updated 2014-06-24 00:28:43) from zeenix

327 older entries...

Older blog entries for zeenix (starting at number 336)