Spacebar is an already existing, open-source reimplementation of the Discord.com API. Chorus aims to provide tooling to write software for and with Spacebar, using Rust.

Polyphony was born out of my desire to finally learn Rust, and to write a client-application for Spacebar with it. However, things are never as straightforward as they seem. I sadly had to discover, that already existing Discord-libraries did not provide the set of features needed to properly connect to, and interact with a Spacebar instance.

I have learned a lot in the past 4-5 months, in which I basically commited all my spare time to writing Rust and working on this project, and I am still learning a lot, daily. My greater motivation with this project is:

• Enable Rust Developers to write Software for Spacebar
• Eventually write my client in pure Rust, and to make it darn good
• Provide an alternative server implementation to Spacebar-Server in Rust
• Create tooling that can rival Matrixes Privacy and Security, while being as easy to use as Discord. I truly believe that self-hosted communications Software like Matrix is being held back through endless complexity, making it impossible to convince any layperson to actually give it a fair shot. Also, most of the Matrix clients I have tried so far are simply... not very user friendly. Our end-goal is to create free, open-source and easy-to-use software, which can provide secure communication for the masses.

This library is currently in an early alpha-stage. Most APIs should be stable, but nothing is guaranteed, up until the 1.0 release.

Please check out Chorus and the Polyphony GitHub-org here if you're so inclined, and perhaps leave a star and join our Discord server, if you'd like to follow the project more closely. :)

Whenever I encounter an interesting Rust programming technique, I add it to this blog post. I've amassed a bit of a collection. Hopefully someone finds it interesting and useful!

A community fork of a language named after a plant fungus. All of the memory-safe features you love, now with 100% less bureaucracy!

Tantivy 0.10.0 is released.

Tantivy is a search engine library inspired by Lucene. It is already fast.

I think it is fair to say this release does not contain any major changes, considering the amount of time since last release.

Life have been pretty busy, and a large amount of my tantivy time is spent answering emails/issues/messages nowadays. Fortunately, tantivy now has a lot of contributors that can help polish the project into a great search engine library.

Kudos to @hntd187, @petr-tik, @fdb-hiroshima, @kompass, @uvd, and @drusellers for the great work! Thanks also to all of the patreons : Colin, Florian, Frederik, Nate, Sanghyeon, Stephen and Zane!

Any kind of support -communication, code, patreon- really helps tantivy!

Here goes the changelog :

Tantivy 0.10.0

Tantivy 0.10.0 index format is compatible with the index format in 0.9.0.

• Added an API to easily tweak or entirely replace the default score. See TopDocs::tweak_scoreand TopScore::custom_score (@pmasure l)

• Added an ASCII folding filter (@drusellers)

• Bugfix in query.count in presence of deletes (@pmasurel)

• Added .explain(...) in Query and Weight to (@pmasurel)

• Added an efficient way to delete_all_documents in IndexWriter (@petr-tik).

  All segments are simply removed.

Minor

• Switched to Rust 2018 (@uvd)
• Small simplification of the code. Calling .freq() or .doc() when .advance() has never been called on segment postings should panic from now on.
• Tokens exceeding u16::max_value() - 4 chars are discarded silently instead o f panicking.
• Fast fields are now preloaded when the SegmentReader is created.
• IndexMeta is now public. (@hntd187)
• IndexWriter add_document, delete_term. IndexWriter is Sync, making i t possible to use it with a Arc<RwLock<IndexWriter>>. add_document and delete_term can only require a read lock. (@pmasurel)
• Introducing Opstamp as an expressive type alias for u64. (@petr-tik)
• Stamper now relies on AtomicU64 on all platforms (@petr-tik)
• Bugfix - Files get deleted slightly earlier
• Compilation resources improved (@fdb-hiroshima)

How to update?

Your program should be usable as is.

Fast fields

Fast fields used to be accessed directly from the SegmentReader. The API changed, you are now required to acquire your fast field reader via the segment_reader.fast_fields(), and use one of the typed method:

• .u64(), .i64() if your field is single-valued ;
• .u64s(), .i64s() if your field is multi-valued ;
• .bytes() if your field is bytes fast field.

Written by me and gegy1000. We have implemented the following:

• Physical memory manager (buddy allocator)
• Virtual memory manager
• Kernel heap (buddy allocator)
• Serial (for logging)
• PIC, interrupts (incl. IST)
• PIT
• PS/2 (busy being reworked), keyboard input
• Snake game (runs on boot in kernel mode)
• ACPI (through acpi crate, with which we are involved)

Currently in progress:

• Userspace
• PS/2 rewrite
• System calls

Oh boy, here we go