musicmatzes blog

imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 18th iteration on whats coming up in imag, 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.

The past

I released filters in v0.1.1 and task-hookrs in v0.2.1.

They are now licensed under the terms of MPL-2.0, there were no changes in functionality besides, in the filters library, one can use a filter as an Fn now, but only on nightly rust. I did not bump the version from v0.1.0 to v0.2.0 because I do not think that nightly features should be promoted. They are nice to play with, but stable rust is my target, so I do not include these things as minor versions. And, as semver specifies, we are in v0.x.y, so I can do anything I want!

New contributors

In the last 14 days I got some PRs:

  • matthew-piziak submitted #797: “Simplify implementation of FoldResult and add tests”
  • mario-kr submitted #810: “Single crate for all binaries”
  • rnestler submitted #818: “[WIP] Use Result for from_storeid”
  • Thiez submitted #820: “Add Iterator for Iterator> tracing”

Thank you all very much for your contributions!

PRs merged/closed in the last 14 days

  • 759 added support for commit-on-drop, so we create one commit for all changes of one imag run.
  • 775 added readline support in libimaginteraction.
  • 786
  • 788
  • 789
  • 790
  • 793
  • 794
  • 799
  • 800
  • 801 starts libimagannotation, a library for annotating entries (simply a combination of libimagnotes and libimagentrylink).
  • 803 one part of 802
  • 804 another part of 802
  • 805
  • 807 and another part of 802 which rewrites the external linking part of libimagentrylink.
  • 808
  • 809 a hook for the store which denies deletion of entries that have still links to other entries.
  • 815 a prep-PR for the upcoming release.
  • 816
  • 817
  • 819

PRs opened in the last 14 days and not yet closed

There's not much to say about the following list of PRs, so I just list them here.

Issues opened and already closed

And there's not that much to say about this issues either... so I simply list them here.

The future

Well, the future. The release is really close. I am still not sure how to properly do the release.

As listed below, we have some discussion in #814, and TheNeikos suggested to simply run cargo publish --no-verify in a loop until all crates are up there. I do not like this idea very much, though I do not see an alternative. If you have an alternative, feel free to tell!

For readers that are not familiar with the imag codebase, here's the problem again:

  • We have multiple crates in one repository.
  • We have multiple root crates in one repository.

That means, we have a rather complex net of dependencies of crates in one repository. We have more than 30 crates there. A release process would need to find the one crate that does not depend on any other crate from our repository, cargo publish that one and then walk up the dependency tree until all crates are published. For this, we would either need to parse the Cargo.toml files, to find the dependencies, or just loop over all crates and try to force-publish (as in cargo publish --no-verify) them.

If you have any idea how to do this in a clean and nice (and reproducible) and automated way (I do not want to do this by hand, really), feel free to post a comment on #814!

Issues opened and not yet closed

Some issues were opened that are not yet closed.

  • 791
  • 792 wants ENV-var expansion from the configuration.
  • 798 wants the git-mv hook for Store::move* functions
  • 802 tracking issue for the libimagentrylink rewrite to return iterators instead of Vecs.
  • 806
  • 813
  • 814 is a discussion how to do the upcoming (first) release (version 0.2.0)

That's it for today, I guess.

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

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 17th iteration on whats coming up in imag, 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.

The past

I posted an article about how I organize my 0.x.y releases.

Now lets see what happened in the past 14 days.

Despite me not beeing on vacation in the last 14 days (surprise!), we didn't manage to get this much done. But at least we got some things done.

PRs merged/closed in the last 14 days

  • 767
  • 770
  • 774 adds copyright- and license-notices at the beginning of all files.
  • 772 adds tests for error-returing store hooks.

PRs opened in the last 14 days and not yet closed

  • 764 adds imag-mail based on libimagmail.
  • 771 implements utility functions to be used with the clap “validator functions” feature, so they can be used to verify commandline input.
  • 775 adds readline support in libimaginteraction, so one can use readline to ask the user for data.
  • 783 rewrites the README.md file of the repository.

Issues opened and already closed

