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: General, Ingenieria, Programacion
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:
- We fixed the GTK theme for our snap package. (Long version of the story: ever since we upgraded our snap generation process to take place in Ubuntu 20.04 instead of Ubuntu 18.04, the theme stopped working so the app was not showing anymore with the default theme of the system, but with the default Gtk theme, which is very plain. Even if you might consider this issue important, we haven't had time to look at it because we've been very busy finishing Lightning support. Sorry.)
- The chart rendering doesn't use SkiaSharp anymore, but good-old Cairo. This fixes some UI glitches that we had in the GTK frontend. (Long version: for this, we didn't just draw the chart using Cairo in our Gtk frontend, we actually wrote an implementation of the Shapes API for the Xamarin.Forms' GTK backend, and we contributed the work upstream: https://github.com/xamarin/Xamarin.Forms/pull/14235 . Hopefully they merge it soon so that we don't need to use our own forked repo/nuget anymore.)
- Fixed a crash when pairing with a cold-storage wallet. (Long version: user might not know that pairing is only allowed against another geewallet instance; low-hanging fruit bugfix which I shouldn't have neglected for so long, I know.)
- Fixed a crash when scanning some QR-codes that contained unknown parameters in the bitcoin URI. (Long version: I was actually in El Salvador and when trying to use a BTM, I found this bug! Apparently some BTMs here add an extraneous "chivo" param in the URI's querystring, in case the wallet being used is the one from the government; not sure why. In this case, geewallet was failing fast instead of ignoring the unexpected intruder.)
- 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).
- 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!
Labels: General, Gnome, Mono, Programacion, SoftwareLibre, Xamarin
Saturday, February 08, 2020
Xamarin forks and whatnots
- In Linux(GTK), cold storage mode when pairing was broken, because the absence of internet connection was not being detected properly. The bug was in a 3rd-party nuget library we were using: Xam.Plugin.Connectivity. But we couldn't migrate to Xamarin.Essentials for this feature because Xamarin.Essentials lacks support for some platforms that we already supported (not officially, but we know geewallet worked on them even if we haven't released binaries/packages for all of them yet). The solution? We forked Xamarin.Essentials to include support for these platforms (macOS and Linux), fixed the bug in our fork, and published our fork in nuget under the name `DotNetEssentials`. Whenever Xamarin.Essentials starts supporting these platforms, we will stop using our fork.
- The clipboard functionality in geewallet depended on another 3rd-party nuget library: Xamarin.Plugins.Clipboard. The GTK bits of this were actually contributed by me to their github repository as a Pull Request some time ago, so we just packaged the same code to include it in our new DotNetEssentials fork. One dependency less to care about!
- Xamarin.Forms had a strange bug that caused some buttons sometimes to not be re-enabled. This bug has been fixed by one of our developers and its fix was included in the new pre-release of Xamarin.Forms 4.5, so we have upgraded geewallet to use this new version instead of v4.3.
Labels: CSharp, General, Ingenieria, Miscelanea, Mono, Programacion, SoftwareLibre, Xamarin
Sunday, January 05, 2020
Introducing geewallet
- Make it even more user friendly: blockchain addresses are akin to the numeric IP addresses of the early 80s when DNS still didn’t exist. We plan to use either ENS or IPNS or BNS or OpenCAP so that people can identify recipients much more easily.
- Implement Layer2 technologies: we’re already past the proof of concept phase. We have branches that can open channels. The promise of these technologies is instantaneous transactions (no waits!) and ridiculous (if not free) fees.
- Switch the GTK Xamarin.Forms driver to work with the new “GtkSharp” binding under the hood, which doesn’t require glue libraries. (I’ve had quite a few nightmares with native dependencies/libs when building the sandboxed snap package!)
- Integrate with some Rust projects: MimbleWimble(Grin) lib, the distributed COMIT project for trustless atomic swaps, or other Layer2-related ones such as rust-lightning.
- Cryptography work: threshold keys or deniable encryption (think "duress" passwords).
- NFC support (find recipients without QR codes!).
- Tizen support (watches!).
- Acceptance testing via UI Selenium tests (look up the Uno Platform).
- Flatpak support: unfortunately I haven’t had time to look at this sandboxing technology, but it shouldn’t be too hard to do, especially considering that there’s already a Mono-based project that supports it: SparkleShare.
- Ubuntu packaging: there’s a patch blocked on some Ubuntu bug that makes the wallet (or any .NET app these days, as it affects the .NET package manager: nuget) not build in Ubuntu 19.10. If this patch is not merged soon, the next LTS of Ubuntu will have this bug :( As far as I understand, what needs to be solved is this issue so that the latest hotfixes are bundled. (BTW I have to thank Timotheus Pokorra, the person in charge to package Mono in Fedora, for his help on this matter so far.)
- GNOME community: I’m in search for a home for this project. I don’t like that it lives in my GitLab username, because it’s not easy to find. One of the reasons I’ve used GitLab is because I love the fact that being open source, many communities are adopting this infrastructure, like Debian and GNOME. That’s why I’ve used as a bug tracker, for merge requests and to run CI jobs. This means that it should be easy to migrate to GNOME’s GitLab, isn’t it? There are unmaintained projects (e.g. banshee, which I couldn’t continue maintaining due to changes in life priorities...) already hosted there, so maybe it’s not much to ask if I could host a maintained one? It's probably the first Gtk-based wallet out there.
- Please don’t ask me to add support for your favourite %coin% or <token>.
- If you want to contribute, don’t ask me what to work on, just think of your personal itch you want to scratch and discuss it with me filing a GitLab issue. If you’re a C# developer, I wrote a quick F# tutorial for you.
- Thanks for reading up until here! It’s my pleasure to write about this project.
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.
Labels: CSharp, General, Gnome, Ingenieria, Miscelanea, Mono, Programacion, Seguridad, SoftwareLibre, Xamarin
Wednesday, January 23, 2019
WORA-WNLF
- Xamarin (the company) was bought by Microsoft and, at the same time, Xamarin (the product) was open sourced.
- Xamarin.Forms is opensource now (TBH not sure if it was proprietary before, or it was always opensource).
- Xamarin.Forms started supporting macOS and Windows UWP.
- Xamarin.Forms 3.0 included support for GTK and WPF.
Labels: CSharp, General, Gnome, Ingenieria, Mono, Programacion, SoftwareLibre, Xamarin
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:
- The newer versions of your desktop or desktop programs don't run properly with the settings saved in your .dotDirectories (they are to blame because they didn't probably have a settings-conversion feature).
- The newer versions of your desktop or desktop programs have a buggy settings-conversion feature; because your program does not run properly, or as well as it would have run if it had been ran for the first time with no settings saved at all.
- The newer versions of your non-buggy desktop or desktop programs convert your settings to a new format. Then when you go back and run your old distro again, your old-versioned programs stop working because they see settings in a new format which they don't understand. (This is impossible to fix, or very hard.) It's very important that this scenario works, because the migration to the new version of your distro may not be immediate, it may take you some days to figure everything out, and until that happens, you want to still be able to run the stable version of your desktop and desktop programs
- Etc.
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:
- /home/knocteXAB/Music -> /home/knocte/Music
- /home/knocteXAB/Documents -> /home/knocte/Documents
- /home/knocteYCD/Music -> /home/knocte/Music
- /home/knocteYCD/Documents -> /home/knocte/Documents
- Etc.
- Debugger not stopping on breakpoints.
- Builds breaking with obscure error messages.
- Debugger opening file in the IDE which was already open, duplicating two tabs for the same file.
- Etc.
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:
- Even the slickest workarounds have problems. Try to fix or report settings-conversion bugs!!
- Don't ever quit trying to fix a problem. Some day you'll have the solution and you will realize it was simpler than you thought.
- realpath is your friend.
- MonoDevelop (master branch) is now less buggy and as amazing as (or more than) ever (</PUBLIC_SERVICE_ANNOUNCEMENT>).
Labels: CSharp, General, Gnome, Mono, Programacion, SoftwareLibre
Tuesday, May 20, 2014
Banshee GSoC-2014 projects under Gnome umbrella
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:
- Nicholas Little will be working on creating a new extension for Bluetooth synchronization, and if time permits, refactoring our MTP support. In regards to the latter, if you have an Android phone you might have experienced some bugs getting it to work with Banshee lately (our MassStorage synchronization support is great, but the latest versions of Android have been deprecating this mode in favour of MTP, which we never supported very well); we have been working hard on fixing them, but Nicholas is going to try to give it that extra push at the end of the summer, which I'm confident he will do very well (he was the developer who brought Symbian support for the masses -or rather, for his Nokia N95 ;) -, on Banshee 2.9.0). And you may be wondering, why do we need Bluetooth sync? Well, we understand that it's much slower than USB or Wifi, but:
- 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!
- 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).
- Marcin Kolny, which has convinced us that he will do a great job given his great patches and the fact that he's already very involved in opensource (maintainer of C++ bindings to GStreamer if I recall correctly), will be working on integration with AcoustID. To summarize it very bluntly, AcoustID is the open-source alternative to Shazam, so thanks to this, if you have many tracks in your library which didn't get ripped properly with tags, or you got from some friend which is not very metadata-driven ;) then you will be able to fix this situation! We will be likely reusing the MetadataFixer extension that we already have in Banshee, to not reinvent the UI wheel.
- Dmitriy Petukhov, a very motivated Russian student, will be helping us get two extensions in shape, which were developed in the last GSoC (more details about this in my previous blog post), but were not ready for mainstream yet. The FanArt.TV extension, which retrieves artist logos and shows them next to your album icons, needs some caching (we could even violate FanArt.TV service's ToS if we don't do this) and UI polish (our ListView widget doesn't play well with differently-sized images, so we need to modify this custom GTK widget to allow rendering rows with different heights). The SongKick extension works great, but also needs caching, and it especially needs GeoLocation to maybe even work autonomously (imagine, you don't even know what SongKick is, and because you installed the banshee-community-extensions package of your distro, you suddenly get told that one of your favorite bands is soon playing a gig near your city!).
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: General, Gnome, Mono, Programacion, SoftwareLibre