imag — musicmatzes blog

Building imag with nix remote builds

Sun, 01 Apr 2018 16:39:26 +0200

This is mostly a reminder for myself how to do it, because the documentation non the nix side is pretty sparse.

What I want to do is to build imag on a remote server using nix 2.0 features - nix remote builds.

Here are the steps I did for achieving that goal:

build the Cargo.lock file with cargo generate-lock for the imag workspace
generate a build.nix file using carnix --standalone --src . --output build.nix Cargo.lock
monkey-patching the generated nix file because carnix generates wrong pathes for the build.rs file in the nix expressions. I did that with a simple substitude pattern in vim: %s/"\.\.\/\.\.\/\.\.\/build\.rs"/.\/build.rs/
ensure the remote machine has nix 2.0
use NIX_REMOTE=ssh-ng://user@host nix build -f ./build.nix imag_0_7_0 to build imag on the remote machine.

Unfortunately, because the generated expressions do not use cargo but execute the rustc compiler directly, the build fails because I need the CARGO_BUILD_VERSION and CARGO_PKG_VERSION environment variables which are set by cargo during the build.

I hope carnix gets support for automatically adding those variables to the build soonish, so I can build imag completely remote.

tags: #imag #nix #rust

34c3

Mon, 01 Jan 2018 16:38:38 +0100

34c3 was awesome. I prepared a blog article as my recap, though I failed to provide enough content. That's why I will simply list my “toots” from mastodon here, as a short recap for the whole congress.

(2017-12-26, 4:04 PM) – Arrived at #34c3
(2017-12-27, 9:55 AM) – Hi #31c3 ! Arrived in Adams, am excited for the intro talk in less than 65 min! Yes, I got the tag wrong on this one
(2017-12-27, 10:01 AM) – Oh my god I'm so excited about #34c3 ... this is huge, girls and boys! The best congress ever is about to start!
(2017-12-27, 10:25 AM) – Be awesome to eachother #34c3 ... so far it works beautifully!
(2017-12-27, 10:31 AM) – #34c3 first mate is empty.
(2017-12-27, 10:46 AM) – #34c3 – less than 15 minutes. Oh MY GOOOOOOOOOD
(2017-12-27, 10:49 AM) – Kinda sad that #fefe won't do the Fnord this year at #34c3 ... but I also think that this year was to shitty to laugh about it, right?
(2017-12-27, 10:51 AM) – #34c3 oh my good 10 minutes left!
(2017-12-27, 11:02 AM) – #34c3 GO GO GO GO!
(2017-12-27, 11:16 AM) – Vom Spieltrieb zur Wissbegierig! #34c3
(2017-12-27, 12:17 PM) – People asked me things because I am wearing a #nixos T-shirt! Awesome! #34c3
(2017-12-27, 12:59 PM) – I really hope i will be able to talk to the #secushare people today #34c3
(2017-12-27, 1:44 PM) – I talked to even more people about #nixos ... and also about #rust ... #34c3 barely started and is already awesome!
(2017-12-27, 4:28 PM) – Just found a seat in Adams. Awesome! #34c3
(2017-12-27, 8:16 PM) – Single girls of #34c3 – where are you?
(2017-12-28, 10:25 AM) – Day 2 at #34c3 ... Yeah! Today there will be the #mastodon #meetup ... Really looking forward to that!
(2017-12-28, 12:32 PM) – Just saw ads for a #rust #wayland compositor on an info screen at #34c3 – yeah, awesome!
(2017-12-28, 12:37 PM) – First mate today. Boom. I'm awake! #34c3
(2017-12-28, 12:42 PM) – #mastodon ads on screen! Awesome! #34c3
(2017-12-28, 12:45 PM) – #taskwarrior ads on screen – #34c3
(2017-12-28, 3:14 PM) – I think I will not publish a blog post about the #34c3 but simply list all my toots and post that as an blog article. Seems to be much easier.
(2017-12-28, 3:15 PM) – #34c3 does not feel like a hacker event (at least not like the what I'm used to) because there are so many (beautiful) women around here.
(2017-12-28, 3:36 PM) – The food in the congress center in Leipzig at #34c3 is REALLY expensive IMO. 8.50 for a burger with some fries is too expensive. And it is even less than the Chili in Hamburg was.
(2017-12-28, 3:43 PM) – Prepare your toots! #mastodon meetup in less than 15 minutes! #34c3
(2017-12-28, 3:50 PM) – #34c3 Hi #mastodon #meetup !
(2017-12-28, 3:55 PM) – Whuha... there are much more people than I've expected here at the #mastodon #meetup #34c3
(2017-12-28, 4:03 PM) – Ok. Small #meetup – or not so small. Awesome. Room is packed. #34c3 awesomeness!
(2017-12-28, 4:09 PM) – 10 minutes in ... and we're already discussing pineapples. Community ftw! #34c3 #mastodon #meetup
(2017-12-28, 4:46 PM) – Limiting sharing of #toots does only work if all instances behave! #34c3 #mastodon #meetup
(2017-12-28, 4:56 PM) – Who-is-who #34c3 #mastodon #meetup doesn't work for me... because I don't know the 300 usernames from the top of my head...
(2017-12-28, 5:17 PM) – From one #meetup to the next: #nixos ! #34c3
(2017-12-28, 5:57 PM) – Unfortunately the #nixos community has no space for their #meetup at #34c3 ... kinda ad-hoc now!
(2017-12-28, 7:58 PM) – Now... Where are all the single ladies? #34c3
(2017-12-28, 9:27 PM) – #34c3 can we have #trance #music please?
(2017-12-28, 9:38 PM) – Where are my fellow #34c3 #mastodon #meetup people? Get some #toots posted, come on!
(2017-12-29, 1:44 AM) – Day 2 ends for me now. #34c3
(2017-12-29, 10:30 AM) – Methodisch Inkorrekt. Approx. 1k people waiting in line. Not nice. #34c3
(2017-12-29, 10:43 AM) – Damn. Notebook battery ran out of power last night. Cannot check mails and other unimportant things while waiting in line. One improvement proposal for #34c3 – more power lines outside hackcenter!
(2017-12-29, 10:44 AM) – Nice. Now the wlan is breaking down. #34c3
(2017-12-29, 10:57 AM) – LAOOOOLAAA through the hall! We did it #34c3 !
(2017-12-30, 3:45 AM) – 9h Party. Straight. I'm dead. #34c3
(2017-12-30, 9:08 PM) – After some awesome days at the #34c3 I am intellectually burned out now. That's why the #trance #techno #rave yesterday was exactly the right thing to do!
(2017-12-30, 11:35 PM) – Where can I get the set from yesterday night Chaos Stage #34c3 ??? Would love to trance into the next year with it!
(2017-12-31, 11:05 PM) – My first little #34c3 congress résumé: I should continue on #imag and invest even more time. Not that I do not continue it, but progress is slowing down with the last months of my masters thesis... Understandable I guess.