The future

Issues opened and not yet closed

  • 765 started a discussion about whether the linking-feature should be extended for a link-annotation feature.
  • 766 started a discussion about caching. Thanks you for the issue, Julian!
  • 768 asks for better documentation of the linking feature. Thank you again, Julian!
  • 773
  • 776
  • 777 asks to reduce the use of foo.fold(Ok(()),... and replace it by fold_defresult or similar helper functions we have in the codebase.
  • 778 asks for a refactor of the FromStoreId trait that is defined and used in libimagdiary.
  • 779 asks for a refactor of libimagentryfilter.
  • 780
  • 781 asks for updating all dependencies of imag.
  • 782 asks for changing the libimagstore::store::Store interface to be non-consuming where possible.
  • 784 asks for refactoring the libimagstore::store::EntryHeader type. This is actually a really complex issue which might be solved in several PRs rather than in one step.
  • 785 asks for a imag mv feature, with some functionality like mv, but also some functionality to move store entries. Thank you again, Julian!

Other things

I finally started my masters degree this week and I guess I will have a rather high workload in this semester, so I really hope I'm able to do some imag things.

Doing the 0.2.0 release within this year (it is planned to happen before 31.12.2016) should be possible, though we will see whether the 3-month-cycle for the next releases I announced in the blog post about my release strategy will be possible.

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

Another 14 days vanished quickly as hell. Despite my one-week trip to the Dolomite Alps, I got a hell lot of things done.

Read it up here, in the 16th iteration on whats coming up in imag, the personal information management suite for the commandline

The past

I published a crate imag on crates.io to claim the name "imag" – it doesn't contain anything by now – I only created it to claim the name and therefor is published in version 0.0.0. As version 0.2.0 should be published within this year, this will soon change. I do not yet have any ideas how to publish a multi-crate project on crates.io, though.

(If you wonder why I jump from 0.0.0 to 0.2.0 – I already had a really early release of imag, 0.1.0, which had some minimal functionality. After that, I started a big rewrite and rewrote the complete codebase, because the initial foundations and core infrastructure was just not well done.)

We also had a small contribution from Julian Ganz, thank you very much!

PRs merged/closed in the last 14 days

Here are the closed PRs from the last 14 days. The range also includes some PRs that did not yet hit the master branch, as they are from another long-running PR which introduces some tests for libimagstore (and fixes for bugs from that library).

  • 486 – finally! Git support! This PR merged the initial git hook support, so the store is now git version controlled. While this is fundamental git support (and was a rather long-running PR), more PRs will come and add additional features. The following PRs were involved in this PR:

  • 729

  • 730 introduced matrix builds with travis, to have faster build times.

  • 734 introduced more Makefile targets, so one can execute tests via the makefile now.

  • 741

  • 742

  • 751

  • 756 introduced an option in the configuration file to disable git hooks.

  • 757 reverted a feature from the initial git hook support which was broken.

  • 758 fixed that git created empty commits if no change was made to the contents of the store.

  • 760

  • 762

  • 763

PRs opened in the last 14 days and not yet closed

Some PRs from the last 14 days are not yet closed:

  • 750
  • 759 introduces a new feature so that the commit for a change in the store is made when the store is closed, that leads to less commit noise in the repository.
  • 761

Issues opened and already closed

We did not open that much issues in the last 14 days, but anyways some are already closed:

The future

What's coming up in the future?

Issues opened and not yet closed

Lets have a look at the issues we opened and did not close in the last 14 days, we clearly want to close them in the next 14 days:

Other things

Well... I have about two weeks left until my semester starts again, so two more weeks to get some stuff done. After that, I guess, development will slow down a bit. Hopefully not much, but enough so I can get good grades in my masters degree.

I'm almost done with the 0.2.0 milestone, so the first release for imag could happen in the next two weeks. We have 83% already done and only soft-required things left, so theoretically we could release in this very moment. Though, I'd like to at least merge the store tests before we do 0.2.0.

Also I'm really thinking about release-strategy and also how to do the release.

Strategy before 1.0.0 would be to simply git tag a commit on the master branch and declare that as release. After that I guess I will create version branches, but as a 1.* release is far away in the future, I don't think too hard about it.

The second thing is – how to release this crate on crates.io? I mean... imag is a crate with multiple root crates and also multiple crates in one repository. I already asked on reddit but I'm not sure the answers fit my problem. All these crates have one root crate which depends on all other crates in the repository. imag does not have that – in the imag repository, each imag-* directory is a root crate that depends on other crates from the repository. And the bin subdirectory also contains one.

I'm not even sure whether it is actually possible with cargo to publish this setup on crates.io.

Maybe I should ask in the cargo IRC channel on this specific subject.

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

Another 14 awesome days in the imag codebase

A lot has happened in this 14 days, despite I first thought it wouldn't be this much. Read up here what progress we made, implementing the PIM suite for the commandline – imag!

The past

Lets have a look at the last 14 days. As said, a lot of things happened – more than I thought could happen, actually.

PRs merged/closed in the last 14 days

Here goes a list of the merged and closed pull requests from the last 14 days, the more important ones are annotated:

  • 670
  • 672
  • 691 was a PR on 635
  • 673
  • 674 disabled the debug output on travis.
  • 675
  • 692 adds a helper for Result types to automatically trace() errors when mapping over them.
  • 693
  • 694
  • 695
  • 696
  • 706
  • 707
  • 708 fixed the imag-link testing code.
  • 709
  • 710
  • 712
  • 713
  • 717
  • 718 was a PR on 635
  • 719
  • 720 superceeded 719
  • 721 was a PR on 486 and implemented the UpdateHook for the git hook implementation. Finally making progress there!
  • 722 was a PR on 721 to refactor the hook
  • 723 is a PR on 486 and fixed the hook implementation for the CI servers, so the tests run successfully now. code a bit.
  • 725

The following PRs were PRs towards #667 – the rewrite of the StoreId type.

PRs opened in the last 14 days and not yet closed

Here is a list of pull requests we have opened in the last 14 days but are not yet merged.

I hope they will land soon.

Issues opened and already closed

We also have a few issues that were opened and closed within the last 14 days:

The future

And now,... what's coming up in the next 14 days.

Issues opened and not yet closed

The bunch of issues we have opened but didn't manage to close, yet. There are more than expected, actually.

git hooks!

Well, well...

I'm working heavily on the git hook implementations, this is cooking for way to long now. The basics are already working, though. One can commit changes to the store with a default message which is set in the configuration file (no commandline yet, though the --override-config flag should work – at least I cannot see why it shouldn't). One can also commit via the commandline (interactive) by either using the editor or by typing on the commandline directly, though there only a single line is supported.

