profile
viewpoint

EFanZh/Graphviz-Preview 60

Extension for Visual Studio Code to preview Graphviz (DOT) files.

EFanZh/EOPL-Exercises 25

My solutions to exercises from the book Essentials of Programming Languages.

EFanZh/Introduction-to-Algorithms 8

Codes for the book Introduction to Algorithms, Third Edition.

EFanZh/LeetCode 5

Solutions to LeetCode algorithm problems.

EFanZh/Archived 4

EFanZh’s programs.

EFanZh/CTfP-Challenges 1

Challenges from Category Theory for Programmers (https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/)

EFanZh/lightsabers 1

some beautiful code

EFanZh/approx 0

Approximate floating point equality comparisons and assertions

EFanZh/cargo-binutils 0

Cargo subcommands to invoke the LLVM tools shipped with the Rust toolchain

issue commentbrendanzab/approx

clippy::if_then_panic warning (nightly)

I think #72 has fixed this issue, so maybe this can be closed?

Bromeon

comment created time in 4 hours

push eventEFanZh/approx

Caden Haustein

commit sha bf15f5e500d3133a24c4d74f2c99be65f75d6e18

Remove the use of std

view details

Caden Haustein

commit sha 1b1e284cf5f4e58e1bb6da67176e491898648159

Fix errors

view details

Caden Haustein

commit sha 412811bddb4b6f10e9e2d8d9d9f77c45a8868587

Update Cargo.toml

view details

TÖRÖK Attila

commit sha 435e44eb2ebf52e55724c20bd0b5200bf9dd8b84

Fix clippy::if_then_panic lint

view details

TÖRÖK Attila

commit sha 3991701142a5441b5d90a17d22b090b3b7181401

Fix clippy::needless_update lint

view details

TÖRÖK Attila

commit sha 59b0ef78dc00d2e283667f3603ee363852ba55e2

Fix clippy::clone_on_copy lint

view details

TÖRÖK Attila

commit sha 81e69878c2e71d98c83e8109caba04c0867a5df1

Run cargo format

view details

Ilya Bobyr

commit sha 7ea218a748ae5f85225d724998119b81b4d7b31a

Replace `unsafe` with `to_bits()` While `to_bits()`[1] is implemented as `unsafe { mem::transmute(self) }` it seems nicer to rely on the standard library to hide the unsafe implementation. Some people audit the libraries they use and may get nervous when they see `unsafe`. [1] https://doc.rust-lang.org/std/primitive.f32.html#method.to_bits

view details

Sébastien Crozet

commit sha 1398e382895f1c297497bf5913f364a387a24f2f

Merge pull request #72 from torokati44/chores Fix a couple clippy lints, run cargo format

view details

Sébastien Crozet

commit sha cc6067d9fe8de2a3abcda9a6d2f0be0896413794

Merge pull request #64 from brightly-salty/remove-std Remove the use of std

view details

Sébastien Crozet

commit sha 81be089bb32d0b9823cca5dc7f9c558099011913

Merge branch 'master' into master

view details

Sébastien Crozet

commit sha ee07aef756519758a204d80bd92ba00349a146cb

Merge pull request #63 from ilya-bobyr/master Replace `unsafe` with `to_bits()`

view details

EFanZh

commit sha 6e43a5f7dea1883f89237c305f648e93abc08c55

Merge branch 'master' into fixes-issues-71-and-73

view details

push time in 4 hours

push eventEFanZh/LeetCode

EFanZh

commit sha f9f0bef555bfbfa31059a970cfcc27019dea3970

Add problem 912: Sort an Array

view details

push time in 9 hours

startedkennytm/rustup-toolchain-install-master

started time in 21 hours

push eventEFanZh/LeetCode

EFanZh

commit sha de20ce381fcd7198fa97f478246ef3b1717f8c1c

Add problem 907: Sum of Subarray Minimums

view details

push time in a day

issue closedrust-lang/rust

The size of `(T, Infallible)` is not zero

Since Infallible is an empty type, I expect (T, Infallible) also be an empty type, thus they should have the same size. But I noticed that (T, Infallible) have the same size as T, so currently, we have

  • mem::size_of::<Option<Infallible>>() == 0
  • mem::size_of::<Option<(u32, Infallible)>>() = 8

I guess this is because Rust treats empty type to have size 0, so the size of (T, Infallible) is size of T plus size of Infallible equals size of T. May be we can use something like Option<usize> to represent the size of a type internally, where None means the size of an empty type, in this way, we can distinguish empty types from zero sized types. For example, internally, we can have a function like:

fn internal_size_of<T>() -> Option<usize> { ... }

To keep the current behavior of mem::size_of, it can be implemented as:

fn size_of<T>() {
    internal_size_of::<T>().unwrap_or(0)
}

closed time in 2 days

EFanZh

push eventEFanZh/LeetCode

EFanZh

commit sha c88a28b0398eb3e153c941ceb8a19a739df67357

Add problem 901: Online Stock Span

view details

push time in 2 days

push eventEFanZh/laboratory

EFanZh

commit sha 33579fbdac42a5921a33b18783dfb4023e6ed000

Add `UniqueOneshotEvent`

view details

EFanZh

commit sha e58bd7d6f7f285038fe8ee8105c88b7ca2604b6f

Collect futures

view details

push time in 3 days

issue openedrust-lang/rust

The size of `(T, Infallible)` is not zero

Since Infallible is an empty type, I expect (T, Infallible) also be an empty type, thus they should have the same size. But I noticed that (T, Infallible) have the same size as T, so currently, we have

  • mem::size_of::<Option<Infallible>>() == 0
  • mem::size_of::<Option<(u32, Infallible)>>() = 8