That was my congress. Yes, there are few toots after 28th... because I was really tired by then and also had people to talk to all the time, so little time for microblogging there. All in all: It was the best congress so far!

tags: #ccc #social

Planning a log-functionality refactoring for imag

Sun, 27 Aug 2017 16:38:17 +0200

Here I want to describe how I plan to refactor the logging back end implementation for imag.

This post was published on imag-pim.org as well as on my personal blog.

What we have

Right now, the logging implementation is ridiculously simple. What we do is: On every call to one of the logging macros, the log crate gives us an object with a few informations (line number, file, log message,...) – we apply our format, some color and write it to stderr.

This is of course rather simple and not really flexible.

What we want to have

I want to rewrite the logging backend to give the user more power about the logging. As we only have to rewrite the backend, and the log crate handles everything else, the actual logging looks non different and “client” code does not change.

+----------------------------+
| imag code, libs, bins, ... |
+----------------------------+
              |
              | calls
              |
              v
+----------------------------+
| crate: "log"               |
+----------------------------+
              |
              | calls
              |
              v
+----------------------------+
| imag logging backend impl. |
+----------------------------+

So what features do we want? First of all, the imag user must be able to configure the logging. Not only with the configuration file but also via environment variables and of course command line parameters. The former will be overridden by the latter, respectively. This gives the user nice control, as she can configure imag to log to stderr with only warnings being logged but when calling a script of imag commands or calling imag directly from the command line, these settings can be temporarily (for the script or one command) be overridden.

The configuration options I have in mind are best described by an example:

# The logging section of the configuration
[logging]

# the default logging level
# Valid values are "trace", "debug", "info", "warn", "error"
level = "debug"

# the destinations of the logging output.
# "-" is for stderr, multiple destinations are possible
default-destinations = [ "-", "/tmp/imag.log" ]

