brunocodutra / reducer Goto Github PK

Facebook has updated the flux pattern link, the old link in the doc returns 404.

The updated link should be https://facebook.github.io/flux/docs/in-depth-overview/

rusttype is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The maintainer has further advised to migrate over to ab_glyph.

Last release seems to have been over two years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• ab_glyph

See advisory page for additional details.

memmap is unmaintained

The author of the memmap crate is unresponsive.

Maintained alternatives:

• mapr
• memmap2

See advisory page for additional details.

macOS is frustrating. If an application wants to have a gui, that gui has to be on the main thread, as described when trying to run the conrod example.

▲ CXXFLAGS+=-stdlib=libc++ cargo run --release --example conrod
    Finished release [optimized] target(s) in 0.59s
     Running `target/release/examples/conrod`
thread '<unnamed>' panicked at 'Windows can only be created on the main thread on macOS', /Volumes/data/tmp/cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.16.2/src/platform/macos/window.rs:595:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I am not decent enough at threading to refactor the example to have winit on the main thread with the rest of the application in a spawned thread, but that would fix it on macOS. Maybe conrod has examples but I'm not sure.

difference is unmaintained

The author of the difference crate is unresponsive.

Maintained alternatives:

• dissimilar

• similar

• treediff

• diffus

See advisory page for additional details.

stb_truetype crate has been deprecated; use ttf-parser instead

This crate was maintained for use in rusttype which has switched to use ttf-parser

See advisory page for additional details.

with cargo run --release --example conrod or cargo run --release --example libui
while building ui-sys 0.1.3

I had to do CXXFLAGS+=-stdlib=libc++ cargo run --release --example libui, as mentioned in https://github.com/LeoTindall/libui-rs/issues/38

Out-of-bounds write in nix::unistd::getgrouplist

On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the reqested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.

See advisory page for additional details.

I took a quick glance over your dependencies. There doesn't seem to be reason that jumps out to me that you couldn't make this project full on no_std + alloc if you built an executor without future-rs

rusttype is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The maintainer has further advised to migrate over to ab_glyph.

Last release seems to have been over two years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• ab_glyph

See advisory page for additional details.

In the JS-land Redux, one of the convenient things is having various patterns that allow you to dispatch actions based on actions dispatched. e.g thunks and more complex concepts like rx , sagas, epics in an asynchronous way that involves side effects.
What would be the equivalent here?

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

xml-rs is Unmaintained

xml-rs is a XML parser has open issues around parsing including integer
overflows / panics that may or may not be an issue with untrusted data.

Together with these open issues with Unmaintained status xml-rs
may or may not be suited to parse untrusted data.

Alternatives

• quick-xml

See advisory page for additional details.

Using this crate I find that there is a need to get a reference to the current state, which seems impossible with the current API. For the time being, I'm registering a reactor that copies the state so a caller can get it later. Better would be a get_state(callback: Subscription<State>) function on the Store so I don't have to copy the state. At least that's what I think, you may have entirely different thoughts on this topic.

It would also be splendid if I could register more than one reactor. For now I'm maintaining my own collection of listeners.

I'd be happy to submit a pull request, although there is a chance you'd end up rewriting whatever I did.

rusttype is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The maintainer has further advised to migrate over to ab_glyph.

Last release seems to have been over two years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• ab_glyph

See advisory page for additional details.

Out-of-bounds write in nix::unistd::getgrouplist

On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the reqested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.

See advisory page for additional details.