What I want to implement in the basic git hook support:

  • When a file is created, it should be added to the repository (done)
  • When a file is removed, it should be removed from the repository

What I want to implement as soon as possible:

  • When a file is moved, it should be moved in the repository
  • A user might want to select, what entries in the store should be committed automatically with a commit message from the configuration, and what things she wants to commit herself.
  • If there is no repository in the store, it should be created automatically. If there are entries that are not yet added, but are not part of the update hook (so they are not in the repository and we are currently working on another entry) the user should at least get a warning. Even better would be if the user could decide whether the entries should be committed automatically or whether they should be left alone.

Other things

Another week of vacation.

Yes, I'm on vacation again from September 10th until September 19th (or maybe 20th). There will be no merges in this time, but you are all welcome to open PRs or issues and of course I will answer and review as soon as I'm back.

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

As I wrote in the last iteration on what's coming up in imag, I was on vacation from Tuesday, August 16th until Sunday, August 21th, so there was little progress in this period.

Anyways, we got some things done. Read about it here, in the 14th iteration on what's coming up in imag, the personal information management suite for the commandline.

The past

First, lets have a look at the past.

Issues with the compiler

This is actually the first time I have issues with the compiler that broke my build. The beta compiler fails due to some regression. We therefor allow travis to fail the beta compiler job.

