musicmatzes blog

programming

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.

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?

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

I just released my task-hookrs crate in version 0.3.0!

Here's what changed.

This release was made because I could update the serde dependency to 0.9, which gave me the ability to remove tons of code:

$ git diff --shortstat v0.2.2..v0.3.0
11 files changed, 126 insertions(+), 492 deletions(-)

because we now have custom derive! So I could remove my custom implementations for Serialize and Deserialize.

v0.3.0 also has some changes in the API, so not another 0.2.x release. This release pins the minimum compatible compiler to rustc 1.15, too.

So, all in all, this release really was a step forward from my point of view.

tags: #programming #software #open-source #tools

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.

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?

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

I just found the website githubreportcard.reflect.io which generates github user statistics for 2016.

I went ahead and tried it out. And hell yeah, 2016 was a productive year!

Of course, I worked a lot on imag, which resulted in a lot of changes. But I also did other things in 2016... and guess what? Rust is not the language I wrote the most code in – at least not by repo count!

So let me show some of my numbers:

“This year I made 3,438 commits across 40 GitHub repos in 12 languages.”

12 Languages? Well... yes! I don't know what these languages are, but here are some of them listed (ordered by number of repositories I contributed to): TeX, Rust, Shell, Ruby, C, Racket, Nix, Unknown, PHP. Yes,... “Unknown” is also there, I'm not sure what this is, actually.

Let me show some more numbers:

My Additions – 151,411 My Deletions – 92,512 My Open Source Changes – 95,290

Hell yeah! 151.411 lines of code? Holy sh!t! That's huge, isn't it? I'm not sure where this all comes from ... a huge portion must be from imag. Thinking of some repositories I also deleted in 2016 because they where old... this number might be even higher!

While I guess that 2017 won't be as productive as 2016 (because masters degree, blabla ... you know it – and because a long journey which is planned in summer), I really hope I can have a decent statistic at the end of this year as well.

Enough of me – what about you? What's your github graph of 2016 like?

tags: #github #life #open-source #software #programming

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.

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?

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

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.

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

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

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.

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

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

I could not think of a better title, I'm sorry.

These are notes how to create a kernel which can be booted in qemu and pass a drive to it which has loadable kernel modules.

The idea

I wanted to play around with the linux kernel and write a minimal filesystem inside the kernel tree. I wanted to boot the kernel in a QEMU, as I do not want to mess with my running kernel.

Here are the steps I did (on a debian VM I run on my universitys infrastructure).

Setup

sudo apt-get install build-essential bc git gcc
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
make x86_64_defconfig
make kvmconfig
make menuconfig

The last step brings up the kernel configuration interface, which I used to enable SATA (Device Drivers -> Serial ATA and Parallel ATA drivers (libata) -> Generic ATA support) support which is needed to be able to mount a device into the qemu instance, where we can put things to play around with in the VM.

I then did a make -j 16 (if you have not 8 cores, use a lower number).

While the kernel compiled, I created a busybox initramfs. I used this blog article for how to do it. I'll dump in the commands from the blog article, for detailed information, go and read it, it's a really good article. I didn't do the speed-optimizing things, as the QEMU boots fast enough for me (~3 seconds).

