Development and project specifications are on their gitlab page: https://gitlab.com/robigalia

Considering introducing to Plume.

Genuinely serious since this is so much of a meme.

I'm looking to build something in Rust that requires being able to extract a variety of archive and compressed file formats, like various forms of compressed tar files, zip files, iso files, etc. The 7zip software suite is really good at both auto-detecting what format it's in and extracting almost anything you throw at it (it even dumps out the objects in Linux, Mac and Windows executables).

I was originally just thinking of including 7zip as a dependency and calling its command line tool from Rust so I can get it to do all the work, but is there a Rust library that is similarly versatile that I can use instead, or is 7zip actually my best option?

Flowgger is a fast, simple and lightweight data collector written in Rust.

Alternative to Fluentd and Logstash.

All these tests are run on Lemmy tag v0.6.74, using cargo build --release.

• Normal release build: 19mb
• After running strip 13mb
• Setting opt-level=z (optimize binary size): 21mb
• Optimize for size + strip: 13mb
• Optimize for size + enable link-time optimization: 14mb
• Optimize for size + lto + strip: 14mb
• only lto: 15mb
• lto + strip: 11mb
• lto + strip + reduce codegen-units: 11mb

Check this document for a detailed explanation of these options

Based on these numbers and the difference in compile time between options (which I didnt record), lto + strip looks like the best option to me.

This is also useful: https://github.com/johnthagen/min-sized-rust

Could this effect Lemmy if the framework eventually stops being maintained?

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