In this article, I would like to share some of my thoughts about a problem I encountered, my process of solving it, and possibly start a discussion about the validity of the proposed approach. I certainly would like to hear any comments and opinions about both the problem and the decisions I made in my solution.
The topic of this article is transforming, or "transposing", an optional collection or an iterator into an iterator of options. You might be familiar with
Result::transpose methods, which transform
Option<Result<T, E>> into
Result<Option<T>, E> and vice versa. My goal is quite similar, but instead, I would like to transform
Option<I: IntoIterator> into
impl Iterator<Option<I::Item>> and
Result<I: IntoIterator, E> into
impl Iterator<Result<I:Item, E>>.
First, I will discuss the motivation behind it and how such operation could be defined. Then, I will walk you through the implementation of this functionality, which uses a trait to extend
Result with an additional method. So hopefully, even if the motivation fails to convince you, there is still some value in following the implementation details.
In this article, I want to share some of my experience from implementing
a small discrete-event simulation library.
The code is available on github, and the (limited at the moment)
documentation on docs.rs.
Note that this implementation is experimental, so
use caution if you want to use any of the code in the current form.
The main focus of this write-up is the library's type-safe interface.
There is no jaw-dropping magic here, but I found the process of writing it
very educational, and decided to share what I had learned.
If you have any comments you'd like to share, corrections
you'd like to make, or questions you'd like to ask, please do reach out,
I would be very interested in hearing from you.
Github is arguably the most popular git hosting service out there,
and it's easy to see why: it's free (for open source projects),
it's powerful, and because it's already familiar,
it's easy to get a new project up and running without much hustle.
Moreover, ever since Github's acquisition by Microsoft, I have noticed a growing effort
to deliver a full-featured CI/CD solution.
Microsoft's investment also seems to ensure the platform's longevity and stability.
But this change in ownership has a flip side, too.
We all remember Microsoft's hostile attitude towards both Linux and open source,
and, despite their recent claims of the newfound love and appreciation for both,
there is a fair share of skepticism in the community, and therefore much reluctance
to put their code on Github.
Of course, there are alternatives.
Probably the biggest contender to Github is GitLab, which is used by quite a number
of open source projects, such as GNOME, Inkscape, and mutt to name a few.
It is offered both as a paid service (although limited free tier
is available for open source projects) and a self-hosted application.
Interestingly, the latter comes in two flavors: free Community Edition
(missing certain features), distributed
under the MIT license, and Enterprise Edition, distributed under a
proprietary license (even though the code is openly available).
But if you read the title of this post carefully, then you know this is not about GitLab.
Instead, I will talk about another git hosting platform.
Gitea, as stated on their official website, is a community managed lightweight code hosting
solution, and is published under the MIT license.
I decided to try it out and write down my experience with setting it up for personal my use.
Today, I learned how to correctly use Cargo build scripts.
Or, more precisely, I learned how to do one particular thing correctly,
but it was significant enough for me that I decided write it down.
Of course, had I read the Cargo Book more carefully before,
I would have saved myself some time, and there would be no dramatic revelation,
and no reason to write this post either.
I guess what I am trying to say is: thank goodness my reading sucks.