There is already a PR for reverting this change, so we build imag on beta as soon as the beta compiler was released with the fix for this issue.

PRs merged/closed in the last 14 days

These PRs were merged or closed unmerged in the last 14 days.

  • 479 – We do not need a LGPL checker in my opinion. The LICENSE file should be enough.
  • 502
  • 510
  • 638 was reopened in 656
  • 646 rewrote the Makefile.
  • 648 rewrote the libimagentryfilter crate by using the filters crate – thank you, impo!
  • 649
  • 650
  • 651 added github pages with the documentation for all crates imag depends on (of course the imag-* binaries are not documented in here, but all libimag* crates are). Finally!
  • 652 allows travis to fail the CI builds with the beta compiler, as written above.
  • 654
  • 659
  • 661 adds some documentation for the github pages.
  • 665
  • 666
  • 669

PRs opened in the last 14 days and not yet closed

These PRs were opened in the last two weeks and are not yet closed.

Issues opened and already closed

There was only one issue which was opened in the last 14 days and is already closed:

  • 647 – Rewrite the libimagentryfilter helper with the filters crate
  • 668

The future

Things that come up for the next two weeks.

Issues opened and not yet closed

These issues were opened in the last period, but are not yet closed. Of course we want to close them as soon as possible.

  • 653 – As described above, we ran into an issue with the beta compiler and disabled the travis checks for them. This issue is a tracking issue for reverting this patch.
  • 658 asked whether to disable the debug output in travis. We agreed that we do not want the debug output anymore in travis, so this turned into a tracking issue.
  • 660
  • 662
  • 663
  • 664

Other things

I declared my goals for the rest of the year. I really want to release version 0.2.0 of imag within this year, but some thing have to be done beforehand:

  1. Fix the StoreId problem
  2. Implement the git hooks (which requires the fix for the StoreId)
  3. Fix imag-notes edit which seems to be broken
  4. (optionally) Have a minimal working mail module
  5. (optionally) Cleanup imag-diary/libimagdiary a bit

Some more required (hard or soft) and optional things can be found in the milestone for this release I created.

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

When we designed the imag core functionality – the imag “Store” – we introduced a type called StoreId.

It turned out that the way we designed this type was a big mistake and turned out to be the first big imag design flaw by now. With this post I try to wrap my head around possible solutions to this flaw.

What is this about?

So we wrote the StoreId type. It is a wrapper around std::path::PathBuf, so it is basically a path. We wanted it to be the path to a store entry, but it should be absolute to the store root itself. So a valid StoreId object could be "note/car" – it would uniquely identify a file in the store. We made the StoreId also contain a version part, to be able to write imag modules which could check their data for compatibility with the current version of the library.

The Problem is that we just wrapped the path type. A StoreId can be created from any PathBuf and even from any String – which clearly is not the way it is supposed to be.

We didn't use the type system enough. We should have designed this type more carefully. Lessons learned, I would say.

I know that I should write I messed up, but as the StoreId type was also designed by my friend Marcel, I use the term we.

How to clean this up?

Well, this is the hard part. As we do not have a release yet, we do not have to be backwards compatible, so there is no problem with that.

Anyways, we need to rewrite a lot of code to fix this design flaw. As imag gets more momentum in the rust community, this gets more important. This design flaw is actually blocking some other things, as we cannot rely on the properties of the StoreId as we should be able to.

One idea is to rip out the StoreId type completely and redefine it. In my opinion, a StoreId should only be constructed by the Store, upon request by the store user. That means that the user should be able to store.new_id("module", "path/to/entry") which then creates a new StoreId that points to $STORE/module/path/to/entry. That would be a clean way. The StoreId type then may contain functionality to create, retrieve and get and maybe even delete the entry it points to (so it contains a reference to the actual Store object internally).

I'm still not sure about the details. As said, I try to wrap my head around this problem with this very article.

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

Ten days ago I published another crate on crates.io - the 'filters' crate.

Its source code was partially extracted from imag. In this article I want to show you what you can do with it as well as list some things that should be improved.

How to Filter<N>

