Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Saturday, March 02, 2024

 

Safety shouldn't be opt-in

Many years ago, when I was starting to have my first experiences with Functional Programming (thanks to learning the amazing F# language), I discovered what seemed to be a problem that was not really a concern in the OOP world that I was leaving behind: stack overflows caused by stack recursion.

I was puzzled: from one point of view, mutability is dangerous and has to be avoided; however, if you avoid it in a certain way by using recursion, you might hit this other kind of problem. Sure, an exception at runtime is much better than the typical problems associated with mutability (race conditions or heisenbugs, which are very hard to debug and fix), however there was no way of making sure that you don't hit this problem in your recursion-based algorithms unless you made sure that... you use TailCall-friendly recursion.

Huh? What in the world does TailCall-friendly recursion means? When I first tried to wrap my head around this concept, it was hard, and to this day it is still is. But the real problem I saw is that there was no deterministic way to make sure that your recursive algorithm that you tried to make TailCall-friendly, is indeed TailCall-friendly. That's why I thought: wouldn't it be nice that the compiler warns me when I didn't succeed in making this algorithm TailCall-friendly? And that's why I filed an enhancement request in the proper channel for that which, at the time, used to be UserVoice.

Several weeks or months later, I discovered that my enhancement request was the most upvoted of all?! Maybe because the F# team had recently moved to UserVoice and I had been lucky to be one of the first people to file a ticket, which subsequently got a lot of views? I don't know, but I was happy. And the team agreed to implement it "in principle" (as far as I remember).

Some years passed, and I started getting better and better at F#, to the point that I started my own opensource project using it. But in the back of my mind I was still concerned about this downside that I had discovered when delving for the first time in Functional Programming. So I looked for the UserVoice ticket to see if it had been finally implemented: sadly, the F# team had moved out from UserVoice to a different way of tracking enhancement requests, and therefore, all the upvotes of it had vanished, and it was no longer "the most upvoted". Also, it hadn't been marked as fixed or actioned at all. There were some people talking about it and proposing ways of doing it, but nothing had really been set in stone.

Until last December! It turns out someone had finally worked on it and contributed it upstream. I was very happy and delighted that you can finally protect yourself at compile-time from this pitfall. However, when I saw how the feature can be used, I was a bit heart-broken. The initial feature request was titled along the lines of "Emit a compiler warning when a recursive algorithm is not tail-recursive", then probably Microsoft renamed it to "Enable a compiler-warning when...". Then I thought: ah, they are going to make it opt-in at the project level, probably. Boo! They didn't make it opt-in at the project level, not even at the module level! They made it opt-in at the function level! :-(

Oh well, it's a step in the right direction for sure. But don't we all think that SAFETY SHOULDN'T BE OPT-IN? Especially as F# developers, because many of us moved away from C# because F# has safer defaults, for example: if you want to use mutability, you can still do it, but then you need to use a keyword to opt-in: `mutable` (not like in C# in which safety is opt-in, e.g. the keyword `readonly`).

So then... I decided to do something about it.

If you're a lover of static typing, you rather prefer to get compiler errors than runtime errors. And if you like compiler errors, there's a chance that you also like warnings. And if you like warnings, there's a chance that you like to turn on "warnings as errors". And if you like warnings as errors, there's a chance that you also normally like to go the extra mile: you like linters and static analysis tools. And so, if you're already using a tool like this, wouldn't you expect them to give you extra protection? And wouldn't you want that the strongest protection layers that these tools provide are enabled by default, not opt-in? Enter EnsureTailCallDiagnosticsInRecursiveFunctions!!: a new FSharpLint rule that my team has implemented which will not shut up until you have marked all your recursive functions with the `[<TailCall>]` attribute, to make sure you are properly warned when you're not protected from potential stack overflows.

I merged the PR that implemented this rule this week, and made a release, 0.24.2, so that you can already adopt it in your project, and be protected by default (because the rule is enabled by default). And so if you're using FSharpLint, safety is not opt-in anymore, it is default. And you can opt-out from safety by disabling this rule (completely, or in a case-by-case basis) in case you need it.

Labels: , ,


# posted by knocte @ 12:35 pm 0 comments

Saturday, December 18, 2021

 

geewallet 0.4.300.0 released!

10th of my 21-day quarantine*! And to celebrate, I'm going to release a new version of geewallet. It's not that I blog about geewallet releases often (or blog at all, lately), but this one is a special one for me. We decided to call it 0.4.300.0


The highlights:

The less important (not user-facing) work:
  • Our CI now checks that our Android, macOS, and iOS frontends don't break. Previously the only frontends that we built in CI were the Gtk one (Linux) and the Console one (cross-platform, it's just terminal-based).
  • We do snap package generation in GitLab now instead of GitHub. This is good because Microsoft keeps changing the Linux VMs being used in the GitHubActions service so we cannot keep up fixing things that just break out of the blue (so, they break independently from what we change in our commits, which is very confusing!). (Long version: we had to use GitHubActions because GitLabCI uses docker under the hood; so given that snapcraft uses systemd, it conflicts with it; now we use a "docker in docker" approach to be able to run in GitLabCI; which also allows us to publish the snap package as an artifact in the GitLabCI pipeline, not just publishing it to the Snap Store; this way, in case you somehow need a previous version in the future you can grab it from there, something that you couldn't just via snap AFAIU).
Limitations:
  • Even though this wallet supports two ETH currencies (ETH itself, and DAI), we don't recommend their use at the moment because of the high fees and long confirmation waits these days. This is because the wallet waits for an ETH transaction to be mined (to make sure it didn't run out of gas, and if it did, report the problem to the user), but these days this wait is longer than the time-out. The short-term fix for this is either a) assume it will never ran out of gas, since our address is not a contract anyway (so I guess it can never run out of gas, right? feel free to prove me wrong, my ETH knowledge is not top-notch), or b) have some UI indicating that a transaction has been sent but not accepted by the network yet. The long-term fix is to have off-chain (Layer2) technology supported by the wallet, but we don't know which technology we will choose for this, and of course we're giving priority to the first Layer2 technology: Lightning (which is only compatible with BTC and LTC). All this aside, the wallet works well with ETC (an Ethereum-compatible technology). Anyway, this doesn't worry me too much because... what is the ETH blockchain used for these days, mainly? NFTs and DeFi pyramid schemes. In case you didn't get the memo, most of the former (if not all) are scams, and the latter are all of them mainly based on dubious centralized stablecoins (which could suffer fractional reserve and therefore cause bank runs, as Elizabeth Warren has already warned about).
  • Despite this wallet being implemented with .NET (F#), our Windows compatibility story is very poor :'-( We ran into limitations of the Microsoft's AOT technology being used for UWP apps (required by the official process required to publish it in the WindowsStore) in the past. Nowadays apparently you can publish apps in the WindowsStore without these limitations, but we haven't tried again. Maybe by the next time we give it another go, we might have moved to MAUI already (which means WinUI instead of UWP under the hood). As always, if this is your cup of tea, we accept MRs!
BTW on the topic of F#, I augmented my tiny C#-to-F# tutorial to include Python (so Python devs can try how it feels to switch to a more typed approach without the need to be so verbose, thanks to F# type inference!), as both languages have a very similar style (indentation based, no curly braces!). Check it out.

* And on the topic of quarantine (which was increased from 14 to 21 days for me just because of the omicron panic) I just wanted to share some rambling that is in my head: if the omicron strain is more infectious but at the same time is less dangerous (I think it was only yesterday that the first death happened because of it, right? at least the first one covered by the media) than the others, then wouldn't this be a good outcome? Or rather, a least worse one. I mean, if this variant gets more prevalent around the pandemic, this coronavirus might actually become just the next flu, right? So: endemic, but with much less mortality rate. I don't know, hopefully something along these lines happens, just sharing some positive perspective! Be safe.

NB: if you're looking for this version in Android, please be aware that the validation from Google takes a bit of time, hopefully the update will be available in the Play store in less than 24h.

Labels: , , , , ,


# posted by knocte @ 5:50 pm 0 comments

Saturday, February 08, 2020

 

Xamarin forks and whatnots

Busy days in geewallet world! I just released version 0.4.2.198 which brings some interesting fixes, but I wanted to talk about the internal work that had to be done for each of them, in case you're interested.
PS: Apologies if the previous blogpost or this one shows up in planets again, as it might be a side-effect of updating its links to point to the new git repo!

Labels: , , , , , , ,


# posted by knocte @ 8:37 am 0 comments

Sunday, January 05, 2020

 

Introducing geewallet

Version 0.4.2.187 of geewallet has just been published to the snap store! You can install it by looking for its name in the store or by installing it from the command line with `snap install geewallet`. It features a very simplistic and minimalistic UI/UX. Nothing very fancy, especially because it has a single codebase that targets many (potential) platforms, e.g. you can also find it in the Android App Store.

What was my motivation to create geewallet in the first place, around 2 years ago? Well, I was very excited about the “global computing platform” that Ethereum was promising. At the time, I thought it would be like the best replacement of Namecoin: decentralised naming system, but not just focusing on this aspect, but just bringing Turing-completeness so that you can build whatever you want on top of it, not just a key-value store. So then, I got ahold of some ethers to play with the platform. But by then, I didn’t find any wallet that I liked, especially when considering security. Most people were copy+pasting their private keys into a website (!) called MyEtherWallet. Not only this idea was terrifying (since you had to trust not just the security skills of the sysadmin who was in charge of the domain&server, but also that the developers of the software don’t turn rogue…), it was even worse than that, it was worse than using a normal hot wallet. And what I wanted was actually a cold wallet, a wallet that could run in an offline device, to make sure hacking it would be impossible (not faraday-cage-impossible, but reasonably impossible).

So there I did it, I created my own wallet.

After some weeks, I added bitcoin support on it thanks to the library NBitcoin (good work Nicholas!). After some months, I added a cross-platform UI besides the first archaic command-line frontend. These days it looks like this:



What was my motivation to make geewallet a brain wallet? Well, at the time (and maybe nowadays too, before I unveil this project at least), the only decent brain wallet out there that seemed sufficiently secure (against brute force attacks) was WarpWallet, from the Keybase company. If you don’t believe in their approach, they even have placed a bounty in a decently small passphrase (so if you ever think that this kind of wallet would be hacked, you would be certainly safe to think that any cracker would target this bounty first, before thinking of you). The worst of it, again, was that to be able to use it you had again to use a web interface, so you had the double-trust problem again. Now geewallet brings the same WarpWallet seed generation algorithm (backed by unit tests of course) but on a desktop/mobile approach, so that you can own the hardware where the seed is generated. No need to write anymore long seeds of random words in pieces of paper: your mind is the limit! (And of course geewallet will warn the user in case the passphrase is too short and simple: it even detects if all the words belong to the dictionary, to deter low entropy, from the human perspective.)

Why did I add support for Litecoin and Ethereum Classic to the wallet? First, let me tell you that bitcoin and ethereum, as technological innovations and network effects, are very difficult to beat. And in fact, I’m not a fan of the proliferation of dubious portrayed awesome new coins/tokens that claim to be as efficient and scalable as these first two. They would need not only to beat the network effect when it comes to users, but also developers (all the best cryptographers are working in Bitcoin and Ethereum technologies). However, Litecoin and Ethereum-Classic are so similar to Bitcoin and Ethereum, respectively, that adding support for them was less than a day’s work. And they are not completely irrelevant: Litecoin may bring zero-knowledge proofs in an upcoming update soon (plus, its fees are lower today, so it’s an alternative cheaper testnet with real value); and Ethereum-Classic has some inherent characteristics that may make it more decentralised than Ethereum in the long run (governance not following any cult of personality, plus it will remain as a Turing-complete platform on top of Proof Of Work, instead of switching to Proof of Stake; to understand why this is important, I recommend you to watch this video).

Another good reason of why I started something like this from scratch is because I wanted to use F# in a real open source project. I had been playing with it for a personal (private) project 2 years before starting this one, so I wanted to show the world that you can build a decent desktop app with simple and not too opinionated/academic functional programming. It reuses all the power of the .NET platform: you get debuggers, you can target mobile devices, you get immutability by default; all three in one, in this decade, at last. (BTW, everything is written in F#, even the build scripts.)

What’s the roadmap of geewallet? The most important topics I want to cover shortly are three:
With less priority:

Areas where I would love contributions from the community:

And just in case I wasn't clear:

I'm excited about the world of private-key management. I think we can do much better than what we have today: most people think of hardware wallets to be unhackable or cold storage, but most of them are used via USB or Bluetooth! Which means they are not actually cold storage, so software wallets with offline-support (also called air-gapped) are more secure! I think that eventually these tools will even merge with other ubiquitous tools with which we’re more familiar today: password managers!

You can follow the project on twitter (yes I promise I will start using this platform to publish updates).

PS: If you're still not convinced about these technologies or if you didn't understand that PoW video I posted earlier, I recommend you to go back to basics by watching this other video produced by a mathematician educator which explains it really well.

PS II: Apologies if this blogpost shows up in planets again, as it might be a side-effect of updating it to fix broken links or typos.

Labels: , , , , , , , , ,


# posted by knocte @ 5:31 pm 0 comments

Wednesday, January 23, 2019

 

WORA-WNLF


I started my career writing web applications. I had struggles with PHP web-frameworks, javascript libraries, and rendering differences (CSS and non-CSS glitches) across browsers. After leaving that world, I started focusing more on the backend side of things, fleeing from the frontend camp (mainly actually just scared of that abomination that was javascript; because, in my spare time, I still did things with frontends: I hacked on a GTK media player called Banshee and a GTK chat app called Smuxi).

So there you had me: a backend dev by day, desktop dev by night. But in the GTK world I had similar struggles as the ones I had as a frontend dev when the browsers wouldn’t behave in the same way. I’m talking about GTK bugs in other non-Linux OSs, i.e. Mac and Windows.

See, I wanted to bring a desktop app to the masses, but these problems (and others of different kinds) prevented me to do it. And while all this was happening, another major shift was happening as well: desktop environments were fading while mobile (and not so mobile: tablets!) platforms were rising in usage. This meant yet more platforms that I wished GTK supported. As I’m not a C language expert (nor I wanted to be), I kept googling for the terms “gtk” and “android” or “gtk” and “iOS”, to see if some hacker put something together that I could use. But that day never happened.

Plus, I started noticing a trend: big companies with important mobile apps started to stop using HTML5 within their apps in favour of native apps, mainly chasing the “native look & feel”. This meant, clearly, that even if someone cooked a hack that made gtk+ run in Android, it would still feel foreign, and nobody would dare to use it.

So I started to become a fan of abstraction layers that were a common denominator of different native toolkits and kept their native look&feel. For example, XWT, the widget toolkit that Mono uses in MonoDevelop to target all 3 toolkits depending on the platform: Cocoa (on macOS), Gtk (on Linux) and WPF (on Windows). Pretty cool hack if you ask me. But using this would contradict my desires of using a toolkit that would already support Android!

And there it was Xamarin.Forms, an abstraction layer between iOS, Android and WindowsPhone, but that didn’t support desktops. Plus, at the time, Xamarin was proprietary (and I didn’t want to get out of my open source world). It was a big dilemma.

But then, some years passed, and many events happened around Xamarin.Forms:

So that was the last straw that made me switch completely all my desktop efforts toward Xamarin.Forms. Not only I can still target Linux+GTK (my favorite platform), I can also make my apps run in mobile platforms, and desktop OSs that most people use. So both my niche and mainstream covered! But this is not the end: Xamarin.Forms has been recently ported to Tizen too! (A Linux-based OS used by Samsung in SmartTVs and watches.)

Now let me ask you something. Do you know of any graphical toolkit that allows you to target 6 different platforms with the same codebase? I repeat: Linux(GTK), Windows(UWP/WPF), macOS, iOS, Android, Tizen. The old Java saying is finally here! (but for the frontend side): “write once, run anywhere” (WORA) to which I add “with native look’n’feel” (WORA-WNLF)

If you want to know who is the hero that made the GTK driver of Xamarin.Forms, follow @jsuarezruiz which BTW has been recently hired by Microsoft to work on their non-Windows IDE ;-)

