duktape-rs
duktape-rs copied to clipboard
emk
differences between forks
There are three crates out there:
- https://crates.io/crates/duktape
- https://crates.io/crates/duktape_sys
- https://crates.io/crates/duktape_ffi
could you please explain the differences?
@flosse, duktape_sys and duktape_ffi are the same - low-level bindings to the C functions from the original duktape -, the difference being that duktape_ffi compiles (on stable Rust). duktape is a crate that depends on duktape_sys and is a higher-level-wrapper with some abstractions and is still a WIP (that is discontinued as far as i can tell)
I'm happy to transfer control of my crates (and the names on crates.io) to people actively working on duktape. Please don't hesitate to ask.
I have a C project using Duktape right now, and I'd like nothing more than to port it to Rust. I'd be willing to take over duktape-rs if you are still looking for a maintainer.
@flosse @moosingin3space Could you two perhaps work out a plan for who wants to be charge of maintaining this crate in the future? Thank you for any suggestions!
@emk @flosse I went ahead and made a set of bindgen-generated bindings in my duktape-sys repository, which I'd like to become the duktape-sys crate on crates.io. At present, I'm also working on re-writing the Duktape REPL in Rust, and by attempting to minimize the amount of unsafe in that project, I am implementing a new high-level API for Duktape in Rust.
Would everyone be okay with my duktape-sys repo taking over duktape-sys on crates.io?
@moosingin3space @emk I stumbled upon this repo after having created a duktape-sys of my own. It looks like this: https://github.com/dflemstr/duk/tree/master/duktape-sys
I'm not sure which approach is best for this particular crate?
@moosingin3space I think it would be nice to have a hybrid of sorts; since my code depends on libclang during build time it can't build on some platforms... Any ideas?
I opted to include the generated source code in the repository now and ship the code generator as a Cargo example... Might not be ideal but works rather well
@emk My duktape wrapper https://github.com/dflemstr/duk is now quite feature-ful, see the doc for details: https://dflemstr.github.io/duk/duk/
I would like to be able to upload it to crates.io but would hope to take over the duktape crate name for visibility.
@dflemstr, your high-level wrappers look really useful.
What's the consensus here? I'm willing to consider turning over the name if everybody agrees on which crate should have it. :-)
@emk I'm fine with @dflemstr taking the name.
On Aug 17, 2016 4:38 AM, "Eric Kidd" [email protected] wrote:
@dflemstr https://github.com/dflemstr, your high-level wrappers look really useful.
What's the consensus here? I'm willing to consider turning over the name if everybody agrees on which crate should have it. :-)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emk/duktape-rs/issues/3#issuecomment-240375812, or mute the thread https://github.com/notifications/unsubscribe-auth/AAyqguaFGiDzUAzWlQFHYplSt08kGPnoks5qguS7gaJpZM4FuQ9N .
@dflemstr OK, I think the name is yours. Let me know how you want to handle the transition. I can give you commit rights on this repo, and access to the crate on crates.io.
Done! I've added you to duktape, duktape_sys, and this GitHub repository (the latter will at least allow you to see bugs, etc.) Thank you for working on Rust duktape, and my apologies for how long it has taken me to figure out what I was doing here.
@theduke you are right, I kept using the duk name, I didn't find a reason to take over this specific crate