First of all, Filter is a generic trait. It can be implemented for a wide range of things, of course, but is implemented for all T: Fn(&I) -> bool. It requires one function: Filter::filter(&N) -> bool to be implemented. This function should hold the predicate definition. So you can do something like this:

use filters::filter::Filter;
struct EqTo {
    pub i: usize,
}

impl Filter<usize> for EqTo {
    fn filter(&self, n: &usize) -> bool {
        self.i == *n
    }
}

fn filter_with_eqto() {
    let eq = EqTo { i: 0 };
    assert_eq!(eq.filter(&0),  true);
    assert_eq!(eq.filter(&1),  false);
    assert_eq!(eq.filter(&17), false);
    assert_eq!(eq.filter(&42), false);
}

in your codebase. Of course, that is a lot of boilerplate code for simply filtering something for beeing equal to a number, right? That's why we implemented it for all T: Fn(&I) -> bool – you can boil down the upper example to this:

fn filter_with_eqto() {
    let eq = |&a: &usize| *a == 0;
    assert_eq!(eq.filter(&0),  true);
    assert_eq!(eq.filter(&1),  false);
    assert_eq!(eq.filter(&17), false);
    assert_eq!(eq.filter(&42), false);
}

And/or/not now?

This does not yield any code abstraction improvements yet. But the Filter trait has also has some more functions which are already implemented for you: and, or, not and so on.

This is where the other types from the crate come into play: There are types available which implement logical operations using the Filter trait. And the functions from the trait itself use them so they are convenient:

fn filter_inside_range() {
    let zero = |&a: &usize| *a > 0;
    let hund = |&a: &usize| *a < 100;

    let f = zero.and(hund);

    assert_eq!(f.filter(&0),  false);
    assert_eq!(f.filter(&1),  true);
    assert_eq!(f.filter(&17), true);
    assert_eq!(f.filter(&100), false);
}

And of course you can chain them:

fn filter_inside_range() {
    let zero = |&a: &usize| *a > 0;
    let hund = |&a: &usize| *a < 100;

    let f = zero.and(hund.not()).not().or(true);

    assert_eq!(f.filter(&0),  true);
    assert_eq!(f.filter(&1),  true);
    assert_eq!(f.filter(&17), true);
    assert_eq!(f.filter(&100), true);
}

As shown above, we also implement Into<Bool> for bool so you can easily provide default values for your filters.

What this crate is for

This crate was designed for imag, but should prove helpful elsewhere, too. It was written to be able to construct complex filters based on user input. For example if your application has a commandline interface which allows the user to specify predicates and logical operators, you can use this crate to build these filters and connect them.

That is also exactly the usecase for imag, by the way.

Issues

There are two remaining things I want to implement in the codebase. The crate is usable as of the time of writing, but I also want to do the following things:

  • Implement BitAnd, BitOr, ... etc for all filters. With this, one could do (written in short now) (|a| a > 1) & (|b| b < 5) – using bitwise operators to make these things even nicer.
  • Provide a possibility to use a Filter as function, so one can do myvec.iter().filter(foo) instead of myvec.iter().filter(|x| foo.filter(x))

These issues are posted in the github repository of the crate and of course you are welcome to help out.

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

Another 14 days – a lot has happened in the repository of the imag codebase, the commandline personal information management suite written in Rust.

Read a summary of the last two weeks here, in the 13th iteration on what's coming up in imag.

The past

Lets see what was done in the last 14 days.

Website, IRC, mailinglist!

First: The important things!

We have a website now! Meet us at imag-pim.org. We also have a git mirror there.

So if you want to contribute to imag but you do not have a github account or you do not want to contribute via github, you can ask me for a repository on the git repository on our website and contribute via mail or via this repository. I will push your patches to github PRs anyways, because of our CI server, but you do not have to interact with github at all. For details, read our CONTRIBUTING file.

We have an IRC channel now! Since 1st of August you can join irc.freenode.net/#imag and talk to us/me directly!

