bluss/arrayvec 287
A vector with a fixed capacity. (Rust)
bencher is just a port of the libtest (unstable) benchmark runner to Rust stable releases. `cargo bench` on stable. "Not a better bencher!" = No feature development. Go build a better stable benchmarking library.
bluss/defmac 12
A macro to define lambda-like macros inline.
NOTE: Crate dbg mostly supplants this one; DebugIt: Use specialization so you can debug-print a value without explicit (and viral) Debug trait bound.
Rust library with a trait for the `as` operator for primitive numeric types.
BLAKE2s hash function https://blake2.net PowerPC/Altivec implementation by Ulrik Sverdrup
[Feel free to adopt/fork this repo!] Experimental Rust bindings for BLIS
Aeon is a gradually typed, interpreted programming language that combines the flexibility of a dynamic language with the safety of a static language.
Experimental B-tree map in Rust using ArrayVec
startedBurntSushi/bstr
started time in 3 days
startedVeykril/tlborm
started time in 7 days
issue closedrust-ndarray/ndarray
Is it possible to index an N-dimensional ArrayBase using a single offset into the slice?
I know there is a to_slice method that could make this work, but it returns Option. I'm wondering if I can index, for example, a 3D ArrayBase, using just one number, assuming I know the memory layout (row-major). In certain applications, it is too expensive to do the multiplications to convert NdIndex into an offset for every point.
closed time in 10 days
bonsairobo
issue commentrust-ndarray/ndarray
Is it possible to index an N-dimensional ArrayBase using a single offset into the slice?
If you know the array is row major, then you can use as_slice and index into the resulting slice. Still, multidimensional or single dimensional indexing is not recommended for processing in a loop - rather use the traversal methods mentioned in the docs.
The raw access is through the raw pointer accessors - pointers which you can offset manually as you said - as briefly mentioned in the as_ptr doc, but this is not easy to use.
comment created time in 10 days
startedearthstar-project/earthstar
started time in 11 days
pull request commentbluss/indexmap
Let feature "serde" work as well as "serde-1"
Makes sense
comment created time in 11 days
Pull request review commentbluss/matrixmultiply
+[package]+name = "ensure_no_std"+version = "0.1.0"+authors = ["Geordon Worley <[email protected]>"]+edition = "2018"
could have publish = false set
comment created time in 14 days
pull request commentbluss/matrixmultiply
We just need Rust 1.36 if the std feature is disabled. So we don't need to break existing users actually
comment created time in 14 days
startedmapbox/osm-bright
started time in 14 days
pull request commentbluss/matrixmultiply
Thanks, looks good! I think normally we'd bump to version 0.3 here since we have a Rust MSV bump. Can't that be avoided, though?
comment created time in 14 days
startedfredrik-johansson/arb
started time in 14 days
startedmatrix-construct/construct
started time in 15 days
startedstr4d/rage
started time in 16 days
issue openedfruktkartan/fruktkartan
When using the map in the field, it's useful for many users to show the user's current location on the map (you know with a blue dot or similar).
created time in 16 days
startedfruktkartan/fruktkartan
started time in 16 days
startedstainless-steel/sqlite
started time in 17 days
startedPlume-org/Plume
started time in 18 days
startedaspenluxxxy/nanorand-rs
started time in 18 days
issue commenttootsuite/mastodon
Is there an alternative here? For example, if instead you'd make a reply to the original post, and somehow could make that reply visible in your regular timeline, and to those that don't follow the post you reply to. Like an "open reply"?
comment created time in 19 days
startedJetBrains/lets-plot
started time in 19 days
pull request commentbluss/indexmap
map: Make Eq comparisons ordering-aware.
Thanks for filing. Not a bug since it's the intentional design, but worth discussing for sure. I think a method for ordered eq would be worth it.
comment created time in 19 days
Pull request review commentbluss/indexmap
map: Make Eq comparisons ordering-aware.
mod tests { assert_eq!(&set_a & &set_b, empty); assert_eq!(&set_b & &set_a, empty); assert_eq!(&set_a | &set_b, set_c);- assert_eq!(&set_b | &set_a, set_c);+ assert_ne!(&set_b | &set_a, set_c); assert_eq!(&set_a ^ &set_b, set_c);- assert_eq!(&set_b ^ &set_a, set_c);+ assert_ne!(&set_b ^ &set_a, set_c);
when this is revived later, this change does not preserve the intent of the test. It can of course be fleshed out when/if relevant later.
comment created time in 19 days
startedrustodon/rustodon
started time in 20 days
issue commenttootsuite/mastodon
I agree that the difference here is not straightforward. If the status is not local, it seems that (2) and (3) will link to different instances - (2) to the home instance of the status, and (3) is the web view on the current instance.
comment created time in 20 days
issue commenttootsuite/mastodon
Ability to forcefully update remote user data
There is an API that fetches the relevant info, is that right? The followers method; and it has pagination. Is it really too expensive to use? To show something a bit better here would make the federation experience a lot smoother.
comment created time in 20 days
startedtootsuite/mastodon
started time in 20 days
startedpygae/clifford
started time in 21 days
starteddimforge/simba
started time in 22 days
startedpwoolcoc/elefren
started time in 22 days
startedtordanik/OSM2World
started time in 22 days
startedreHackable/awesome-reMarkable
started time in a month
startedritchie46/polars
started time in a month
startedEreski/generic-std
started time in a month
Pull request review commentrust-lang/rust
Add Iterator::join to combine Iterator and Join
+//! Allocation extensions for [`Iterator`].+//!+//! *[See also the Iterator trait][Iterator].*+#![unstable(feature = "iterator_join", issue = "75638")]++use crate::slice::Join;+use crate::vec::Vec;++/// Iterator extension traits that requires allocation.+#[unstable(feature = "iterator_join", issue = "75638")]+pub trait IteratorExt: Iterator {+ /// Flattens an iterator into a single value with the given separator in+ /// between.+ ///+ /// Combines `collect` with `join` to convert a sequence into a value+ /// separated with the specified separator.+ ///+ /// Allows `.join(sep)` instead of `.collect::<Vec<_>>().join(sep)`.+ ///+ /// ```+ /// #![feature(iterator_join)]+ /// use alloc::iter::IteratorExt;+ ///+ /// assert_eq!(["hello", "world"].iter().copied().join(" "), "hello world");+ /// assert_eq!([[1, 2], [3, 4]].iter().copied().join(&0), [1, 2, 0, 3, 4]);+ /// assert_eq!([[1, 2], [3, 4]].iter().copied().join(&[0, 0][..]), [1, 2, 0, 0, 3, 4]);+ /// ```+ #[inline]+ #[unstable(feature = "iterator_join", issue = "75638")]+ #[must_use = "if you really need to exhaust the iterator, consider `.for_each(drop)` instead"]+ fn join<Separator>(self, sep: Separator) -> <[Self::Item] as Join<Separator>>::Output+ where+ [Self::Item]: Join<Separator>,+ Self: Sized,+ {+ Join::join(self.collect::<Vec<Self::Item>>().as_slice(), sep)+ }+}++// ExactSizeIterator is used to guarantee non-infinite iteration.
non-infinite iteration sounds nice if it could be checked, but ESI is pretty far away from a perfect check for that, so I'd avoid that requirement. collect for example does not try to ensure the iterator is finite.
comment created time in a month
pull request commentbluss/indexmap
Update the README for the hashbrown-based implementation
Thanks for all your work on this feature :) and the release
comment created time in 2 months
startedfrankmcsherry/columnation
started time in 3 months
issue commentbluss/indexmap
I just have an attitude problem with ahash, would be more charmed by a pure-rust hash function.
But for an actual argument, for a public dependency we need them to have an 1.x version or equivalent.
comment created time in 3 months
issue commentrust-ndarray/ndarray
Cannot use some binary operators "foo_assign" on &mut ArrayBase
You are right, making a new release and updating num-complex should be a priority
comment created time in 3 months
issue commentbluss/indexmap
insert_sorted is still O(n) so I'm not sure it's good enough.
comment created time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
I'd vote to merge this and go for indexmap 1.5 with this
comment created time in 3 months
issue commentrust-ndarray/ndarray
Help with R language integration
ndarray does not at the moment support creating custom owned arrays like that unfortunately, but using array views is possible.
comment created time in 3 months
issue commentrust-ndarray/ndarray
Need .axis_iter()-analog taking K axes and returning NdProducer of (D-K)-dim ArrayViews
For it to not be too slow, I think it needs to be implemented with specific dimension types (and not IxDyn/dynamic dim).
comment created time in 3 months
issue commentbluss/indexmap
Added item for a proper std crate feature. Makes it easier for deps
comment created time in 3 months
pull request commentbluss/indexmap
Implement direct usize indexing
That makes sense but
ith Index<Idx> for IndexMap<K, V, S, Idx>, but I can't prove that Index<Idx> and Index<&Q> are distinct
Won't we have a trait bound on Idx? If that's a local trait it should be enough, it will prove that no references implement it? (Or maybe that doesn't work because references are fundamental)
comment created time in 3 months
pull request commentbluss/arrayvec
Make new functions const (gated by feature="const").
Nice that this can be done. How far are we from that this is stable? The trait bounds are a problem aren't they?
I'm not sure we can commit to having unstable features in the crate, but if we could the following remains:
- I'd suggest the feature name
unstable-const-fn - The crate feature must be documented (as unstable) at the top of lib.rs with the other features.
- The pull request updated with a description
🙂
comment created time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
I can't really think of any breaking changes that are on the wishlist.
I definitely don't want to pile on work here, but a 2.0 version could include the parameterization by index type. Then we can update the Default impl to be fully generic without having to fear type inference regressions (and the other new* methods too?).
The "experimental things - Equivalent trait works well, the MutableKeys trait I don't know, so those things seem like they could stay for 2.0.
Which method to make the default .remove() - I still think the current decision is fine, no change from my end for 2.0.
(Good way to document this would be to say that "remove is the fastest way to remove an element, and if order should be preserved, ...")
comment created time in 3 months
issue openedinteger32llc/rust-playground
"const fn main" not detected as main function.
Feature request: detect "const fn main" as a main function. 😈
The following program says it doesn't detect a main function:
const fn main() -> Result<(), ()> {
Err(())
}
But if you fool it, it runs:
/*
fn main() */
const fn main() -> Result<(), ()> {
Err(())
}
Compiling playground v0.0.1 (/playground)
Finished dev [unoptimized + debuginfo] target(s) in 0.44s
Running `target/debug/playground`
Error: ()
created time in 3 months
issue commentbluss/arrayvec
@Michael-F-Bryan Yes, I think we should, if it makes sense. There might be other crates already filling this need?
comment created time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
I agree
comment created time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
I don't think it's wrong to carefully raise the MSRV, it's the plan we have documented and promised since 1.0. However we can discuss it with those that depend on us.
comment created time in 3 months
pull request commentbluss/indexmap
Implement direct usize indexing
I think we should just wait with this, in that case. If we have an indexing operator, IMO it must use the index type that we have parameterized the map with.
comment created time in 3 months
pull request commentbluss/indexmap
Demonstrate fnv and fxhash as alternate hashers
I'll just approve and you can merge - don't want to cause conflicts with other prs, if there are any conflicts.
comment created time in 3 months
pull request commentbluss/indexmap
Demonstrate fnv and fxhash as alternate hashers
Thanks
comment created time in 3 months
push eventcuviper/indexmap
commit sha 291ebbc730c329188254fe302f0a08639b666454
Make methods that get RawBucket parameters unsafe; add safety comments These methods trust their caller to pass correct RawBucket values, so we mark them unsafe to use the common safe/unsafe distinction. I used allow(unused_unsafe) to write the functions in the (hopefully) future style of internal unsafe blocks in unsafe functions.
push time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
This might be the first time we raise the MSRV in 1.x, but with a good reason.
It looks like we might break serde_json, which builds CI with Rust 1.31? cc @dtolnay, when we raise ours to Rust 1.32 here.
Other top rdeps - toml, http, petgraph, they look fine from MSRV standpoint.
comment created time in 3 months
pull request commentbluss/indexmap
Switch to hashbrown's RawTable internally
Thanks all for your input on the discussion, and helping me find some solid footing again with the raw pointer code. Thanks cuviper for working on this - I'll work on helping you wrap this up as soon as you want.
There are two discomforting things left; I think it's something that's rather general to come up in this situation
-
We handle raw buckets (raw pointer wrappers) that are passed in structs and between function scopes
- Usually in Rust, we use safe abstractions, maybe just a simple lifetime to help us with the book keeping when leaving local reasoning. Lifetimes often help us convert the problem into just using local reasoning instead of global reasoning. I'm not saying it's worth the trouble to wrap this in further abstractions here, to make it safer, but it's the things we try to do if it's possible.
-
We have internal functions that don't follow the usual safe/unsafe distinction
-
I believe it is best practice, that for example
fn swap_remove_bucket(&mut self, raw_bucket: RawBucket) -> (usize, K, V), should be an unsafe method. The reason is that we must trust the caller to pass a correct raw bucket. I'll push a commit with this change. History is mutable, so feel free to toss it out if you don't like it. -
We end up in a gray area here, since struct fields can not be made unsafe to assign (known issue), so we don't follow this completely stringently.
-
comment created time in 3 months
push eventcuviper/indexmap
commit sha 602c7eed2c7fcd8a1217cf7969d6bb7145a08bad
Make methods that get RawTable parameters unsafe; add safety comments These methods trust their caller to pass correct RawBucket values, so we mark them unsafe to use the common safe/unsafe distinction. I used allow(unused_unsafe) to write the functions in the (hopefully) future style of internal unsafe blocks in unsafe functions.
push time in 3 months