# The format for the logging output
#
# The format supports variables which are inserted for each logging call:
#
#  "%no%"       - The of the logging call
#  "%thread%"   - The thread id from the thread calling the log
#  "%level%"    - The logging level
#  "%module%"   - The module name
#  "%file%"     - The file path where the logging call appeared
#  "%line%"     - The line No of the logging call
#  "%message%"" - The logging message
#
# Functions can be applied to the variables to change the color of
# the substitutions.
#
# A format _must_ contain "%message%, else imag fails because no logging should
# be forbidden
#
[logging.formats]
trace = "cyan([imag][%no%][%thread%][%level%][%module%][%file%][%line%]): %message%"
debug = "cyan([imag][%no%][%thread%][%level%][%module%][%file%][%line%]): %message%"
info  = "[imag]: %message%"
warn  = "red([imag]:) %message%"
error = "red(blinking([imag][uppercase(%level%)]): %message%)"

# Example entry for one imag module
# If a module is not configured or keys are missing
# the default values from above are applied
[logging.modules.libimagstore]
enabled = true
level = "trace"
destinations = [ "-" ]
# A format is only globally configurable, not per-module

One of the most complex things in here would be the format parsing, as variable expansion and functions to apply are some kind of DSL I have to implement. I hope I can do this – maybe there's even a crate for helping me with this? Maybe the shellexpand library will do?

These things and configuration options give the user great power over the logging.

The approach

Because imag already logs a lot, I think about an approach where one thread is used for the actual logging. Because each logging call involves a lot of complexity, I want to move that to a dedicated thread where other threads speak to the logging thread via a MPSC queue.

Of course, this should be opt-in.

The idea is that the logging starts a thread upon construction (which is really early in the imag process, nearly one of the first operations done). This happens when the Runtime object is build and hence no “client code” has to be changed, all changes remain in libimagrt.

This thread is bound to the Runtime object, logging calls (via the logging backend which is implemented for the log crate) talk to it via a channel. The thread then does the heavy lifting. Of course, configuration can be aggregated on construction of the logging thread.

The logging thread is killed when the Runtime object is dropped (one of the last operations in each imag process). Of course, the queue has to be emptied before the logging is closed.

I am also thinking about converting the code base to use the slog crate, which offers structured logging. But I'm not yet sure whether we will benefit from that, because I don't know whether we would need to pass a state-object around. If that is the case, I cannot do this as this would introduce a lot of complexity which I don't want to have. If no such object needs to be passed around, I still have to evaluate whether the slog crate is a nice idea and of course this would also increase the number of (complex) dependencies by one... and I'm not sure whether the benefits outrule the inconveniences.

tags: #linux #open source #programming #rust #software #tools #imag

imag-pim.org - The new website

Sat, 10 Jun 2017 16:38:13 +0200

The imag-pim.org website just got a new face.

