Re: [rust-dev] Extending struct and trait
Hi Nadav, This list is defunct. You should use users.rust-lang.org. See https://www.rust-lang.org/community for other places to communicate. On Fri, Apr 26, 2019, at 07:03, Nadav Vinik wrote: > Hello > > I don't know why you don't want to implement heritage of classes but it > will be easier if will be a macro like: implement_trait_on > object(trait, self.c, except_methods)! > > for example: > > fn get_homogeneous() -> bool { > self.c.get_homogeneous() > } > > Rust complain about missing 1 parameter but it not display what the > missing parameter. > In the trait there is only one parameter. > > --- > error[E0049]: method `set_center_widget` has 1 type parameter but its > trait declaration has 2 type parameters > --> src/widget.rs:63:25 > | > 63 | fn set_center_widget>(, widget: > Option<>) > | ^ found 1 type parameter, expected 2 > --- > > See at: > https://users.rust-lang.org/t/i-implement-method-trait-with-two-params-but-rust-insist-that-i-have-only-one/27643 > > Thanks > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- cmr http://octayn.net/ +16038524272 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rust-dev will be shut down soon
Note that it *is* linked, through https://github.com/rust-lang/rust/wiki/Note-guide-for-new-contributors, just not the homepage. On Fri, Jan 23, 2015 at 10:59 AM, Steve Klabnik st...@steveklabnik.com wrote: The current discourse has not been linked because it's for compiler internals and language development, not general users. A second instance is being set up for regular user discussion. It will get linked from the home page. And both are available for anyone to register in. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] (FFI) Compile a dylib to x86 from a x86_64 machine and rust toolchain
You need at least a 32-bit stdlib, but you can build with `cargo build --target i686-unknown-linux-gnu` and it will Just Work assuming you have the proper libs in $PREFIX/lib/rustlib/i686-unknown-linux-gnu. http://doc.rust-lang.org/src/rustc_back/target/mod.rs.html#330 has a list of the built-in targets, and http://doc.rust-lang.org/rustc_back/target/index.html has docs on how to create your own. On Sun, Dec 28, 2014 at 2:11 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Hello Rustacean, I’ll go straight to the point: I’m building a small FFI library which needs to be called from a C++ x86 project. I cannot change the arch of the latter (it’s Doom3, and relies on x86 arch entirely). Thus linker reject my Rust library as “file was built for x86_64 which is not the architecture being linked (i386)”. Thus my question: It’s possible (without rebuilding the toolchain) to instruct cargo to generate a x86 dylib? Something like (fantasy syntax): cargo build —arch-type=x86 Thanks in advance! Alfredo ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] target json documentation
http://static.rust-lang.org/doc/master/rustc_back/target/index.html On Tue, Dec 9, 2014 at 8:55 AM, Valerii Hiora valerii.hi...@gmail.com wrote: Hi Kashyap, I've used it here - https://github.com/ckkashyap/unix/blob/master/kernel/Makefile and it appears that the compiler does honor the contents of the json file that is passed. Corey Richardson can help you with that. -- Valerii -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes
The target specs that rustc will use won't be relevant to the build system. Adding things to platform.mk is how the build system is extended, right now, and I don't foresee that changing. On Fri, Oct 17, 2014 at 5:19 PM, Cody P Schafer d...@codyps.com wrote: On Fri, Oct 17, 2014 at 4:41 PM, Ben Harris m...@bharr.is wrote: I don't believe it implies that. Only rustc would be interpreting the json file (first the snapshot rustc, then the stage0 rustc). Are any variables in the JSON relevant to configure or make? I thought only the target would be needed, and that is passed as a variable. My impression was that the linker (cc) was relevent to the initial build of the included libraries. If all of the calls to target build tools are driven by rustc (and never driven directly by make/configure), then it will be fine. If make or configure ever call the linker (or any other target build tools), it will need to parse the target JSON. Looking at the build process, at least jemalloc (which I've run into bugs cross building) needs the target build tools (not just the linker). As a result, we'd need to parse json before building jemalloc (pretty sure rustc isn't calling that build) Also, I'd have to check to be sure, but I think the build of jemalloc will need more than a linker. Even assuming the linker is also the C compiler (as is the current case) might be insufficient. This means the linker json currently proposed will need a few more fields to be useful for the initial build/configure. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Research Project Query
LLVM already has support for instrumenting code to generate gcov data, I believe Luqman and Huon have looked into this, at least slightly. On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur smcart...@mozilla.com wrote: A project I'd love to see (either separate, or eventually baked into the test harness), is test coverage data. Something like how Go's cover[1] works, by adding counters to the source code, seems simplest. I've thought about this, and it could either be a CLI tool, like `rustc --cover --test`, or a plugin. Perhaps including a `#![cover]` attribute in the crate or something. With a plugin, the Plugin Registrar would need to add the ability to register a Visitor that can modify the AST. [1] http://blog.golang.org/cover ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Is there a PNG lib?
https://github.com/PistonDevelopers/rust-image On Mon, Sep 8, 2014 at 9:44 AM, Oldřich Vetešník oldrich.vetes...@gmail.com wrote: Hello, I’m curious - is there a PNG processing lib for Rust? I’d like to write a tiny client tool for processing a directory of images into HTML and I’ll need to resize those big images. I tried searching but wasn’t very successful. :-) Thank you, Ollie ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rust and cuda
See http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf and http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/ for prior work. On Sat, Sep 6, 2014 at 1:09 PM, Madhu Srinivasan smadhuea...@outlook.com wrote: Hello fellow Rustians, I am wondering (before attempting anything) if anyone has tried creating cuda bindings for rust? Or has discovered any other route to use cuda kernels with rust as the host language ? If not, I am willing to work in this direction, but would need some guidance from the community on using rust-bindgen and it's FFI usage etc. Thanks, Madhu https://github.com/smadhueagle ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Please help me test flexible target specification!
Patch here: https://github.com/rust-lang/rust/pull/16156 If you cross compile, or can test on perhaps-lesser-used setups, I would very much appreciate a `make check`. This is touching all the fiddly bits of linking, so it's not very easy to test. Thanks! -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] This Week in Rust
Atom feed is in the same place it always has been: http://blog.octayn.net/atom.xml and On Mon, Jul 28, 2014 at 1:20 AM, Diggory Hardy diggory.ha...@unibas.ch wrote: Any chance you can add RSS feeds on the new blog? On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote: Been super busy, but there's some good stuff in store: http://blog.octayn.net/blog/2014/06/09/future-of-twir/ On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski ntypan...@gmail.com wrote: It's moved here http://blog.octayn.net/, although there hasn't been an update since 15 July. Nathan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] This Week in Rust
Been super busy, but there's some good stuff in store: http://blog.octayn.net/blog/2014/06/09/future-of-twir/ On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski ntypan...@gmail.com wrote: It's moved here http://blog.octayn.net/, although there hasn't been an update since 15 July. Nathan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Conflicting implementations of a trait
Not right now. Extending the language to allow this is the subject of RFC 24: https://github.com/rust-lang/rfcs/blob/master/active/0024-traits.md On Tue, Jul 22, 2014 at 9:50 AM, Allen Welkie allen.wel...@gmail.com wrote: Can there be two simultaneous implementations of a generic trait? I ask because I want to extend the Complex class to allow for multiplication by scalars, so that you can use a * b where a and b can be either scalars or Complex. The Complex struct already has an implementation of the Mul trait. I wanted to add another, so I added the implementation of MulT, ComplexT for ComplexT, and used the scale() function. But I get a compiler error saying that there are conflicting implementations for trait 'core::ops::Mul'. Is it possible to simultaneously overload the Complex (*) operator scalars and complex numbers? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Implementation of traits in Rust: could it be dynamic?
You can avoid monomorphization by using trait objects, which erase the precise implementing type through a vtable + pointer. http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch has some documentation. On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux lionel.parre...@gmail.com wrote: Hi, So traits seem to be quite similar to Haskell's classes, being also used for parametric polymorphism. Now, Haskell classes are usually implemented using runtime dictionary passing. In general, code cannot be specialized for every function call, since there may be an unbounded number of instances generated for it, as is explained in this reddit answer: http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju Knowing that Rust implements traits using monomorphization of code (much like C++ templates), I was curious about how it handled such cases, and tried this: struct WT { f: T } trait Show { fn show(self) - int; } impl Show for int { fn show(self) - int { 666 } } implT:Show Show for WT { fn show(self) - int { self.f.show()+1 } } implT:Clone Clone for WT { fn clone(self) - WT { W{f:self.f.clone()} } } fn fooS:Show+Clone(s: S, n: int) { let w = W{f:s.clone()}; if n 0 { foo(w, n-1); } } fn main() { foo(W{f:42i},42); } It gave me an error: reached the recursion limit during monomorphization, which... well, that's a possible solution :) I'm not sure whether this is a big problem in practice, but I was wondering if it would be possible to switch to some runtime mechanism in cases like this. Maybe we could make a special version of every generic functions, that takes a dictionary at runtime and that would be able to handle types unknown at compile-time. We would switch to this version when monomorphization does not work. It could also allow dynamic linking of libraries with generic functions, or it could be a way to compile some programs (or some parts of programs) much faster. I was thinking about, for example, an IDE where generic function calls to types defined inside the files currently being edited use their dynamic version, so that recompile times can be virtually inexistent (like Java). On the other hand, the release build would of course monomorphize as much as possible to make the perf optimal. Now the question is: would this conform to the current semantic of monomorphization? Do special things happen during monomorphization that cannot be reproduced at runtime? This is the case in C++ (and one of the reasons why C++ templates are so bad). Is it the case in Rust, which should already have all the required info (type bounds) before monomorphization? I apologize if this has already been discussed. I could not find many satisfying answers by googling. Cheers, LP. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] moving out few odd libraries from the main tree
I believe it has long been the goal that once we have a robust package manager, we would start moving everything we could get away with out of the tree. Cargo is pretty awesome now, and I think we could get away with moving those out, with the caveat that cargo depends on semver.. On Mon, Jul 21, 2014 at 2:28 PM, Ilya Dmitrichenko errordevelo...@gmail.com wrote: It would be great to discuss which libraries can be removed from the main tree, I can see that there had been some progress with liburl [1], but there appear to be a few other very dubious libraries that can easily leave outside of the main tree. The ones I was able to spot so far, would be: - libfourcc - libsemver The main question would be where would these live on github? Should it be under the main (`github.com/rust`) organisation or actually we could consider creating `github.com/rust-libs`? [1]: https://github.com/rust-lang/rust/issues/10707 Cheers, -- Ilya ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
That's right. `BufferedReader` takes the `Reader` it wraps by-value, but the `read` method takes `mut self`. Moving something doesn't require it to be stored in a mutable variable, but taking a `mut` to it does. On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson di...@ubuntu.com wrote: Hi, Consider these two examples: 1) let mut file = File::open(filename); file.read(buf); 2) let file = File::open(filename); let mut reader = BufferedReader::new(file); reader.read(buf); My question is: in example 2, why doesn't BufferedReader need file to be mutable? After all, BufferedReader ends up calling file.read(), which needs a mutable reference to the file. It looks like I'm able to bypass the mutability requirement, just because I wrap the file inside a BufferedReader? // David ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
Complaining about something I don't like: Due to the choice of MPLv2, this won't be usable in the wider Rust ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) requires that any distribution in Executable Form carry a notice about how to acquire the source code of zmq.rs. This is not unworkable, but it is something we have avoided so far in the community. Otherwise, I look forward to reviewing this in more depth tomorrow. Nice work! On Tue, Jul 1, 2014 at 11:38 PM, Fantix King fantix.k...@gmail.com wrote: Hi, Here is zmq.rs, a native implementation of ØMQ in the Rust programming language in MPLv2. I've just got a very ugly prototype running till now, and I'm expecting to hear more comments on anything. https://github.com/zeromq/zmq.rs For who wants to know more about ØMQ, it looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. (according to http://zguide.zeromq.org/page:all) Back to the project, I did a few iterations and got what it is now, in the hope that more discussion can be raised over some actual code to talk about. zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I also blogged a bit about the design here (more to come): http://blog.segmentfault.com/fantix/119000593564 You are more than welcome to: * comment on the design * suggest different solution * complain about whatever you don't like * open issues on github * send me PRs and code reviews * join me developing and maintaining it * or even star it on github ;) BR, Fantix -- http://about.me/fantix ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
See also the discussion on IRC: https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232page=22 It wasn't my intention to discourage using any particular license, but to raise its requirements if they weren't consciously chosen. On Wed, Jul 2, 2014 at 12:33 PM, SiegeLordEx slab...@aim.com wrote: On 07/02/2014 03:16 AM, Corey Richardson wrote: Complaining about something I don't like: Due to the choice of MPLv2, this won't be usable in the wider Rust ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) requires that any distribution in Executable Form carry a notice about how to acquire the source code of zmq.rs. This is not unworkable, but it is something we have avoided so far in the community. I should note that this is not a universally held opinion in the Rust community. While it is true that many/most current Rust projects mimic the license of `rustc` itself, there's nothing in Rust as a language that precludes or encourages the use of any particular license. The mentioned 'avoidance' is likely a consequence of the people just preferring those licenses (i.e. they'd use them for their non-Rust projects as well) rather than Rust being against the spirit of attribution, share-alike, copyleft etc per se. Personally, I would encourage Free Rust software just like I would encourage it in any other language. You shouldn't feel like you need to compromise on your moral principles (or whatever else you consult when choosing a license) to contribute to Rust's success. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] box syntax question
The full syntax is: box [( EXPR )] EXPR The first expression is the boxer, or where the result of the second expression will be stored. GC and HEAP are special cased right now as the only boxers, but the goal is to use a trait such that you can use Rc, arenas, vectors, or any other arbitrary type as a boxer. On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin os...@twitter.com wrote: Once in the tutorial, I see this syntax: let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10]; It seems to me, that should be: boxGc, as it feels like box is referring to a container type (which the default type is Box_, but may be Rc_ or Gc_). What is the principle behind the current notation? What is GC is this context other than a special string that is a one-off syntax? -- Oscar Boykin :: @posco :: http://twitter.com/posco ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Initial Alpha of Cargo
There is an Ubuntu PPA available at https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or otherwise. On Mon, Jun 23, 2014 at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote: Folks, I'm happy to announce that Cargo is now ready to try out! The Cargo repository is now at https://github.com/rust-lang/cargo and you can learn all about it at http://crates.io/. Don't forget to check out the FAQ at http://crates.io/faq. You can build Cargo from master using the latest `rustc` and running `make install`. It assumes a `rustc` and `git` on the path, so you won't need to recompile Cargo every time you update the nightly. Cargo is still under heavy development and features are coming quickly. At the moment, all dependencies are downloaded from Github, but we are working on a Cargo registry that you will be able to publish packages to. There are more details about that in the FAQ. The next features we're planning on working on are: `cargo package name` to create a new package skeleton Supporting refs other than `master` from git packages Support for environments (such as development, production and test) as well as a `cargo test` command. This includes per-environment dependencies. Support for per-platform configuration. More deterministic builds using a shrinkwrap file (like the bundler Gemfile.lock or shrinkwrap.json in npm). Since people have asked often, we plan to transparently support duplicates of the same package name and version in the following conditions: From different git repositories or different branches of the same git repository In versions less than 1.0 for packages from the Cargo registry For different major versions for packages from the Cargo registry By default, we will encourage package authors to comply with semantic versioning and not introduce breaking changes in minor versions by using the single highest available minor version for each depended-on major version of a package from the Cargo registry. For example, if I have three packages: uno depends on json 1.3.6 dos depends on json 1.4.12 tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. This makes good use of Rust's symbol mangling support, while also avoiding unnecessary code bloat. This will tend to produce significantly smaller binary sizes than encouraging libraries to depend on precise versions of published packages. We tried to strike a good balance between isolating unstable code and avoiding binary bloat in stable libraries. As the ecosystem grows, we'll watch carefully and see if any tweaks are necessary. Yehuda Katz (ph) 718.877.1325 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling Rust programs with the Meson build system
Hey Jussi, Very cool! Always happy to see tools with Rust support :) As to file names, do you know about `rustc --crate-file-name`? On Wed, Jun 18, 2014 at 3:17 PM, Jussi Pakkanen jpakk...@gmail.com wrote: Hi I'm working on a build system called Meson (https://jpakkane.github.io/meson/) and I figured I'd add native Rust support. Here's what a build definition for a simple Rust application ended up looking: - project('rustproject', 'rust') executable('rustprog', 'prog.rs') This gives you all the features you'd expect such as different build types (debug/release/etc), accurate dependency tracking via --dep-info, unit tests, install targets and so on. Shared library support is there, but I need to first fix one issue before it will actually work. This has to do with the fact that you can't know beforehand what the output file name will be (if you set it manually with -o, rustc will not link against it). If you want to try it our yourself, here's the steps: - check out Meson's git trunk: https://github.com/jpakkane/meson - cd into it, mkdir buildtest - ./meson.py test\ cases/rust/1\ basic buildtest - cd buildtest - ninja (or ninja-build if you are on Fedora) Test 2 does not work because of the above mentioned issue, so you probably don't want to run it. Feel free to try it out. If you have any questions I'm happy to answer them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] self/mut self in traits considered harmful(?)
Or bound by Copy. On Thu, Jun 12, 2014 at 10:17 AM, Patrick Walton pwal...@mozilla.com wrote: You could just clone the value to get around that error. On June 12, 2014 10:03:40 AM PDT, Tommi rusty.ga...@icloud.com wrote: On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote: On 6/11/14 6:27 AM, SiegeLord wrote: So, I think the situation is pretty bad. What can be done to fix it? Seems to me we can just make the overloaded operator traits take by-value self. I definitely wouldn't want to see something like the following: pub trait GreaterByOneT { fn greater_by_one(self) - Self; } pub fn my_algorithmX, T: GreaterByOneX + AddT, T(value: T) - T { value.greater_by_one() + value.greater_by_one() // error: use of moved value: `value` } -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] self/mut self in traits considered harmful(?)
It's called Copy. `trait Foo: Copy { ... }`. On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote: I think a new keyword, something like `stable`, is needed for specifying that an argument passed to a trait function is guaranteed to be logically unchanged after the function call. For example: trait Foo { fn foo(stable self); } impl Foo for int { fn foo(self) {} // OK } impl Foo for uint { fn foo(self) {} // OK } impl Foo for Boxint { fn foo(stable self) {} // OK (implicitly clones self) } fn main() { let x: Boxint = box 42; x.foo(); // `x` is implicitly cloned x.foo(); // OK } ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] self/mut self in traits considered harmful(?)
Implicit cloning is a non-starter. Clones can be very expensive. Hiding that cost is undesirable and would require adding Clone to the language (it's currently a normal library feature). On Thu, Jun 12, 2014 at 10:46 AM, Tommi rusty.ga...@icloud.com wrote: `Copy` types aren't really relevant to a discussion about adding to Rust the C++ like optimization of moving rvalues (of non-Copy types) when they're passed to certain functions. On 2014-06-12, at 20:30, Corey Richardson co...@octayn.net wrote: It's called Copy. `trait Foo: Copy { ... }`. On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote: I think a new keyword, something like `stable`, is needed for specifying that an argument passed to a trait function is guaranteed to be logically unchanged after the function call. For example: trait Foo { fn foo(stable self); } impl Foo for int { fn foo(self) {} // OK } impl Foo for uint { fn foo(self) {} // OK } impl Foo for Boxint { fn foo(stable self) {} // OK (implicitly clones self) } fn main() { let x: Boxint = box 42; x.foo(); // `x` is implicitly cloned x.foo(); // OK } ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Is there a Parsec equivalent in Rust?
We have a ragel backend. https://github.com/erickt/ragel On Thu, Jun 12, 2014 at 3:28 PM, richo ri...@psych0tik.net wrote: On 11/06/14 15:43 +0900, Akira Hayakawa wrote: Hi, Haskell's Parsec is really a good tool to parse languages. Scala also has the equivalent. What about Rust? Largely offtopic, but I've spent the last few days thinking seriously about working on a ragel backend for rust, which while orthagonal to Parsec (which I love), would be another option for solving a lot of the same problems. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] self/mut self in traits considered harmful(?)
Keeping in mind that the `self` value here can be a reference. Ie, implementing the traits also for references to a type. On Wed, Jun 11, 2014 at 11:47 AM, Tommi rusty.ga...@icloud.com wrote: On 2014-06-11, at 21:33, Daniel Micay danielmi...@gmail.com wrote: Cloning big integers, rationals based on big integers or arbitrary precision floating point values for every single operation has a high cost. I didn't say that all functions should start taking their arguments by value. I said `Mul` and similar should do it, i.e. functions that take a variable and return a variable of that same type. Instead of passing by reference and making a clone of the passed reference inside those functions, you force the caller to make the clone and mutate the passed argument in place. This enables the C++ like rvalue reference optimization for functions like multiplication. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] how is Rust bootstrapped?
I currently have 4246 builds of rustc, going back to a little bit before bors started being used. On Mon, Jun 9, 2014 at 10:16 AM, Steve Klabnik st...@steveklabnik.com wrote: I have this pipe dream of compiling every Rust version ever and GPG signing them though heh. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust (Servo) Cross-Compile to ARM
You need to change the target, not just the target-cpu. `rustc --target arm-unknown-linux-gnueabihf ...` On Sun, Jun 8, 2014 at 2:57 PM, Skirmantas Kligys skirmantas.kli...@gmail.com wrote: Luqman Aden laden@... writes: Building a Rust cross compiler that can target arm isn't too hard. You just need the right toolchain installed. I personally use Debian with the gcc-4.7-arm-linux-gnueabi package from the Emdebian repo. (I believe Ubuntu and other distros have similar packages). From there it's just a simple matter of passing the right triple to the configure script. ./configure --target=arm-unknown-linux-gnueabi make That'll build a rustc that can target arm as well as all the libraries. Then you can run it like so: rustc --target=arm-unknown-linux-gnueabi --linker=arm-linux-gnueabi-gcc hello.rs That'll give you a binary, hello, which will run on arm/linux. So, that's the basic gist of it. I am trying to follow these instructions and also https://gist.github.com/amatus/6665852 unsuccessfully. export PATH=$PWD/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian- x64/bin:$PATH cd rust ./configure --prefix=/usr/local/stow/rust-pi-20140608 --target=arm-unknown- linux-gnueabihf make -j2 sudo make install cfg: build triple x86_64-unknown-linux-gnu cfg: host triples x86_64-unknown-linux-gnu cfg: target triples x86_64-unknown-linux-gnu arm-unknown-linux-gnueabihf cfg: non-build target triples arm-unknown-linux-gnueabihf cfg: enabling more debugging (CFG_ENABLE_DEBUG) cfg: host for x86_64-unknown-linux-gnu is x86_64 cfg: host for arm-unknown-linux-gnueabihf is arm cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu cfg: os for arm-unknown-linux-gnueabihf is unknown-linux-gnueabihf cfg: using CC=gcc (CFG_CC) cfg: no pdflatex found, deferring to xelatex cfg: no xelatex found, deferring to lualatex cfg: no lualatex found, disabling LaTeX docs cfg: no pandoc found, omitting PDF and EPUB docs cfg: no llnextgen found, omitting grammar-verification ... A rustc gets built, but it targets Intel: $ rustc -C target-cpu=help hello.rs Available CPUs for this target: amdfam10 - Select the amdfam10 processor. athlon- Select the athlon processor. athlon-4 - Select the athlon-4 processor. athlon-fx - Select the athlon-fx processor. athlon-mp - Select the athlon-mp processor. athlon-tbird - Select the athlon-tbird processor. athlon-xp - Select the athlon-xp processor. athlon64 - Select the athlon64 processor. athlon64-sse3 - Select the athlon64-sse3 processor. ... Any ideas? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Building rustc @ 1GB RAM?
1.4GB peak, consumed by rustc and every child process. The bencher is currently running after being down for a while, so it will fill in today. There are no real workarounds. On Thu, Jun 5, 2014 at 11:13 AM, Ian Daniher explodingm...@gmail.com wrote: 1GB is close-ish to the 1.4GB last reported (over a month ago!) by http://huonw.github.io/isrustfastyet/mem/. Are there any workarounds to push the compilation memory down? I'm also exploring distcc, but IRFY has a bit of semantic ambiguity as to whether or not it's 1.4GB simultaneous or net total. Thanks! -- Ian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The meaning of 'box ref foo' ?
As with most things in Rust, in a pattern, a keyword means the *opposite* of its normal meaning. So where `box e` in an expression will box up the result of `e`, `box p` in a pattern will unbox `p`. On Tue, May 27, 2014 at 9:50 AM, Tommi rusty.ga...@icloud.com wrote: What is the meaning of this 'box ref foo' syntax found in the tutorial over at http://doc.rust-lang.org/tutorial.html#references In short, it's: enum Shape { Sphere(Boxf32) } let shape = Sphere(box 1.0f32); let r = match shape { Sphere(box ref radius) = *radius }; I thought the 'box' keyword meant: allocate on heap and wrap into a Box. That doesn't make sense to me in the context of 'box ref radius'. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback
Given the size of the binaries it looks like you may not have been passing -O, which often gives the best code size. On Thu, May 22, 2014 at 1:27 PM, Alexander Tsvyashchenko n...@endl.ch wrote: Hi All, Recently I was playing with bindings generator from C++ to Rust. I managed to make things work for Qt5 wrapping, but stumbled into multiple issues along the way. I tried to summarize my pain points in the following blog post: http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5 I hope that others might benefit from my experience and that some of these pain points can be fixed in Rust. I'll try to do my best in answering questions / acting on feedback, if any, but I have very limited amount of free time right now so sorry in advance if answers take some time. Thanks! -- Good luck! Alexander ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] dynamic memory allocations
No, there are no task-specific heaps. An old concept from the manual is the exchange heap, which is where ~ boxes lived (ie, the normal heap) and that @-boxes were some magic task-local heap. But you can always send BoxT between tasks. There's been mention of wanting a task-local box in IRC. However, jemalloc uses per-thread caches, and does not always need to synchronize allocation. On Wed, May 21, 2014 at 6:19 AM, Zoltán Tóth zo1...@gmail.com wrote: Daniel Micay danielmi...@gmail.com wrote: ... the default allocator, which is jemalloc right now. Rust's memory management is still under-documented in the manual. I have a question which have been bothering me for a while. I may have misunderstood something basic. Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready. However does Rust not use task-specific heaps? [I thought that most of the dynamic allocations happen in task-specific heaps.] For those is Jemalloc's synchronization not an unnecessary waste of processor time? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] owned pointer vs. owning pointer vs. owned box
See https://github.com/mozilla/rust/wiki/The-Rusticon for an up-to-date glossary and syntax reference. On Tue, May 20, 2014 at 3:59 PM, Daniel Micay danielmi...@gmail.com wrote: On 20/05/14 06:45 PM, Masanori Ogino wrote: Hello. I found that the Reference Manual uses the term owning pointer, the Pointer Guide and liballoc do owned pointer and Tutorial does owned box. Which term is canonical today? -- Masanori Ogino masanori.og...@gmail.com mailto:masanori.og...@gmail.com http://twitter.com/omasanori http://gplus.to/omasanori Either owned box (a dynamic allocation owned by a pointer) or owning pointer (a pointer owning a dynamic allocation) is accurate. On the other hand, the term 'owned pointer' doesn't make sense as even references and `RcT` are an owned *pointer*, but the ownership relationship doesn't pass through them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] morestack prologue contains broken machine code
Sending it upstream is far better. Ping someone (probably Alex) to upgrade our LLVM once it's merged. On Tue, Apr 22, 2014 at 3:43 AM, Vladimir Pouzanov farcal...@gmail.com wrote: The problem is that mrc is generated unless target is thumb1, but cortex-m3 is thumb2 that still doesn't support mrc: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka398.html, so an additional check to ST-TargetTriple.Data is required to verify it's not thumbv7m. Do I need to submit patch against https://github.com/rust-lang/llvm or send it to upstream? On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov farcal...@gmail.com wrote: Hm, it seems to have precautions to stop mrc from materializing on Thumb1. I guess I need to take a better look into what's going wrong on my side. I'll see what I can do with that. On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton a...@crichton.co wrote: The split stack patches for ARM were recently upstreamed, and they were modified when being upstreamed as well. Primarily the location of the split stack is no longer at a magic address for thumb, but rather it uses the same instruction as ARM (some thumb processors do indeed have the coprocessor). More information is in the long thread starting at the initial attempt to upstream [1]. For now you'll have to use no_split_stack because the thumb split stack will always use a coprocessor, but I'm sure that the upstream LLVM devs would be quite welcoming to tweaks to the slit-stack support (I'd also be willing to help). You can find the initial commit for support at rust-lang/llvm [2]. [1] - http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html [2] - https://github.com/rust-lang/llvm/pull/4 On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com wrote: Starting recently (no more than two weeks), rustc is generating a broken prologue for arm. Here's the sample assembly: 0x0f44 +0: push {r4, r5} = 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3} 0x0f4a +6: mov r5, sp 0x0f4c +8: b.n 0xa78 main+2616 0x0f4e +10: ands r4, r0 0x0f50 +12: cmp r4, r5 0x0f52 +14: bcc.n 0xf66 _ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34 0x0f54 +16: movs r4, #16 0x0f56 +18: movs r5, #0 0x0f58 +20: push {lr} 0x0f5a +22: bl 0x19d8 __morestack 0x0f5e +26: ldr.w lr, [sp], #4 0x0f62 +30: pop {r4, r5} 0x0f64 +32: bx lr The problem is at 0x0f46, where code tries to read from coprocessor 15 register 13, which is process id register. Well, coprocessor 15 (actually, all of the coprocessors) are missing from my target thumbv7m-linux-eabi (with added flavour of -Ctarget-cpu=cortex-m3, which should be redundant anyway), so I'm getting hardfaults in every function that rust doesn't inline. Any ideas on what might be going wrong? I assume that this is actually llvm's fault, as llvm should not materialize machine code which is not available for target anyway. Wrapping everything in #[no_split_stack] is a temporary workaround and surely not a long-term strategy. -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing ~foo
`box foo` would create a SomeBox'static str, as outlined in the meeting notes: box foo - Heap'static Str foo.to_owned() - HeapStr (or ~Str) Heap::from(foo) - HeapStr (or ~Str) Rc::from(foo) - RcStr On Tue, Apr 15, 2014 at 2:06 PM, SiegeLord slab...@aim.com wrote: On 04/15/2014 01:12 PM, Patrick Walton wrote: The new replacement for `~foo` will be `foo.to_owned()`. You can also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you will likely also be able to write `Heap::from(foo)`. Why not `box foo`? Is that scheduled to break? -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Large Collection of rustc builds
Hello all, I now have on a disk here every merge into master that builds on my machine, built. That is, 3733 copies, using 560GB of disk, of rustc going back to the first run of bors on February 1, 2013. If there's anything interesting you want to do with them, let me know! -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Debugging with Rust 0.11 nightly
-g, or --debuginfo (0|1|2) will generate debuginfo. -g means --debuginfo 2. see rustc --help for more details. On Thu, Apr 10, 2014 at 8:13 AM, Artella Coding artella.cod...@googlemail.com wrote: Previously I would have debugged using the command rustc -Z debug-info example.rs. However with Rust 0.11 nightly it does not work. What do I replace the above command with? Thanks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] impl num::Zero and std::ops::Add error
range doesn't return a forward iterator. RangeA also implements DoubleEndedIterator. On Thu, Apr 10, 2014 at 12:53 AM, Kevin Ballard ke...@sb.org wrote: On Apr 9, 2014, at 9:50 PM, Tommi Tissari rusty.ga...@icloud.com wrote: On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote: FWIW, my point about range is it relies on One being the number 1, rather than being the multiplicative identity. AFAIK there's nothing special about 1 in a ring outside of its status as a multiplicative identity. Certainly it's not considered some special value for addition. Another problem with std::iter::range is that it requires too much from its argument type A by saying A must implement AddA, A while it only returns a forward iterator. Perhaps, in order to make a more sensible implementation of iter::range, a new concept, a trait, is needed to be able to specify that a certain type T implements a method 'increment' that modifies a variable of type T from value x to value y such that: 1) x y 2) there is no valid value z of type T satisfying x z y For integral types there would an implementation of this trait in stdlib with 'increment' doing x += 1; Then, a natural extension to this trait would be a trait that has a method 'advance(n: uint)' that would, at constant time, conceptually call the 'increment' method n times. Then there would also be a 'decrement' method for going the other direction. There probably needs to be some other use cases for this new trait to carry its weight though. This trait would disallow range(0f32, 10f32) because there are quite a lot of valid values z of type f32 satisfying 0f32 z 1f32. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Porting some nesC features to rust?
You don't use bounds in the struct, you put them in the impl. So you would instead say struct LCDS { spi: S, ... } and then: implS: SPI LCDS { ... } On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com wrote: I might have found an unsupported case. Consider the following: trait SPI { ... } struct McuSPI; impl SPI for McuSPI { ... } struct LCD { spi: SPI, ... } This code results in a dynamic dispatch to SPI, as trait bounds are not allowed in structure definitions. Is it in any way possible to use static dispatch from LCD to SPI given the exact implementations are known at compile time? On Thu, Apr 3, 2014 at 2:46 AM, Ashish Myles marci...@gmail.com wrote: And just in case there is a confusion (as I have noticed others to have), it might help to see a specific example comparing static dispatch with dynamic. // This is a single function for all types implementing the LCD Trait. fn foo(x : LCD) { // x's type is LCD rather than the actual type of the object being passed in x.line(); // dynamic dispatch } // Like C++ templates, this generates a function for each type T that implements LCD. fn fooT : LCD(x : T) { // x's type is T rather than LCD x.line(); // static dispatch based on type T known at compile-time } On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com wrote: On 02/04/14 06:25 AM, Vladimir Pouzanov wrote: If I get it right, calls to traits are resolved in runtime (so, traits are kind of similar to C++ virtual methods). All method calls on regular types are resolved via static dispatch, whether or not they come from a trait. For example, consider a generic function like the following: fn minT: TotalOrd(a: T, b: T) - T { if a b { a } else { b } } This function performs a *static* call of the `lt` method defined on the `Ord` trait that `TotalOrd` inherits from. Generics are fully expanded at compile-time just as C++ templates are. Rust also allows using traits as boxed objects, but this is an entirely transparent choice. They're almost always used for static dispatch via trait bounds on generics, or simply outside of generics. What I'm proposing here is a compile-time approach. Let's say we have the following trait: pub trait LCD { fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8); fn rect(mut self, x0: i32, y0: i32, x1: i32, y1: i32, color: u8); fn fillrect(mut self, x0_b: i32, y0_b: i32, x1_b: i32, y1_b: i32, color: u8); fn putc(mut self, value: char); fn puts(mut self, s: str); fn flush(self); fn clear(mut self); } which defined a LED screen. There are two structs implementing it: C12832 and ILI9341 (two different lcd controllers). So I want my app to print hello world on lcd, I write the following code: let mut lcd = lcd_c12832::C12832::new(spi); let mut l: mut lcd::LCD = lcd as mut lcd::LCD; l.puts(hello, world); Which results in a runtime dispatch, a slower and bigger code than the one I'd have without a trait. You can call methods defined on a trait without boxing the object as a trait object. The ability to perform dynamic dispatch via a trait object is totally optional. The methods can also be called directly, including inside a generic function by specifying the trait as a type parameter bound. You can simply call the `puts` method directly on the `lcd` object without a cast. A second problem is there is no easy way to write unified code that supports both the lcds based on passed in --cfg, as I can't apply #[cfg(lcd_c12832)] to a chunk of code in fn, and it's kind of problematic to return a LCD out from it given that there is no heap and no analog of placement new from C++. Rust supports generic functions, and you can write code supporting both types by making it generic. The choice between static dispatch and dynamic dispatch is entirely up to you in the current system. Proposed binding concept solves those two problems: #[cfg(lcd_c12832)] let Binding: binding { let lcd: lcd_c12832::C12832; let main: Main; bind main.lcd = lcd; } at this point of time compiler can be sure about what struct is implementing LCD trait for main.lcd and can bind the function bodies as compile time, inlining them if applicable. This also might be something that is already implemented, please advice. The goal here is to minimise runtime code being executed and its size. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/
Re: [rust-dev] Porting some nesC features to rust?
`'static SPI` is going to be a trait object (with dynamic dispatch). The error it's giving is that `SPI` (the trait object) doesn't implement `SPI` (the trait). You would have to explicitly implement `SPI` for `SPI`. I'm not really sure how to solve this without using trait objects; you seem to want an inherently dynamically-dispatched system. On Tue, Apr 8, 2014 at 2:08 PM, Vladimir Pouzanov farcal...@gmail.com wrote: That actually worked much better than I expected inlining everything and getting rid of vtables (I don't have support for .data section at the moment :-) ). I can't say the syntax is very clear to me, but I can get used to it. Still, one more question remains. I have a debug output concept, which means that debug::d(str) gets delivered to either LCD or UART, whatever is configured at runtime. I do it via static mut: pub trait Debugger { fn debugs(mut self, s: str); } pub static mut debug_output: *mut c12332::C12332'static, 'static spi::SPI = unsafe { init() }; pub fn d(s: str) { let debugger = unsafe { mut (*debug_output) as mut Debugger }; // failed to find an implementation of trait hal::spi::SPI for 'static hal::spi::SPI:'static debugger.debugs(s); } pub fn set_debugger(lcd: *mut c12332::C12332spi::SPI) { unsafe { debug_output = lcd; }; } I don't really support UART now, but I'd still like to access my LCD via a globally known static getter. How can I re-write that with typed struct? On Tue, Apr 8, 2014 at 6:26 PM, Corey Richardson co...@octayn.net wrote: You don't use bounds in the struct, you put them in the impl. So you would instead say struct LCDS { spi: S, ... } and then: implS: SPI LCDS { ... } On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com wrote: I might have found an unsupported case. Consider the following: trait SPI { ... } struct McuSPI; impl SPI for McuSPI { ... } struct LCD { spi: SPI, ... } This code results in a dynamic dispatch to SPI, as trait bounds are not allowed in structure definitions. Is it in any way possible to use static dispatch from LCD to SPI given the exact implementations are known at compile time? On Thu, Apr 3, 2014 at 2:46 AM, Ashish Myles marci...@gmail.com wrote: And just in case there is a confusion (as I have noticed others to have), it might help to see a specific example comparing static dispatch with dynamic. // This is a single function for all types implementing the LCD Trait. fn foo(x : LCD) { // x's type is LCD rather than the actual type of the object being passed in x.line(); // dynamic dispatch } // Like C++ templates, this generates a function for each type T that implements LCD. fn fooT : LCD(x : T) { // x's type is T rather than LCD x.line(); // static dispatch based on type T known at compile-time } On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com wrote: On 02/04/14 06:25 AM, Vladimir Pouzanov wrote: If I get it right, calls to traits are resolved in runtime (so, traits are kind of similar to C++ virtual methods). All method calls on regular types are resolved via static dispatch, whether or not they come from a trait. For example, consider a generic function like the following: fn minT: TotalOrd(a: T, b: T) - T { if a b { a } else { b } } This function performs a *static* call of the `lt` method defined on the `Ord` trait that `TotalOrd` inherits from. Generics are fully expanded at compile-time just as C++ templates are. Rust also allows using traits as boxed objects, but this is an entirely transparent choice. They're almost always used for static dispatch via trait bounds on generics, or simply outside of generics. What I'm proposing here is a compile-time approach. Let's say we have the following trait: pub trait LCD { fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8); fn rect(mut self, x0: i32, y0: i32, x1: i32, y1: i32, color: u8); fn fillrect(mut self, x0_b: i32, y0_b: i32, x1_b: i32, y1_b: i32, color: u8); fn putc(mut self, value: char); fn puts(mut self, s: str); fn flush(self); fn clear(mut self); } which defined a LED screen. There are two structs implementing it: C12832 and ILI9341 (two different lcd controllers). So I want my app to print hello world on lcd, I write the following code: let mut lcd = lcd_c12832::C12832::new(spi); let mut l: mut lcd::LCD = lcd as mut lcd::LCD; l.puts(hello, world); Which results in a runtime dispatch, a slower and bigger code than the one I'd have without a trait. You can call methods defined on a trait without boxing the object as a trait object. The ability to perform dynamic dispatch via a trait object is totally optional. The methods can
Re: [rust-dev] Building a static array of pointers
A C-style array is written `*T`, much like in C (note: I'm not saying `T*` and `T[]` are the same type, I know they aren't) On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin simon.sa...@exyr.org wrote: On 05/04/2014 11:39, Vladimir Pouzanov wrote: The problem is that [extern unsafe fn()] results in 8 bytes, pointer to the actual array and its size. Is there any way I can get a plain C-style array in rust? If the size is known as compile-time you can use: static table: [extern unsafe fn(), ..2] = [foo, bar]; -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tagged integral floating-point types
Language suggestions should go through our new RFC process: https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md On Thu, Apr 3, 2014 at 8:26 PM, Tommi rusty.ga...@icloud.com wrote: I forgot to mention that this same space-optimization could be done for Optionbool already. On 2014-04-04, at 03:18, Tommi rusty.ga...@icloud.com wrote: I have a suggestion. Let's add new primitive data types: i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63 Those would behave exactly like the integral data and floating-point data types: i8, i16, i32, i64, u8, u16, u32, u64, f32 and f64 ...except that the new data types would come with the (unchecked) promise that the high-order bit of each of those new data types' representations would never be set to 1 (with the floating-point types it would be the high-order bit of the exponent). That would reduce the range of values the user is supposed to represent with those types. But the new types would give rise to an optimization for OptionX, where X is one of the new primitive data types: OptionX wouldn't need to use extra memory for a separate tag, but could simply use the high-order bit as a tag to indicate the None case. If a user assigns a value which sets the high-order bit of those data types, then it would be considered a logical overflow (even though the actually representation hasn't overflown) and Some(x) where x is such a logical overflown value would be None (which, to me, kind of makes sense). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 0.10 prerelease testing
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik st...@steveklabnik.com wrote: I compiled from source just yesterday, but everything's been going swimmingly! I just have one comment on 0.10: It seems like println was removed from the prelude. While I can totally appreciate that most people will use println!, which is automatically use-able, it _is_ making my 'hello world' examples significantly more complex, since basically every one of them needs to either import println or use println!({}, foo); I'm not sure if this is a good or bad thing, just wanted to raise that as a possible issue. It has been raised, as an extension to the macro, that invocation with a single, non-string literal, could expand into `println!({}, $that_arg)` rather than requiring the `{}`. -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Porting some nesC features to rust?
See our new RFC process for proposing changes to the language: https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md On Mon, Mar 31, 2014 at 10:01 AM, Vladimir Pouzanov farcal...@gmail.com wrote: I'd like to propose to extend the language with some concepts from nesC, which is a nice but quite unknown C superset outside of TinyOS world. The concept would allow better static polymorphism and better code optimisations and is loosely based on nesC modules/components. It might be possible to implement the same in rust without extending the syntax and compiler, please tell me if that's the case. unbound struct S { reg: u32, comp: ~T, } defines a struct that has a u32 value and some trait. Those values could be used in S impls as usual. It is impossible to create an instance of S, the only way to get it is to bind it in compile time: let Binding: binding { let SImpl: S; let TImpl: T; bind SImpl.reg = 0x12345678; bind SImpl.comp = TImpl; } The result of this is that all references to reg and comp are replaced by actual values (TImpl must obviously be an unbound struct as well), so that the whole SImpl could be optimised away and don't use any storage bytes other than required by constants. Why is it useful? Embedded systems are commonly represented as a tree of components hooked up to one another. Also, resources on embedded are used to be expensive. This code allows to define a configuration of a system which is completely resolved in compile time, allowing better optimisation of the code while maintaining readable code. Some close-to-real-life example: unbound struct Led; impl Led { pub fn set_enabled(self, enabled: bool) { // set the led state } } trait Callable { fn callback(self); } unbound struct Timer { actor: ~Callable, } impl Timer { pub fn start(self) { // init the timer, hardware will call fired() via ISR } fn fired(self) { actor.callback(); } } unbound struct Blinker { mut state: bool, led: Led, timer: Timer, } impl Callable for Blinker { fn callback(self) { self.state != self.state; led.set_enabled(self.state); } } impl Blinker { pub fn main(self) { self.timer.start(); } } let Binding: binding { let timer = Timer; let led = Led; let blinker = Blinker { state: false }; // we can also set the mut property here. This one is static mut by nature, but available only in Blinker impl. bind timer.actor = blinker; bind blinker.timer = timer; bind blinker.led = led; } pub fn main() { Binding.blinker.start(); } -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Alternatively, in this future where people are deploying Rust applications to hundreds of thousands of servers, we could be using Intel's Memory Protection Extensions for much cheaper bounds checking etc. Which surely other applications will be using once bounds checks are nearly free. Rust will still have the advantage of only needing bounds checking for vectors and not *every* pointer like they are integrating into GCC. On Thu, Mar 27, 2014 at 4:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
It's not about debugging, it's about memory safety. It'd be ridiculous to disable bounds checking just because you've done QA. How many security exploits are over- or under-flows? On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote: I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. -- Lee On 27/03/14 23:09, Matthew McPherrin wrote: I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Sandboxed compilation (browser playground)
Daniel Micay (strcat) already has a sandbox. It drives the rusti bot in IRC, and has a web frontend sometimes available at http://strcat.zapto.org:8000/. The source is at https://github.com/thestinger/rust-playpen. There are plans to have a VM run a similar thing on rust-lang.org On Fri, Mar 28, 2014 at 1:09 AM, Jared Forsyth jabap...@gmail.com wrote: I'm thinking about putting together a server that acts similar to play.golang.org - it allows you to learn rust from the comfort of your own browser. Of course, there are some restrictions that must be placed on compilation. Is there a good way to blacklist some standard libraries? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How do I pass -march down to llvm from rustc?
No. See https://github.com/mozilla/rust/pull/8955 and https://github.com/mozilla/rust/issues/11871 for discussion. You can stub out morestack but that won't remove the stack size checks. It's sanest to just compile the IR yourself (the stack checking is a target-specific machine pass, which is why it shows up with --emit asm but not --emit bc) On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov farcal...@gmail.com wrote: So it doesn't work in the end. rustc --emit bc with flags set for cortex-m0 provides exact same bc with only difference in target triple (which makes perfect sense) However, replacing llc step with rustc --emit asm provides a different assembler file, which requires __morestack. Should I expect rustc to generate freestanding code given some additional options? On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.com wrote: Nevermind, I lost -O somewhere in between copying and pasting command line flags. Optimised version doesn't have any morestack references (which is strange concept though). On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov farcal...@gmail.com wrote: Figured out I can use --target thumbv6m-linux-eabi, which implies -mthumb. Now the problem is that if I use rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o instead of three-step process I mentioned before, I get a valid object file for cortex-m0, but functions have big prologues and symbol table is much bigger: U STACK_LIMIT U _GLOBAL_OFFSET_TABLE_ D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E 0008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E 0004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E 0078 t _ZN4main10__rust_abiE t _ZN4wait20h53ffb23463e08f19Maa4v0.0E U __aeabi_unwind_cpp_pr0 U __morestack 004c T main vs. D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E T main in the initial version. Also, I now need to provide __morestack (no idea what's that about). On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote: You should be able to assemble standalone objects for any triple through rustc itself, you'll likely have to specify a different linker or assembler though: rustc foo.rs --target arm-non-linux-gnueabi \ -C linker=arm-non-linux-gnueabi-ld \ -C ar=arm-non-linux-gnueabi-ar As you discovered, you can pass through arguments to LLVM via the -C llvm-args=foo command line option to rustc. If you get complaints that it's an unknown command line argument, it's LLVM telling you those complaints, not rustc. On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov farcal...@gmail.com wrote: I'm trying to experiment with rust and some embedded code. Currently I have to do a three-pass compilation: rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s arm-none-linux-gnueabi-as main.s -o main.o First, I'm not sure how relevant is --target flag for rustc. I seems to change target datalayout/triple in generated bc, but that should be overriden by llc -mtriple anyway, right? Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with rustc: Unknown command line argument '--march=thumb'. Any hints on how can I drop explicit llc and as steps here? -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ -- Sincerely, Vladimir Farcaller Pouzanov http://farcaller.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Goto statement missing
Note that there's Rust support for Ragel (https://github.com/erickt/ragel), so you can just use that. It's much easier than writing out your state machines by hand. On Sun, Mar 23, 2014 at 1:18 PM, Patrick Walton pcwal...@mozilla.com wrote: On 3/23/14 9:04 AM, Clark Gaebel wrote: I think the biggest case for gotos is jumping out of nested loops. Does rust have a nice way of doing that yet? There's labeled break and continue. Use `'foo:` to denote a label. (The reason that we use lifetime syntax there is that eventually it may be possible to denote lifetimes explicitly using labels.) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Was there a weekly meeting on 2014-3-4?
No, due to the Rust Workweek that is this week. On Thu, Mar 6, 2014 at 1:13 AM, Liigo Zhuang com.li...@gmail.com wrote: Hi Rustist: I can't find any information for that in the wiki page: https://github.com/mozilla/rust/wiki/Meetings -- by Liigo, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About RFC: A 30 minute introduction to Rust
Notice that there was a link to a two-month old thread on the list. His email is in that... On Sun, Mar 2, 2014 at 11:44 PM, Fernando Pelliccioni fpellicci...@gmail.com wrote: I don't have the Steve's email address. Please could someone provide it. Thanks. On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccioni fpellicci...@gmail.com wrote: What about Feedback very welcome on the rust-dev mailing list or on Twitter. ? On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton pcwal...@mozilla.com wrote: On 3/2/14 8:34 PM, Fernando Pelliccioni wrote: This is a misleading propaganda against C++. I think it's pure marketing. I hope this code ugly C++ was not on purpose. I think it would be fair that you enable comments on the website so I can show how to code in real C++. Do you dare to discuss seriously? If the feedback is in a different place (mailing list), the reader of the article does not have a chance to really compare the two languages. Sorry, but discussion of blog posts that aren't part of the official Rust documentation aren't on-topic for this mailing list. Please email Steve privately. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [Announcement] cargo-lite v.1.1.0
Hello all, I'm pleased to announce the 1.1.0 release of cargo-lite: https://github.com/cmr/cargo-lite/tree/v1.1.0. You can install it with `pip install cargo-lite`. See the readme for more details. A summary: cargo-lite is a very simple package manager, with no concept of versioning. It requires explicit configuration. It supports rebuilding dependencies when they change (according to mtimes) or when rustc's version changes. These features make it convenient for using when doing development, but it does not attempt to solve any of the hard problems of package management. It compiles crates with -O by default. I find it very useful (which is why I wrote it), and it eases a huge pain: keeping libraries up to date with nightly rustc's. You may find it useful too, even if it's not ideal. -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Opt-in builtin traits
(My idea for the lint was `#[allow_kind(Name)]` , which someone on IRC remarked as opt-out opt-in builtin traits On Fri, Feb 28, 2014 at 4:36 PM, Gábor Lehel glaebho...@gmail.com wrote: I think this is a really great idea. There's another potential compromise that would preserve most of its benefits, and reduce the annotation burden: There was another proposal earlier, driven by similar motivations, that structs with private fields should be non-`Pod`. Combining the two ideas, we could say that the built-in traits would be derived automatically for types with fully-public interiors, and would have to be declared or derived manually if any field is private. This would still accomplish what I think is the most important thing, which is to preserve abstraction boundaries: clients of a thing (type, module, package) should be insulated against changes to its private implementation. Relying on public information is, in this respect, however, fair game. The truly troublesome aspects of the current regime are, I believe, all consequences of the violation of abstraction boundaries. Types like `Cell` rely on these boundaries to ensure their safety, but under the current system, information about their private implementation leaks out. The OP and the above modification to it would both steer clear of this problem. I think the main tradeoffs between the two would be around simpler rules vs. fewer annotations, and the principle of least astonishment. This here idea is more complicated, because it has different rules for fully-public and abstract datatypes, and also (as currently) has different rules for built-in and user-defined traits. In exchange you only have to state your intentions explicitly if you have something to hide. The PoLA is harder to evaluate. Returning to the canonical example, if I write `struct Point { x: int, y: int }`, I think I'd be surprised if it weren't copyable. On the other hand, perhaps the afore-mentioned inconsistencies would also be surprising. So I dunno. This argument is rather weakened by the continued necessity of a `marker::InvariantType` marker. This could be read as an argument towards explicit variance. However, I think that in this particular case, the better solution is to introduce the `MutT` type described in #12577 -- the `MutT` type would give us the invariance. I don't see the difference here. Why do you think this should be handled differently? This is the same sort of abstraction boundary violation as the others: information about private fields is leaking out into the public interface via variance inference. Under the above scheme we could say that type parameters default to invariant for types with private fields, and are inferred for fully-public types. (How you would/could explicitly declare variance is another question, but kind of orthogonal to the idea that you /should/.) On Fri, Feb 28, 2014 at 4:51 PM, Niko Matsakis n...@alum.mit.edu wrote: From http://smallcultfollowing.com/babysteps/blog/2014/02/28/rust-rfc-opt-in-builtin-traits/: ## Rust RFC: opt-in builtin traits In today's Rust, there are a number of builtin traits (sometimes called kinds): `Send`, `Freeze`, `Share`, and `Pod` (in the future, perhaps `Sized`). These are expressed as traits, but they are quite unlike other traits in certain ways. One way is that they do not have any methods; instead, implementing a trait like `Freeze` indicates that the type has certain properties (defined below). The biggest difference, though, is that these traits are not implemented manually by users. Instead, the compiler decides automatically whether or not a type implements them based on the contents of the type. In this proposal, I argue to change this system and instead have users manually implement the builtin traits for new types that they define. Naturally there would be `#[deriving]` options as well for convenience. The compiler's rules (e.g., that a sendable value cannot reach a non-sendable value) would still be enforced, but at the point where a builtin trait is explicitly implemented, rather than being automatically deduced. There are a couple of reasons to make this change: 1. **Consistency.** All other traits are opt-in, including very common traits like `Eq` and `Clone`. It is somewhat surprising that the builtin traits act differently. 2. **API Stability.** The builtin traits that are implemented by a type are really part of its public API, but unlike other similar things they are not declared. This means that seemingly innocent changes to the definition of a type can easily break downstream users. For example, imagine a type that changes from POD to non-POD -- suddenly, all references to instances of that type go from copies to moves. Similarly, a type that goes from sendable to non-sendable can no longer be used as a message. By opting in to being POD (or sendable, etc), library
Re: [rust-dev] Faster hashDoS-proof hashing
See https://mail.mozilla.org/pipermail/rust-dev/2014-February/008766.html, which describes the new hashing code. With a feature flag, you can define arbitrary hashers. On Wed, Feb 26, 2014 at 7:32 PM, Richard Gomes rgomes.i...@gmail.com wrote: How can I apply my impl to several structs? Is there something similar to #[deriving] ? Thanks Richard Gomes http://rgomes.info http://www.linkedin.com/in/rgomes mobile: +44(77)9955-6813 inum: +883(5100)0800-9804 sip:rgo...@ippi.fr On 27/02/14 00:21, Corey Richardson wrote: We already have this. You just need to implement Hasher. On Wed, Feb 26, 2014 at 7:14 PM, Tony Arcieri basc...@gmail.com wrote: On Wed, Feb 26, 2014 at 4:10 PM, Richard Gomes rgomes.i...@gmail.com wrote: I suggest that the user should have the ability to chose the hash algorithm to be employed among a repertoire of some available hash algorithms or maybe an implementation of Hasher that the user decides to create. I'd suggest the default hash function be hashDoS proof (since attacker-controlled data has the tendency to leak deep into programs), however a specifically performance-oriented hash/map (which isn't hashDoS/collision resistant) should be available for those who want to opt into it. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Importing/exporting macros
This is problematic because name resolutions happens far after macro expansion. I think this could be doable with an extremely limited macro module system, but I think it's not-very-good to have the same path syntax for two incredibly different systems. On Tue, Feb 25, 2014 at 4:39 PM, Sean McArthur smcart...@mozilla.com wrote: Rust now has the ability to import macros from other crates, hurray! However, I'd like to propose adjusting the current way of using them to be more like importing/exporting other symbols of a crate. 1) It's more consistent, makes it easier to find where macros came from. 2) Current usage brings name collisions. Current example: pub mod foo { // assume other macros as well #[macro_export] macro_rules! bar ( ... ) } pub mod baz { // assume other macros as well #[macro_export] macro_rules! bar ( ... ) } mod herp { // i want bar! from foo, and some other macros from baz [phase(syntax)] use super::foo; [phase(syntax)] use super::baz; pub Derp = bar!(); // which bar? is this an ICE? or logic error? } Proposed example: pub mod foo { pub marco_rules! bar ( ... ); } pub mod baz { pub marco_rules! bar ( ... ); pub marco_rules! quux ( ... ); } mod herp { use super::foo::bar!; use super::baz::quux!; // using same name macros, no problem use baz! = super::baz::bar!; pub Derp = bar!(baz!()); } ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows
Is this not already expressible with swap/replace? Is there a big improvement here that I'm missing? On Tue, Feb 25, 2014 at 4:23 PM, Kevin Ballard ke...@sb.org wrote: I too was under the impression that you could not read from a mutably-borrowed location. I am looking forward to the ability to move out of a mut (as long as the value is replaced again), if the issues around task failure and destructors can be solved. -Kevin On Feb 25, 2014, at 12:19 PM, Michael Woerister michaelwoeris...@posteo.de wrote: I'm all for it. In fact, I thought the proposed new rules *already* where the case :-) On 25.02.2014 19:32, Niko Matsakis wrote: I wrote up an RFC. Posted on my blog at: http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust-rfc-stronger-guarantees-for-mutable-borrows/ Inlined here: Today, if you do a mutable borrow of a local variable, you lose the ability to *write* to that variable except through the new reference you just created: let mut x = 3; let p = mut x; x += 1; // Error *p += 1; // OK However, you retain the ability to *read* the original variable: let mut x = 3; let p = mut x; print(x); // OK print(*p); // OK I would like to change the borrow checker rules so that both writes and reads through the original path `x` are illegal while `x` is mutably borrowed. This change is not motivated by soundness, as I believe the current rules are sound. Rather, the motivation is that this change gives strong guarantees to the holder of an `mut` pointer: at present, they can assume that an `mut` referent will not be changed by anyone else. With this change, they can also assume that an `mut` referent will not be read by anyone else. This enable more flexible borrowing rules and a more flexible kind of data parallelism API than what is possible today. It may also help to create more flexible rules around moves of borrowed data. As a side benefit, I personally think it also makes the borrow checker rules more consistent (mutable borrows mean original value is not usable during the mutable borrow, end of story). Let me lead with the motivation. ### Brief overview of my previous data-parallelism proposal In a previous post I outlined a plan for [data parallelism in Rust][dp] based on closure bounds. The rough idea is to leverage the checks that the borrow checker already does for segregating state into mutable-and-non-aliasable and immutable-but-aliasable. This is not only the recipe for creating memory safe programs, but it is also the recipe for data-race freedom: we can permit data to be shared between tasks, so long as it is immutable. The API that I outlined in that previous post was based on a `fork_join` function that took an array of closures. You would use it like this: fn sum(x: [int]) { if x.len() == 0 { return 0; } let mid = x.len() / 2; let mut left = 0; let mut right = 0; fork_join([ || left = sum(x.slice(0, mid)), || right = sum(x.slice(mid, x.len())), ]); return left + right; } The idea of `fork_join` was that it would (potentially) fork into N threads, one for each closure, and execute them in parallel. These closures may access and even mutate state from the containing scope -- the normal borrow checker rules will ensure that, if one closure mutates a variable, the other closures cannot read or write it. In this example, that means that the first closure can mutate `left` so long as the second closure doesn't touch it (and vice versa for `right`). Note that both closures share access to `x`, and this is fine because `x` is immutable. This kind of API isn't safe for all data though. There are things that cannot be shared in this way. One example is `Cell`, which is Rust's way of cheating the mutability rules and making a value that is *always* mutable. If we permitted two threads to touch the same `Cell`, they could both try to read and write it and, since `Cell` does not employ locks, this would not be race free. To avoid these sorts of cases, the closures that you pass to to `fork_join` would be *bounded* by the builtin trait `Share`. As I wrote in [issue 11781][share], the trait `Share` indicates data that is threadsafe when accessed through an `T` reference (i.e., when aliased). Most data is sharable (let `T` stand for some other sharable type): - POD (plain old data) types are forkable, so things like `int` etc. - `T` and `mut T`, because both are immutable when aliased. - `~T` is sharable, because is is not aliasable. - Structs and enums that are composed of sharable data are sharable. - `ARC`, because the reference count is maintained atomically. - The various thread-safe atomic integer intrinsics and so on. Things which are *not* sharable include: - Many types that are unsafely implemented: - `Cell`
Re: [rust-dev] Linked libraries and exec size
The size comes from statically linking to the standard library and runtime. To keep size down, you can pass `-C prefer-dynamic` to rustc to link to them dynamically instead. On Mon, Feb 24, 2014 at 6:23 PM, S.A. qmt...@yahoo.com wrote: Hello, I am new to rust and have a question on what options to pass to rustc to reduce the size of the executable. I see a huge variation between the exec generated from a simple C vs Rust program: :: hello1.rs :: fn main () { println!(Hello World!); } :: hello2.rs :: use std::io::stdio; fn main () { stdio::println(Hello World!); } :: hello.c :: #include stdio.h main () { printf (Hello World!\n); } Compilations: $ gcc -o hello_c hello.c $ rustc hello1.rs $ rustc hello2.rs Outputs from the above are: -rwxrwxr-x 1 admin admin8377 Feb 24 17:25 hello_c* -rwxrwxr-x 1 admin admin 2874699 Feb 24 17:25 hello2* -rwxrwxr-x 1 admin admin 2879032 Feb 24 17:25 hello1* As you can see the sizes of the rust execs (hello1 and hello2) are far more than the simple C's. Set of linked libraries are: $ ldd hello_c hello1 hello2 hello_c: linux-vdso.so.1 = (0x7fff00bfe000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f440cfc3000) /lib64/ld-linux-x86-64.so.2 (0x7f440d397000) hello1: linux-vdso.so.1 = (0x7fff8effe000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fbf2e1df000) /lib64/ld-linux-x86-64.so.2 (0x7fbf2e5b3000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbf2dfda000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fbf2dcde000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbf2dac1000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fbf2d8aa000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fbf2d6a2000) hello2: linux-vdso.so.1 = (0x7fffef7fe000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc1853b2000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fc1851a9000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc184de9000) /lib64/ld-linux-x86-64.so.2 (0x7fc1855e3000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc184be5000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc1848e8000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fc1846d2000) Can someone shed some light on this. Thanks ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Question regarding modules
You're assuming `use` loads code, but it only brings names into scope. `mod submodule;` is what loads `submodule` into the crate. See http://static.rust-lang.org/doc/master/tutorial.html#crates-and-the-module-system On Wed, Feb 19, 2014 at 11:37 PM, benjamin adamson adamson.benja...@gmail.com wrote: Hello, I am trying to get over a hurdle I've been stuck on for a while. I can't seem to figure out how to get the 'use' statements to work. I've created the smallest possible examples I could to demonstrate the problem I am having. The first commit shows my first attempt to 'use' a rust module. With this commit I am not using a mod.rs file: https://github.com/ShortStomp/rust-submodule-confusion-example/tree/d0e5445fbfbc01850bf8a4a523a13aff4e50c229 Here is the output I get from the compiler for this basic program: https://gist.github.com/ShortStomp/9107140 My second attempt at getting this basic example to work involves adding a mod.rs file inside the submodule directory. https://github.com/ShortStomp/rust-submodule-confusion-example/tree/5f3d3058ded8b1e29800685cba7a0438f288abe6 I get the same error that I linked in the gist above. So what gives, what fundamental assumption am I getting wrong? The compiler is telling me to try adding an extern mod statement, but I don't think that is what I want. The files I want to use are in no way external to this package, unless that is a cause of my confusion? Thanks! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] issue numbers in commit messages
Bors already mentions the pull request that he merged, and any commits that close or work on issues usually mention that explicitly in their commit message. What more do you want? On Mon, Feb 17, 2014 at 6:40 PM, Nick Cameron n...@ncameron.org wrote: This is a nice solution, I like it. People who know about bors - is it possible to make it work? On Tue, Feb 18, 2014 at 11:39 AM, Steve Klabnik st...@steveklabnik.com wrote: Why not make bors simply add the issue number in when it makes the actual merge commit? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Using Rust with LLVM's Sanitizers
Hey all, As you are probably aware, we use LLVM for code generation and optimization. It is a large project, and one of its cooler features is the variety of sanitizers it provides (http://clang.llvm.org/docs/index.html#using-clang-as-a-compiler). These are not clang-specific, but indeed can be used with Rust! For example, to use AddressSanitizer (asan) on my system, I do: rustc --passes asan,asan-module --link-args /usr/bin/../lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a foo.rs I got the path to the necessary asan library by looking at clang -v -fsanitize=address foo.c For example, the following program: use std::libc::{free,malloc}; fn main() { unsafe { let p = malloc(42); free(p); free(p); } } Outputs https://gist.github.com/cmr/8800111 Similarly, you can use ThreadSanitizer (tsan) by using `--passes tsan` and replacing asan with tsan in the link-args. Also useful is msan (for detecting uninitialized reads) and tsan (for detecting data races). One caveat is that although LLVM will happily run all of the sanitizer passes for you, you can actually only use one at a time (you will see this when you try to link the multiple *san libraries together). Now, these aren't going to be as useful in Rust given its focus on safety, but they can still be useful when debugging unsafe code, writing bindings, etc. Any time valgrind would be useful, often one of the sanitizers can be used with less overhead. Cheers, cmr ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Using Rust with LLVM's Sanitizers
On Tue, Feb 4, 2014 at 12:23 PM, Daniel Micay danielmi...@gmail.com wrote: On Tue, Feb 4, 2014 at 3:45 AM, Corey Richardson co...@octayn.net wrote: Hey all, As you are probably aware, we use LLVM for code generation and optimization. It is a large project, and one of its cooler features is the variety of sanitizers it provides (http://clang.llvm.org/docs/index.html#using-clang-as-a-compiler). These are not clang-specific, but indeed can be used with Rust! For example, to use AddressSanitizer (asan) on my system, I do: rustc --passes asan,asan-module --link-args /usr/bin/../lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a foo.rs I got the path to the necessary asan library by looking at clang -v -fsanitize=address foo.c For example, the following program: use std::libc::{free,malloc}; fn main() { unsafe { let p = malloc(42); free(p); free(p); } } Outputs https://gist.github.com/cmr/8800111 Similarly, you can use ThreadSanitizer (tsan) by using `--passes tsan` and replacing asan with tsan in the link-args. Also useful is msan (for detecting uninitialized reads) and tsan (for detecting data races). One caveat is that although LLVM will happily run all of the sanitizer passes for you, you can actually only use one at a time (you will see this when you try to link the multiple *san libraries together). Now, these aren't going to be as useful in Rust given its focus on safety, but they can still be useful when debugging unsafe code, writing bindings, etc. Any time valgrind would be useful, often one of the sanitizers can be used with less overhead. Cheers, cmr This mostly doesn't work without frontend support. It's true that it will add checks to certain function calls, but the frontend support is missing so the majority of the feature set is not there. It will be unsafe to find out-of-bounds array access, out-of-bounds pointer arithmetic, dereferences of dangling pointers, data races and other problems originating in Rust code. No error is produced for the following: fn main() { unsafe { let xs = [1, 2, 3]; xs.unsafe_ref(3); } } When using `clang`, you get the following error report: = ==15431==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5cbe8eac at pc 0x47b92e bp 0x7fff5cbe8e10 sp 0x7fff5cbe8e08 READ of size 4 at 0x7fff5cbe8eac thread T0 #0 0x47b92d in main (/home/strcat/a.out+0x47b92d) #1 0x7ff1aecacb04 in __libc_start_main (/usr/lib/libc.so.6+0x21b04) #2 0x47b5ec in _start (/home/strcat/a.out+0x47b5ec) Address 0x7fff5cbe8eac is located in stack of thread T0 at offset 44 in frame #0 0x47b6bf in main (/home/strcat/a.out+0x47b6bf) This frame has 1 object(s): [32, 44) 'a' == Memory access at offset 44 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 main Shadow bytes around the buggy address: 0x10006b975180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b975190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b9751a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b9751b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b9751c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x10006b9751d0: f1 f1 f1 f1 00[04]f4 f4 f3 f3 f3 f3 00 00 00 00 0x10006b9751e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b9751f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b975200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b975210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10006b975220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:fb Freed heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==15431==ABORTING Vadim brought this up at https://github.com/mozilla/rust/issues/749#issuecomment-34040924. I'm working on emitting the necessary stuff but the C API is a pain. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
Also after sleeping on it I'm not as big of a fan of this proposal. But, I find the idea raised earlier of having generic blocks to group implementations etc that have the same implementation nice. Fully backwards compat though, so I'm not going to worry about it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Using Default Type Parameters
Default typarams are awesome, but they're gated, and there's some concern that they'll interact unpleasantly with extensions to the type system (most specifically, I've seen concern raised around HKT, where there is conflicting tension about whether to put the defaults at the start or end of the typaram list). I've already come across situations where default typarams will make for a nicer API, but I'm wondering whether I should use them without hesitation, looking forward to when they are no longer gated, or whether I should shun them because they will make my code incompatible with future changes to the language. Is there any thoughts on this so far? This question also applies to other feature gatess; the level of assurance one can use a given feature with without having to deal with explosive breakage down the line. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
Hey all, bjz and I have worked out a nice proposal[0] for a slight syntax change, reproduced here. It is a breaking change to the syntax, but it is one that I think brings many benefits. Summary === Change the following syntax: ``` struct FooT, U { ... } implT, U TraitT for FooT, U { ... } fn fooT, U(...) { ... } ``` to: ``` forallT, U struct Foo { ... } forallT, U impl TraitT for FooT, U { ... } forallT, U fn foo(...) { ... } ``` The Problem === The immediate, and most pragmatic, problem is that in today's Rust one cannot easily search for implementations of a trait. Why? `grep 'impl Clone'` is itself not sufficient, since many types have parametric polymorphism. Now I need to come up with some sort of regex that can handle this. An easy first-attempt is `grep 'impl(.*?)? Clone'` but that is quite inconvenient to type and remember. (Here I ignore the issue of tooling, as I do not find the argument of But a tool can do it! valid in language design.) A deeper, more pedagogical problem, is the mismatch between how `struct Foo... { ... }` is read and how it is actually treated. The straightforward, left-to-right reading says There is a struct Foo which, given the types ... has the members This might lead one to believe that `Foo` is a single type, but it is not. `Fooint` (that is, type `Foo` instantiated with type `int`) is not the same type as `Foounit` (that is, type `Foo` instantiated with type `uint`). Of course, with a small amount of experience or a very simple explanation, that becomes obvious. Something less obvious is the treatment of functions. What does `fn foo...(...) { ... }` say? There is a function foo which, given types ... and arguments ..., does the following computation: ... is not very adequate. It leads one to believe there is a *single* function `foo`, whereas there is actually a single `foo` for every substitution of type parameters! This also holds for implementations (both of traits and of inherent methods). Another minor problem is that nicely formatting long lists of type parameters or type parameters with many bounds is difficult. Proposed Solution = Introduce a new keyword, `forall`. This choice of keyword reads very well and will not conflict with any identifiers in code which follows the [style guide](https://github.com/mozilla/rust/wiki/Note-style-guide). Change the following declarations from ``` struct FooT, U { ... } implT, U TraitT for FooT, U { ... } fn fooT, U(...) { ... } ``` to: ``` forallT, U struct Foo { ... } forallT, U impl TraitT for FooT, U { ... } forallT, U fn foo(...) { ... } ``` These read very well. for all types T and U, there is a struct Foo ..., for all types T and U, there is a function foo ..., etc. These reflect that there are in fact multiple functions `foo` and structs `Foo` and implementations of `Trait`, due to monomorphization. [0]: http://cmr.github.io/blog/2014/02/01/polymorphic-declaration-syntax-in-rust/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On Sat, Feb 1, 2014 at 6:12 PM, Vladimir Lushnikov vladi...@slate-project.org wrote: Also, reusing 'for' would be confusing as well, because you expect a loop there, not a generic type bound. How about 'any': any is a super useful identifier and is already used. I do not want to reserve it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote: Responses inlined. Hey all, bjz and I have worked out a nice proposal[0] for a slight syntax change, reproduced here. It is a breaking change to the syntax, but it is one that I think brings many benefits. Summary === Change the following syntax: ``` struct FooT, U { ... } implT, U TraitT for FooT, U { ... } fn fooT, U(...) { ... } ``` to: ``` forallT, U struct Foo { ... } forallT, U impl TraitT for FooT, U { ... } forallT, U fn foo(...) { ... } ``` The Problem === The immediate, and most pragmatic, problem is that in today's Rust one cannot easily search for implementations of a trait. Why? `grep 'impl Clone'` is itself not sufficient, since many types have parametric polymorphism. Now I need to come up with some sort of regex that can handle this. An easy first-attempt is `grep 'impl(.*?)? Clone'` but that is quite inconvenient to type and remember. (Here I ignore the issue of tooling, as I do not find the argument of But a tool can do it! valid in language design.) I think what I've done in the past was just `grep impl | grep Clone'. A deeper, more pedagogical problem, is the mismatch between how `struct Foo... { ... }` is read and how it is actually treated. The straightforward, left-to-right reading says There is a struct Foo which, given the types ... has the members This might lead one to believe that `Foo` is a single type, but it is not. `Fooint` (that is, type `Foo` instantiated with type `int`) is not the same type as `Foounit` (that is, type `Foo` instantiated with type `uint`). Of course, with a small amount of experience or a very simple explanation, that becomes obvious. I strongly disagree with this reasoning. There IS only one type Foo. It's a type constructor with kind * - * (where * means proper type). Fooint and Foouint are two different applications of Foo and are proper types (i.e. *) because Foo is * - * and both int and uint are *. Regarding people confusing Foo, Fooint and Foouint, I think the proposed forallT struct Foo {...} syntax is actually more confusing. With the current syntax, it's never legal to write Foo without type parameters, but with the proposed syntax it would be. I've yet to see a proposal for HKT, but with them that interpretation would be valid and indeed make this proposal's argument weaker. Something less obvious is the treatment of functions. What does `fn foo...(...) { ... }` say? There is a function foo which, given types ... and arguments ..., does the following computation: ... is not very adequate. It leads one to believe there is a *single* function `foo`, whereas there is actually a single `foo` for every substitution of type parameters! This also holds for implementations (both of traits and of inherent methods). Again, I strongly disagree here. There IS only one function foo. Some of it's arguments are types. foo's behavior *does not change* based on the type parameters because of parametricity. That the compiler monomporphizes generic functions is just an implementation detail and doesn't change the semantics of the function. It can if it uses Any, size_of, etc. eddyb had integers in the typesystem by using size_of and [u8, ..N]. Anything using the properties of types or the tydescs *will* change for each instantiation. Another minor problem is that nicely formatting long lists of type parameters or type parameters with many bounds is difficult. I'm not sure how this proposal would address this problem. All of your proposed examples are longer than the current syntax equivalents. The idea is there is an obvious place to insert a newline (after the forall), though bjz would have to comment more on that. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On Sat, Feb 1, 2014 at 6:31 PM, Corey Richardson co...@octayn.net wrote: On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote: Again, I strongly disagree here. There IS only one function foo. Some of it's arguments are types. foo's behavior *does not change* based on the type parameters because of parametricity. That the compiler monomporphizes generic functions is just an implementation detail and doesn't change the semantics of the function. It can if it uses Any, size_of, etc. eddyb had integers in the typesystem by using size_of and [u8, ..N]. Anything using the properties of types or the tydescs *will* change for each instantiation. Furthermore, I don't considered monomorphic instantiation to be an implementation detail. Without it the difference between trait objects and generics is nonsensical, and iirc there's code that depends on the addresses of different instantiations being different (though I might be confusing that with statics). It's also important to understanding the performance characteristics of Rust, esp binary size and why metadata is so huge. It's a vital detail to understanding Rust, and any use of it needs to consider it. If it is indeed considered an implementation detail, it's probably the most important implementation detail I've seen in anything. Given Rust's target market, it'd be irresponsible to ignore it... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
I see where Tony is coming from for this one. Just because we *can* doesn't necessarily mean we should. If possible we should definitely prefer to find a common version that both libraries can be happy with. I myself don't have the answers to his questions, though. On Fri, Jan 31, 2014 at 6:24 PM, Strahinja Markovic v...@markovic.io wrote: On Fri Jan 31 2014 at 3:03:54 PM, Tony Arcieri basc...@gmail.com wrote: I am 100% clear that, from a technical perspective, Rust has the ability to support multiple different versions of the same library simultaneously. However: 1) Is this a good idea? Of course it's a good idea. There's a need for that today in C++, Python and other languages. Without this feature you end up in the clash of there's no single version that satisfies all of my deps and you're sad and unhappy. And waste time and money. With Rust, the symbols won't conflict so there's no downside. 2) Is this compatible with the idea of toposort-style dependency resolution? I honestly can't even say I understand what exactly you mean by toposort-style dependency resolution, but I can't help but feel that the answer to your question is Why do we care?. Implementing an algorithm that fulfills the design I and others have proposed is trivial. Can anyone point to a real-world example of a dependency resolver which can produce solutions which may-or-may-not contain multiple versions of the same library? What's the point? I don't know of any language other than Rust that doesn't bork when you link/load/eval multiple versions of a library in the same binary/process/interpreter. So no other language even could have implemented this without hacks like adding the library version to its name/namespace/whatever. Let's not limit what we can build for Rust by constraining ourselves to what others have built for languages that don't have Rust's capabilities. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] let mut - var
Last I did a survey, `let mut` was less than half (and more around 30-40%) of the `lets` I found, though it wasn't exhaustive. It's also important to note that Rust is not a language suited for new programmers. Far too many concerns; it tackles hard problems and makes tradeoffs that new programmers don't particularly benefit from, esp. pedagogically. (I also teach new programmers, at Thinkful) On Wed, Jan 29, 2014 at 10:09 PM, Samuel Williams space.ship.travel...@gmail.com wrote: I agree that it is syntactic salt and that the design is to discourage mutability. I actually appreciate that point as a programmer. w.r.t. this specific issue: I think what concerns me is that it is quite a high burden for new programmers (I teach COSC1xx courses to new students so I have some idea about the level of new programmers). For example, you need to know more detail about what is going on - new programmers would find that difficult as it is one more concept to overflow their heads. Adding var as a keyword identically maps to new programmer's expectations from JavaScript. Writing a program entirely using var wouldn't cause any problems right? But, could be optimised more (potentially) if using let for immutable parts. Anyway, I'm not convinced either way, I'm not sure I see the entire picture yet. But, if I was writing code, I'd certainly get sick of writing let mut over and over again - and looking at existing rust examples, that certainly seems like the norm.. On 30 January 2014 15:59, Samuel Williams space.ship.travel...@gmail.com wrote: I guess the main gain would be less typing of what seems to be a reasonably common sequence, and the formalisation of a particular semantic pattern which makes it easier to recognise the code when you visually scanning it. On 30 January 2014 15:50, Kevin Ballard ke...@sb.org wrote: On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com wrote: On 01/29/2014 06:35 PM, Patrick Walton wrote: On 1/29/14 6:34 PM, Samuel Williams wrote: Perhaps this has been considered already, but when I'm reading rust code let mut just seems to stick out all over the place. Why not add a var keyword that does the same thing? I think there are lots of good and bad reasons to do this or not do it, but I just wanted to propose the idea and see what other people are thinking. `let` takes a pattern. `mut` is a modifier on variables in a pattern. It is reasonable to write `let (x, mut y) = ...`, `let (mut x, y) = ...`, `let (mut x, mut y) = ...`, and so forth. Having a special var syntax would defeat this orthogonality. `var` could potentially just be special-case sugar for `let mut`. To what end? Users still need to know about `mut` for all the other uses of patterns. This would reserve a new keyword and appear to duplicate functionality for no gain. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Failure stacktraces
You're not actually seeing a stack entry, you're seeing the string that was given to `fail!()`. You can get a real backtrace with gdb, break on `rust_fail`. You can also get a super crappy backtrace using the backtrace function, see prototype https://gist.github.com/cmr/8192817. We used to use it, but it only really works for dynamic linking (which we discourage for a variety of reasons right now), and doesn't work on OS X. Getting a real backtrace when unwinding would be possible, but we'd need to start parsing DWARF etc. Not trivial. On Sun, Jan 19, 2014 at 12:58 PM, Vladimir Matveev dpx.infin...@gmail.com wrote: Hi, Is it possible to view full stacktraces when task fails? Currently only the last item in the stacktrace is printed to the terminal when I run a failing program. I'm very surprised that I was not able to find any information on this. It looks like that the problem is nonexistent. However, the ability of getting full failure stacktraces is of colossal importance. Failures mean stack unwinding, so it shouldn't be a problem, should it? Thanks, Vladimir. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] sandboxing Rust?
On Sat, Jan 18, 2014 at 10:30 PM, Scott Lawrence byt...@gmail.com wrote: On Sat, 18 Jan 2014, Corey Richardson wrote: Rust's safety model is not intended to prevent untrusted code from doing evil things. Doesn't it succesfully do that, though? It might! But Graydon was very adamant that protection from untrusted code was/is not one of Rust's goals. I can't think of anything evil you could do without unsafe code, and assuming a flawless compiler. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs for 0.8: No idea what this does
You realize you're using a 3 month old unsupported release of a pre-alpha language, right? Anyway I don't know how those got promoted to doc comments, they used to just be comments. On Mon, Jan 13, 2014 at 8:25 PM, Andrew Pennebaker andrew.penneba...@gmail.com wrote: Who wrote these 0.8 docs: http://static.rust-lang.org/doc/0.8/extra/getopts/struct.Matches.html Fortunately, they're much improved in 0.9. -- Cheers, Andrew Pennebaker www.yellosoft.us ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] line params
I don't know what print_args is, but there's a getopt-alike in extra::getopts On Sun, Jan 12, 2014 at 11:48 AM, Renato Lenzi rex...@gmail.com wrote: If i want to access line command params i used code like this: fn main() { let args: ~[~str] = ::std::os::args(); println(args[0]); } Is this the best way to play with such params or the best is using print_args? i've found no examples using print_args thanks, regards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Questions from a newcomer
Hi Abraham, * Is there any built-in way to iterate over all values of a C-like enum? It's not hard to define an iterator method that implements this for any given type, but it's tedious boilerplate that seems better left to the compiler. Not really. What is your usecase? One boilerplate-avoiding workaround is to use FromPrimitive[1] and put `#[deriving(FromPrimitive)]` on your enum. Then, to iterate over the valid discriminants, you can use: range(0, std::uint::max_value).filter_map(|x| FromPrimitive::from_uint(x).map(|y| y as uint)) Note that this iterates over the entire range of uint. This is required for an enum like: enum WhatAPain { A, B = 42, C = 12312455 } Needless to say this is not going to perform well. You can substitute the variant whose discriminant is the largest to make it cheaper: range(0, C as uint).filter_map(|x| FromPrimitive::from_uint(x).map(|y| y as uint)) * Is it possible to express if a type implements trait A, here is a default implementation of trait B? I tried the obvious way (implT: TraitA TraitB for T), but it looks like the rust compiler can't disambiguate between that impl and type-specific impls. You are doing it correctly. There is an issue open about this: https://github.com/mozilla/rust/issues/10601 * Why does the do-notation require a function that takes a proc()? Given that || is the recommended type for HOFs it seems like it would be much more convenient if it worked with functions expecting a proc() or a ||. `do` previously applied to any closure type but that was removed because the meaning of `do` can change wildly depending on what you apply it to. In particular, using the old syntax, do applied to a `fn(~fn())` will have an allocation, whereas `fn(fn())` will not. To make such costs obvious, `do` no longer works with `fn()` (now written `||`). `proc()` corresponds to `~once fn()`, that is, a closure which may be called once and whose environment is allocated on the heap. The advantage of this is that it allows for moving values into the body of `do`. [1]: http://static.rust-lang.org/doc/0.9/std/num/trait.FromPrimitive.html ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Failure
What type is `3`? There's know way to know. Use `3i` for int, `3u` for uint, etc. On Sat, Jan 11, 2014 at 12:17 PM, Renato Lenzi rex...@gmail.com wrote: The code is trivial: fn main() { let x = 3; println(x.to_str()); } the error is this (on Win7) d:\Rust09\binrustc 00025.rs 00025.rs:4:11: 4:22 error: multiple applicable methods in scope 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #1 is `std::int::ToStr$int::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #2 is `std::i8::ToStr$i8::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #3 is `std::i16::ToStr$i16::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #4 is `std::i32::ToStr$i32::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #5 is `std::i64::ToStr$i64::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #6 is `std::uint::ToStr$uint::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #7 is `std::u8::ToStr$u8::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #8 is `std::u16::ToStr$u16::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #9 is `std::u32::ToStr$u32::to_str` 00025.rs:4 println(x.to_str()); ^~~ 00025.rs:4:11: 4:22 note: candidate #10 is `std::u64::ToStr$u64::to_str` 00025.rs:4 println(x.to_str()); ^~~ error: aborting due to previous error task 'rustc' failed at 'explicit failure', C:\bot\slave\dist2-win\build\src\libs yntax\diagnostic.rs:75 task 'main' failed at 'explicit failure', C:\bot\slave\dist2-win\build\src\lib rustc\lib.rs:453 any idea? thanks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
This RFC isn't about using a single build system for everything, it's the build system we use to build Rust itself. On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy li...@dhardy.name wrote: A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a C-family project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: On 10/01/14 08:16, Gaetan wrote: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. On Friday, January 10, 2014, George Makrydakis wrote: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] general onlookers questions on rust development
On Fri, Jan 10, 2014 at 5:38 PM, Don Question donquest...@rocketmail.com wrote: Congrats to 0.9! I'm coming from a C/C++/Python background and was loosely following the progress of Rust for quite a while now, but never tried it until yesterday. I must admit i'm quite pleased so far, but i have some question, which i hope you could help to clarify. 1. I miss a search functionality on the mailing list. Am i just blind, or do i have to use google with the site: option? You're not blind. But, there's also a searchable gmane mirror: http://blog.gmane.org/gmane.comp.lang.rust.devel 2. I'm used to curly braces, but every time i have to code in C or JavaScript i miss the better readability of python's curly-free syntax. What was the reason to keep the (imho: annoying) curly braces? I must confess i was a little bit taken aback by the first sentence on rust-lang.org: Rust is a curly-brace, ... I'm not 100% sure but afaik it's to keep syntactical familiarity. 3. If i wanted to use Rust instead of C for external Python-Modules, what would be my options to achieve that? Could i use ctypes and Rust's extern? Devin Jeanpierre (aka ssbr) has Python bindings: https://bitbucket.org/devin.jeanpierre/pyrite. They might need updating. But yes, you'd want to use `extern C` and then use it the same way you'd use a C module. 4. Why is the BSD implementation almost 3 times faster then the linux and mac-versions ? http://huonw.github.io/isrustfastyet/buildbot/ It isn't. It's running a stripped down version of the test suite (make check-fast). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
The current consensus on this subject, afaik, is the rename int/uint to intptr/uintptr. They're awful names, but it frees up int for a *fast* bigint type. Fast here is key. We can't have a suboptimal numeric type be the recommended default. We need to perform at least as well as GMP for me to even consider it. Additionally we'd have generic numeric literals. I don't think anyone wants what we current have for *numerics*. Fixed-size integers are necessary for some tasks, but numerics is not one of them. As long as we rename int/uint to intptr/uintptr and leave int etc reserved, I think we can defer the language issues to post-1.0. It should be entirely backwards compatible. Development of robust numerics can happen outside the standard library. Talk to bjz about this, he has some ideas :) As an aside, you mention a real in your blog post like it's something that exists. Rust does not have any such type. On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden leebr...@gmail.com wrote: This may be go nowhere, especially so late in Rust's development, but I feel like this is an important, relatively small change (though a high-profile one). I believe it could have a large, positive impact in terms of targeting new developer communities, gaining more libraries and applications, giving a better impression of the language, AND on performance and futureproofing. However, a lot of people who are interested in performance will probably baulk at this, on first sight. If you're in that group, let me encourage you to keep reading, at least until the points on performance improvements. Then baulk, if you like ;) Also, I said it in the post as well, but it's late here, so apologies for any readability / editing issues. I tried, but sleep beckons ;) http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
Simple answer: then it shouldn't be our default numeric type. You say earlier that we don't need a default, and that is a case I hadn't considered before. But I'm growing to like it. On Sat, Jan 11, 2014 at 1:23 AM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson co...@octayn.net wrote: We need to perform at least as well as GMP for me to even consider it. The only realistic way to accomplish this is using GMP. Lots of other big integer implementations exist with lots of work put into them and the performance is not even in the same ballpark. It's difficult just to implement all of the required algorithms: https://gmplib.org/manual/Division-Algorithms.html#Division-Algorithms Then, consider that you're going to need to write the low-level code by hand in assembly so you're going to need domain experts for several architectures. Processors and compilers are terrible at dealing with the side effects like carry/overflow flags and can't deal with this kind of code well. You'll need versions for different revisions of the CPU instruction set too, since useful features are added all of the time. For example, Haswell introduces the `MULX` instruction (among others) and Broadwell will introduce `ADCX` and `ADOX`. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Future of the Build System
Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Emscripten for Rust?
Any such conversion is going to be lossy enough as to be worthless. It's only acceptable for emscripten because the web platform can't run native code. But any use of Rust is already going to be targetting something that can run C. On Sun, Jan 5, 2014 at 9:11 PM, Greg g...@kinostudios.com wrote: I'd happy chip in for a Kickstarter-type project to automatically convert C/C++ to Rust. Anything like this exists or anyone planning on making this type of announcement? - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Emscripten for Rust?
Much of it would be. But why? On Sun, Jan 5, 2014 at 9:25 PM, Huon Wilson dbau...@gmail.com wrote: On first glance it seems like C - Rust would be very feasible via a lot of `unsafe`, * and *mut. On 06/01/14 13:21, Corey Richardson wrote: Any such conversion is going to be lossy enough as to be worthless. It's only acceptable for emscripten because the web platform can't run native code. But any use of Rust is already going to be targetting something that can run C. On Sun, Jan 5, 2014 at 9:11 PM, Greg g...@kinostudios.com wrote: I'd happy chip in for a Kickstarter-type project to automatically convert C/C++ to Rust. Anything like this exists or anyone planning on making this type of announcement? - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Configuration files library for Rust
oslo.config looks decent. On some projects I've worked on, we started out using INI files but found them severely lacking once we wanted to extend the options. We ended up using libconfig[0], which I think is an excellent library. In multibuilder[1], we use extra::serialize to load a config directly into the struct we'll be using. It's super convenient, but a bit unfortunate in that it's impossible to make a field truly optional (OptionT requires the field to be null, iirc). [0] http://www.hyperrealm.com/libconfig/ [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 flape...@gmail.com wrote: Hi Guys, I was looking around and I couldn't find a config file parser library for Rust. Getopt support seems to be pretty complete and stable, which would make the development of such library easier. Since I've some experience on this area, I thought about doing some work on it for Rust. My current plan is to do something along the lines of oslo.config[0] - which I've been contributing to - and take advantage of the existing getopt module, just as we do in oslo.config. The config file format parsed by oslo.config follows the INI[1] files format but with some changes to support list options and other types. One of the advantages of this library is that the config options registration is explicit and simple. However, before starting to work on this, I'd like to know what folks on this list think about the library, if there's been some work on this area that I'm not aware of, what the preferences are, etc. Cheers, FF [0] https://github.com/openstack/oslo.config [1] http://en.wikipedia.org/wiki/INI_file -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] rust-redis and rust-msgpack
If you slap a #[no_uv]; on the benchmark, it will use libnative, which is threads On Sat, Jan 4, 2014 at 11:16 AM, Michael Neumann mneum...@ntecs.de wrote: Am 04.01.2014 17:14, schrieb Michael Neumann: Hi all, rust-redis: A Redis client library written in pure Rust. Thanks to the new rust runtime it is pretty fast, despite being only 200 lines of code. rust-msgpack: Fully featured and high performance msgpack implementation for Rust. Both work with rust 0.9-pre. Too stupid/sleepy that I forgot the links: http://github.com/mneumann/rust-redis http://github.com/mneumann/rust-msgpack Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
I quite like this proposal, though I'd suggest that the else clause is evaluated as the value for when the pattern fails. `!` would always be substitutable there. On Sun, Dec 22, 2013 at 10:47 AM, Gábor Lehel glaebho...@gmail.com wrote: Using `match` works well enough, but if there's demand for a refutable `let` which is lighter-weight, what about: let Some(result) = from_utf8(some_bytes) else fail!(); In other words, if the `let` pattern is refutable, you have to provide something `else` with return type `!` as the alternative for when the `let` fails to match. (I could imagine that being generalized to any number of `else`s of which only the last returns `!` (i.o.w. never returns), for example let Some(result) = from_utf8(some_bytes) else from_utf8(some_other_bytes) else fail!(); and/or to allowing anything `else` which always matches, e.g. let Some(result) = from_utf8(some_bytes) else Some(default); of which anything that returns `!` would be only a special case. But these have progressively diminishing returns, and I'm merely mentioning, not endorsing them.) On Tue, Dec 17, 2013 at 9:11 PM, Kevin Ballard ke...@sb.org wrote: On Dec 17, 2013, at 11:37 AM, Stefan Plantikow stefan.planti...@gmail.com wrote: Hi, Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net: On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow stefan.planti...@gmail.com wrote: Hi, Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com: I have no idea if it would be feasible in the standard library, but wouldn't the ideal solution be having one function (e.g. from_utf8()) that could return two possible values, a bare result and an Option? Letting the compiler decide which version to use based on type inference like this: let result: ~str = from_utf8(...); let result: Option~str = from_utf8(...); Assuming both of them are passed invalid UTF8, then the first version would fail, but the second version would just return None. We already have pattern matching in `let` (the LHS is a pattern), but it's only for irrefutable patterns. IOW, `let` can never fail, and that's a very very useful property IMO. oh ok I haven’t kept up on the syntax then. Given the utility of destructuring bind for error handling, wouldn't it make sense to have a variant of let that can fail? Now syntax is a matter of practicality and taste but spontaneously this comes to mind: let opt Some(~result) = from_utf8(..) comes to mind. You can do it with a bit more verbosity, which I think is perfectly fine as it makes failure much more obvious. let result = match from_utf8(..) { Some(~result) = result, _ = fail!(b0rk b0rk b0rk) }; Of course, in this particular example, you'd probably just write let result = from_utf8(..).unwrap(); but the longer match form will work for other enums. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Iterator naming convention
The reason the Iterator suffix was removed is because when when one is required to write the type signature it becomes hugely annoying to keep writing Iterator all the time. Personally I think Alex's idea is a good way forward. On Sat, Dec 21, 2013 at 4:35 PM, Kevin Cantu m...@kevincantu.org wrote: Rust's standard libs are still pretty thin on their trait hierarchies, but I'm sure this will change. Kevin On Sat, Dec 21, 2013 at 1:30 PM, Palmer Cox palmer...@gmail.com wrote: Are there examples of structs that implement Iterator that also implement other non-Iterator related traits? Although its possible to do that, I can't think of a use case for it off the top of my head. An Iterator basically represents the state of an ongoing computation and once that computation is completed, the object is mostly uselss. It seems like it would be awkward to implement other traits for such an object. Maybe I'm not thinking of something, however. -Palmer Cox On Sat, Dec 21, 2013 at 4:24 PM, Kevin Cantu m...@kevincantu.org wrote: Iterators are just structs which implement the Iterator or a related trait, right? These structs which do can also implement lots of other traits, too: no reason to make -Iter special. Kevin On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox palmer...@gmail.com wrote: I'm not a big fan of Hungarian notation either. I'm not sure that having a naming convention for Iterators is Hungarian notation, however. For example, if you are doing Windows programming, you'll see stuff like: DWORD dwFoo = 0; In this case, the dw prefix on the variable indicates that we have a DWORD variable. However, the Iterator suffix that I'm proposing here is a suffix on the type names, not the actual variable names. So, if you are writing Rust code, you'd write something like this: let chunks = some_vector.chunks(50); So, the actual variable name doesn't have the Hungarian notation and the types aren't even generally visible since the compiler infers much of that. However, someone reading through the documentation and/or code will see a struct named ChunkIterator and instance know how the struct behaves - as an Iterator. So, I think the suffix serves less to describe the datatype and more to describe class of behavior that the struct implements. Anyway, as I said, I prefer #1. But, I also have done lots of Java programming so I'm probably much more used to verbosity than others. I'm not horribly against some sort of other naming convention, either, of course, but I would like to see some consistency. My main motivation for opening the request was because I created MutChunkIter and then realized that it was named differently than majority of other Iterators. I don't want to be responsible for someone reading through the docs and seeing something thats inconsistent for no good reason! Also, I was reading through some code and happened upon a Map and was exceptionally confused about it, until I realized it was iter::Map as opposed to container::Map. I figured I probably wasn't the only person that was going to be confused by something like this. -Palmer Cox On Sat, Dec 21, 2013 at 3:14 PM, Kevin Cantu m...@kevincantu.org wrote: IMHO Hungarian notation is for things the type system and tooling cannot deal with. I'm not sure this is one of them... Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] pkgid changes
Hey all, #11041 just landed, which changes the pkgid attribute to crate_id. It's a very straightforward transition, but probably inconvenient, especially for the rust-ci users. With it also landed the --crate-name, --crate-id, and --crate-file-name flags to rustc, which will print out those attributes about the crate. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow stefan.planti...@gmail.com wrote: Hi, Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com: I have no idea if it would be feasible in the standard library, but wouldn't the ideal solution be having one function (e.g. from_utf8()) that could return two possible values, a bare result and an Option? Letting the compiler decide which version to use based on type inference like this: let result: ~str = from_utf8(...); let result: Option~str = from_utf8(...); Assuming both of them are passed invalid UTF8, then the first version would fail, but the second version would just return None. If rust allowed pattern matching in let, this problem would go away: let Some(~result) = from_utf8(…); This would fail if from_utf8(..) would not return None. This solution has several benefits: - The code clearly expresses intent (a result was expected and thus it should fail if instead None is returned) - Only one function is needed and that functions signature covers all possible return cases - This approach isn’t limited to Option and could very well also work with Result. The generated error message could contain the value that was not matched (and thus have more detailed error information). - IMHO the required syntax change won't break existing code (?) We already have pattern matching in `let` (the LHS is a pattern), but it's only for irrefutable patterns. IOW, `let` can never fail, and that's a very very useful property IMO. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust crates and the module system
Packages don't really exist as a concept at all. Supposedly `rustpkg` deals with packages but in reality, it just deals with crates. And they're certainly not part of the module system. On Fri, Dec 13, 2013 at 8:14 PM, Liigo Zhuang com.li...@gmail.com wrote: What is the distinction of package and crate in Rust? 2013/12/14 Patrick Walton pcwal...@mozilla.com On 12/13/13 4:56 PM, Liigo Zhuang wrote: package and module, we only need one. Most other language only have one. The more, the more complicate. libstd.so: What we call it? library package crate?? other language usually call it library. std::io::fs: We call it module, other language usually call it package or module. So, whatever we call it, package and module, we only need ONE of them, and let another gone. .NET has a two-level distinction: assembly and namespace. C++ has a three-level distinction in practice—namespace, library/executable, and translation unit—although C++'s is somewhat different. OCaml has a two-level distinction: library and module. D has a two-level distinction as far as I can tell: library and module. Racket has a two-level distinction as far as I can tell: package and module. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by Liigo, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
I'm in favor of this but it makes things less pretty. Is the choice really between pretty and fast? On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin simon.sa...@exyr.org wrote: We have some functions and methods such as [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may succeed and give a result, or fail when the input is invalid. 1. Sometimes we assume the input is valid and don’t want to deal with the error case. Task failure works nicely. 2. Sometimes we do want to do something different on invalid input, so returning an `OptionT` works best. And so we end up with both `from_utf8` and `from_utf8`. This particular case is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, to cover everything. Multiplying names like this is just not good design. I’d like to reduce this pattern. Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the Option. I think we should rename every `foo_opt()` function or method to just `foo`, remove the old `foo()` behavior, and tell people (through documentation) to use `foo().unwrap()` if they want it back? The downsides are that unwrap is more verbose and gives less helpful error messages on task failure. But I think it’s worth it. What do you think? (PS: I’m guilty of making this worse in #10828, but I’d like to discuss this before sending pull requests with invasive API changes.) -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] new compile errors in the master since a few days
No, since it isn't known which trait the method should come from. It could list *all* the traits that provide that method with that signature, but even that wouldn't be great if you had the signature off. On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu philippe.delr...@free.fr wrote: I found my error. It's a classical problem. TestStruct2 implement the trait `extra::serialize::Encodable` using the generated impl by the compiler. I didn't declare : use extra::serialize::Encodable; So the compiler doesn't find it and declare the problem at the implementation. It's the same problem when you work with different file and the trait is implemented in one file and use in another. Usually I found the error but I was confused with other errors and the message wasn't clear. Is it possible to change the message by for example in this case trait `extra::serialize::Encodable` not found for encode, or to add all `use` needed when using a type and its implementation. Philippe Le 05/12/2013 10:53, Philippe Delrieu a écrit : Thank you it correct my first problems. I didn't send code because I thought it has the same cause. For the last problems the code is : use extra::serialize; use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; use extra::treemap::TreeMap; use std::io::Decorator; //second struct with manually implemented Decodable, Encodable #[deriving(Decodable, Encodable, Eq)] pub struct TestStruct2{ dataInt: u8, dataStr:~str, dataArray:~[u8], } let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~toto, dataArray:~[2,3,4,5]}; //{\dataArray\:[2,3,4,5],\dataInt\:1,\dataStr\:\toto\} let mut m3 = MemWriter::new(); { let mut encoder3 =Encoder::init(mut m3 as mut Writer); test3.encode(mut encoder3); } Rustc result : test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement any method in scope named `encode` test/test_json.rs:292 test3.encode(mut encoder3); Philippe Le 05/12/2013 09:56, Kevin Ballard a écrit : `do` no longer works with stack closures. It now only works with the new proc() type, which basically means you're only going to see it used with spawn(). You need to now say something like let rc = endpoint.with_c_str(|cstr| { unsafe {smq_bind(self.sock, cstr)} }); I can't speculate on your encode error without seeing it. -Kevin On Dec 5, 2013, at 12:43 AM, Philippe Delrieu philippe.delr...@free.fr wrote: Hello, since a few days, I have a lot of new errors in the master compiler. For example in the rust_zmq lib that I use. When I compile it I have these errors : 321:9 error: last argument in `do` call has non-procedure type: |*i8| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 unsafe {zmq_bind(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: 330:9 error: last argument in `do` call has non-procedure type: |*i8| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 unsafe {zmq_connect(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 do data.as_imm_buf |base_ptr, len| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 let msg = [0, ..32]; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 unsafe { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 // Copy the data into the message. /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(msg, len as size_t); ... /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: 342:43 error: the type of this value must be known in this context /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(msg, len as size_t); ^~~ /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: 344:32 error: cannot determine a type for this bounded type parameter: unconstrained type /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 ptr::copy_memory(::cast::transmute(zmq_msg_data(msg)), base_ptr, len); ^~~~ I have the same type of errors in my
Re: [rust-dev] new compile errors in the master since a few days
How about method `foo` no found and no trait in scope provided one ? On Thu, Dec 5, 2013 at 4:29 PM, Philippe Delrieu philippe.delr...@free.fr wrote: Perhaps the error message can be more explicit like trait not found for method instead of method not found. Le 05/12/2013 21:57, Corey Richardson a écrit : No, since it isn't known which trait the method should come from. It could list *all* the traits that provide that method with that signature, but even that wouldn't be great if you had the signature off. On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu philippe.delr...@free.fr wrote: I found my error. It's a classical problem. TestStruct2 implement the trait `extra::serialize::Encodable` using the generated impl by the compiler. I didn't declare : use extra::serialize::Encodable; So the compiler doesn't find it and declare the problem at the implementation. It's the same problem when you work with different file and the trait is implemented in one file and use in another. Usually I found the error but I was confused with other errors and the message wasn't clear. Is it possible to change the message by for example in this case trait `extra::serialize::Encodable` not found for encode, or to add all `use` needed when using a type and its implementation. Philippe Le 05/12/2013 10:53, Philippe Delrieu a écrit : Thank you it correct my first problems. I didn't send code because I thought it has the same cause. For the last problems the code is : use extra::serialize; use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; use extra::treemap::TreeMap; use std::io::Decorator; //second struct with manually implemented Decodable, Encodable #[deriving(Decodable, Encodable, Eq)] pub struct TestStruct2{ dataInt: u8, dataStr:~str, dataArray:~[u8], } let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~toto, dataArray:~[2,3,4,5]}; //{\dataArray\:[2,3,4,5],\dataInt\:1,\dataStr\:\toto\} let mut m3 = MemWriter::new(); { let mut encoder3 =Encoder::init(mut m3 as mut Writer); test3.encode(mut encoder3); } Rustc result : test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement any method in scope named `encode` test/test_json.rs:292 test3.encode(mut encoder3); Philippe Le 05/12/2013 09:56, Kevin Ballard a écrit : `do` no longer works with stack closures. It now only works with the new proc() type, which basically means you're only going to see it used with spawn(). You need to now say something like let rc = endpoint.with_c_str(|cstr| { unsafe {smq_bind(self.sock, cstr)} }); I can't speculate on your encode error without seeing it. -Kevin On Dec 5, 2013, at 12:43 AM, Philippe Delrieu philippe.delr...@free.fr wrote: Hello, since a few days, I have a lot of new errors in the master compiler. For example in the rust_zmq lib that I use. When I compile it I have these errors : 321:9 error: last argument in `do` call has non-procedure type: |*i8| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 unsafe {zmq_bind(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: 330:9 error: last argument in `do` call has non-procedure type: |*i8| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 unsafe {zmq_connect(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| - V3 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 do data.as_imm_buf |base_ptr, len| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 let msg = [0, ..32]; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 unsafe { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 // Copy the data into the message. /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(msg, len as size_t); ... /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: 342:43 error: the type of this value must be known in this context /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(msg, len as size_t); ^~~ /home/pdelrieu/Documents
Re: [rust-dev] Rust forum
Very well for the Python community, too; there's a python-tutor list whose sole focus is helping newbies effectively. On Tue, Dec 3, 2013 at 5:32 PM, Martin DeMello martindeme...@gmail.com wrote: In practice this has worked out well for the ocaml community - there's an ocaml-beginners mailing list that gets a small amount of traffic, but very quick responses from a lot of the more experienced people on the list. martin On Tue, Dec 3, 2013 at 2:20 PM, Gaetan gae...@xeberon.net wrote: I also agree to split in rust-user for newbee question, but i hope good programmers will go a bit on this ml... Le 3 déc. 2013 21:42, Martin DeMello martindeme...@gmail.com a écrit : On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry thadgui...@gmail.com wrote: Users benefit from the developers list and vice-versa... splitting us apart would not be a wise choice. the only downside is that people are reluctant to ask newbie user questions on a list where people are talking about hacking on the compiler. martin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Put Unicode identifiers behind a feature gate
The compiler still handles it, and there are still tests for it. I think it's more of a not 1.0 priority, than anything else. On Mon, Dec 2, 2013 at 11:31 PM, Kevin Cantu m...@kevincantu.org wrote: When I started my old Rust PPA (now superseded), the first user to email me was an engineer from China who was getting ready to give a talk introducing Rust to a programming user group in Guǎngzhōu bigger than any of the Rust-specific meetups we've ever had yet in the San Francisco Bay area. There are a ton of people who don't do their best work in English: our ASCII world is quite small, despite how loud people like me happen to talk. Excluding foreign language users when we don't have to would be a huge mistake. Gating this for now only works if we aren't later going to try to sacrifice this awesome feature to the elder gods of backwards compatibility... Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On Sat, Nov 30, 2013 at 8:51 PM, Florian Zeitz flo...@babelmonkeys.de wrote: Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. I really like this proposal. I've watched this thread and the original `new` proposal with indifference, but `box` really makes sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On Sat, Nov 30, 2013 at 9:30 PM, Kevin Ballard ke...@sb.org wrote: I'm still very much a fan of leaving ~ as the allocation operator. Despite what Patrick says, I'm pretty sure the reason why users are confused about it is purely due to sub-par documentation, and not due to any actual inherent problems with using a non-alphabetic symbol as an operator. Heck, we have plenty of other non-alphabetic operators that don't cause confusion, why is this one special? I'll admit, I don't find the confusing argument very convincing. I just think `box` looks better than `~`. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] This Week in Rust
Welcome to another issue of *This Week in Rust*, a weekly newsletter summarizing Rust's progress and community activity. As always, if you have something you'd like to be featured, just [send me an email](mailto:co...@octayn.net?subject=This Week in Rust Suggestion). Last week was very slow, but this week more than makes up for it I think! Static linking landed, and there's been some nice cleanup of error messages and various APIs. # What's cooking on master? 59 PRs were merged this week. ## Breaking Changes - Names of methods creating iterators have [changed drastically](https://github.com/mozilla/rust/pull/10622) to remove the `_iter` suffix. This reflects that iterators are a primary focus of APIs. The PR description has all of the changes summarized. - We now have [static linking support](https://github.com/mozilla/rust/pull/10528)! It does, however, involve some changes with how the `link` attribute works. The error messages should guide you to the fixes. - In preparation for the placement new changes, the `Path` constructor has been [renamed from `new` to `init`](https://github.com/mozilla/rust/pull/10697),. - Some overly-permissive borrow checking for `mut mut` [has been fixed](https://github.com/mozilla/rust/pull/10519). This is fairly obscure, most code shouldn't have hit it. - The parser is [more strict](https://github.com/mozilla/rust/pull/10642) about what it accepts as a doc comment. Now, only `///` and `/**` are counted as introducing doc comments (previously, `` and `/***` would also introduce a doc comment). - `std::{uint, int}::{min, max}` [have been removed](https://github.com/mozilla/rust/pull/10719). They were identical to the functions in `std::cmp`, so use those instead. - `extra::json` [has been rid of @ boxes](https://github.com/mozilla/rust/pull/10727), and now uses idiomatic constructor names. - The `type_id` intrinsic [now uses a language item as its return value](https://github.com/mozilla/rust/pull/10722). - Some [cleanup](https://github.com/mozilla/rust/pull/10662) has been done to `std::rt::thread`, which is an interface to native threads (rather than tasks). - `do` blocks are [no longer allowed](https://github.com/mozilla/rust/pull/10581) in non-`proc` contexts. This means that `do` can not be used with a function whose last argument is not a `proc`. A fairly large [thread on the mailing list](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006999.html) is ongoing about this change. - `LittleLock` now [uses RAII](https://github.com/mozilla/rust/pull/10660). - C-like enums are [now represented as an integer](https://github.com/mozilla/rust/pull/10652) rather than a struct, at the LLVM level. This affects ABI. - Linked failure [has been removed](https://github.com/mozilla/rust/pull/10603) from the runtime. - `extra::term` [no longer uses `@mut Writer`](https://github.com/mozilla/rust/pull/10637), instead taking the writer to use by value. ## Other changes - `RefCellT`, previously known as `MutT`, [has finally landed](https://github.com/mozilla/rust/pull/10514), for all your dynamic borrow checking needs. - A lint for unknown attributes [has finally been added](https://github.com/mozilla/rust/pull/10316). The compiler will now warn when it sees an attribute it doesn't recognize. - A lock-free [Chase-Lev deque](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097rep=rep1type=pdf) has [been added to the runtime](https://github.com/mozilla/rust/pull/10678). - The shootout-spectralnorm benchmark [has been resurrected](https://github.com/mozilla/rust/pull/10704). - Unknown feature gates [are now linted](https://github.com/mozilla/rust/pull/10680), rather than being a hard failure. - The AST is [now frozen](https://github.com/mozilla/rust/pull/10693)! - `GenericPort` [now has an iterator](https://github.com/mozilla/rust/pull/10688) over the messages it receives. - `NodeId`, `CrateNum`, `Name`, and `Mrk` (types in libsyntax) [have been shrunk to 32 bits](https://github.com/mozilla/rust/pull/10670). - The restriction on macros expanding to a single item [has been lifted](https://github.com/mozilla/rust/pull/10649). This obviates the need for macros hackily expanding to a module containing the desired items. Do note that this only works when the macro is in item position, or where an item is expected. There is an [issue](https://github.com/mozilla/rust/issues/10681) open for lifting this restriction. - A `thread_local` attribute [has been added](https://github.com/mozilla/rust/pull/10312), which exposes a platform's native TLS, a la C11/C++11 `thread_local`. - Cross compilation to win64 (via mingw-w64) [is now supported](https://github.com/mozilla/rust/pull/10578). There were also a [bunch of fixes](https://github.com/mozilla/rust/pull/10631) on real win64. - The parser gives a [better error message](https://github.com/mozilla/rust/pull/10641)
Re: [rust-dev] do
On Sat, Nov 30, 2013 at 10:28 PM, Patrick Walton pcwal...@mozilla.com wrote: On 11/30/13 7:25 PM, Michael Letterle wrote: I've got to say that the do syntax is one of the things that appeals to me about Rust, and will probably appeal to the people that Steve Klabnik is drawing to the language with Rust for Rubyists. It might seem like a small thing but the effects on the type of programs you can write, it actually has a pretty profound effect, IMO. -- Tony Arcieri I agree actually, I was using do to implement some convenience logic and my code went from: do function { someotherFunction() }; to function(|| someotherFunction()); Maybe I'm abusing something here, but I found the first format more intuitive and elegant... I know there's rumblings about io conditions going away, but the change also makes that more awkward... :/ The point of this change was to got rid of closure type inference. With the old rules it was not possible to see whether you were allocating without looking at the type signature of the function you're calling. Moreover the capture rules are extremely different depending on the type of closure it is. It's too much magic for Rust. Maybe `do` can just change from procs to closures. I can't really say how often I've actually wanted a proc. Task bodies are a far minority compared to other uses of do, from the backlash, and I don't find `spawn(proc() { ... })` that unappealing. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Separated/Incremential compilation
I experimented with LZ4. https://github.com/mozilla/rust/pull/6954. It isn't worth it, IMO. On Fri, Nov 29, 2013 at 1:51 PM, Carter Charbonneau zcart...@gmail.com wrote: Why not lz4? It's faster than snappy. On Nov 29, 2013 11:29 AM, Patrick Walton pcwal...@mozilla.com wrote: On 11/29/13 10:26 AM, comex wrote: On Fri, Nov 29, 2013 at 12:07 PM, Daniel Micay danielmi...@gmail.com wrote: A minimal program definitely doesn't compile more slowly than `clang`: Well, I said it was mostly unrelated. :) Importing the std crate is responsible for the overhead, but if the C program can bring in basic library functions in the time it takes Rust to bring in nothing, it's still faster. ...but according to Instruments, almost 70% of the compilation time for an empty non-#[no_std] crate is being spent inside flate::inflate_bytes (93ms). If that's accurate, it doesn't sound too hard to fix, if it matters to anyone. Compilation time for more substantial crates is more interesting, of course, but I do like the instantaneous feeling of compiling small C utilities. Yeah, we need to rework the representation of metadata. I'd also like to try switching to Snappy at some point (or just not compressing). Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] any tips and tricks for faster compilation of compiler itself?
5+ minutes isn't bad, actually. On my (fairly beefy) desktop building stage1 takes about that long. There isn't really too much to do to help with compile times right now, unfortunately :( The only advice I have is don't bootstrap: use the stage1 make targets. Their names slip my mind, so someone else will have to toss them out there. `make check-stage1` in particular is useful, though, and `make check-stage1-std NO_REBUILD=1` can help if you're working on the std lib and not the compiler. On Wed, Nov 27, 2013 at 10:37 PM, Ömer Sinan Ağacan omeraga...@gmail.com wrote: Hello everyone, I'm trying to make some changes on the Rust compiler(and I'll hopefully open some pull requests) but I'm suffering from incredibly long compilation times. I know some part of it is related with my computer but I don't have anything to do about that for now, so I'm looking for tips and tricks to make compilation of compiler itself faster on same hardware. Any helps would be really appreciated, currently one line of trivial change takes literally 5+ minutes to compile on my system. Thanks, ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Mentoring + E-easy
Hey fellow Rusties, We have a fair number of new contributors, and my devious mind wonders how we can get more. My first thought was a new tag, E-mentored, where someone can volunteer to mentor someone through an E-easy issue. It's a very lightweight, non-formal process, and can hopefully give some more guidance to people who come into #rust asking for a good issue to get started with. This is intended for brand-new contributors, whereas I feel E-easy is a teeny bit misused. I also propose that, when tagging an issue as E-easy, a comment describing the nature of the fix and where (file + function ideal) one would look to start the fix. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev