diff options
authorMatthias Beyer <>2017-01-25 19:59:01 +0100
committerGitHub <>2017-01-25 19:59:01 +0100
commit55ea7f8228481a4859b1c2d34f9347b7cd35ee8e (patch)
parent0a417aa3c6b599f067284ed1628d7e3fc5e9a44e (diff)
parent0748146a3b54848b57837d56f79e579bafdbb45a (diff)
Merge pull request #869 from matthiasbeyer/readme-updates
Readme updates
2 files changed, 16 insertions, 38 deletions
diff --git a/ b/
index 779839e..f82d999 100644
--- a/
+++ b/
@@ -44,11 +44,9 @@ give you a commandline application.
### Building
-We use `make` to automate the build process (as `cargo` is not (yet?) able to
-build several applications at once).
-Make sure to _not_ include some `-j 8` arguments, as cargo parallelizes the
-build process on its own. If you parallelize it with make, you end up with a
-really high load on your system.
+We use `make` to automate the build process.
+Make sure to _not_ include some `-j 8` arguments, this will _not_ work as you
+might think!
There are several targets for each of the sub-crates in the Makefile:
@@ -66,7 +64,7 @@ There are several targets for each of the sub-crates in the Makefile:
| update | * | Run `cargo update` | `make update` |
The `Multi` targets are callable for each sub-crate. For example you can call
-`make imag-bookmark-check` to run `cargo check` on the `imag-bookmark` subcrate.
+`make imag-store-check` to run `cargo check` on the `imag-store` crate.
### Running
@@ -86,8 +84,7 @@ There is no RSS feed, though.
We also have a [mailinglist]( where I post
updates and where discussion and questions are encouraged.
-There is a blog series which gets a update every other week
-on my blog, where
+There is a blog series which gets an update once a month on my blog, where
[entries are tagged "imag"](
I also post non-regular posts about imag things there.
@@ -105,7 +102,9 @@ which can be compiled to PDF or a website.
These docs are not published anywhere and are not even integrated into our CI,
so it might be broken (though it's unlikely).
Developer documentation is also available
-[online on](
+[online on](
+and [on](, though they might
+be a bit outdated.
## Please contribute!
diff --git a/libimagruby/ b/libimagruby/
index 2f761fb..b11cc5c 100644
--- a/libimagruby/
+++ b/libimagruby/
@@ -56,8 +56,6 @@ But I hope we get it in travis soonish.
This crate will contain both the Rust bindings for imag using `ruru` and a bunch
of wrapper code for the actual `imag` gem.
-We are not there yet, though.
### Why another layer of indirection?
As "ruru" does not yet support modules (which is sad btw) we would end up with
@@ -67,40 +65,21 @@ E.G.: `imag_runtime_setup()` instead of `Imag::Runtime::setup()`
I want to add a Ruby gem to wrap these things.
-So basically a piece of Ruby which uses `imag.rb` (the Rust gem) to build
+So basically a piece of Ruby which uses the Rust code to build
`imag` as a gem which then exports a fine module system.
-### Ideas for module system:
+### The module system:
Imag (Module)
- Runtime (Class)
- Store (Class)
- Entry (Class)
- EntryHeader (Class)
EntryContent (Class (inherits from String))
+ EntryHeader (Class)
+ FileLockEntryHandle (Class)
+ StoreHandle (Class)
StoreId (Class)
-I would name the types the same as in the Rust codebase, to avoid confusion.
-Only exception would be the `Entry` class, which would be a `FileLockEntry`
-If we adapt `libimagentrytag` and the other `libimagentry*`
-libraries, we would extend this type.
-## More plans
-I want to pull these libraries into the Ruby bindings:
-* libimagentryedit
-* libimagentryfilter
-* libimagentrylink
-* libimagentrylist
-* libimagentrymarkdown
-* libimagentrytag
-* libimagentryview
-Which all provide functions on top of `libimagstore::store::{FileLock,}Entry`,
-so we will implement them on `Imag::Entry`.
+`libimagentrytag` and the other `libimagentry*` libraries will be pulled into
+this library to support more advanced operations with the `FileLockEntryHandle`