The channel has a bot (nick “imagned”) running which can be used to log discussions. It is a sopel bot, see the page on the “meetings” module for documentation how discussions can be logged.

We have a mailing list now! Since 2nd of August you can join our mailinglist and talk to the imag community via it. Of course, there are few mails posted yet, as this list is really new.

We accept patch mails via this mailinglist as well! Make sure you've read the CONTRIBUTING guide before submitting patches.

Numbers!

We reached the 100 stars on github! Awesome! Thank you all for this! We are reached the 2,500 commits and we reached 400 closed PRs!

New contributors and integration of the first external tool!

Besides that, we have merged #383, which was a huge one. It implements libimagtodo and imag-todo, using taskwarrior hooks to store references to taskwarrior tasks in the imag store. This allows us to refer to tasks created with taskwarrior from within imag. imag-todo is therefor the first imag module using an external tool to implement the PIM aspect it covers. This is huge! I hope this is the first step into the direction of multiple backends as well.

The PR was created as semester project at Hochschule Furtwangen University and therefor contains commits from several contributors (in alphabetical order):

I did some cleanup in this PR as well as some restructuring. So it was joint work. Because of this, the shortlog tells us the following:

  • 52 commits from Mario
  • 51 commits from me
  • 6 commits from Yasemin
  • 4 commits from Sascha
  • 2 commits from Roman

Thanks a lot for your contributions!

Other contributors were:

Thank you a lot, too! I also want to thank Julian Ganz and Pascal Hertleif for contributing ideas and participating in discussions on issues.

PRs merged/closed in the last 14 days

We had a lot of small PRs in the last 14 days, fixing one or two things. This is truely awesome, but the list for PRs is even longer than from last week. I will only add notes to the bigger ones here, I guess I if this trend continues I will start to list only the noteworthy PRs in the future.

But here we go, with the full list of PRs and some of them explained or with an additional note.

  • 383 (explained above)
  • 594 added an utility to print debugging information while map()ing over Results or Options.
  • 595
  • 597
  • 598
  • 599
  • 600
  • 601 updated the user documentation a bit.
  • 604
  • 605
  • 607
  • 608
  • 609
  • 610 added an EditorView in the libimagentryview library, so one can now view entries with the $EDITOR.
  • 611 fixed a serious locking bug in the libimagstore library.
  • 612 added support for --no-color output in libimagrt (so all modules get it automatically).
  • 613
  • 614 added a TableLister type for libimagentrylist – not tested yet.
  • 616
  • 617
  • 620
  • 621
  • 622
  • 623
  • 630
  • 631
  • 633
  • 634
  • 636
  • 640
  • 641 fixed our travis setup and shortened build times from up to 50 minutes down to about 30 minutes.
  • 642
  • 643 outsourced editor-calling code from libimagrt into the new library libimagentryedit.

PRs opened in the last 14 days and not yet closed

Issues opened and already closed

These issues were opened and are already closed:

The future

Lets see what the future will bring us.

Issues opened and not yet closed

First of all we have a bunch of new issues which are not yet closed.

  • 602 asks whether we can remove the version part of the StoreId.
  • 618
  • 628
  • 629 asks for an explicit subcommand with imag-todo to import the task export exported data from taskwarrior.
  • 637 asks for a feature in libimagref so we can only hash the first N bytes to speed up both hashing and refinding of entries (which is untested btw).
  • 644

Issues reopened

I reopened issues #2, #3, #4 and #5, which ask for a contacts-, calendar-, mail- and wiki-module respectively. Unfortunately, there is no vcard/icalendar crate for rust available. There is vobject, but this is a very basic abstraction over the filetypes. I would need something more complex and powerful, which has a lot capabilities and hides the file format in nice abstractions. For example, if I want to check whether two calendar entries collide somehow, the library should be able to check whether the entries are recurring and whether they collide some time in future ... or the contact library should offer a simple interface for querying numbers, mail adresses, adresses, names and so on. With the vobject crate I would need to implement all these things on my own – I really don't want to do that right now!

Also, I would need a library to read mails from a Maildir for the mail module. There is mailparse – I'm not sure whether it fits my needs, though.