(I used the latest busybox, but I don't see why it should work with the one from the article, which is about two versions old)

curl http://busybox.net/downloads/busybox-1.23.2.tar.bz2 | tar xjf -
cd busybox-1.23.2
mkdir -pv /tmp/obj/busybox-x86
make O=/tmp/obj/busybox-x86 defconfig
make O=/tmp/obj/busybox-x86 menuconfig # See below why
cd /tmp/obj/busybox-x86
make -j 16

# it does not install in your system, so you can execute this without fear
make install

mkdir -p /tmp/initramfs/x86-busybox
cd /tmp/initramfs/x86-busybox
mkdir -pv {bin,sbin,etc,proc,sys,usr/{bin,sbin}}
cp -av /tmp/obj/busybox-x86/_install/* .

# now edit the init script
vim init

You have to enable busybox build as static binary (with the menuconfig part).

The init script I use:

#!/bin/sh

echo "INIT SCRIPT"

mount -t proc none /proc
mount -t sysfs none /sys
mount -t debugfs none /sys/kernel/debug

mkdir /tmp
mount -t tmpfs none /tmp

mdev -s # We need this to find /dev/sda later

echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"

exec /bin/sh

The init script boots into a /bin/sh. We can now build the initramfs with it:

chmod +x init
find . -print0 \
    | cpio --null -ov --format=newc \
    | gzip -9 > /tmp/initramfs-busybox-x86.cpio.gz

Try it out (1)

Now we can try it out, whether the kernel boots and we get out shell:

# In the kernel tree:
qemu-system-x86_64 \
    -kernel arch/x86_64/boot/bzImage \
    -initrd /tmp/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0"

We should see some output like this:

[...]
[    7.170702] Freeing unused kernel memory: 1200K (ffffffff81f55000 - ffffffff82081000)
[    7.171539] Write protecting the kernel read-only data: 14336k
[    7.177328] Freeing unused kernel memory: 816K (ffff880001934000 - ffff880001a00000)
[    7.219360] Freeing unused kernel memory: 1116K (ffff880001ce9000 - ffff880001e00000)
INIT SCRIPT
mount: mounting none on /sys/kernel/config failed: No such file or directory
mount: mounting none on /tmp failed: No such file or directory

Boot took 7.33 seconds

/bin/sh: can't access tty; job control turned off
/ # [    7.630681] input: ImExPS/2 BYD TouchPad as /devices/platform/i8042/serio1/input/input3

/ #

(Yes, the output is slightly messed up... but hey! We just booted a linux kernel in a QEMU!

Load the kernel module

We can now create a kernel module in the linux kernel tree:

# In the kernel tree
git checkout -b my-module
mkdir fs/iamcoolfs/ # because I like filesystems
cat <<EOS > ./fs/iamcoolfs/Kconfig
config COOL_FS
        tristate "COOLFS support"
        help
          Private FS for playing and learning FS programming

          This will definitively eat everything you put into it.

EOS
cat <<EOS > ./fs/iamcoolfs/Makefile
#
# Makefile for the linux mb-filesystem routines.
#

obj-$(CONFIG_MB_FS) += coolfs.o
EOS
cat <<EOS > ./fs/iamcoolfs/coolfs.c
#include <linux/init.h>
#include <linux/module.h>

static int __init coolfs_init(void)
{
        pr_debug("cool module loaded\n");
        return 0;
}

static void __exit coolfs_fini(void)
{
        pr_debug("cool module unloaded\n");
}

module_init(coolfs_init);
module_exit(coolfs_fini);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("<YOUR NAME GOES HERE>");

EOS

This creates all the files we need for a minimal module. Because I like filesystems and I really want to implement a minimal filesystem, I chose to create the files in ./fs, but I guess it shouldn't matter.

Make sure you adapt the fs/Kconfig file to find your new module! Put

source "fs/coolfs/Kconfig"

into it.

Now you can execute make menuconfig and find the configuration option for your new module. We can also simply make M=fs/coolfs to build the module. Now we create a (ext2) disk where we can cp the module to, so we can mount that disk into our QEMU and use the module there:

dd if=/dev/zero of=/tmp/disk bs=4M count=100
sudo mkfs.ext2 /tmp/disk # you could also try ext4, for example
mkdir /tmp/disk-mount
sudo mount /tmp/disk /tmp/disk-mount
cp fs/coolfs/coolfs.ko /tmp/disk-mount/
sudo umount /tmp/disk-mount

Try it out (2)

And when we boot our QEMU now with -hda /tmp/disk, we can find /dev/sda in the booted instance and mount that:

# In the booted VM
mkdir sda
mount /dev/sda ./sda
ls sda

Happy FS dev!

tags: #c #linux #open source #programming #software #testing #kernel

I managed to break one of my codebase (the master branch) without even touching it.

If you think about, the “issue” I ran into is trivial. It really is. Though, I want to write about it because often, these things get too little attention in my opinion.

So what did I do?

I maintain this project task-hookrs. The project itself depends on a few other crates. I updated these dependencies and then released a new version of my crate.

The rewrite included some lines which I had to change, not a big deal actually. One of my dependencies, namingly serde had a breaking change from 0.7.* to 0.8.0 which resulted in a small rewrite of a portion of my code. No functionality was changed, though.

I released 0.2.2 after the dependencies were upgraded. The last version before that version was 0.2.1. And despite me not changing any functionality, the micro-release was a mistake. Not because API changes (which I didn't have) but because of link-time dependencies.

My other project, imag dependes on task-hookrs, but the dependency specification states task-hookrs = "0.2" (note the missing .1 at the end). When the master of imag got rebuild, it failed because imag itself depends on uuid = "0.2", whereas task-hookrs now depended on uuid = "0.3" – the linker failed because the types I passed from imag to task-hookrs were different.

Fuck.

What did I do? Well, I updated uuid in imag as well, everything solved. But that really got me thinking. What I should have done: Updating the minor version (0.2.1 -> 0.3.0).

We talk a lot about breaking changes in APIs and such, in fact this is why we introduced semantic versioning in the Rust community. What we do not talk about is that dependencies are also relevant when updating. Even the semantic versioning website states:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Which clearly states that MAJOR version when you make incompatible API changes – though nobody tells you that updating a dependency of your library might also be a incompatible API change!


After all I'm (kinda) safe here, because the semantic versioning spec also contains the following:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

So nobody can blame me. Although this really bugs me and it really shouldn't have happened.

tags: #programming #open source #software #testing

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