What's coming up in imag (5)

Wow, another 14 days! When I started writing this article, I thought I didn’t manage to do a lot of changes in the last 14 days. git proved me wrong.

What happened

When I started writing this article, I thought “Oh man, another 14 days with little progress in imag”. I was proven wrong:

$ git log --oneline --merges --since=2016-04-07
c3618ec Merge pull request #343 from matthiasbeyer/libimagstorestdhook/flock
45f93e5 Merge pull request #366 from matthiasbeyer/update-dependency/regex
25a71ce Merge pull request #365 from matthiasbeyer/libimagstorestdhook/zero-warnings
a2288ba Merge pull request #364 from matthiasbeyer/libimagnotes/zero-warnings
791b3ad Merge pull request #363 from matthiasbeyer/libimagentrylist/zero-warnings
f0d29da Merge pull request #362 from matthiasbeyer/libimagentryfilter/zero-warnings
e040d0d Merge pull request #361 from matthiasbeyer/libimagrt/zero-warnings
3e29ec0 Merge pull request #359 from matthiasbeyer/remove-init-logging
19808cf Merge pull request #360 from matthiasbeyer/update-dep/iterools
99e1e41 Merge pull request #353 from matthiasbeyer/rename/libimaglink
a5e9bf7 Merge pull request #358 from matthiasbeyer/imag-view/zero-warnings
d3b94df Merge pull request #354 from matthiasbeyer/libimaglink/zero-warnings
3a5c965 Merge pull request #355 from matthiasbeyer/libimagutil/zero-warnings
86ae438 Merge pull request #356 from matthiasbeyer/imag-counter/zero-warnings
f64ed8e Merge pull request #357 from matthiasbeyer/imag-link/zero-warnings
ed6d912 Merge pull request #352 from matthiasbeyer/rename/libimagtag
179ae2b Merge pull request #350 from matthiasbeyer/libimagtag/zero-warnings
f003625 Merge pull request #351 from matthiasbeyer/libimagcounter/zero-warnings
ff20e79 Merge pull request #338 from matthiasbeyer/imag-link/external-linking
e4e3c05 Merge pull request #326 from matthiasbeyer/libimaglink/external-linking-rewrite
3d124df Merge pull request #347 from matthiasbeyer/libimaglink/unique-internal-links
17610ef Merge pull request #337 from matthiasbeyer/imag-link/list-implementation
20a76f8 Merge pull request #330 from matthiasbeyer/update-contributing
535483d Merge pull request #335 from matthiasbeyer/libimaglink/bugfixes
18627f1 Merge pull request #336 from matthiasbeyer/imag-link/cli-unpacking-bugfix
8d7e2d9 Merge pull request #331 from mario-kr/add-description_to_build/run_imag
9866c63 Merge pull request #311 from matthiasbeyer/libimaginteraction/init
92b471b Merge pull request #328 from matthiasbeyer/imag-link/fix-ui
cd2bc0b Merge pull request #325 from matthiasbeyer/libimaglink/internal-linking-use-storeid

Let me do a short iteration.

Zero Warnings

I opened an issue about warnings and that we should enable compiler lints to make them hard errors. Then I started to write pull requests for each crate in the repository and also got them merged. We have almost no warnings left when compiling imag, which is what I consider nice progress!


Some time ago we rewrote the Runtime setup code for logging, so we had the logger enabled at the earliest possible point in program execution. Now I removed some debug!() calls which were done in the main.rs of almost all crates right after the Runtime object was built which stated something like "logging enabled...". These debug!() calls were outdated, so I removed them.

Libraries renamed

Some of the libraries were renamed. For example "libimagtag" got renamed to "libimagentrytag".

This is none of a big deal and as we are pre-1.0 I can do this, I guess.

This is one of the gems here, really. I finally got my feet up to rewrite the external linking part of the linking library and got imag-link adapted so it works appropriately now. How awesome is that?

More Hooks!

I implemented a flock() hook in libimagstorestdhook and I have another open PR for a verify-link hook which uses libimagentrylink to verify that all linked entries exist.

Dependencies updated!

I updated a number of dependencies (namely itertools and regex) and I also rewrote the Cargo.toml files to depend not on the master-minor-patchlevel version of the crates but on master-minor versions, so cargo can figure out what patchlevel to use.

What’s coming up

I’m about to re-write the libimagdiary because what I did in my initial PR for the library was a mess. I tried to implement the diary functionality by re-using the note functionality, which resulted in ugly spagetti code and the like, so I decided it would be better to just re-write the whole thing.

I’m about to merge a PR which introduces the concept of non-failing hook errors. So a hook can return an error which does not abort the store operation which invoked the hook itself.

I also started to implement libimagentryview on my own, as the friend of mine who said he wants to do it hasn’t made anything yet, so I’m a bit pissed of on him. But Hey, it is open source, nobody can force anybody! So I will just stick with implementing it on my own (and it is also almost finished).

I also started to refactor the implementation of the StoreId type, as we might need to extend this type in external crates, so doing a pub type StoreId = PathBuf was not the best idea and I started to rewrite it as pub struct StoreId(PathBuf) - I hope I can manage to do this in a backwards compatible way, but I’m not sure.

I also started implementing a Walk type for the Store which does a walk through all the objects in the store. This is not an iterator but something that also notes folders within the store and gives the possibility to iterate through a tree rather than through a flat list of entries. Could be helpful sometimes.

We also have an open PR for DSL support with libimagentryfilter, so the user is able to filter entry iterators with a DSL. This is early-state but looks rather promising IMHO.