Giter VIP home page Giter VIP logo

copyless's People

Contributors

badboy avatar benbrittain avatar bors[bot] avatar danielhenrymantilla avatar erjanmx avatar eun-ice avatar jrmuizel avatar kvark avatar marcotoniut avatar nageshlop avatar stanislav-tkach avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

copyless's Issues

Question: Why mem::replace?

I just ran across this and wanted to understand how this crate avoids memcpy. One thing I stumbled upon is this:

let ptr = mem::replace(&mut self.0, ptr::null_mut());

Why is this using mem::replace, which seems like it'd do an unnecessary write, as opposed to let ptr = &mut *(self.0);?

Does not work with nested arrays

So I came across this while tinkering around on this.
The essence is that when trying to create a box of [[0i32;SomeBigNumber];SomeBigNumber] the stack overflows, but when creating a box of [i32;SomeBigNumber*SomeBigNumber] it works.

I would understand if this is something this crate cannot change (as its a missed opportunity from the compiler to optimize this) but wanted to ask if there is a known specific reason for this to not work?

Minimal example

I'm using the latest nightly and of course use cargo run --release while testing this.

box! macro?

It feels like there could be a box! macro that would do Box::alloc().init(...).

Memory issue with zero-sized types

I have a serious issue I cannot explain. My guess is that copyless creates some sort of memory issue when called with static functions.

assume the following traits:

pub struct Runnable {
    runnable_box: Box<RunnableBox + Send>
}

impl Runnable {
    pub fn run(self) {
        self.runnable_box.run();
    }
}

trait RunnableBox {
    fn run(self: Box<Self>);
}

impl<F: FnOnce()> RunnableBox for F {
    fn run(self: Box<F>) {
        (*self)()
    }
}

And these two constructors, one using Box::new, the other using Box::alloc().init

impl Runnable {
    pub fn new_box<F>(func: F) -> Runnable
        where
            F: FnOnce() + Send + 'static {
        Runnable { runnable_box: Box::new(func) }
    }
    #[allow(dead_code)]
    pub fn new_copyless<F>(func: F) -> Runnable
        where
            F: FnOnce() + Send + 'static {
        Runnable { runnable_box: Box::alloc().init(func) }
    }
}

Creating a static Runnable seems to create some sort of memory overwrite I cannot exactly pin down:

Runnable::new_box(move || { println!("scheduled task 1"); }); // Works

Runnable::new_copyless(move || { println!("scheduled task 1"); }) // Error

let now = Instant::now();
Runnable::new_copyless(move || { println!("scheduled task 1 {:?}", now); }) // Works

I have attached a testcase that fails on macos and on linux using Rust 1.33 stable and rustc 1.35.0-nightly (0576ac109 2019-03-24).

copyless.tar.gz

Turn a Box into a BoxAllocation

It might be useful to be able to take an existing Box and turn it back into a BoxAllocation.
For example, you might want to use the same allocation twice like in this contrived example:

fn make_big_thing(box_alloc: BoxAllocation<Thing>) -> Box<Thing> {
    box_alloc.init(...)
}

fn main() {
    let box_alloc = BoxAllocation::init();
    let thing = make_big_thing(box_alloc);
    do_something_with_thing(&thing);

    let box_alloc = BoxAllocation::from_box(thing);
    let thing2 = make_big_thing(box_alloc);
    do_something_with_thing(&thing2);
}

Why is this crate deprecated?

I see in the crate description that this crate is deprecated. Please consider adding a note to the README describing/linking to a description of why. Is it just unmaintained, or is it no longer necessary thanks to improvements to the Rust standard library, or maybe something else?

More pemissive license?

I'm not sure if it is appropriate, but can you please replace the license by a more permissive one? For example, MIT or Apache 2.0. I would like to use this library, but the company that I'm currently working at has a policy that forbids MPL license.

published version on crates.io has executable attribute on all files

*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/bors.toml is executable but has empty or no shebang, removing executable bit
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/LICENSE is executable but has empty or no shebang, removing executable bit
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/src/boxed.rs is executable but has empty or no shebang, removing executable bit
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/src/vec.rs is executable but has empty or no shebang, removing executable bit
*** ERROR: ./usr/share/cargo/registry/copyless-0.1.2/src/lib.rs has shebang which doesn't start with '/' ([warn(missing_docs)])
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/rustfmt.toml is executable but has empty or no shebang, removing executable bit
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/CHANGELOG.md is executable but has empty or no shebang, removing executable bit
*** WARNING: ./usr/share/cargo/registry/copyless-0.1.2/README.md is executable but has empty or no shebang, removing executable bit

That is creating problems when packaging for Fedora.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.