For the wiki part I don't need anything besides markdown parsing capabilities, and I guess I already have them. I would implement the wiki module with the libimagref library, which can then be used to ref to existing wikis such as vimwiki. I'm not sure whether this is the proper way to do this, though.

Other things

Vacation! I will be on vacation from Saturday August 13th until Tuesday, August 23th. I will be at the Summerbreeze Heavy Metal Festival (feel free to meet me there!) from Tuesday, August 16th until Sunday, August 21th, so there will be no commits in this timerange (at least not from me) and of course no merges.

Because of that I'm pretty sure that the next iteration on imag will be a short one – but well, I guess I deserve a break from my bachelors thesis which is almost finished.

And also because of this, I do not have any plans for the next 14 days. Lets see what comes up... lets hope something great! Maybe some new contributors...

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

Yesterday I got asked what the usecases for imag are. I tried to explain it and afterwards thought about it the whole night.

I already wrote about the purpose of imag, but I guess some usecases would explain even better what imag is for.

So now I try to explain three usecases for the imag commandline personal information management suite.

Please keep in mind that these are the usecases how I would describe them as final goal of imag. None of the following is implemented and all of this is music from the future! But that's the ultimate destination of the project.

Go shopping for me.

You get an Email from Sally. A hook script informed imag, so it already knows about the mail, has fetched the contact information from the email header and linked the email to the vcard of Sally. In the mail, Sally asks you if you want to cook with her and if yes, you should buy eggs. You type in a shortcut to call imag. You tell imag that you want to create a new shopping-list. imag creates a new shopping list. Because you called it from a mail, it asks you to link this mail. After you created the shopping list, imag creates a task in your todo tool for you. It asks you whether you want to create a calendar entry for the shopping list.

Later you add things to the shopping list. You add potatoes and sweet chestnuts. imag recognizes the change in the shopping list. It notices that you had similar shopping lists that contained Eggs, potatoes and sweet chestnuts and that they were linked to a recipe. Imag asks you whether you want to link that recipe to the current shopping list.

After you went to the mall, you type the cash slip into your ledger. imag recognizes that you bought stuff you had on a shopping list that isn't marked as done yet and therefor asks you whether the shopping list can be marked as done. You mark the shopping list as done. imag links the ledger entry with the shopping list. imag asks you whether it should mark the linked todo entry as done for you. Yes, you want to close this todo entry. Because you went shopping before the calendar entry, it asks whether it should delete the calendar entry for you. You delete the entry. imag recognizes that you linked an email – but no response for that email exists. So it asks you whether you want to reply to Sally. You reply to the mail and tell Sally that you buyed the things and you'd love to come over and cook together.

You query imag for that recipe imag told you about and add it to the mail, asking Sally whether this would be appropriate. imag has already linked your response to the original mail from Sally. imag also linked the recipe to your response. imag recognizes that there are notes attached to the recipe and asks you whether they should be in the mail as well.

You type in another shortcut to create a new calendar entry “Go to Sallys, cook with her”. imag links that calendar entry. imag recognizes “Sally” in the subject of the calendar entry and asks which Sally from your contacts should be linked to the calendar entry.

New contacts and a party

You were at a party and met Amelie. You add her contact information to your contact application. imag knows that contact now, too. You tell imag that you met Amelie at the calendar entry for yesterday evening. imag links the contact with the calendar entry from yesterday evening. Because the calendar entry is linked with a location and the website of the club, imag knows that these pieces of data are in relationship with eachother.

A few weeks later you're typing an email to Dave, asking whether he would come with you to the club. You query imag for the website of the club. imag links that email with your bookmark of the website of the club.

Your friend replies yes (imag links the reply with your mail), so you add a calendar entry. imag recognizes that you linked the website of the club and a calendar entry with mails between you and Dave. It asks you whether it should show you other contacts that are somehow in relation with calendar entries that are related to the bookmark of the club. You find out that you met Amelie some weeks ago at this club. You invite her, too.