PS: If you like .NET and GTK, my employer is also hiring! (remote positions might be available too) ping me 

Labels: , , , , , , ,


# posted by knocte @ 8:55 am 6 comments

Tuesday, March 17, 2015

 

How do you upgrade your distro? A tale of two workarounds

Every classic Linuxer would know why it's very handy to dedicate a separate partition for the /home folder of your tree: you could in theory share it between multiple OSs that you installed in your box (which you choose to run when you start your computer).

Now, I'm guessing that many people reading and nodding to the above, will also know that sharing /home/ is one thing, sharing $HOME (/home/yourUserName) is a completely different beast.

For example: you have a stable distro installed in your box; you decide to install a new version of that distro along the old one, in the same box. You run the new distro with a new account tied to the old /home/yourUserName folder: KABOOM!!! Weird things start happening. Among these:

To workaround these problems, I have a strategy: I use a different /home/ sub-directory for each distro installed in my system. For example, for distro X version A.B I use /home/knocteXAB/, for distro Y version C.D I use /home/knocteYCD/. The advantage about this is that you can migrate your settings manually and at your own pace. But then, you may be asking, how to really take advantage of sharing the /home folder when using this technique?

Easy: I keep non-settings data (mainly the non-dotfiles) in a different /home/ folder with no associated account in any of the distros. For example: /home/knocte/ (no version suffix). Then, from each of the suffixed /home/ subfolders, I setup symlinks to this other folder, setting the appropriate permissions. For instance:

