This is the 37th 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?

The last update on what’s happening in the imag codebase was in May, so we have a bit to catch up to, right? We had the 0.8.0 release after that last post, so we’ll go from there.

The merges 30d58379, 7c44bc1a, f912d3e7, c911be87, c8da09f6, a138dd40 and e5020404 added post-release-patches, fixed code for compiler warnings, updated the rust compiler and added minor patches

851db4ab was a contribution from newpavlov which replaced the rust-crypto crate with sha-1 and others. Thank you a lot for your contribution!

crate with and others. Thank you a lot for your contribution! 2a62b6df fixed a bug in libimagstore where the filesystem was accessed without using the filesystem abstraction.

acdc1e84 fixed a missing header in imag-diary

f2916aa5 updated rustc on travis

5b82d53f changed the backend so that the filesystem abstraction does not hold the File open anymore. Files are now read into memory and re-opened on write() , thus reducing the amount of FDs held open.

open anymore. Files are now read into memory and re-opened on , thus reducing the amount of FDs held open. 6a81c0af updated rustc on travis once more

ccbc2b26 added a progressbar to imag-diagnostics

c791977a added minor patches

9bce68b1 optimized the iterator story from libimagstore for accessing the filesystem fewer times when iterating over all entries. This was done by introducing an Entries iterator which is returned by Store::entries() . The Entries iterator supports selecting subcollections, which is optimized to not simply ignore everything else (but still iterating over it), but replacing the underlying walkdir::WalkDir iterator with a newly created and optimized one.

iterator which is returned by . The iterator supports selecting subcollections, which is optimized to not simply ignore everything else (but still iterating over it), but replacing the underlying iterator with a newly created and optimized one. 01c56257 updated dependencies

6b8c2916 rewrote the github templates. We’re now not developing on github anymore. Rationale here.

8ab5f550 added some optimizations for travis jobs

879dc253 added a Code of Conduct.

a101e777 updated dependencies

3dba5c21 fixed a bug in imag-link where links were not properly detected when creating

42247170 fixed a bug in imag-contact where Store::create was used rather than Store::retrieve

was used rather than 3c801a26 added a few minor bugfixes

What will happen

Right now, we’re in the middle of two major refactorings which are necessary unfortunately:

Transition to failure for error management. By replacing error_chain and introducing failure to the codebase and abstractions created in the imag libraries, we redefine the whole error-handling story in imag. Hopefully this will ultimatively reduce the amount of code needed to handle errors conveniently. The only thing that’s left to be done is removing all error-chain calls/generation and replacing it with the new infrastructure. Patches to the branch are wholeheartedly welcome! Redefining the IO Story in imag. This is a bit more complicated to explain. We wrote everything down in the documentation of libimagrt. By now, everything seems to work rather well and we’re planning to include that change in the next release. Although, some work is still needed as all the crates have to be changed to use the new IO system (rather trivial to implement actually). Patches to the branch are wholeheartedly welcome!

After that I plan to get imag-entry implemented. It is another plumbing tool for programmatically modifying entries without having to implement the logic yourselves. For example, it could not only be used to check whether variables in an entry header are present or have a certain value, but also to create entries, delete them and so on. It will be a better alternative to imag-store , which is too low-level (CLI-wise) to be used by end-users.

I hope we can get these things done before mid-November, because by then I’ll be back traveling (see the last section of this post).

Back to posts