Further, imag tells you that it knows from your ledger that you spend around 50 bucks last time you had an event that was linked with that club (on cola and water, of course). It also knows that you have about 20 bucks in your pocket right now. imag asks you whether you want to create a task “Go to bank”. Yes, you want that. imag finds out that you have time tomorrow at 4pm and asks you whether you want to create a calendar entry for this at that time. Yes, you want that. Because the other calendar entries from tomorrow are linked to locations downtown, imag infers that you are in this location and finds the best bank nearby for you, asking you whether that location should be linked to the calendar entry.

Business, Business!

You get an email from your boss, she tells you that you have to fly to another country tomorrow, to attend an important meeting with a customer. She sends you a icalendar file containing information about the flight. imag already knows that this calendar entry has to go to your business calendar, because the mail was from a contact from your business contacts.

You add the calendar entry via a shortcut from your mail client to your business calendar. imag recognizes that this is a business trip and asks you whether it should search for packing lists. It could also create a todo for you “Pack things for business trip” and link the packing list to it. Hell yeah, you want that!

Because all your flights are linked to a location that is about 50 miles away from your home, imag asks you whether you want to create another calendar entry “Drive to Airport” right before the flight. Of course you want that. Because there is another calendar entry which collides with the trip to the airport, imag asks you whether you want to create an email to the contact linked to that calendar entry. imag has already figured out an alternative date for the meeting you have to postpone.

You might call me crazy, but yes, that is exactly the way imag should work in the end. Of course, this is far far away in the future as of now, but I do not think that it is unachievable!

How the interaction with imag works in detail is not described here, of course. I don't know it! It will grow with the project. Maybe all the above will be done via commandline calls, maybe there will be some fancy curses UI or maybe there will even be a web frontend (though this is less likely).

imag is a tool for nerds, from nerds. So it will require some scripting and fiddling to get imag integrated in all the tools. imag tries to provide a convenient interface for all these things, but not a out-of-the-box solution (maybe in 10+ years, but it is not a short- or mid-term goal).

I hope that these use cases explained some things and helped you understanding the purpose of imag.

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

imag just got a website, a mailinglist, a git repository setup and an IRC channel.

So I wanted to set up a website for imag for months already, but I finally got to it. I actually developed the website offline and it was almost done, and now it is online.

I wrote the website using nanoc, a static site generator. I used nanoc before and I also contributed some code to nanoc, so I already knew what to do and how to do it. I wrote a minimal theme for the website, I wanted to have it plain-text-ish, as imag itself is a plain text tool.

I managed to register an IRC channel on the freenode irc network, which is awesome. travis was set up to post to this IRC channel if a build succeeds or fails which is really convenient as well.

Of course we also have a mailinglist now. One can register there to contribute patches via mail and to ask questions. Of course there's not that much on the mailinglist yet, as we do not have a community around imag, yet. Anyways, there's the possibility to build one now, which is awesome, I guess!

Background

So what's running in the background here?

I registered a space at uberspace where also this very website is hosted, set up a gitolite and a cgit webfrontend for the git repositories.

The mailinglist is run by ezmlm, which was written by djb and is very well documented how to setup on an uberspace.

The domain was registered on united-domains.de.

Costs

Well, I pay these things from my own money (I can make some money this summer working at my university, so that's not a big problem).

Currently, I pay 19 Euro per Year for the domain and 2,50 Euro per Month for the Uberspace, but I will increase this as soon as there are more contributors on the git hosting or on the mailinglist (as soon as my setup causes actual workload on their servers) or as soon as I have a job, whatever comes first.

So that makes it 49 Euro per year with the current setup, which is affordable for me. As soon as I increase the monthly fee for uberspace (I will go to 5 Euro if I make my own money and no contributors and more if there are contributors), this will cost me 100 Euro per year if I give uberspace 6.75 Euro per month. Still not much, I guess.

As soon as I have to pay more than 100 Euro per year I guess I will add a “support this project” button on the website ... or something like this. Well, we'll see...

tags: #linux #open source #programming #rust #software #tools #imag #git #mailinglists #network #social