You may think that it's an interesting strategy and that I'm done with the blog post, however, when using this strategy you may start finding buggy applications that don't deal very well with symlinked paths. The one I found which annoyed the most was my favourite Gnome IDE, because it meant I couldn't develop software without problems. I mean, they were not just cosmetic problems, really:

So I had to use a workaround for my workaround: clone all my projects in $HOME instead of /home/knocte/Documents/Code/OpenSource/ (yah, I'm this organized ;) ).

I've been trying to fix these problems for a while, without much time on my hands.

But the last weeks a magical thing happened: I decided to finally sit down and try to fix the last two remaining, and my patches were all accepted and merged last week! (at least all the ones fixing symlink-related problems), woo!!!

So the lessons to learn here are:

Labels: , , , , ,


# posted by knocte @ 2:56 am 1 comments

Tuesday, May 20, 2014

 

Banshee GSoC-2014 projects under Gnome umbrella

Here we are, at the beginning of a great summer!

This time, Google has given plenty of slots to the GNOME project, so we could accept many participants, including 3 brilliant students to work on the Banshee project. In case they haven't blogged about it, or didn't give much detail, I'll elaborate a bit about what they will be aiming to do these months:

  1. USB can work for the first sync, but whenever you update your library, I never remember to connect my phone again with my cable, or I'm too lazy to do it. Now imagine that whenever your phone is near your computer (and of course if you have Banshee running), they could negotiate together to update the sync without the need of moving a finger!
  2. Wifi could work also for the use case I just explained, but getting Wifi to work, compared to Bluetooth, would involve creating an app for the phone that could talk with Banshee. And we all know what are the problems associated with that: we would need to be cross-platform for at least the 3 main mobile platforms out there (well, iOS wouldn't even work neither with this nor with Bluetooth, because there are no public APIs to integrate with the music database of the OS, sigh iTunes...), and that means a lot of maintenance burden (even if we choose a same-language native platform like Xamarin), and a user experience that is not so seamless (as it would require the user to install an app first).
As you can see, most things are work under-the-hood this year, with little UI work. That's good for me because I'm no design expert. However, there is one area which we could do with some help: the new backgound tasks that will be implemented will need a way to notify the user (i.e. SongKick: when a new gig is discovered; AcoustID: when new/better metadata is found). In this respect, maybe Hylke Bons (our chief designer for the last Gnome .NET hackfest) and Garrett LeSage (assistance that Hylke proposed now to avoid getting himself swamped!) will be able to help! (BTW, if you're interested in participating in this year's Gnome .NET hackfest, message David Nielsen, which started to plan it recently.)

I'm very happy about starting the mentoring of these projects this year. And I'm specially jealous about my students... I became mentor of GSoC myself without being GSoC student first! (Maybe I should switch roles in the future?)

Wish them good luck! It was actually just yesterday when GSoC really started! (gotta love mondays)

UPDATE: Fixed embarrassing typo: I meant AcoustID, not OpenID!

Labels: , , , ,


# posted by knocte @ 11:58 pm 1 comments

Monday, May 05, 2014

 

GSoC 2013 with Gnome

So let this be a belated report about previous GSoC! sorry for the delay.

In summer 2013, Tomasz Maczynski worked on Banshee as a GSoC student, and he did great work! He developed a SongKick extension, and a FanArt.tv one. Both were worked on in the banshee-community-extensions repository. They work very well but there are a few downsides about this work, which we didn't have time to fix:

That is all folks! Stay tuned for the next blog post, which will explain the plan for GSoC 2014 (this year I get to mentor three students!).

Labels: , , , ,


# posted by knocte @ 12:41 pm 0 comments

Sunday, May 04, 2014

 

Belated Gnome .NET Hackfest post

OMG, I should feel embarrassed about posting such a belated blog post (yes, the hackfest was more than 6 months ago), but oh well, at least I can say I have enough excuses:
So this doesn't leave enough room for blogging, which is a necessary but a less appealing task. But I have to say it somewhere: the hackfest that David Nielsen organized was amazing, the best kind I have attended so far, as I came to meet for the first time some awesome hackers such as him, and:

(BTW I didn't include the awesome Bertrand Lorentz, fellow Banshee co-maintainer and GtkSharp gatekeeper, in the list, because I had already met him before, it wasn't my first time!).

And it was with the latter Stephan (not Stefan) the one I ended up spending more time with, because we decided to work on the new GStreamerSharp bindings since the 2nd day of the hackfest (the 1st day I mainly worked with Bertrand to release Banshee 2.9.0, our first Gtk3 compatible release, which he already blogged about).

So what was special about this work?
"Polish" sounds like easy work, but it wasn't. We fixed lots of crashes, and we contributed fixes to GObject-Introspection metadata upstream. And we proposed big patches for the gtk-sharp GAPI generator. And of course we updated our Banshee managed playback backend to the new GStreamerSharp API.

Main kudos should go to him though. I mainly added Banshee expertise, gtk-sharp contributing expertise, and lots of motivation (or at least I thought).

We had a big success: a Banshee playing audio with GStreamerSharp. Unfortunately video playback was freezing. But some months later after the hackfest we fixed it, and we released first GStreamerSharp 1.0 preview, which we called "0.99.0", and we released the first Banshee release that depends on this work: 2.9.1.

And it was my first time in Austria (and in Vienna). Overall a great experience, and I need to mention our awesome sponsors:


The GNOME Foundation, providers of the GNOME desktop


The University of Vienna and the Institute for Theoretical Chemistry, our venue sponsors

Collabora Ltd, Open Source Consulting

Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting


Novacoast IT, Professional Services and Product Development

 
Hotel Schottenpoint, our hotel partner

Labels: , , , ,


# posted by knocte @ 12:18 am 0 comments

Monday, October 28, 2013

 

Launchpad pull request

So you want to do a pull-request to a LaunchPad project?
Stop right there! The content of this blog post has been migrated to this question in stackoverflow. Move on, nothing to see here.

Labels: , , ,


# posted by knocte @ 6:10 pm 0 comments

Friday, June 14, 2013

 

Modernizing blam's autotools (or shaving the yak to move out from GoogleReader...)

Before focusing my spare time completely on the GSoC* (as I have mentoring responsibilities this year \o/ ), I wanted to solve a problem that cannot wait after July...

Yes, I've been victim of Google's cuts too... And I was wondering, where should I move? Feedly? ThingyBob? Well, I shouldn't make the same mistake twice, right?

Actually, some time ago I was using a desktop app to avoid relying on software that I cannot control (yes, vendor lock-in, the most important thing that open source tries to solve, right?): Thunderbird. But somehow the convenience of a web app (that I can access from any computer) and the hassle of using my mail client for RSS reading made me move to the web.

I should be able to find a replacement that no company or individual can "take down", and which feels less clunky than Thunderbird for reading RSS. So, enter blam (in the future I'll figure out how to sync its state between computers, maybe using SparkleShare?, to achieve that same convenience that a web-app provides), that Gnome app that has strangely managed to not catch my eye until now...

Well, maybe because if I install it from debian sid and I try to import my very first RSS feed from my GoogleReader list it doesn't work? Well, apparently it is a bug that is already fixed upstream, thanks to Carlos which has modernized the way that the program deals with XML and serialization.

Then I went ahead and tried to compile master myself... and guess what, the autogen.sh execution fails. Here the yak shaving begins, when I feel like this when trying to fix the autotools stuff:


Fortunately, after some tinkering (and some copy&paste from banshee's build scripts), I managed to fix the problem, and also modernized a bit some things (like using the brand new ".ac" extension instead of ".in" for the configure script, or using properly the AC_INIT and AM_AUTOMAKE_INIT macros,...).

Anyway, the real thing to highlight here is that while I was fixing this stuff and pushing to the repository...


... I saw some really good stuff committed by Carlos: using the new .NET 4.5 C# async patterns to get rid of those ugly callbacks! Kudos to him.

And if you're willing to help more with our autotools housekeeping, please do, I still feel this autogen.sh is way too long and needs some ironing.

* And if you're wondering what's up with GSoC (aka Google Summer of Code):



Labels: , , , ,


# posted by knocte @ 11:29 am 1 comments

Tuesday, May 01, 2012

 

Apple and LastFM can still receive open source love

Here we are in an era in which ad-based services (like LastFM) and closed-products (like Apple ones) are on the rise.

But contradicting what you may think, open source is still friendly to them.

If you have an Apple device supported by libgpod* and you're an avid user of LastFM's scrobbling feature, you can today configure Banshee to send all the songs that were played on your device to your LastFM account the next time you connect your device while you have Banshee running.

Pretty handy, especially if you own a device that doesn't have internet connection these days (something definitely not on the rise). You should thank our new Banshee developer Phil Trimble for doing an awesome job on implementing this feature (and on resisting to not sending me to hell when I made the patch reviews...).

The next version of Banshee, in the 2.5.x series, should include this feature. Until then, hold on to your seats! (or compile it yourself from master ;) )

* Beware: not the last generation ones! you would have to donate to libgpod project if you want those recognised.

PS: If you're a developer and want to extend this feature to other kind of devices, you should just implement the interface IBatchScrobblerSource in the corresponding Source class of your device. If you want to make it scrobble to a different service than LastFM, just create a Banshee addin (simple sample here) that subscribes to the ServiceManager.SourceManager.SourceAdded event to then later subscribe to the IBatchScrobbleSource.ReadyToScrobble event from it, to later make the corresponding HttpWebRequests to the scrobbling service.

Labels: , , , , ,


# posted by knocte @ 9:39 pm 0 comments

Sunday, May 08, 2011

 

#gtk#

The title of this post is the name of the GimpNet IRC channel that some people are recently using to talk about the .NET bindings of gtk+.

I had never seen this channel with people in it at all in the past. I guess the recent interest comes from the fact that gtk-sharp master is already targeting Gtk+ 3.x API and some people are starting to use it to port things.

One example is Hyena, the awesome library that Gnome projects F-Spot, Banshee and PdfMod use (am I missing some other?). I started the port some weeks ago and all I have received is positive feedback, encouragement, and also a lot of help! For example Olivier Dufour (which I guess he will be recently known as one of the superstars that brought DVD support to Banshee -- work finished but still unmerged) who helped with accessibility and warnings, and Mike Kestner (father/maintainer of all these GAPI-based *-sharp bindings) which helped reviewing my patches to the binding and fixing other issues I reported (and of course for making huge efforts, in the first place, to have the bindings ready for the 3.x cycle, with even some GObject-Introspection experimentation, which I guess is still in the early stages and not enabled yet).

Stay tuned for the progress! (as new contributors have expressed interest in helping out soon). Branches are being created so you can join the effort if you feel like (bugs in bugzilla too, to track what's pending).

Labels: , , , , ,


# posted by knocte @ 5:09 pm 2 comments

Monday, April 11, 2011

 

Calling hackers who care about Android+Banshee

If you care about the neat feature about synchronizing metadata to your device using Banshee, and you have an Android device, you may be interested to hear that I created a patch for it, and it was recently reviewed requesting some changes here.

Unfortunately my Android phone broke completely (don't ask me the details...) so I cannot work on the patch anymore. Anyone wants to continue the work?

If yes, go ahead and ask me anything you want, I'm usually in irc://irc.gnome.org/banshee with the "knocte" nickname, or you could also ask the question on the channel if I'm not there, there are usually awesome contributors there that will try to help. If you haven't ever coded for banshee, check the Contributing page first.

BTW, kudos to all the people involved in the Banshee v.2.0 release!

Labels: , , , ,


# posted by knocte @ 6:50 pm 0 comments

Sunday, April 10, 2011

 

WTF reduction

My first patch to FluentNHibernate was just merged upstream!

What it basically does is a bit of what I call WTF reduction: you will no longer get a confusing message like "For property 'Foo' expected 'Bar' of type 'Bar' but got 'Bar' of type 'Bar'" when unit testing your entities' properties.

AFAIK the next release will include this, and will be the first one to link to the new version of NHibernate, 3.0, which I've found that works very well.

Labels: , , , ,


# posted by knocte @ 11:10 pm 0 comments

Sunday, March 27, 2011

 

RT: MEF vs MonoAddins

Just re-posting in my blog an interesting email that was sent to the MonoAddins list, comparing these two Addin frameworks:

> Can you give a short summary on why you replaced MEF with Mono.Addins?

Basically it came down to maturity. Mono.Addins seems far more stable and mature than MEF. The MEF documentation was lacking, inconsistent and out of date in a lot of places. But all that could be worked around, and for the first few internal versions of our app, MEF was servicing us just fine.

Then our addins became a bit more complex. We needed to package them up with multiple files, ideally distribute them as an archive, host them online in a plugin exchange, allow them to be discovered and installed easily. Essentially this page covers features in Mono.Addins that made us switch rather than implementing a lot of the same things using MEF ourselves:

http://monoaddins.codeplex.com/wikipage?title=Creating%20and%20Managing%20Add-in%20Packages&referringTitle=Programming%20Guide

At the time as well MEF had issues on Mono on linux. This might have been a problem with how we were using it, but it just turned out easier to plonk Mono.Addins in instead. Was an easy migration and has a lot more power and features straight out of the box (and it worked on Linux).

Your millage may vary, and your needs are probably different. MEF might be an awesome tool for your requirements. It is a little simpler to get up and running and requires less engineering to support it (which was one of the reasons we used it first off).

Hope that helps,

Michael

Labels: , , , ,


# posted by knocte @ 4:49 pm 1 comments

Wednesday, September 08, 2010

 

Version Tolerant Serialization with Mono


(Zoot Woman - Lonely By Your Syde)

During the last months I've kept working {with|on} Mono, but not working for Novell anymore.

Today I'm proud to blog about a bit of work I've done on Mono towards a better Binary Serialization experience:


On a totally unrelated note: kudos to the MonoDevelop team for making such a great releases lately (and fixing the bugs I report so promptly). I've been testing it the last months on Windows and I can say it's a great experience to see your favorite IDE working cross-platform and making you not depend on VS anymore if you need to work on Windows from time to time (I know the Express versions are free, and are great! but they do not support plugins :( ). BTW, I've been lately experimenting with the C language support in this IDE, and have had some problems, but the real culprit seems to lay behind some wierd behaviour of my gdb in opensuse. Taking advantage that I'm in opensuse planet, can I do a couple of lazyweb requests?:

a) If you're quite familiar with gdb, can you take a look at these 2 bugs in case it rings any bell for you? BNC#588175, BNC#459274

b) Can you try to reproduce those bugs in openSUSE 11.3? (I haven't migrated yet from 11.2 because I fear about the HALlessness of it :) )

PS: Wondered why the video on the top? Well, I like the trend that some people have about posting random photos in their blog posts even when they may be completely unrelated, but in my case I love music so I figured this would suit better. Of course I would rather embed a WebM video or, even better, something that can preview a song (without video) in a "normally-lower-quality-than-what-you-can-buy" way, so if you have any hints, those are welcome! I especially mention the latter in this case because the Album version of the song above is much much better (synth pop FTW!).

UPDATE 28-AUG-2012: Found a video-less alternative to youtube for embedding songs! It is GoEar.

Labels: , , , , ,


# posted by knocte @ 6:26 pm 0 comments

Tuesday, July 06, 2010

 

Mono? What?

Really sad to read this:

.NET Culture Shock: Why .NET Adoption Lags Among Startups

Especially sad to find that Mono is not mentioned in the article.

Especially super sad to find that Mono is mentioned in the comments, but in a negative way.

Hey Mono community, help me reply all this nonsense.

Labels: , , , , , ,


# posted by knocte @ 4:10 pm 3 comments

Monday, June 01, 2009

 

It's all about synchronization

It's been a while since I first blogged about iFolder. At that time it was a bit unstable and I didn't have a good experience overall with it. Unfortunately the development of new features stopped, but there were a lot of fixes to improve its stability, which made into the version 3.7. Unfortunately again, this version was not released on the open, but now Novell has rectified and iFolder is gaining momentum again (especially because it's the only really open source alternative to DropBox or UbuntuOne!).

Who could have imagined at that time, that 3 years later I would not only be working for Novell, but also be able to contribute to it at normal work hours! Yes, this is ITO, and our team spent a week hacking on other projects. In my case, I worked with the awesome guys Stephen Shaw and Mario Carrión. We managed to create an iFolder appliance for the server based on openSUSE 11.1, very easy to install thanks to SUSE Studio and to a new OBS repository where we packaged a preview of Mono 2.4.2 and some fixes needed to make it work.

We even created some demos! (Sorry for the quality of the sound, we had some problems when recording them)

The first one: setting up the appliance.
The second one: creating a user and using the Linux iFolder client.

Now, the next two videos are intended to show the second part of our work on that innovation week: new features.

The third one: automatic/immediate local detection of changes, server side trash can.
The fourth one: automatic/immediate remote synchronization of changes.

How cool is that? Unfortunately, the patches still need work and cleanup (help welcome!), but I plan to do it soon and/or on next hack week.

Before coming back to hacking on iFolder, I wanted to finish some stuff am working on for Banshee, which is also about synchronization! Look at this bug for more details. Yes! bidirectional Rating synchronization, not only from Banshee to the iPod but from the iPod to Banshee. The patch is working fine for me, be sure to give it a go and provide some feedback. Thanks!

Another thing I have on my TODO list is integrate some old mono-based GPL ed2k library into monsoon, now that it's getting MonoAddins support! (Lately there's been many people asking me for the source code.) And now that I talk about monotorrent, how cool would be to make iFolder work with this awesome library??

PS: Hello PlanetSUSE! First post. Hola Planeta GnomeHispano ;)

UPDATE Jun-08-2009: It seems someone wants to resurrect the lphant kernel as well, but using WPF! (WTF?): http://sourceforge.net/projects/hathi/.

Labels: , , , ,


# posted by knocte @ 12:47 am 6 comments

Monday, March 30, 2009

 

I14Y happens

Some years ago, I started to get familiarized with abbreviations like 'l10n', 'i18n' when I started contributing to the translation efforts of Mozilla & Firefox under the NAVE Project.

Some months later I came to know the new term 'a11y', and I started to see it in a lot of places. By that time, I only associated it with the web development world. Terms like "Unobstrusive JavaScript" were very related to it (and I even created an "AJAXy" library called AMUSE for this purpose).

Now let's talk about the next one: I14Y. This concept is present when things like this happen: "I can open an (Microsoft's)OpenXML file with some (Novell's) edition of (Sun's)OpenOffice". Or even more weird things: "I can manage my (Apple's)IPod thanks to a (Microsoft's).NET-powered application called (Novell's)Banshee". Or even more awesome ones: "I can use (Sun?'s)Orca screen reader to control my (Microsoft's)Windows.Forms-powered applications in my (Novell's)SUSE Linux Box!".

So, yeah, we made it! Along with the awesome releases of Mono 2.4 and MonoDevelop 2.0.

Now, guess what's the word?

Labels: , , , , , , ,


# posted by knocte @ 11:59 pm 1 comments

This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive

About Me

My Photo
Name:
Location: Hong Kong, Hong Kong

Follow me on Twitter