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