I was really eager to do this becaues the old style was... not that optimal (I'm not a web dev, let alone a web designer).

Because the site is now generated using hugo, I also copied the “What's coming up in imag” blog posts over there (I keeping the old ones in this blog for not breaking any links). New articles will be published on the imag-pim.org website.

This very blog article will be published on both sites, of course.

tags: #linux #open source #rust #software #tools #imag

What's coming up in imag (25)

Sat, 13 May 2017 16:38:13 +0200

This is the 25th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

Luckily I can write this iteration on imag. After we had no blog post about the progress in imag in April this year, due to no time on my side, I'm not very lucky to be able to report: We had progress in the last 4 (8) weeks!

Lets have a look at the merged PRs (I'm now starting to link to git.imag-pim.org here):

#915 merged a libruby dependency for travis.
#918 removed some compiler warnings.
#917 merged some travis enhancements/fixes.
#916 superceeded PR #898, which simplified the implementation of the FoldResult extension.
#895 started a re-do of the ruby build setup.
#911 changed the interface of the StoreId::exists() function to return a Result now.
#904 added initial support for annotations in the libimagentrylink library, which gives us the posibility to add annotations to links. There are no tests yet and also no remove functionality.
#921 was a cleanup PR for #911 which broke master unexpectedly.
#914 fixed a compiler warning.
#929 removed libimagruby entirely because we couldn't merge to master because a dependency on master started to fail. The whole ruby thing is a complete mess right now, dependencies are not found, tests fail because of this... it is a mess.
#927 removed unused imports.
#924 updated links in the readme file.
#926 added tests for the StoreId type.
#919 merged preparings for the 0.3.0 release, which is overdue for one month right now, because the ruby scripting interface does not work.
#930 updated the toml-rs dependency to 0.4, which gives us even more superpowers.
#932 added some tests for the configuration parsing functionality.
#933 Adds a new dependency: is-match, a library I extracted from the imag source code into a new crate.

The libimagruby mess

Well, this is unfortunate.

libimagruby should be ready for one month by now and usable – and it is (the basic things, few things tested also)! But as the CI does not work (fuck you travis!) I cannot merge it. I also don't know how to properly package a Ruby gem, so there's that.

I really hope @malept can help me.

I'm already thinking about adding another scripting interface, so I can continue and start implementing frontends for imag, for example I'm thinking about a lua or ketos interface, still. Lua might be the better idea, as there are libraries around for certain things, while there are no libraries for ketos (I assume).

What will happen

I honestly don't know. I will continue working on imag, of course, but right now, the libimagruby is stalled. I'm not sure where to start working besides libimagruby – a Ruby scripting interface is what I need right now, but it won't work ... so there's that.

As soon as the Ruby interface is ready, we can have nice things. But right now, it is really hard to continue.

tags: #linux #open source #programming #rust #software #tools #imag

What's coming up in imag (23)

Mon, 20 Feb 2017 18:41:03 +0100

This is the 23th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

What happenend?

I'm a bit late this month, I know. Anyways, things happened in the imag distribution and I'm eager to write them down, so here we go!

In the last four weeks I merged a lot of PRs – 27 actually! Here are the most awesome ones:

#836 eliminated the EntryHeader type entirely from the codebase. We are using toml::Value objects now!
#852 was contributed by @mario-kr to enable cargo workspace support! That was a really awesome PR, as it reduced our build times down to ~4 minutes!
#854 removed a lot of things (>4k lines) due to the focus-shift to libimagruby (read below)
#871 added the ruby build setup (read below)
#872 and #873 and #874 and #892 fixed some things to compile with fewer warnings. Awesome!
#878 updated the regex dependency.
#894 reverted the changes from #871 as it broke master :–(

Ruby?

Yes, Ruby!

We implemented the libimagruby, which contains Ruby bindings for libimagstore. So imag can now be programmed in Ruby!

There is a release (0.3.0) in the pipeline (waiting for fixes in cargo), which will then contain rudimentary support for programming the store in the wonderful Ruby programming language. I've written about that before and now it finally works. It is just not released yet.

The next release (0.4.0) will then contain more functionality to program imag, including some more bindings for libraries.

I think this will speed up development a bit, as we have more libraries in Ruby available.

What's coming?

Well, I hope to get out 0.3.0 soonish. We have to wait for Cargo, as we ran into a bug (misbehaviour) of cargo with the current release. As soon as the next cargo version is out I will try to release 0.3.0 and then we'll see...

Of course, I really hope to get some binaries implemented then. Starting with imag-diary and imag-mail, but also more advanced things like imag-music, imag-calendar and imag-contacts.

tags: #programming #rust #software #tools #imag

What's coming up in imag (22)

Tue, 17 Jan 2017 17:41:02 +0100

This is the 22th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

What happenend?

My masters courses are hard (time-wise). I didn't manage to do anything at all in the imag codebase. I hate it. I really want to get imag in a usable shape. So here's what I want to do to make this huge task a bit more achieveable.

Focus shift

I wrote about integrations before. I want to shift the focus of my work on imag to develop a Ruby gem from the imag functionality. This will be the next release. I will write either one or several gems with the imag libraries as backend, so one can write integrations in Ruby. I will do this because I think that the Ruby ecosystem fits the problem pretty well.

So what is the problem?

The problem is the following. We have a working imag store. We have working libraries on top of that “database layer” – namingly tags, refs (though they could use some polishing and features) and most importantly links (both external and internal).

What we do not have is the whole $tool -> database stuff. So we cannot put mails into the store, because we need to parse mails. We cannot put calendar data files into the store, because we need to parse icalendar. We cannot put contacts into the store because we need to parse vcard. And so on and so forth.

But the Ruby ecosystem has libraries for all these things.

So the obvious solution is to write a Ruby integration. We can then write the simple data-format-transformation tools in Ruby and we will be faster implementing it. We do not need the guarantees Rust gives us here – they would be nice, but they are not necessary!

Later, for querying the store, we can write the simple stuff in Ruby as well and the more complex stuff – or the performance-critical parts – in Rust.

How to do the shift?

I guess I will branch-off a major branch for the shift and remove some of the functionality which is already in the repository, namingly:

imag-bookmark
imag-counter
imag-diary
imag-mail
libimagbookmark
libimagcounter
libimagdiary
libimagmail
libimagnotification
libimagtodo

These tools implement functionality which would be way better be implemented in Ruby.

Clearly, some functionality can be kept. We can keep some of the more basic commands:

imag-link
imag-ref
imag-store
imag-tag
imag-view (though a Ruby tool might come up with way better functionality)
libimagentrytag
libimagentryview

And the related libraries will be kept as well:

libimagerror
libimagref
libimagrt
libimagstore
libimagstorestdhook
libimagutil

I'm not sure about imag-notes though. A Ruby tool might have better functionality for this, though imag-notes works for me pretty well so far, so we might keep it, and its library:

imag-notes
libimagnotes

The other libraries... I'm not sure. Maybe some of the tools listed above need them (really... I haven't looked at the codebase for a long time now cry). So maybe we must keep them, maybe we can remove them:

libimagentryedit
libimagentryfilter
libimagentrylink
libimagentrylist
libimagentrymarkdown
libimagtimeui
libimaginteraction

imag.rb

And we will introduce one new crate: imag.rb. This will be a ruby crate – so we will use ruru to build a Ruby gem out of the functionality implemented in the core crates. Clearly, the first step would be to put the libimagstore interface into this crate (plus its dependencies, libimagerror, libimagutil, ...), but I guess it is a good idea to have libimagtag, libimaglink and the functionality of the other core-libraries in there as well.

How long?

Your question might be: How long will this take? Well. Yes.

I really don't know. As said countless times: Masters degree is engaging. I hope I can get some things done after my exams (which end mid-february). until then – I don't think I have time to do much things.

Help is appreciated, though!

tags: #programming #rust #software #tools #imag

What's coming up in imag (21)

Fri, 16 Dec 2016 16:37:56 +0100

This is the 21th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

What happenend?

Well, as I said before, I have a really busy masters degree to do, so progress in imag slowed down a lot. Believe me or not, I don't like that. I want to continue to work on imag as much as possible, but right now, I just do not have enough time for it.

I have a plan, though.

But first, lets see what happenend in the last four weeks.

PRs/Issues

The following issues and PRs were touched in the last weeks:

#764 initialized the work on imag-mail
#838 bumped up the clap version
#839 updated dependencies
#840 works on bulk-import for imag-mail
#841 is a bug report on the behaviour of imag link internal --list
#842 fixes #841
#843 fixes another small bug in a UI
#844 fixes a typo
#845 adds Makefile support for cargo-outdated

What will happen

Well, I cannot predict the future. As Christmas (and 33c3) is coming up, I don't know how much time I will have to work on imag.

But what I want to do: Shift my focus a bit. Before I had a kind of Shotgun-Approach: Implement everything, work on multiple things all the time. I will not do this anymore. In fact, I will move issues from the 0.3.0 release to 0.4.0 and so on, shift everything by one release. That will free the 0.3.0 release and I will focus on one goal in this release then: A scripting API.

I want to develop an imag library for writing scripts for imag. I think about Ruby, because that's a language I am familiar with. Another option would be Lua. I hope I can construct the scripting-API interface in a way so it can be re-used to write a Lua interface.

But that will it be for 0.3.0. Having a neat scripting API (not low-level but rather high-level) gives us the possibility to quickly write simple integrations with tools, for example to integrate mails, a wiki or something similar.

I hope that's a plan. 0.3.0 is due to March 2017 as far as I remember, so there's plenty of time for this.

My next post will be around mid-january 2017, so I think it is appropriate to wish you all a very fine Christmas and a good new year!

tags: #linux #open source #programming #rust #software #tools #imag

What's coming up in imag (20)

Fri, 18 Nov 2016 16:37:56 +0100

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 20th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

Also, I have some changes to this series of blog posts. Read about it here as well.

The past

In the past two weeks, we got almost nothing done, honestly. We had four pull requests and no new issues. Why is that? Well, most of the PRs are mine as well as most of the issues are opened by me. And I have a hell lot to do with my masters degree. Also, I want to write pull requests to the rust-vobject crate to give it a high-level interface to be able to write my calendar and contacts module with it. This is, as you might think, a nontrivial task and therefor take some time as well.

We had one new contributor though. Thanks to Steven Allen for PR #834.

That's why we didn't have that much progress. I will sum it up here:

834 optimized one point in libimagutil where I opened one file twice. Thanks again, Steven Allen, for the contribution!
835 moved the functionality of the EntryHeader (the querying by string in the header toml data structure) to a new libimagstore module, so the module libimagstore::store does only contain a minimal EntryHeader type for backwards compatibility.
836 eliminates the EntryHeader type completely and replaces it by toml::Value, its inner type. This is not completed at the time of writing.
837 adds older compilers to the CI setup for travis.

The future

Lets see what will happen in the next four weeks.

Yes, that's right. I will do...

Less updates

I will slow down this blogging series. This was the 20th iteration on the subject, so I already do this for 40 weeks now. I will now slow this down and only post every four weeks about imag. Partly because my masters degree is really time consuming, partly because I already planned this beforehand. Every four weeks will be enough, I guess. I'm not sure whether I will continue include all PRs and issues or only the major ones. We'll see.

Plans

For the next four weeks I plan to get some functionality into rust-vobject. I will then start to implement imag-contact and I hope to get some progress with imag-mail, but I cannot promise anything.

tags: #linux #open source #programming #rust #software #tools #imag

What's coming up in imag (19)

Fri, 04 Nov 2016 17:37:55 +0100

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 19th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

The past

We have more than 150 stars now! Wow!

Besides that we had really not that much progress in the last 14 days. My masters degree keeps me busy all day long and I really have a hard time with all the things I have to do for my courses, so progress slows down way more than I expected. But I can't change that, so ...

PRs merged/closed in the last 14 days

821 imported commits from our v0.2.0 release branch into the master branch.
822 updates our dependencies. Luckily this worked without too much hassle. Still, we had some problems while updating. We only had to update a method from itertools which was removed. We also had to update task-hookrs as both imag and task-hookrs depend on uuid and they really should depend on the same version of uuid, so I updated task-hookrs to the latest uuid, which in fact included some code removal in the codebase of task-hookrs. This was because uuid depends (and we also need it) on serde, which was update from 0.7.* to 0.8.*. As serde included some new awesome things, we were able to remove some code in task-hookrs.
823
827 implements PartialEq on StoreId, which is a really neat improvement in my opinion. We derive()d it before, but we now only compare the local part of the StoreId object (read: The store-part, not the path to the store itself, which could be absent sometimes, causing weird bugs).
828
829
831

Also, two really old PRs were closed. I do not list older PRs normally, but these two are really noteworthy:

624 included cargo workspace support in our build setup. I'm not sure it works the way I expected it to, as (for example) clap gets rebuild several times... but at least cargo doesn't yell at us anymore, so I included it.
656 sets the codegen units for rustc to 2. I hope we get slightly better build times on travis from that.

PRs opened in the last 14 days and not yet closed

824
826 bakes in shell completion generation for all the imag-* tools
832 – now, this is a really great PR from mario-kr. Mario found a way to build shell completion for all the imag tools, starting at the imag binary itself. I did not even think about this as solution, but it works and I'm willing to merge this as soon as Mario did some cleanup work in the PR. What he did is: He include()d all ui.rs files, where we (more or less by accident) always used the same function name to build the clap:App: build_ui(App) -> App. He includes these source files via a neat macro as sub modules and is then able to call all these build_ui functions to build a App object (with subcommands for each imag module). From that App object, he can retrieve the bash/fish/zsh completion (at build time). This is awesome!
833

Issues opened and already closed

As far as I see, we had no issues opened in the last 14 days that were also closed within theses two weeks.

Maybe in the next iteration again.

The future

Lets have a quick look what the future might bring us in the imag codebase.

Issues opened and not yet closed

830 was our only issue we opened in the last 14 days. It wants a rewrite of all the *.sh scripts we use to test binaries. These scripts really should be rewritten in Rust, we now have the ability to do tests in-memory, so there shouldn't be any issues with implementing these things in Rust. It is really a trivial task (not for a complete rust beginner IMO), so I'll not start implementing this soon, so others can step up.

Other things

As said above, I have a lot to do for my masters degree, so I cannot tell how much we can get done in the next two weeks. I'd love to see some progress with the email module, so we can merge this one at least, but I cannot promise it, sadly.

This does not mean I'm not interested in imag anymore. I'm interested even more in it. I just do not have enough time at the moment to do all the things I want to do.

tags: #linux #open source #programming #rust #software #tools #imag