May be we can have a function like mem::size_of, but returns something like Option<usize>, where None means the size of an empty type:

fn internal_size_of<T>() -> Option<usize> { ... }

And mem::size_of can be implemented as:

fn size_of<T>() {
    internal_size_of::<T>().unwrap_or(0)
}

created time in 3 days

push eventEFanZh/LeetCode

EFanZh

commit sha c4f2976f5961f1b1830eeb1823186efbc2533a81

Add problem 900: RLE Iterator

view details

push time in 3 days

startedsivan/heti

started time in 4 days

issue openedrust-lang/rust-clippy

Check usages of undefined features

What it does

Warn usages of features that are not defined in features section of Cargo.toml and are not optional dependencies.

Lint Name

undefined-features

Category

correctness, suspicious

Advantage

  • Check misspelled feature names.
  • Check unused code.

Drawbacks

No response

Example

fn foo() {}

#[cfg(feature = "bar")]
fn bar() {}

If feature "bar" is not defined in Cargo.toml, the code above could be written as:

fn foo() {}

created time in 4 days

push eventEFanZh/LeetCode

EFanZh

commit sha 12e15e245d4d803bb335298d8252d25245d38b8c

Not a public interface

view details

EFanZh

commit sha c1115f25a819b0f8771de963cc5f0ad440de6e60

Add problem 899: Orderly Queue

view details

push time in 4 days

push eventEFanZh/laboratory

EFanZh

commit sha 54e75876e5595080b3cb725453ea02fb6b58ce17

Add `Defer` future

view details

EFanZh

commit sha 86c4012d383ce8a3f5b58ebac76072857717ee03

Add `Executor`

view details

push time in 5 days

push eventEFanZh/Introduction-to-Algorithms

EFanZh

commit sha 3a4f25a5557166b672e92342d0f0ba36c27b1d5b

Format codes

view details

push time in 5 days

push eventEFanZh/Introduction-to-Algorithms

EFanZh

commit sha b1e1b51ab65834a6e6dd760a69edb9b222f2ed2e

Use `crate` qualifier properly

view details

push time in 5 days

issue openedrust-lang/rust

The assembly codes generated by calling `<[T]>::sort_unstable_by` contains bounds checking codes

See https://godbolt.org/z/fE18sq4WK, you can find serval calls to the following functions:

  • core::panicking::panic
  • core::panicking::panic_bounds_check
  • core::slice::index::slice_end_index_len_fail
  • core::slice::index::slice_index_order_fail
  • core::slice::index::slice_start_index_len_fail

To my understanding, if the sorting algorithm implementation is correct, no bounds checking failure will occur, so this might be something we can optimize, but I am not sure how much these bounds checking codes can affect performance or whether it’s worth looking into.

created time in 5 days

push eventEFanZh/LeetCode

EFanZh

commit sha ed6d23d3cfc074eed78a6b9d68bc705e9fbe4d42

Refactor

view details

EFanZh

commit sha 29e35258887b2cdb2ee362c76a1c0ece8ec47264

Add problem 895: Maximum Frequency Stack

view details

push time in 5 days

push eventEFanZh/efanzh.github.io

EFanZh

commit sha 8d51adf29314df5e178475155aebe2979462387e

Fix CLRS exercise 8.3-1

view details

push time in 6 days

issue openedrust-analyzer/rust-analyzer

Renaming a module shouldn’t change path segments referring this module with `super`

In the following code:

mod foo {
    struct X;

    mod bar {
        use super::X;
    }
}

If I rename foo to baz, the code changes into:

mod baz {
    struct X;

    mod bar {
        use baz::X;
    }
}

Which doesn’t compile any more.

created time in 6 days

push eventEFanZh/LeetCode

EFanZh

commit sha 7e45aa5d544bafcb068b3b5f91733691fb17cb0a

Add problem 898: Bitwise ORs of Subarrays

view details

push time in 6 days

push eventEFanZh/LeetCode

EFanZh

commit sha bc207e71cd87bbcc23083d8da340874be3964edd

Add problem 894: All Possible Full Binary Trees

view details

push time in 7 days

push eventEFanZh/LeetCode

EFanZh

commit sha 575a685935f881106d0d532c230ae74ef32eb79b

Add problem 891: Sum of Subsequence Widths

view details

push time in 8 days

push eventEFanZh/LeetCode

EFanZh

commit sha 1a1642bdc902feefca519b2af92451329a55921a

Add problem 887: Super Egg Drop

view details

push time in 9 days

push eventEFanZh/LeetCode

EFanZh

commit sha 52e3ddd8b4c4b21b3d62d60c4824c1a44fc605fd

Add problem 885: Spiral Matrix III

view details

push time in 10 days

issue commentrust-lang/futures-rs

Mutex is accidentally quadratic

How about replacing Slab with something like HopSlotMap? It claims to have fast iteration speed.

nathdobson

comment created time in 11 days

push eventEFanZh/laboratory

EFanZh

commit sha e8226d31e895ee377ae3082af38e9019b39fe611

Delay cloning `Waker`

view details

push time in 11 days

push eventEFanZh/laboratory

EFanZh

commit sha 705253ffc16fea10d453caa068c5a65199cc0120

Remove incorrect `FusedFuture` implementation

view details

push time in 11 days

push eventEFanZh/laboratory

EFanZh

commit sha 00d70a3382a263c0cec72e4c6d3839956513a8c6

Use `strong_count()` for termination checking

view details

push time in 11 days

push eventEFanZh/LeetCode

EFanZh

commit sha 7ff0955d2a662abf35d9d61fcdf287be05473a84

Add problem 882: Reachable Nodes In Subdivided Graph

view details

push time in 11 days

more