Re: [rust-dev] First impressions of Rust
>> The syntax was pioneered before the RFC process was in effect, so it
>> may not have an official grammar, but it looks something like:
>>
>> expr := 'box' expr | 'box' '(' expr ')' expr
>>
>> The first form is "rewritten" as `box(::std::owned::HEAP) expr` and
>> the second form (the more general) specifies that the second
>> expression should be placed into the first.
>
> Hmm. So in 'box(RC) expr', RC is an allocator? I must be
> misunderstanding something, because I don't see how it knows from
> that:
> a) That it should create an Rc
> b) How to work with and initialize the Rc struct properly
The current design hasn't been written up into an RFC, but the current
thinking is documented in the last work week's minutes [1]. They're a
little messy, but they should be faithful to what we're thinking!
The general idea was that RC isn't actually an allocator per-se, but
rather a "boxer" which knows how to create an Rc from a T. The
"boxer" could be parameterized over an actual allocator which would
dictate where memory comes from, but by the default allocator would
still be the jemalloc heap. We found that the distinction between an
allocator and a boxer gave you a bit more flexibility when it came to
allocators in terms of re-use between pointers such as Rc, Arc, and
Box.
[1]:
https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/box-and-allocators.md
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] First impressions of Rust
>> Feel free to open a bug on the
>> issue tracker (https://github.com/rust-lang/rfcs/issues) or even open
>> an RFC on it! Due to it being a language change, you should register
>> the issue in the RFC repo instead of the rust repo.
>
> Oh my, I'm allowed to start an RFC? I don't feel confident in
> providing the background you just mentioned, and I certainly don't
> have the expertise to implement it myself. But I can certainly give
> my rationale for why it would be a good idea (as I did in my email).
> Is that sufficient?
Certainly! RFC does stand for "request for comments" after all. You're
also welcome to drop by #rust or #rust-internals to ask some more
detailed questions if you're writing something up. We also assign a
shepherd to each RFC (or close it if no one wants to shepherd) who
will help you develop the RFC and can provide any necessary back
story.
In the past another helpful thing to do is to make a pre-RFC and post
it to discuss.rust-lang.org to get some initial feedback. That way by
the time it reaches rust-lang/rfcs it's more of a "final draft" than a
first "rough draft".
Either way though, you're more than welcome to write an RFC!
>> Your example should in
>> theory (doesn't work today) be written as:
>>
>> let a: Box = box 45i;
>> let b: Rc = box(RC) 54i;
>
> Is there a fuller description of the intended syntax and how it works?
The syntax was pioneered before the RFC process was in effect, so it
may not have an official grammar, but it looks something like:
expr := 'box' expr | 'box' '(' expr ')' expr
The first form is "rewritten" as `box(::std::owned::HEAP) expr` and
the second form (the more general) specifies that the second
expression should be placed into the first.
Note, however, that the `box(foo) bar` form is not implemented today,
so you may hit some surprises if you try to use it!
> Awesome! I'll keep it coming then (although it's likely to be a
> trickle rather than a firehose). Is this an appropriate place to post
> such feedback, or would the subreddit and/or discuss forum be better?
Nowadays we tend to prefer discuss/reddit more for inquiries such as
this. I'd probably post on the reddit for general commands and
questions and bring more design-discussion-y questions
discuss.rust-lang.org instead.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] First impressions of Rust
> Disclaimer: please take all of this with a huge grain of salt. This
> feedback is meant with the humility of someone who surely doesn't
> fully understand the language yet and hasn't invested enough time into
> yet to be taken seriously. Much of what I say may have little bearing
> on anything. This is purely just to give my "fresh new user"
> perspective, in the hopes that it might be helpful somehow.
Thanks so much for taking the time to write this up, this is well
written and I know we all definitely appreciate it!
> It took me a stupidly long time to figure out that the 'mod' statement had to
> go after the 'use'
> statement.
I believe there's actually an interesting historical precedent to
this! Awhile back we allowed names to shadow each other through
imports/declaration, and due to bugs in resolve the order of shadowing
was "extern crate", then "use statements", then "everything else". For
example, a program like this wouldn't work as expected:
mod foo;
use bar::foo;
fn main() { foo(); }
In that example, the call to `foo()` from `main` would actually
resolve to calling a module, which is illegal.
Note, however, that we now disallow shadowing, so I believe that it's
plausible to lift this restriction. Feel free to open a bug on the
issue tracker (https://github.com/rust-lang/rfcs/issues) or even open
an RFC on it! Due to it being a language change, you should register
the issue in the RFC repo instead of the rust repo.
> It feels awkward to me that Box and Rc have different ways of initializing:
We are of similar minds! A little-known fact about `box` right now is
that its syntax is intended to be extensible. Your example should in
theory (doesn't work today) be written as:
let a: Box = box 45i;
let b: Rc = box(RC) 54i;
And furthermore, you can extend it even further:
let c: Box = box(HEAP) 1i;
let d: MyPointer = box(MY_HEAP) 5i;
Technically speaking, this is "superior" to calling a function like
Foo::new, similar to how "placement new" works in C++. With the `box`
syntax, you're able to allocate a slot *before* the expression is
evaluated, which means the expression can be evaluated directly into
the destination. Today, with a function like Rc::new, you evaluate the
expression beforehand onto the stack, and then you later copy the
value onto the heap (sub-par).
This is technically feasible to implement today, and I believe that we
plan on implementing this before 1.0 and possibly deprecating
constructors like Rc::new and Arc::new.
> # Can't Write to mut Vec #
This is indeed odd! Currently the syntax you want is provided by
implementing the IndexMut trait, but it is blocked on
https://github.com/rust-lang/rust/issues/12825 before implementing it
for vectors. Be sure to follow the issue to watch the progress on it!
> The syntax for lambdas/closures feels weird to me. Currently there
> are two syntaxes (||{} and proc(){}) which have different semantics.
>
> My understanding is that these are already going to be unified into
> one syntax, and that addresses most of my feeling of weirdness with
> them. But I also wonder if it would be possible to unify them even
> further with regular functions.
This is certainly a nuanced topic! There's two different dimensions to
consider about closures:
1. Invokability, this corresponds to Fn/FnOnce/FnMut. This dictates
how many times a closure can be called, and how it borrows its called
(mutable reference or shared)
2. Capturing outer variables. Variables can be captured by value or by
reference.
The current plan of attack is to have two syntaxes for closures (still
under development:
// infer invokability, infer how variables are captured
|a, b, c| foo + a + b + c
// infer invokability, all variables are captured by value
move |a, b, c| foo + a + b + c
The idea here is to remove the slightly odd 'proc' syntax, and bring
the two in line. The `move` keyword indicates that all captured
variables will be moved into the closure.
We've avoided the syntax you described due to the `fn()` type. This is
a raw function pointer which doesn't correspond to any environment. A
closure, however, is represented differently (it's not just one word)
and it also has an environment. We wanted to avoid the confusion by
making the function pointer type and closure syntax too similar, so we
opted to not use the `fn` keyword to declare a closure, but instead
use bars. Does that make sense?
> There is still a lot of Rust I haven't touched yet. I haven't played
> much at all with unsafe blocks, raw pointers, or named lifetimes among
> other things. As I dive further into Rust, would continued feedback
> like this be appreciated? Is this kind of feedback helpful?
This kind of feedback is definitely helpful! You may also be
interested in our subreddit [1] and our discuss forum [2]. Thank you
for your kind thoughts and opinions, and I hope I was able to answer
some of your questions!
[1]: http://reddit.com/r/rust
[2]
Re: [rust-dev] Migrating libs out of rust-lang/rust
>> There's a cron job running which will trigger each build each night >> after the nightlies have finished building, and the .travis.yml script >> for these repos are all wired to nightlies rather than the PPA. > > > Could the source code for this cron job be published, with instructions on > how to get API keys or whatever Travis wants? I tried > https://github.com/patrickkettner/travis-ping , but only got a mysterious > error messages and didn’t feel like debugging that code. I've posted the scripts here: https://github.com/alexcrichton/bors-travis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Migrating libs out of rust-lang/rust
> Ok, I got the basic going with a temporary for of `libsemver` here:
> - https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
> - https://github.com/errordeveloper/rust-libsemver
Awesome! I've created a new repo for you to make a PR against:
https://github.com/rust-lang/semver
> - should I bother with enabling OS X beta on Travis?
Not at this time.
> - what naming convetion we gonna use? shall it be `rust-lib{name}`?
rust-lang/{name}
>> I've just checked: GitHub does not allow forking (and therefore making PRs
>> to) an empty repository, so the person creating the repository will have to
>> at least check the "Initialize this repository with a README" checkbox to
>> make a dummy first commit.
>
> Yeah, could someone create empty repos for all the libs we agreed to pull out?
This will be done on a case-by-case basis, feel free to just ping me
or others on IRC and we'll make a repo!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Migrating libs out of rust-lang/rust
>> We plan to implement any necessary infrastructure to ensure that the >> crates >> move out of the rust repository maintain the same level of quality they >> currently have. > > > Will these crates’ documentation be available online? At this time there are no plans for this, but we're certainly open to options! The need for these is a little less pressing now that `cargo doc` is implemented, but this is still a very important aspect to these crates. > Long term, I’d like Rust to have an official package index, like Python’s > PyPI: https://pypi.python.org/ We would as well! This will manifest itself in the form of a central package registry which cargo will also use for downloading remote packages and such. >> To this extent, the current process for moving a crate out of the standard >> distribution will be as follows: >> >> 1. A member of the core team will be contacted to create the repository >>`rust-lang/$foo`. >> 2. A PR will be made against `rust-lang/$foo` > > > I’ve just checked: GitHub does not allow forking (and therefore making PRs > to) an empty repository, so the person creating the repository will have to > at least check the "Initialize this repository with a README" checkbox to > make a dummy first commit. Aha, thanks! >> 3. A PR will be made against `rust-lang/rust` which will flag the relevant >> library as `#[deprecated]` with a message pointing at `rust-lang/$foo` >> >> In order to ensure that these repositories continue to stay up to date, we >> will have the following process in place: >> >> 1. Each repository will be hooked up to Travis CI and will be built each >> night once the new nightlies are available. > > > How will this be achieve? http://www.rust-ci.org/ does it, but I’d like to > see something more "official" and tied to the rust-lang.org binary nightlies > rather than the Ubuntu PPA. There's a cron job running which will trigger each build each night after the nightlies have finished building, and the .travis.yml script for these repos are all wired to nightlies rather than the PPA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Migrating libs out of rust-lang/rust
Currently the threshold for being "officially supported" will be one of being in the rust-lang organization or being on the travis dashboard. At this time there are no plans to have an in-tree way to distinguish, although I suspect that a README with a description would likely suffice. On Tue, Jul 29, 2014 at 3:45 PM, Thad Guidry wrote: > [snip] > >> >> 2. A status page [2] is provided to get a quick glance at the status of >> all >>officially supported repositories. >> >> The amount of infrastructure around keeping these repositories up to date >> will likely change over time, but this is the current starting point for >> automation. >> >> [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml >> [2]: http://buildbot.rust-lang.org/travis/travis.html > > > So going forward... > > Where can we look in source / folders / files ... to see what is an > "officially supported repository" and what is not ? Let's say I don't want > to have to look at the Travis view for that info, but just look at source to > figure this out. > > -- > -Thad > +ThadGuidry > Thad on LinkedIn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Migrating libs out of rust-lang/rust
Now that cargo is starting to become a larger part of the Rust ecosystem
it's time for some of the crates as part of the standard distribution to
move out of the main rust repository. This movement has been planned for
quite some time now, and it has only recently become possible with the
advent of cargo.
Starting today, we'd like to evolve crates not needed by rustc itself
outside of the compiler wherever possible. This will reduce cycle time on
development of these libraries, allow them to develop independently from
rustc, and hopefully allow them to be more focused in their target goals.
The process of moving crates out of the standard distribution will be an
ongoing and evolving one. We currently have the benefit of being able to
move the entire distribution forward in one atomic step with everything in
one repository, but this quickly becomes infeasible with many repositories.
We plan to implement any necessary infrastructure to ensure that the crates
move out of the rust repository maintain the same level of quality they
currently have.
To this extent, the current process for moving a crate out of the standard
distribution will be as follows:
1. A member of the core team will be contacted to create the repository
`rust-lang/$foo`.
2. A PR will be made against `rust-lang/$foo` with the current copy of the
code from `rust-lang/rust`. This PR will be expected to have the
following source structure:
* Cargo.toml - a manifest to build this repo as a cargo package
* .travis.yml - configuration to run automated tests on travis. A
sample can be found for hexfloat [1]
* LICENSE-{MIT,APACHE} - copied over from rust-lang/rust
* src/ - the same source structure as the folder in rust-lang/rust
3. A PR will be made against `rust-lang/rust` which will flag the relevant
library as `#[deprecated]` with a message pointing at `rust-lang/$foo`
In order to ensure that these repositories continue to stay up to date, we
will have the following process in place:
1. Each repository will be hooked up to Travis CI and will be built each
night once the new nightlies are available.
2. A status page [2] is provided to get a quick glance at the status of all
officially supported repositories.
The amount of infrastructure around keeping these repositories up to date
will likely change over time, but this is the current starting point for
automation.
[1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml
[2]: http://buildbot.rust-lang.org/travis/travis.html
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to get the file descriptors of standard I/O types?
There is not currently a method of doing so through the `std::io` apis. While possible through the rustuv and native apis, I would discourage manual use of those crates as they have experimental and volatile APIs. You may be interested in https://github.com/rust-lang/rust/pull/15643 which may add support for acquiring the file descriptor. That PR has dome discussion about the hazards of doing so, as well. On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > Hi. I want to use the existing I/O types (files, sockets, etc.) with epoll. > Is there an API call to get hold of their file descriptors? > > --Nat > > -- > http://www.natpryce.com > > ___ > 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] Impending change in RPATH behavior when linking to Rust dynamic libraries
> LD_LIBRARY_PATH is not known about by many The install.sh script now recommends adding an entry to this variable if it detects that this is necessary, so it's not *entirely* unknown. This doesn't help, however, if it's considered a bad practice. > 1) Link dependencies of rustc statically to it? For plugins to work, we're required to link libstd and friends dynamically to rustc, so sadly we're require to link rustc itself dynamically. > 2) On Windows the folder of the executable is always searched for > dependencies. Is this the case on Linux too? Then you could just let 'make > install' copy everything next to rustc. I do not believe that this is this case for linux or OSX, only for windows. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Seemingly Poor Scalability of M:N Scheduler
This is a known performance bug in the green schedulers being tracked at https://github.com/rust-lang/rust/issues/11730. To see the difference, you can run with RUST_THREADS=1 when using the green scheduler. On Fri, Jul 11, 2014 at 1:39 PM, Chandru wrote: > I tried the rust-http's comparison with go from here. > https://github.com/chris-morgan/rust-http/tree/master/comparisons > > Using the default code, which I guess uses 1:1 scheduling, rust falls behind > go when concurrency goes greater than the number of cores (4). I guess this > is to be expected as context switches increase without additional > parallelism. > > go 1 wrk 7856.76 > rust 1 wrk 19617.39 > go 2 wrk 20364.92 > rust 2 wrk 30591.88 > go 3 wrk 30408.15 > rust 3 wrk 45847.69 > go 4 wrk 41953.29 > rust 4 wrk 53632.75 > go 8 wrk 56632.79 > rust 8 wrk 54660.72 > go 16 wrk 58263.69 > rust 16 wrk 54906.18 > go 32 wrk 57773.54 > rust 32 wrk 56682.38 > > However, on switching to M:N with this change, > > #![feature(phase)] > #[phase(plugin)] > extern crate green; > > green_start!(main) > > rust seems to be stuck around 25K req/s while go's throughput goes much > higher. > > go 1 wrk 7850.23 > rust 1 wrk 24361.64 > go 2 wrk 20478.89 > rust 2 wrk 23349.38 > go 3 wrk 30592.79 > rust 3 wrk 24232.2 > go 4 wrk 42165.1 > rust 4 wrk 25950.4 > go 8 wrk 56540.86 > rust 8 wrk 27284.01 > go 16 wrk 57957.76 > rust 16 wrk 26275.33 > go 32 wrk 57611.55 > rust 32 wrk 25674.82 > > Am I reading this wrong or does it indicate some bottleneck in the M:N > scheduler? > > -- > Chandra Sekar.S > > ___ > 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] Stack usage of green tasks
By default, each stack is allocated with a "red zone" at the end for
running code on stack overflow, calling C functions, etc. The current
size of the red zone is 20K.
Requested stack sizes are always at least 20K, but the 20K is not
currently added to the stack size. So for your test case when you
request a 20K stack you're likely getting a ~10 byte stack (explaining
the overflow), and with a 21K stack you get a 1K stack which the task
can run in.
On Wed, Jul 9, 2014 at 8:13 AM, Chandru wrote:
> Hi,
>
> This piece of code,
>
> #![feature(phase)]
> #[phase(plugin)]
> extern crate green;
>
> use std::io::timer;
> use std::task::TaskBuilder;
>
> green_start!(main)
>
> fn main() {
> for _ in range(0, 1i) {
> TaskBuilder::new().stack_size(20*1024).spawn(proc() {
> timer::sleep(2)
> });
> }
> }
>
> fails with,
>
> task '' has overflowed its stack
> Illegal instruction (core dumped)
>
> Changing the stack size to 21K works. Why does such a trivial task overflow
> 20K of stack?
>
> --
> Chandra Sekar.S
>
> ___
> 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 running documented functions from doc code w/ rustdoc
Doc tests are compiled as if they were clients of a library, so you'll
have to write the test assuming the rest of the source was built with
`--crate-type lib` and then import it directly.
For example, you may have to do this:
```rust
main::under_test();
```
Doc test aren't really designed with executables in mind, sadly, but
perhaps that could change!
On Wed, Jul 9, 2014 at 9:37 AM, Jeffery Olson wrote:
> Consider the following docs:
>
>
> /// Foo
> ///
> /// ```rust
> /// under_test();
> /// ```
> pub fn under_test() {
> }
>
> doing `rustdoc main.rs --test` produces:
>
> jeff@jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test
>
> running 1 test
> test foo::under_test_0 ... FAILED
>
> failures:
>
> foo::under_test_0 stdout
> :5:5: 5:15 error: unresolved name `under_test`.
> :5 under_test();
> ^~
> error: aborting due to previous error
> task 'foo::under_test_0' failed at 'Box',
> /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:128
>
>
>
> failures:
> foo::under_test_0
>
> test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured
>
>
> Why is this? I've also tried different combinations of module imports to get
> this to work.. the only place this feature is used, extensively, is in
> libstd and it appears that maybe this is sidestepped because libstd is
> always linked by default? The manual doesn't really cover this in-depth,
> either.
>
> Any help would be appreciated.
>
> Thanks,
> Jeff
>
> ___
> 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] Impending change in RPATH behavior when linking to Rust dynamic libraries
It is indeed! You'll need to ensure that `/Users/ilya/Library/Local/Rust/current/lib` is in your DYLD_LIBRARY_PATH environment variable for OSX. On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko wrote: > Is the following error cause by this change? > > % rustc -v > dyld: Library not loaded: > x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib > Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc > Reason: image not found > Trace/BPT trap > > > On 9 July 2014 00:53, Brian Anderson wrote: >> Yes, it does. >> >> >> On 07/08/2014 04:41 PM, Simon Sapin wrote: >>> >>> On 08/07/14 23:57, Brian Anderson wrote: *Running rustc directly from the build directory will no longer work by default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath to the configure script. >>> >>> >>> Does this also apply to running a (nightly) binary distribution from where >>> the tarball was extracted, without installing it? >>> >> >> ___ >> 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] Met with a terrible fate
> I am thinking that maybe one solution could be that the C code calls > an init function that calls native::start and provides a function pointer > that start calls back into C. That way the C main thread will have a rust > runtime in the background, I *think*?. That is correct! > I hope this would be possible at least, the important thing is that it can > be > in the main thread, as often mobile platforms require to run in the main > thread because the GUI library needs it for some reason. At least in iOS. > (I am building a helper lib for making apps easier with our service) This is indeed possible! We have many many applications and games being written in Rust right now, and they all have the same requirement. > Other than that I don't really know how much I can restructure my code to > work without (objective-)C(#) not having to do anything special. The way > the library will be structured is that it has an internal thread where it > runs > at operation queue. Once that operation queue is empty the thread terminates > and if you add more operations to the queue the thread starts once again. So > a lot of the code will run in its own thread, which is at least good. > However > some of the code will work outside of the operation queue for things like > queries > that might use some kind of mutex to make sure it's not querying something > that > the operation queue is already processing. And for those mutexes to work it > probably > has to be within the same native::start... Unless I can use some kind of > unsafe C > mutex thing. Right now the C => Rust FFI bridge isn't as convenient as it could be. One option you may want to look into is what rust-civet [1] does which is to create a new native rust task per-request, but it doesn't spawn a thread per request. [1]: https://github.com/wycats/rust-civet/blob/master/src/raw.rs#L91-L106 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Met with a terrible fate
If you touch runtime services (such as those mentioned by Benjamin), it is assume that a Rust Task [1] is available. In your case, you're touching the unwinding service, but you have no set a catch-point for the call to unwinding anywhere. This sounds like you're triggering a failure without a task. This is akin to throwing a C++ exception without a try/catch block on the stack. You may wish to explore the std::rt::unwind [2] module, specifically the try function [3], but keep in mind that it is unsafe and you must be careful about what you're doing (the documentation explains this). I love getting the runtime running in nonstandard locations, so if you have any trouble, feel free to ping me on IRC! My nick is acrichto. [1]: http://doc.rust-lang.org/std/rt/task/struct.Task.html [2]: http://doc.rust-lang.org/std/rt/unwind/ [3]: http://doc.rust-lang.org/std/rt/unwind/fn.try.html On Wed, Jul 2, 2014 at 6:07 PM, Isak Andersson wrote: > Hello! > > I have written a library in Rust that has some pub extern fv's in it so that > they are callable from C. I wrote a C program to try calling these functions > and I was met with the following message: > > % ./test > > You've met with a terrible fate, haven't you? > > fatal runtime error: Could not unwind stack, error = 5 > zsh: illegal hardware instruction ./test > > To begin with, nice reference! > > Second of all. How do I fix this, I am guessing that I need to start the > rust runtime or something but I don't know how to do this, if someone could > point me in the right direction that would be great! > > If you need more specific code examples of what I'm doing I can provide it > it's just that I'm gonna sleep now and it doesn't seem like that's all too > relevant. Also I did link to the libraries in the order it told me to. > > Cheers! > > Isak Andersson > > ___ > 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] Rust 0.11.0 Released
ing and sharing rust code examples on-line. * Unused attributes are now more robustly warned about. * The dead_code lint now warns about unused struct fields. * Cross-compiling to iOS is now supported. * Cross-compiling to mipsel is now supported. * Stability attributes are now inherited by default and no longer apply to intra-crate usage, only inter-crate usage. * Error message related to non-exhaustive match expressions have been greatly improved. Contributors to Rust 0.11.0 --- Aaron Raimist Aaron Turon Adolfo Ochagavía Adrien Tétar Ahmed Charles Alan Andrade Alan Williams Alex Crichton Alexandre Gagnon Alexei Sholik Ali Smesseim Andrew Gallant Anton Löfgren Arcterus Ariel Ben-Yehuda Axel Viala Ben Noordhuis Benjamin Adamson Benjamin Herr Björn Steinbrink Boris Egorov Brandon Waskiewicz Brendan McLoughlin Brendan Zabarauskas Brian Anderson Cameron Zwarich Chris Morgan Chris Shea Christoph Burgdorf Christopher Bergqvist Christopher Kendell Clark Gaebel Conrad Kleinespel Corey Richardson Daniel Brooks Daniel Fagnan Daniel Micay David Creswick Derek Chiang (Enchi Jiang) Dirk Leifeld Dmitry Promsky Douglas Young Dylan Braithwaite Eduard Bopp Eduard Burtescu Edward Wang Emanuel Rylke Erick Tryzelaar Falco Hirschenberger Falco Hirschenberger Felix S. Klock II Flavio Percoco Florian Gilcher Florian Hartwig Florian Zeitz Gary M. Josack Guillaume Pinot Gábor Lehel Hanno Braun Heather Herman J. Radtke III HeroesGrave Huon Wilson Ivan Petkov J.C. Moyer Jacob Hegna Jakub Wieczorek James Laverack James Miller James Sanders Jeong YunWon Jihyeok Seo Jim Radford John Clements John Fresco John Schmidt John Simon Jonathan Bailey Jonathan Bailey Jonathan Reem Jonathan S Jordi Boggiano Jorge Aparicio Joseph Crail JustAPerson Justin Noah Jyun-Yan You Kang Seonghoon Kasey Carrothers Keegan McAllister Keegan McAllister Kevin Ballard Kevin Butler Kevin Cantu Kiet Tran Liigo Zhuang Luqman Aden Luqman Aden Manish Goregaokar Marvin Löbel Matt Brubeck Meyer S. Jacobs Michael Dagitses Michael Darakananda Michael Fairley Michael Pratt Michael Reinhard Michael Woerister Michael Zhou Mihnea Dobrescu-Balaur Mike Boutin Ms2ger Nathan Typanski Nick Cameron Nicolas Silva Nikita Pekin Niklas Koep Niko Matsakis Noam Yorav-Raphael OGINO Masanori P1start Patrick Walton Paul Stansifer Pawel Olzacki Phil Ruffwind Piotr Czarnecki Piotr Jawniak Randati Raphael Speyer Reilly Watson Renato Riccieri Santos Zannon Renato Zannon Richard Diamond Richo Healey Robert Buonpastore Ryan Mulligan Ryman Rüdiger Sonderfeld Santiago Rodriguez Sean Gillespie Sean McArthur Seo Sanghyeon Sergio Benitez Simon Sapin Stepan Koltsov Steve Klabnik Steven Fackler Steven Sheldon Sylvestre Ledru Ted Horst Thomas Backman Tim Brooks Timothée Ravier Tobba Tobias Bucher Tom Jakubowski Tom Lee TyOverby Utkarsh Kukreti Vadim Chugunov Valentin Tsatskin Valerii Hiora Virgile Andreani Wendell Smith Yehuda Katz Yuri Kunde Schlesner Zach Pomerantz Zooko Wilcox-O'Hearn aochagavia bachm bors fort free-Runner iancormac84 klutzy lucy m-r-r mdinger moonglum mrec theptrk ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] ref binding for parameters of functions?
Binding by ref is subtly different that the function still owns the
argument. For example, this may go awry with "ref:T"
struct Foo;
impl Drop for Foo {
fn drop(&mut self) { println!("dropping"); }
}
fn foo(ref _param: Foo) {}
fn main() {
let f1: fn(ref:Foo) = foo;
let f2: fn(Foo) = foo;
let f3: fn(&Foo) = foo;
f1(Foo);
f2(Foo);
f3(&Foo);
}
In that program, how many times is `dropping` printed? It should be
three, but I believe it will print four times due to f3 not
understanding that the value has already been dropped.
On Wed, Jul 2, 2014 at 11:49 AM, Sebastian Gesemann
wrote:
> So far I knew that `ref` could be used in `let` and `match`
> expressions. But I just tried using it for a function's parameter to
> see what happens and it actually compiled! :)
>
> fn foo(ref p: int) -> int {
> *p + 1
> }
>
> fn main() {
> let x = 1729i;
> let y = foo(x);
> println!("{}",y);
> }
>
> What I was wondering then was: What is the type of foo and what does
> it mean for how the parameter is passed exactly?
>
> After adding
>
> let bar: fn(int)->int = foo;
>
> to the main function, I realized that the reference called p probably
> refers to a function-local temporary int. A part of me hoped for p
> referring to main's x thus saving a copy/move. But in that case, the
> function's type would have to be different, right?
>
> So, for a brief moment I thought that Rust already supports
> auto-referencing for non-self parameters just like C++ does for "const
> T&". The reason I'm mentioning this is that I noticed an RFC PR for a
> feature like this.
>
> So, what do you think about what kind of semantic you want for such a
> function? Should its p refer to main's x in this case? Should its type
> be fn(ref:int)->int which would be ABI-compatible with fn(&T)->int?
> Due to ABI compatibility one could even be allowed to convert one
> function pointer to another:
>
>let f = foo; // fn(ref:int)->int with auto-referencing
>let g = f as fn(&int)->int; // no auto-referencing anymore
>
> The parameter "type" ref:T could be useful for getting rid of some
> explicit borrows one would otherwise need at the invocation site:
>
> fn show_vec(ref v: Vec) {...}
>
> fn main() {
> let x = vec!(1,2,3i);
> show_vec(x);
> }
>
> Comments? Opinions? Maybe this could be useful. And maybe this is a
> bad idea. I don't know. What I *don't* like about it is that "ref:T"
> is not really a type and this could compose badly in generic code.
>
> Cheers!
> sg
> ___
> 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] 0.11.0 prerelease testing
Hello Rustilians! Bors has outdone himself once again in preparing an 0.11.0 release candidate for us. I've done the usual smoke test, but if you'd also like to try them out the links are all pasted below. Remember that this is not a signed release yet, we've only got checksums for these files at this time. Signatures will come with the upcoming release. These binaries should support Mac OS X 10.7+, Windows 7 and 2008 RC2, and Linux. The source also supports a number of other platforms such as Android and iOS now. If all goes well with this candidate, it'll get signed in the coming days with a release soon after. commit: aa1163b92de7717eb7c5eba002b4012e0574a7fe http://static.rust-lang.org/dist/rust-0.11.0.tar.gz d1b3e36448bf12b8c9289024df416de10774b6d3235d7b1d22b248ef634411ba http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz 331d6374b3c8fca3e2b5fffb65ce75dfce3529bd47333de4a9ce636cb87be432 http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz cbfe2050f708479f2625a935d2f41165868f354ff740d2697e08acb2255670b2 http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz bbac91aff5464c20f39afcf078a693c4612717d6b1cc3f86f92075b2103bc22e http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz 93d6e6e98d00df3e946e4f7765172ad522a118dd34f1fac73ba74d43df92698b http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg 1183d6c8ab021f4049a2906c1527f705bae4bb4935aea897f4860eb5337363c3 http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg 8f5a1fe491d83c6be0a3082f0ac8504c89eed38263ae0ac0fad15d8c02e3b267 http://static.rust-lang.org/dist/rust-0.11.0-install.exe fb253072ba5373eb0af388f63e51122af9dd13379d762ca4100ee7334dbec9d2 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] iOS cross compilation
Nice job Valerii! This is all thanks to the awesome work you've been doing wrangling compiler-rt and the standard libraries. I'm excited to see what new applications Rust can serve on iOS! On Mon, Jun 16, 2014 at 9:19 AM, Valerii Hiora wrote: > Hi, > > So finally Rust can cross-compile for iOS (armv7 only for now). BTW, > it also means that Rust now can be used both for iOS and Android > low-level development. > > Short instructions are available here: > https://github.com/mozilla/rust/wiki/Doc-building-for-ios > > Unfortunately LLVM patch for supporting segmented stacks on armv7 was > declined by Apple (it used kind of private API) and therefore there is > no stack protection at all. > > It still could be enabled by compiling with a patched LLVM (I can > provide a patch and instructions if needed). > > Everything else should "just work" but let me know if you have any > problem. > > -- > > Valerii > ___ > 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] How to kill a child task from parent?
Rust tasks do not support being killed at arbitrary points. You'll
have to arrange ahead of time for a "please die" message to be sent a
long a channel, or a similar scheme for transmitting this information.
On Wed, Jun 4, 2014 at 9:33 AM, Aravinda VK wrote:
> Hi,
>
> I am trying different alternative to kill a task from parent, But I didn't
> get any ways to kill a task from its parent.
>
> In the following approach I started worker2 inside worker1 and worker1 from
> main. After 1000 miliseconds worker1 dies, but worker2 still continues.
>
> use std::io::timer::sleep;
>
> fn worker1(){
> spawn(proc() {
> worker2();
> });
> println!("worker 1");
> sleep(1000);
> fail!("I am done");
> }
>
> fn worker2(){
> loop{
> println!("worker 2");
> }
> }
>
> fn main(){
> spawn(proc() {
> worker1();
> });
> }
> Any suggestions?
>
> --
> Regards
> Aravinda | ಅರವಿಂದ
> http://aravindavk.in
>
> ___
> 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] A better type system
> Sorry for the brevity, I'm writing this from a phone and I haven't thought of > this issue very thoroughly. You appear to dislike one of the most fundamental features of Rust, so I would encourage you to think through ideas such as this before hastily posting to the mailing list. The current iteration of Rust has had a great deal of thought and design poured into it, as well as having at least thousands of man hours of effort being put behind it. Casually stating, with little prior thought, that large chunks of this effort are flatly wrong is disrespectful to those who have put so much time and effort into the project. We always welcome and encourage thoughtful reconsiderations of the design decisions of Rust, but these must be performed in a constructive and well-thought-out manner. There have been many times in the past where the design decisions of Rust have been reversed or redone, but these were always accompanied with a large amount of research to fuel the changes. If you have concrete suggestions, we have an RFC process in place for proposing new changes to the language while gathering feedback at the same time. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] No stdout in test builds?
The test runner captures stdout by default and prints it at the end of the test run, but only if the test failed. This is intended to turn down the noise of successful tests, especially the failing ones. If you pass the --nocapture option to the test binary, it will disable this behavior and println will print to the terminal by default. On Mon, May 26, 2014 at 10:21 PM, Urban Hafner wrote: > Hey everyone, > > still me, the Rust newbie ;) > > Coming from Ruby I use TDD quite heavily. For my toy rust project I've setup > my Makefile in such a way that it first compiles and runs a test build > before compiling the real executable. When trying to debug a failing test I > tried putting println! statements into the code under test. Apart from the > fact that I should probably start using a debugger instead I'd like to know > why the output doesn't show up. Does the test runner swallow it? Is there a > way to write to stdout or stderr during the test runs? > > Urban > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > > ___ > 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 way to wake up rust task?
> Waking up on timeout is hardly a good decision. Let's think about > thousands of connections, each waking up at a reasonable timeouts > (sometimes between 100 ms to 1 sec for my taste). The close_read is a > hack that doesn't work for many cases (listening sockets, pipes, SCTP > sockets, etc.) > > I'm not sure what the API should be. A way to poll on two sockets, or > on socket and channel simultaneously may work for me. Similarly it may > be an ability to kill the task. Or a way to send an interruption > signal (similar to EINTR). I agree that waking up a task arbitrarily blocked at any location is quite useful. It is also a significant amount of implementation to do so, and we do not plan on doing so at this time. Things like selection over sockets would likely come with an async I/O library which is planned for post-1.0 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Any way to wake up rust task?
There is no way to generically wake up or kill a task, it must be arranged via some other means for the task to wake up. For TCP connections, you can use the close_read() method or the set_read_timeout() methods. In 0.10, this was not implemented (we recommend you use master). On Thu, May 15, 2014 at 3:43 PM, Paul Colomiets wrote: > Hi, > > I have a few kinds of tasks like the ones reading from a TCP socket or > listening for TCP connections, that need to be shut down when > unneeded. How can I wake up/kill a task waiting for data in > Reader.read() method or similar? > > In the master branch I can set_timeout and wake up once a while (which > seems like ugly hack too) In 0.10 there is no even timeouts. Is there > any way to interrupt or kill a task? > > -- > Paul > ___ > 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] chaining #[start] methods
Rust doesn't support life-before-main, which is basically what this
ends up entailing. What you've done already is likely what you'll want
to keep doing, which is explicitly chaining control flow through the
startup process.
On Thu, May 15, 2014 at 1:11 PM, Noah Watkins wrote:
> I'd like to put the following in a crate that intercepts start-up to
> modify argc/argv, and then yield to whatever the normal start-up
> procedure is (native, green, call main, etc...).
>
> #[start]
> fn start(...) {
> /* pre-process argc/argv */
> call default start-up stuff
> }
>
> Currently I'm having to expose my crate's start-up routine and have
> the program using the crate handle this start-up process. Is there a
> way to have this work transparently within the create?
>
> -Noah
> ___
> 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] How to translate and use a void(*)(void*) in Rust ?
The equivalent of a function pointer in C is the bare fn type in rust. For example, you could write your binding as: // C code int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); // Rust definition fn sqlite3_bind_text(stmt: *mut sqlite3_stmt, arg1: libc::c_int, arg2: *libc::c_char, arg3: libc::c_int, arg4: extern fn(*mut libc::c_void)) -> libc::c_int; You'll note that "extern" means use the default foreign ABI, as the rust ABI is different than the C ABI. The two types you were trying, procedures and closures, have environments attached to them which is likely what the C function is not expecting. The "extern fn()" type is rust's function pointer type. Notably, however, values of "extern fn()" are assumed to be non-null by the compiler, so the interop with your C library may not be perfect because SQLITE_STATIC cannot have a value of "extern fn()" (as it would be null). To work around this, Rust has a null-pointer optimization where Option is optimized to a nullable pointer in terms of representation. There are currently some issues with ABI compatibility, but these will likely be addressed in the near future! On Tue, May 13, 2014 at 2:17 PM, Christophe Pedretti wrote: > Hi all, > > SQLITE is defining the following C function : > int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); > > How to include it in an extern block ? > I have tried this > fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n > : c_int, f : *proc(*())) -> c_int; > (a pointer to a function taking a pointer as an argument) > i have also tried > fn sqlite3_bind_text(pStmt : *mut(), iCol : c_int, value : *c_char, n > : c_int, f : *|*()|) -> c_int; > > In SQLITE, this argument can takes value SQLITE_STATIC or SQLITE_TRANSIENT > typedef void (*sqlite3_destructor_type)(void*); > #define SQLITE_STATIC ((sqlite3_destructor_type)0) > #define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1) > > for example, how to set this argument to SQLITE_STATIC in Rust ? > > Thanks > > -- > Christophe > http://chris-pe.github.io/Rustic/ > ___ > 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] how to capture de-reference to ~int
The ~int type has since moved to Box, which will one day be a
library type with Deref implemented on it (currently it is implemented
by the compiler). Regardless, there's no need to implement the Deref
trait for the type today, the compiler already takes care of it.
For example, your code will compile without the deref trait:
fn main() {
let x: Box = box 3;
let y = *x;
println!("{}", y);
}
The language only allows for one definition of each lang item, and
most lang items now reside in libcore, so you shouldn't have to define
them manually.
On Mon, May 12, 2014 at 11:50 AM, Noah Watkins wrote:
> I am trying to capture the reference to type `~int` with the following
> code. I can change it to apply to bare `int` and it works fine.
>
> #[lang="deref"]
> pub trait Deref {
> fn deref<'a>(&'a self) -> &'a Result;
> }
>
> impl Deref<~int> for ~int {
> fn deref<'a>(&'a self) -> &'a ~int {
> println!("deref caught");
> self
> }
> }
>
> fn main() {
> let x: ~int = 3;
> *x
> }
>
> Thanks,
> Noah
> ___
> 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] proper linking with exchange_malloc lang item
While not currently possible, we plan on accommodating use cases such as this through first-class allocators via type parameters. You'll be able to specify your own allocator an standard library routines that allocate memory. Your other option currently is to link to libcore (which doesn't provide an allocator), but you lose out on the functionality of the standard library. On Sun, May 11, 2014 at 10:30 AM, Noah Watkins wrote: > I've used the language item `exchange_malloc` to override the default > allocation routine with a custom allocator. A simple example works > fine, but I'm having trouble integrating it into a larger project. > > In particular, how can I use my new allocator and still have access to > all of libstd such that all allocations (even those done in libstd) > are routed through my allocator? As it stands now it only works with > `#![no_std]`, otherwise I get duplicate entries for things like > `allocate`. > > Thanks, > Noah > ___ > 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] Symbol visibility problem
Ah, I forgot to mention, but the visibility rules are different for
libraries than they are for executables (for better or for worse).
An executable only has reachable C functions exported. I don't think
statics are exported, but that's arguably a bug. Libraries, however,
have all functions/symbols exported.
If you're building an application which is invoked primarily through
some other binding, I'd recommend using a staticlib output rather than
an executable output (and just using the object file). This is
primarily what staticlibs exist for.
On Wed, Apr 30, 2014 at 10:41 AM, Vladimir Pouzanov wrote:
> Ok, seems that I found a reasonably good solution.
>
> The "app" is now an rlib, and the actual staticlib app that gets linked is a
> wrapper, that sources all external crates and re-exports required symbols
> like this:
>
> #[no_split_stack]
> #[no_mangle]
> #[start]
> pub extern fn main() {
> app::main();
> }
>
> I also had to move __STACK_LIMIT into external C file, as I couldn't define
> it as external in one crate and provide it in another crate down the chain.
>
>
> On Wed, Apr 30, 2014 at 5:29 PM, Vladimir Pouzanov
> wrote:
>>
>> Right, so I have a publicly reachable symbol __STACK_LIMIT inside my
>> libzinc rlib:
>>
>> #[no_mangle]
>> pub static mut __STACK_LIMIT: u32 = 0;
>>
>> which is present in rlib's object file:
>>
>> % arm-none-eabi-nm zinc.o|grep __STACK_LIMIT
>> B __STACK_LIMIT
>>
>> Now, I compile my application, which is a staticlib, emiting an obj (I
>> could change staticlib to binary, that doesn't really change anything at
>> this emit level):
>>
>> rustc -Z no-landing-pads -C relocation_model=static --target
>> thumbv7m-linux-eabi -Ctarget-cpu=cortex-m3 --opt-level 2 -Z lto --emit obj
>> -L ./build -o ./build/intermediate/app.o ./apps/app_sched.rs
>>
>> Which implicitly links to libzinc-de5e5c68-0.0.rlib.
>>
>> Given the lto nature, ./build/intermediate/app.o will contain all the
>> required code from libzinc (and libcore), so I proceed to linker:
>>
>> arm-none-eabi-ld -Map ./build/zinc.map -o ./build/zinc.elf -T
>> ./src/hal/lpc17xx/layout.ld ./build/intermediate/app.o
>> -L/opt/gcc-arm-none-eabi-4_7-2013q3/lib/gcc/arm-none-eabi/4.7.4/armv7-m
>> --gc-sections -lgcc
>>
>> Which fails due to "undefined reference to `__STACK_LIMIT'", as the lto
>> step didn't keep the __STACK_LIMIT (which is, along with __morestack, used
>> implicitly).
>>
>> I have the same problem with ISRs that re defined in libzinc. For now, I
>> make trampolines in the app code:
>>
>> #[no_mangle]
>> #[inline(never)]
>> #[no_split_stack]
>> pub unsafe fn task_scheduler() {
>> task::task_scheduler();
>> }
>>
>> that look bad, but I don't yet know a better way to do it.
>>
>> I cannot move __STACK_LIMIT or __morestack in a dedicated object file and
>> pass it to linker, as those depend on libzinc which isn't reaching the
>> linker explicitly.
>>
>>
>> On Wed, Apr 30, 2014 at 5:17 PM, Alex Crichton wrote:
>>>
>>> In an rlib, all publicly reachable symbols will be exported from the
>>> object, for example:
>>>
>>>
>>> mod foo { pub static BAR: int = 3; }
>>>
>>> That symbol is not exported because BAR is not reachable from the outside
>>> world.
>>>
>>> pub use foo::BAR;
>>> mod foo { pub static BAR: int = 3; }
>>>
>>> This time, BAR will be an exported symbol because it is publicly
>>> reachable (you could also make 'foo' public).
>>>
>>> Would that help your use case, or are you thinking of something more
>>> complex?
>>>
>>> On Wed, Apr 30, 2014 at 6:49 AM, Vladimir Pouzanov
>>> wrote:
>>> > I have the following setup:
>>> >
>>> > libzinc, compiles as rlib, provides all the stuff
>>> > support, compiles as obj, provides __morestack, memset/memcpy and
>>> > other
>>> > required things
>>> > libapp, compiles as staticlib emitting obj, depends on libzinc,
>>> > builds
>>> > with lto.
>>> >
>>> > I link libapp.o and support.o to get the final binary.
>>> >
>>> > Now, to make multitasking work, I need to move __morestack into
>>> > libzinc, so
>>> > that I can access task API from the function. The problem is that
>>> > publicly
>>> > visible
Re: [rust-dev] Symbol visibility problem
In an rlib, all publicly reachable symbols will be exported from the
object, for example:
mod foo { pub static BAR: int = 3; }
That symbol is not exported because BAR is not reachable from the outside world.
pub use foo::BAR;
mod foo { pub static BAR: int = 3; }
This time, BAR will be an exported symbol because it is publicly
reachable (you could also make 'foo' public).
Would that help your use case, or are you thinking of something more complex?
On Wed, Apr 30, 2014 at 6:49 AM, Vladimir Pouzanov wrote:
> I have the following setup:
>
> libzinc, compiles as rlib, provides all the stuff
> support, compiles as obj, provides __morestack, memset/memcpy and other
> required things
> libapp, compiles as staticlib emitting obj, depends on libzinc, builds
> with lto.
>
> I link libapp.o and support.o to get the final binary.
>
> Now, to make multitasking work, I need to move __morestack into libzinc, so
> that I can access task API from the function. The problem is that publicly
> visible __morestack in libzinc is not visible from libapp, which requires it
> implicitly via function prologues. Other static symbols (like __STACK_LIMIT)
> are not available as well.
>
> Is there any way to promote the visibility of symbols from libzinc to libapp
> in this case?
>
> --
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> ___
> 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] PipeStream.by_ref() - Multiple applicable methods problem
Oddly enough, that was the first thing I jumped to as well! I think
that type inference like that doesn't drive method selection, which is
why it ended up not working out.
On Wed, Apr 30, 2014 at 3:54 AM, Michael Neumann wrote:
>
>
> Am 29.04.2014 22:51, schrieb Alex Crichton:
>
>> The by_ref() method exists on both the Reader and the Writer trait,
>> and you're working with a stream which implements both Reader and
>> Writer (hence the confusion by the compiler).
>>
>> You could work around it with something like:
>>
>> fn rdr<'a, T: Reader>(t: &'a mut T) -> RefReader<'a, T> {
>> t.by_ref()
>> }
>>
>> Eventually, with UFCS, you'll be able to do something like:
>>
>> let rdr = Reader::by_ref(&mut inp);
>>
>> (hopefully soon!)
>
> Thanks so much! This works!
>
> Actually I was trying to explicitly specify the type as in:
>
> let rdr: RefReader = t.by_ref();
>
> and was wondering why it failed.
>
> Regards,
>
> Michael
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] PipeStream.by_ref() - Multiple applicable methods problem
The by_ref() method exists on both the Reader and the Writer trait,
and you're working with a stream which implements both Reader and
Writer (hence the confusion by the compiler).
You could work around it with something like:
fn rdr<'a, T: Reader>(t: &'a mut T) -> RefReader<'a, T> {
t.by_ref()
}
Eventually, with UFCS, you'll be able to do something like:
let rdr = Reader::by_ref(&mut inp);
(hopefully soon!)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Make use of the LLVM ExecutionEngine
This used to be present for the JIT support that the old rusti provided, but the internal support for this has been removed. You may be able to resurrect it outside the compiler with these LLVM apis, but it may also require exposing more LLVM details from the compiler itself. There is currently no plan to bring a rust interpreter back before 1.0 On Mon, Apr 28, 2014 at 5:23 PM, Benjamin Gudehus wrote: > Hi! > > Will there be a way to make usage of ExecutionEngine and call LLVM functions > via a TypeRef to them? > > I saw there is even a LLVMDisposeExecutionEngine in rustc::lib::llvm::llvm. > > pub fn LLVMDisposeExecutionEngine(EE: ExecutionEngineRef); > > --Benjamin > > > ___ > 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] morestack prologue contains broken machine code
The prologue is run on every single function executed in a program, so
I believe that in the hopes of keeping it as light as possible it
never makes any function calls.
I do agree though, that it's at tricky situation in that case. How
does TLS otherwise work for that platform?
On Fri, Apr 25, 2014 at 8:14 AM, Vladimir Pouzanov wrote:
> I have a side question related to the same code.
>
> Currently __STACK_LIMIT is constant, but I would like the preamble to verify
> stack overflow for multithreaded context, i.e. __STACK_LIMIT will depend on
> the current running thread. Is there any reason, why it's not a function?
> Any objections if I do some refactoring and make it a function? For a simple
> case that could be a weak symbol that returns a constant.
>
>
> On Tue, Apr 22, 2014 at 9:00 AM, Alex Crichton wrote:
>>
>> I agree with Corey, it's much better to send it upstream first. I'd be
>> more than willing to help you out with writing tests or taking a peek
>> at the patch if you want! I'm acrichto on IRC
>>
>> On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov
>> 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
>> > 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
>> >> 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
>> >>>
>> >>> 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
>> >>> >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}
>> >&
Re: [rust-dev] morestack prologue contains broken machine code
I agree with Corey, it's much better to send it upstream first. I'd be
more than willing to help you out with writing tests or taking a peek
at the patch if you want! I'm acrichto on IRC
On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov 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
> 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 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
>>> 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
>>> >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
Re: [rust-dev] Announcing the newest member of Mozilla's Rust team, Aaron Turon
Welcome Aaron! I'm so excited to have you with us! On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson wrote: > Hey there, Rusticators, > > Grand news! Starting today Aaron Turon is joining the Rust team. Aaron did > his PhD thesis on concurrency at Northeastern University, where he published > widely-noted papers on 'reagents' and 'LVars'. He will be focusing on making > Rust's standard libraries the best they can be. He's aturon on IRC; say 'hi' > when you see him. > > Welcome aboard, Aaron. > ___ > 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] Per-process arenas and ARCs
> Refcounting is, of course, unsuitable for objects with circular links and I’m > going to have plenty of them. You may be interested in the downgrade() method on Rc/Arc along with the Weak pointers (they allow cycles, but also allow for destruction). > So I’m thinking about adding per-task arenas that can be freed once the task > completes. It looks like it’s possible, but not implemented yet. There is some initial support in libarena [1] you may find useful (specifically the TypedArena) > Additionally, RC boxes are not sendable - is there an easy way to ‘upgrade’ > an object graph to ARCs and then send it? At this time, you'll have to initially create everything as an Arc, you can't upgrade from an Rc to an Arc (totally separate) Hope that help! [1] - http://static.rust-lang.org/doc/master/arena/index.html ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] morestack prologue contains broken machine code
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 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
>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
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cloning Generic Structs/Enums with lifetime parameters
> How do I manually implement "clone()" for Structs/Enums with lifetime
> parameters (e.g. for struct below)?
>
> ---
> struct Cls<'a,T> {
> x:&'a T
> }
impl<'a, T: Clone> Clone for Cls<'a, T> {
fn clone(&self) -> Cls<'a, T> {
Cls { x: self.x }
}
}
You may find the generics [1] and traits [2] sections of the tutorial
helpful as well!
[1] - http://static.rust-lang.org/doc/master/tutorial.html#generics
[2] - http://static.rust-lang.org/doc/master/tutorial.html#traits
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Shouldn't task::try(...).unwrap() fail to compile?
The ~Any type has a special implementation of Show:
https://github.com/mozilla/rust/blob/master/src/libstd/any.rs#L151-L155
I believe it was primarily used in failure messages originally (you
can fail a task with ~Any)
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang wrote:
> It current can compile, but judging from signatures:
>
> std::task::try is pub fn try(f: proc(): Send -> T) -> Result ~Any:Send>
> std::result::unwrap on the other hand is impl Result { fn
> unwrap(self) -> T {...} }
>
> There's no way the error part of result from task::try(...) can fulfil Show
> so it shouldn't compile.
>
> Though to ask the list first before filing a bug report.
>
> Regards,
> Edward
>
> ___
> 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] Storing Handle (for Select) in a collection causes a crash
> unsafe { h.add(); }
>
> handles.insert(h.id(), h);
This is why the add method is unsafe: "This method is unsafe because
it requires that the Handle is not moved while it is added to the
Select set."
You're moving the handle after it's been added, which later will cause
a segfault.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Keeping up with Breaking Changes
Greetings Rustlers! Projects such as cargo and Servo have recently expressed interest in having a "breaking changes" changelog as part of the rust repository. It's often difficult for those not closely tied to the compiler itself to keep up with all the changes that are getting made. Additionally, I imagine that some sort of changelog such as this would be quite useful to others! With this in mind, we're going to introduce two new measures to help developers port code to newer versions of Rust. The first is to produce a "breaking changes log" of changes to the language and its libraries that may break existing code, *along with instructions for porting*. The second is to use the #[deprecated] attribute more aggressively to instruct the compiler to inform users how to upgrade their code. # A log of Breaking Changes The way we've decided to go about doing this is to start being stricter about the content of commit messages. Any commit which is a breaking change will be required to adhere to a particular template. In doing this, we hope to avoid merge conflicts on one literal changelog file, and we also hope to leverage what git already gives us. Note that this requires isolating the breaking change to a single commit instead of having extra changes leak into the commit. If multiple distinct breaking changes are made, they will require separate commits. The precise definition of a breaking change will likely be an evolving concept, but there are a few classes of changes that definitely count: * Changing the semantics of existing functionality in the standard libraries * Removing functionality from the standard libraries * Modifications to the language itself (parsing and semantics) The template which breaking changes will be required to look like is: First, a brief one-line summary of the change Second, take as long as is necessary to explain exactly what the change is, why it's being changed, what it can be replaced with (if applicable) and general guidelines about dealing with the change. In addition to a few paragraphs about the change itself, the literal string "[breaking-change]" must appear at the end of the commit message in order to indicate that it is a commit that has a breaking change. This will allow filtering commits on this string to only take a look at breaking changes. [breaking-change] To get a log of breaking changes, you can use git-log: git log --grep breaking-change # Exclude bors merge commits git log --grep breaking-change --no-merges # Usage of #[deprecated] In addition to a stricter policy around commit messages, we're going to start encouraging more aggressive use of the #[deprecated] attribute to help transitioning code. A good example of this recently is when the `shuffle_mut` function was renamed to `shuffle`. The original function had an attribute that looked like: #[deprecated = "function renamed to `shuffle`"] We aren't yet going to require that the old function retain its functionality, it is acceptable to replace it with a fail!()-ing stub for now. The compilation warning should be a good enough indicator about what needs to be changed. The deprecated functions themselves aren't expected to stick around for all eternity. By 1.0 we will clean out all #[deprecated] functionality, and before then we'll likely leave in #[deprecated] functions for about a month or so. # Be on the lookout! With these two guidelines in place, we hope to ease the pain of upgrading through versions of rust while it's still under rapid development. Reviewers, be sure to keep an eye out for breaking changes in the future and make sure that the that these measures are followed! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] does not fulfill `Send` error since last pull request
Your BaseImpl enum isn't necessarily Send because it contains a trait
object (~Base). The typechecker doesn't know what type is behind this
trait object, so it doesn't know whether it's send or not. To make the
BaseImpl type Send again, you can change the definition to:
enum BaseImpl {
FirstThinkImpl(~Base:Send), // note the ":Send"
SecondThinkImpl(~SecondThink),
}
This error message should get much better with opt-in bounds [1] as it
will point exactly at what's not Send.
[1] -
https://github.com/rust-lang/rfcs/blob/master/active/0003-opt-in-builtin-traits.md
as
On Thu, Apr 10, 2014 at 11:23 AM, Philippe Delrieu
wrote:
> Since my last today gill fetch I have this error:
>
> error: instantiating a type parameter with an incompatible type `~BaseImpl`,
> which does not fulfill `Send`
>
> for this code :
> trait Base{}
>
> struct SecondThink{
> count2: int,
> }
>
> enum BaseImpl{
> FirstThinkImpl(~Base),
> SecondThinkImpl(~SecondThink),
> }
>
> let (newchan, newport): (Sender, Receiver) = channel();
> <-- error here
> ^~~
> The Send behavior has changed? Is it permanent and if yes is there a work
> around?
>
> Philippe
> ___
> 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] Building a static array of pointers
As you've discovered in bug #13325, dealing with external constants in
static expressions is sometimes a little tricky. I would avoid casting
for now (as happens in the bug) in favor of stronger types. For
example, this compiles and runs for me:
extern {
fn foo();
fn bar();
}
static table: &'static [extern unsafe fn()] = &[foo, bar];
pub mod test {
#[no_mangle] pub extern fn foo() { println!("foo"); }
#[no_mangle] pub extern fn bar() { println!("bar"); }
}
fn main() {
for f in table.iter() {
unsafe { (*f)(); }
}
}
Note that in rust, a value of type `extern fn()` cannot be null, but
`Option` can indeed be null. You'll probably want
something along the lines of:
#[link_section = ".isr_vector"]
pub static ISR_VECTOR_TABLE: [Option, ..N] =
[Some(...), None, Some(...), ...];
On Fri, Apr 4, 2014 at 12:53 PM, Vladimir Pouzanov wrote:
> Is it possible to port the following C code to rust?
>
> __attribute__ ((section(".isr_vector")))
> void (* const isr_vector_table[])(void) = {
> &_stack_base,
> main, // Reset
> isr_nmi, // NMI
> isr_hardfault,// Hard Fault
> 0,// CM3 Memory Management Fault
> 0,// CM3 Bus Fault
> 0,// CM3 Usage Fault
> &_boot_checksum, // NXP Checksum code
> 0,// Reserved
> 0,// Reserved
> 0,// Reserved
> isr_svcall, // SVCall
> 0,// Reserved for debug
> 0,// Reserved
> isr_pendsv, // PendSV
> isr_systick, // SysTick
> };
>
> here main and isr_* are rust external functions, and _stack_base is defined
> as
>
> extern void _stack_base()
>
> and gets loaded from linker script.
>
> Also, is it possible to make a weak symbol in rust or somehow emulate it?
> Weak symbols are used in C code to provide the following functionality:
> isr_* functions are stubs with default implementation (morse out id code
> with led, loop forever), but if any of those requires actual code, than it
> is overrides the weak "morse-blinking" function symbol.
>
> --
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> ___
> 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] Rust 0.10 Released
ge. * native: The default runtime is now `libnative`. If `libgreen` is desired, it can be booted manually. The runtime guide has more information and examples. * native: All I/O functionality except signals has been implemented. * green: Task spawning with `libgreen` has been optimized with stack caching and various trimming of code. * green: Tasks spawned by `libgreen` now have an unmapped guard page. * sync: The `extra::sync` module has been updated to modern rust (and moved to the `sync` library), tweaking and improving various interfaces while dropping redundant functionality. * sync: A new `Barrier` type has been added to the `sync` library. * sync: An efficient mutex for native and green tasks has been implemented. * serialize: The `base64` module has seen some improvement. It treats newlines better, has non-string error values, and has seen general cleanup. * fourcc: A `fourcc!` macro was introduced * hexfloat: A `hexfloat!` macro was implemented for specifying floats via a hexadecimal literal. * Tooling * `rustpkg` has been deprecated and removed from the main repository. Its replacement, `cargo`, is under development. * Nightly builds of rust are now available * The memory usage of rustc has been improved many times throughout this release cycle. * The build process supports disabling rpath support for the rustc binary itself. * Code generation has improved in some cases, giving more information to the LLVM optimization passes to enable more extensive optimizations. * Debuginfo compatibility with lldb on OSX has been restored. * The master branch is now gated on an android bot, making building for android much more reliable. * Output flags have been centralized into one `--emit` flag. * Crate type flags have been centralized into one `--crate-type` flag. * Codegen flags have been consolidated behind a `-C` flag. * Linking against outdated crates now has improved error messages. * Error messages with lifetimes will often suggest how to annotate the function to fix the error. * Many more types are documented in the standard library, and new guides were written. * Many `rustdoc` improvements: * code blocks are syntax highlighted. * render standalone markdown files. * the --test flag tests all code blocks by default. * exported macros are displayed. * reexported types have their documentation inlined at the location of the first reexport. * search works across crates that have been rendered to the same output directory. Contributors to Rust 0.10 Adrien Tétar Alan Andrade Alex Crichton Alex Whitney a_m0d Andre Arko Andrew Chin aochagavia Arcterus Axel Viala aydin.kim b1nd Ben Harris Ben Noordhuis Ben Striegel Birunthan Mohanathas Björn Steinbrink Brendan Zabarauskas Brian Anderson Brian Leibig Bruno de Oliveira Abinader Byron Williams Cadence Marseille Carl-Anton Ingmarsson Chris Morgan Chris Wong chromatic Clark Gaebel Cole Mickens Colin Sherratt comex Corey Richardson Daniel Fagnan Daniel MacDougall Daniel Micay Dave Hodder David Manescu Davis Silverman Derek Chiang Derek Guenther Div Shekhar Dmitry Promsky Dmitry Vasiliev Douglas Young Dylan Braithwaite Eduard Bopp Eduard Burtescu Edward Wang Edward Z. Yang Ehsanul Hoque Erick Tryzelaar Eunchong Yu Felix Crux Felix S. Klock II Flavio Percoco Florian Hahn Florian Zeitz Gábor Lehel Gary M. Josack gentlefolk Geoffroy Couprie George Papanikolaou gifnksm Guillaume Pinot HeroesGrave Hong Chulju Huon Wilson Ian Daniher Ivan Enderlin Jack Moffitt Jag Talon Jake Kerr James Deng James Miller Jan Kobler Jan Niklas Hasse Jason Fager Jed Davis Jeff Olson JeremyLetang joaoxsouls Johannes Löthberg Johannes Muenzel Jonathan S Jorge Aparicio Jyun-Yan You Kang Seonghoon Keshav Kini Kevin Ballard Kiet Tran klutzy korenchkin kud1ing kvark Laurent Bonnans Liigo Zhuang Lindsey Kuper lpy Luca Bruno lucy Luqman Aden Luqman Aden Marcel Rodrigues Marvin Löbel Matt Brubeck Matthew McPherrin Matthias Einwag Matthijs van der Vleuten Micah Chalmer Michael Darakananda Michael Woerister Mickaël Delahaye Mike Boutin mr.Shu Ms2ger musitdev Nathaniel Herman Nick Cameron Nick Desaulniers Nif Ward Niko Matsakis noam OGINO Masanori Olle Jonsson Palmer Cox Patrick Walton Peter Marheine Petter Remen Piotr Czarnecki Piotr Zolnierek Q.P.Liu Raphael Catolino Richard Diamond Robert Gawdzik Ryan Scheel (Havvy) Salem Talha Scott Jenkins Scott Lawrence Sean Chalmers Sean McArthur Seo Sanghyeon Shamir Khodzha SiegeLord Simon Sapin Stepan Koltsov Sterling Greene Steven Fackler Steven Stewart-Gallus Ted Horst Tobias Bucher Tomas Sedovic Tom Lee TorstenWeber Trent Ogren Vadim Chugu
[rust-dev] Reminder: ~[T] is not going away
I've noticed recently that there seems to be a bit of confusion about the fate of ~[T] with an impending implementation of DST on the horizon. This has been accompanied with a number of pull requests to completely remove many uses of ~[T] throughout the standard distribution. I'd like to take some time to straighten out what's going on with Vec and ~[T]. # Vec In a post-DST world, Vec will be the "vector builder" type. It will be the only type for building up a block of contiguous elements. This type exists today, and lives inside of std::vec. Today, you cannot index Vec, but this will be enabled in the future once the indexing traits are fleshed out. This type will otherwise largely not change from what it is today. It will continue to occupy three words in memory, and continue to have the same runtime semantics. # ~[T] The type ~[T] will still exist in a post-DST, but its representation will change. Today, a value of type ~[T] is one word (I'll elide the details of this for now). After DST is implemented, ~[T] will be a two-word value of the length and a pointer to an array (similarly to what slices are today). The ~[T] type will continue to have move semantics, and you can borrow it to &[T] as usual. The major difference between today's ~[T] type and a post-DST ~[T] is that the push() method will be removed. There is no knowledge of a capacity in the representation of a ~[T] value, so a push could not be supported at all. In theory a pop() can be efficiently supported, but it will likely not be implemented at first. # [T] As part of DST, the type grammar will start accepting [T] as a possible substitute for type parameters. This basically means that if your type parameters is &T, then &[U] can satisfy the type parameter. While possible, I imagine that it will be rare for this to appear in apis. This is an unsized type, which means that it's more limited what you can do with it than you can with a sized type. The full details of [T] will become apparent once DST is implemented, but it's safe to say that APIs and usage should rarely have to deal with this type, and it will likely be mostly transparent. # Converting between Vec and ~[T] Conversions between these two types will be provided, and the default implementations will be free. Converting from Vec to ~[T] will be simply forgetting the capacity, and converting from ~[T] to Vec will set the capacity to the length. Helper methods will likely be provided to perform a forceful reallocating shrink when going from Vec to ~[T], but it will not be the default. ## The cost of Vec => ~[T] Some concerns have been brought up that this can in theory be a costly transition under the assumption that this does a reallocation of memory to shrink to the capacity to exactly the length. This will likely not be the default implementation. Some concerns have then been brought up that some allocators require the size of the allocation to be passed to free(), and that this model is incompatible with that flavor of allocator. We believe that this fear can be alleviated with a "shrink if necessary" method on allocators. The default allocator (backed by the system malloc) would be a no-op because the size to free is not used. Allocators which use the size passed to free would actually perform a reallocation. # Choosing between Vec and ~[T] Primarily, if you need a growable vector, you should use Vec. If you do not need a growable vector, but you're instead just dealing with an array of items, then you should use ~[T]. As a concrete example, I'll take the read_to_end() method on io's Reader trait. This type must use a Vec internally to read data into the vector, but it will return a ~[T] because the contents are conceptually frozen after they have been read. There is no blanket right decision to choose between Vec and ~[T], this will need to be done on a case-by-case basis to evaluate whether apis should take or consume Vec or ~[T]. # Moving Forward In order to implement DST, it is not necessary to remove all usage of ~[T] today. It is necessary to remove all *growable* usage of ~[T], however. All uses of vectors which need growable or shrinkable vectors need to switch to Vec. If a vector does not need to be grown or shrunk, it can remain as ~[T]. Concretely speaking, the next steps forward for ~[T] would entail: * Add a Vec -> ~[T] conversion. This will be an expensive conversion today because it requires an allocation (due to the layout of today's ~[T]), but it will not be expensive in the future. * Add a ~[T] -> Vec conversion. Like the above step, this will also be expensive, but it will not be so in the future. * Remove the `push` and `pop` families of methods from ~[T] Hopefully that clears up any mystery surrounding what's happening with ~[T] and Vec! If you have any questions, feel free to respond to this email or to join us in IRC. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.moz
[rust-dev] 0.10 prerelease testing
Greeting Rustlers! Our lovely automation has recently prepared an 0.10 release candidate recently. I've tested them slightly, and if you'd like to also give them a shot all the links are included at the end of this message. Remember that this is not a signed release yet, we've only got checksums for these files at this time. Signatures will come with the upcoming release. The astute may notice that we have a large number more links for 0.10 than we did for 0.9, and these are all the new binary installers for Linux and Mac. These have seen little testing beyond the recent nightlies, and more usage would be greatly appreciated! These binaries should support Mac OS X 10.7+, Windows 7 and 2008 RC2, and Linux. The source also supports FreeBSD and Android. If all goes well with this RC, it'll get signed in the coming days with a release soon after. commit: a5681d25906fd07eee00dd430a1053ff722da26a http://static.rust-lang.org/dist/rust-0.10.tar.gz 461ef730566d644466f6edee23181e1f8200c83927912e5eb95864a2a83824da http://static.rust-lang.org/dist/rust-0.10-x86_64-unknown-linux-gnu.tar.gz ff65bc52b8486c6df0e44e94e030b912b8d25170db8e498841ca568ab0fc9fe2 http://static.rust-lang.org/dist/rust-0.10-i686-unknown-linux-gnu.tar.gz 7deb2225fe3f6ab01fada566d9a37a0d2db1bae2edb179eb24e5c2574dac02ae http://static.rust-lang.org/dist/rust-0.10-x86_64-apple-darwin.tar.gz b018f3649beee30c4f34fa0bbfe1a784c63e8be86d71883b9893d6941af8a429 http://static.rust-lang.org/dist/rust-0.10-i686-apple-darwin.tar.gz 25c35c762b7c485230bcc5f7893ef961fdba48da537f19f2a16d0f68303b4d3e http://static.rust-lang.org/dist/rust-0.10-x86_64-apple-darwin.pkg 5d21be30318137f6c17ad190d8c272e8afe00335666ec547729cba3ebe690246 http://static.rust-lang.org/dist/rust-0.10-i686-apple-darwin.pkg 5e2b210e2d9ea64ffb7afd376a256fedcb48350bc32472ae8abd4aa72de2535c http://static.rust-lang.org/dist/rust-0.10-install.exe 03a7655bf5e154599efddb9688451664fb2f17acb792ef1a2c74b4ea19636bbe I'm sure that 0.10 will be an amazing release, and I hope everyone is as excited as I am! ___ 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?
You are right in that the __morestack function is a requirement from enabling segmented stacks in LLVM. While we no longer use truly segmented stacks, we still use the segmented stack prologue in order to detect stack overflow. This is a crucial piece of infrastructure for rust code used to ensure safety. It's difficult to provide a __morestack implementation for all platforms, however (as you've discovered), and we're thinking of possibly adding an option to disable split stacks globally (the function prologue), or moving to an alternative scheme which requires fewer runtime dependencies. On Sun, Mar 23, 2014 at 11:48 AM, Vladimir Pouzanov wrote: > Thanks for links to bugs. > > Is there anything to read on the whole morestack thing? I thought that it's > connected to segmented stacks that are (are they?) going away. > > It seems that I can use #[no_split_stack] before each and every function to > generate a valid freestanding binary. If I just could use that in header... > > > On Sun, Mar 23, 2014 at 6:24 PM, Corey Richardson wrote: >> >> 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 >> 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 >> > 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 >> >> >> >> 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 >> >>> 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-
Re: [rust-dev] How do I pass -march down to llvm from rustc?
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 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 > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fork in Rust
I would recommend using io::process with the detach option set to true rather than invoking fork(). The green runtime is not fork-safe, and at this time we're not guaranteeing that the native runtime is fork-safe. On Mon, Mar 17, 2014 at 4:59 AM, John Mija wrote: > Is possible to fork/daemonize in Rust? Without problems due to the > interaction between fork(2) and threads. > ___ > 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] Work week minutes and upcoming RFCs
> I was working from the assumption that the initializers of non-mut statics > are checked to ensure they do not contain values of non-Freeze types, nor > destructors. Does the new plan also involve lifting this restriction? (From > the below it seems like it does.) Yes, by disallowing taking the address of non-Freeze non-mut (confusing, right?) statics, we can allow non-Freeze values in non-mut statics. > While I understand the motivation here, couldn't/shouldn't this use case be > served by an `init_atomic_uint!()` macro? Sadly not quite, the fields of an `AtomicUint` should be private, and macros don't bypass privacy (they're just AST expansion) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Work week minutes and upcoming RFCs
> Can someone explain why this is necessary? > > static FOO: Option> = None; > let foo = &FOO; Implementation-wise, FOO is placed into read-only memory in the executable. This is done mainly for optimization purposes for LLVM. Something like static NUM_BITS: uint = 32; should act like a #define in C, so we must mark it as constant (read-only) > Why would this be a problem? Or is this not what's being referred to? If you attempt to mutate read-only memory, you get a signal. See https://github.com/mozilla/rust/issues/10577 for more info > Actually... given that you can't move out of a static, and all > functions/methods are either by value (moves) or by ref (takes address), > this means the only way you could interact with a non-Freeze static _at all_ > is if it were Pod/Copy. But Pod/Copy types are never non-Freeze. That's close, but there's on other crucial use case, which is initialization of other statics. Consider atomics static INIT_ATOMIC_UINT: AtomicUint = ...; static mut CNT: AtomicUint = INIT_ATOMIC_UINT; The first static should *not* have to be mut, because then you can mutate the initial pattern, which seems weird. Hence, we forbid taking the address of INIT_ATOMIC_UINT. The second one, however, must be mutable, but it's also in a module outside of where AtomicUint is defined. We use the original bit-pattern, copying it into read-write memory so we can modify it. We allow taking the address of `static mut` memory. In general though, yes, a non-freeze static is only useful as a *value* if it's Copy, but it's quite useful for other static initialization. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] #[link] using absolute path?
Right now #[link] only takes library names (it gets passed through as
a -l flag).
It doesn't seem much more brittle to use -C link-args than to have
absolute paths, so you may wish to explore that route.
On Wed, Mar 5, 2014 at 1:12 AM, Doug wrote:
> Hey~
>
> I've been trying to hook rust up the v8 VM to play with, and although I've
> got it working, it's kind of annoying to do.
>
> In CMake you can extract a list of build targets using something like:
>
> function(get_dependent_targets TARGET RETURN)
> get_property(LOC TARGET ${TARGET} PROPERTY LOCATION)
> set(RTN ${LOC})
> get_property(LIBS TARGET ${TARGET} PROPERTY LINK_LIBRARIES)
> foreach(LIB ${LIBS})
> get_dependent_targets(${LIB} LIB_LIST)
> foreach(LIBI ${LIB_LIST})
> list(APPEND RTN ${LIBI})
> endforeach()
> endforeach()
> set(${RETURN} ${RTN} PARENT_SCOPE)
> endfunction()
>
> That generates a list of the absolute paths to the libraries you're linking
> against for your target.
>
> So in my case I have some light V8 interop libraries in libv8i, and the
> output list of static libraries to link against is:
>
> /Users/doug/projects/rust/rust-v8/build/libv8i.a
> /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a
> /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a
> /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a
> /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a
> /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a
>
> Now, what do I do with that list to link with rustc?
>
> I tried generating an include using a template, and the output was along the
> lines of:
>
> #[link(name = "/Users/doug/projects/rust/rust-v8/build/libv8i.a", kind =
> "static")]
> #[link(name =
> "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a",
> kind = "static")]
> #[link(name =
> "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a",
> kind = "static")]
> #[link(name =
> "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a",
> kind = "static")]
> #[link(name =
> "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a",
> kind = "static")]
> #[link(name =
> "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a", kind
> = "static")]
> extern {
> ... etc.
> }
>
> ...but that doesn't work. Instead I've had to fudge my template down to
> non-absolute paths, and invoke it like this:
>
> rustc package.rs -Lbuild -Lbuild/src/v8/out/native
>
> It's not a huge deal in this trivial example, but as the number of
> dependencies increases you end up stuck either have an absolutely massive
> rustc call script to generate (or something like that), or having to copy
> all your static libraries into a single folder post-build.
>
> So TLDR; is there some way to specify an absolute path for #[link]?
>
> (I did see #[link_args] but that's not portable as I understand it)
>
> ~
> Doug.
>
>
> ___
> 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] How to import std::comm::select?
You can use the prototype through `std::comm::Select` for now, but the
macro is not currently exported. See
https://github.com/mozilla/rust/issues/12044 for more information.
On Mon, Feb 24, 2014 at 10:59 PM, Frank Huang wrote:
> Hi everyone,
>
> Here with a novice question. I'm trying to use the select! macro in:
>
> http://static.rust-lang.org/doc/0.9/std/comm/select/index.html
>
>
> And can't figure out how to get it to import. My current code looks like
> this:
>
> use std::comm::select;
>
> fn main() {
> let (p,c): (Port, Chan) = Chan::new();
> spawn(proc() {
> c.send(42);
> });
>
> select! (
> val = p.recv() => {
> print(val);
> }
> );
> }
>
>
> However, `rustc testselect.rs` says "error: macro undefined: 'select'". I've
> also tried "use std::comm::*" with feature(globs). Thanks for the help!
>
> Frank
>
> ___
> 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] Travis CI is building Pull Requests
Greetings Rustafarians! As of a few minutes ago, along with the merging of #12437, I would like to inform everyone that we're now going to be building all Pull Requests on Travis CI [1]. Travis is a continuous integration system which integrates very well with Github and makes it fairly easy to run lots of builds. Running a full "make check" would be quite burdensome for Travis, so we're limiting it to building a stage1 rustc and then running some of the broader, yet quick test suites. These builds should take about 20-30 minutes per build, and builds will be triggered for each new PR along with each force-push to the PR. We will continue to gate all PRs on bors, and bors will continue to run the exhaustive test suites on our "tier 1" platforms. Using Travis will hopefully provide quicker feedback about misformatted files, failed tests, typos, etc. It is still highly recommended to run "make check" before submitting a PR (as always), but Travis will hopefully start serving as a first line of defense for bors. The ultimate goal is for this to take some load off bors with fewer failed PRs. You can check the status of a PR by looking at the bottom of the page on Github, or visiting Travis's status page [2]. That's all for now, keep on being awesome everyone! [1] - https://travis-ci.org/ [2] - https://travis-ci.org/mozilla/rust ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] unique vector patterns are no longer supported at head
This feature was removed from the language in
https://github.com/mozilla/rust/pull/12244. The as_slice() method will
continue to work for now.
On Thu, Feb 20, 2014 at 4:53 PM, Michael Dagitses wrote:
> The following no longer works:
> let file = match std::os::args() {
> [_prog, f] => f,
> _ => fail!("usage"),
> };
>
> This works, but is not pretty. Is there a better solution?
> let file = match std::os::args().as_slice() {
> [ref _prog, ref f] => f.to_owned(),
> _ => fail!("usage"),
> };
>
> Thanks, and sorry if this is a repeat, I don't see any relevant threads and
> I see this is a very recent change.
> 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] Improving our patch review and approval process (Hopefully)
> Currently, all patches are being tested after they are approved. However, I > think it would be of great benefit for contributors - and reviewers - to > test patches before and after they're approved. I would personally love to explore using Travis-CI for this. I think this is almost exactly what travis was built for. That being said, there's no way that travis could handle a full `make check` for rust. However, perhaps travis could handle `make check-stage0-lite` (not that this rule exists yet). I think we would have to figure out how to avoid building LLVM, but beyond that we *should* be able to run a bunch of stage0 tests and optimistically print out the results of the PR. This obviously won't catch many classes of bugs, but perhaps it would be good enough for a preemptive check. The best part about this is that it's almost 0 overhead of automation for us because travis would handle all of it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: About the library stabilization process
> Does that include ABI compatibility? For now, this is going to be tough to provide because of compiler bugs sadly (see #10208 and #10207). ABI stability is a broad topic which encompasses symbol names, whether the function is generic or not, implementation of a generic function, etc. For now, I believe the stability attributes are targeted at the signature of a method. > Should it be an error to use lower stability internally? One of the goals will be to have the intrinsics module be #[experimental] or something other than #[stable], but this module is the basis of implementation for many other stable functions, so I believe that the module itself will have to opt-in to using the unstable intrinsic api, but the api provided by the module will still be stable. >> By default all nodes are *stable* - library authors have to opt-in to >> stability index tracking. This may end up being the wrong default and we'll >> want to revisit. > > Oh dear god no. `stable` should be *earned* over time, otherwise it's > meaningless. The compiler should treat untagged code as `unstable`, > `experimental` or a special `untagged` stability and accept that level > by default. One thing we should be sure to accomplish with this default is that you cannot use unstable apis by default. I imagine that an #[unstable] module can use #[unstable] functions, but perhaps #[unstable]-flagged items still have to opt-in to using other unstable items? > Requesting permission to spam the issue tracker with minor annoyances > we definitely don't want to live with forever. The C FFI <-> idiomatic > Rust bridge is especially painful. You may be interested in #11920 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb instruction set.
Yes, if you use rust-llvm-2014-02-11 as the base of the PR I can merge
it in and update the LLVM that rust is using.
On Sun, Feb 16, 2014 at 4:08 AM, Svetoslav Neykov wrote:
> I don't find any of the ARM split stack changes in the LLVM tree, just a
> single
> patch to the llvm-commits a year ago with no followup.
> (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130318/168838
> .html)
> Since my changes depend on the ARM changes it doesn't make sense to try to
> merge
> them before the previous changes are accepted.
>
> I guess I should use the rust-llvm-2014-02-11 branch as the base for my PR?
>
> Svetoslav.
>
>
> -Original Message-
> From: alexc...@gmail.com [mailto:alexc...@gmail.com] On Behalf Of Alex
> Crichton
> Sent: Sunday, February 16, 2014 1:16 AM
> To: Svetoslav Neykov
> Cc: rust-dev@mozilla.org
> Subject: Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb
> instruction set.
>
> For LLVM patches, we prefer if you have first attempted to upstream
> the patch with LLVM before we push it to our local fork. This normally
> entails emailing the llvm-commits mailing list. Once this upstream
> attempt has been made, you can open a PR against the rust-lang/llvm
> repo on github.
>
> This looks pretty awesome though, nice work!
>
>
> On Sat, Feb 15, 2014 at 8:36 AM, Svetoslav Neykov
> wrote:
>> Hi,
>>
>> I am working on getting Rust to directly compile code for bare metal ARM
>> devices working in Thumb mode. I created a patch for LLVM to emit
>> the appropriate function prologue. Since I couldn't find instructions on
> how
>> to submit the change for review and inclusion in the Rust's copy of LLVM I
>> am sending it here on the dev mailing list.
>>
>> Besides the mechanincal differences between the ARM and Thumb functions,
>> because of the different instruction sets, there is difference in how the
>> stack limit is located. The ARM version uses hardware which isn't
> available
>> on the lower-end Thumb processors (namely system co-processor and MMU)
>> therefore I am looking for the stack limit at a predefined location in
>> memory - STACK_LIMIT. It is the responsibility of the wrapping runtime
>> to manage this location with the correct value. It can vary from a simple
>> constant defined by the linker to actively managed variable by a RTOS
>> implementation.
>> (thanks to whitequark for discussing the possible approaches)
>>
>> There is an old pull request for Rust which was the precursor to this
> change
>> located at https://github.com/mozilla/rust/pull/10942. Once the patch is
>> accepted I will try to update it to the latest changes in the repository.
>>
>> Here is the patch itself:
>>
>
> ===
>>
>> Add stack overflow check for ARM Thumb instruction set.
>>
>> The code assumes that the stack limit will be located at the
>> address labeled STACK_LIMIT.
>> ---
>> lib/Target/ARM/ARMFrameLowering.cpp | 184
> +++-
>> lib/Target/ARM/ARMFrameLowering.h | 2 +
>> 2 files changed, 185 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/Target/ARM/ARMFrameLowering.cpp
> b/lib/Target/ARM/ARMFrameLowering.cpp
>> index bdf0480..c286228 100644
>> --- a/lib/Target/ARM/ARMFrameLowering.cpp
>> +++ b/lib/Target/ARM/ARMFrameLowering.cpp
>> @@ -14,6 +14,7 @@
>> #include "ARMFrameLowering.h"
>> #include "ARMBaseInstrInfo.h"
>> #include "ARMBaseRegisterInfo.h"
>> +#include "ARMConstantPoolValue.h"
>> #include "ARMInstrInfo.h"
>> #include "ARMMachineFunctionInfo.h"
>> #include "ARMTargetMachine.h"
>> @@ -1481,10 +1482,20 @@ static uint32_t AlignToARMConstant(uint32_t Value)
> {
>> // stack limit.
>> static const uint64_t kSplitStackAvailable = 256;
>>
>> +void
>> +ARMFrameLowering::adjustForSegmentedStacks(MachineFunction &MF) const {
>> + const ARMSubtarget *ST = &MF.getTarget().getSubtarget();
>> + if(ST->isThumb()) {
>> +adjustForSegmentedStacksThumb(MF);
>> + } else {
>> +adjustForSegmentedStacksARM(MF);
>> + }
>> +}
>> +
>> // Adjust function prologue to enable split stack.
>> // Only support android and linux.
>> void
>> -ARMFrameLowering::adjustForSegmentedStacks(MachineFunction &MF) const {
>> +ARMFrameLowering::adjustForSegmentedStacksARM(MachineFunction &MF) const
> {
>>const ARMSubtarget *ST = &
Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb instruction set.
For LLVM patches, we prefer if you have first attempted to upstream
the patch with LLVM before we push it to our local fork. This normally
entails emailing the llvm-commits mailing list. Once this upstream
attempt has been made, you can open a PR against the rust-lang/llvm
repo on github.
This looks pretty awesome though, nice work!
On Sat, Feb 15, 2014 at 8:36 AM, Svetoslav Neykov wrote:
> Hi,
>
> I am working on getting Rust to directly compile code for bare metal ARM
> devices working in Thumb mode. I created a patch for LLVM to emit
> the appropriate function prologue. Since I couldn't find instructions on how
> to submit the change for review and inclusion in the Rust's copy of LLVM I
> am sending it here on the dev mailing list.
>
> Besides the mechanincal differences between the ARM and Thumb functions,
> because of the different instruction sets, there is difference in how the
> stack limit is located. The ARM version uses hardware which isn't available
> on the lower-end Thumb processors (namely system co-processor and MMU)
> therefore I am looking for the stack limit at a predefined location in
> memory - STACK_LIMIT. It is the responsibility of the wrapping runtime
> to manage this location with the correct value. It can vary from a simple
> constant defined by the linker to actively managed variable by a RTOS
> implementation.
> (thanks to whitequark for discussing the possible approaches)
>
> There is an old pull request for Rust which was the precursor to this change
> located at https://github.com/mozilla/rust/pull/10942. Once the patch is
> accepted I will try to update it to the latest changes in the repository.
>
> Here is the patch itself:
> ===
>
> Add stack overflow check for ARM Thumb instruction set.
>
> The code assumes that the stack limit will be located at the
> address labeled STACK_LIMIT.
> ---
> lib/Target/ARM/ARMFrameLowering.cpp | 184
> +++-
> lib/Target/ARM/ARMFrameLowering.h | 2 +
> 2 files changed, 185 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Target/ARM/ARMFrameLowering.cpp
> b/lib/Target/ARM/ARMFrameLowering.cpp
> index bdf0480..c286228 100644
> --- a/lib/Target/ARM/ARMFrameLowering.cpp
> +++ b/lib/Target/ARM/ARMFrameLowering.cpp
> @@ -14,6 +14,7 @@
> #include "ARMFrameLowering.h"
> #include "ARMBaseInstrInfo.h"
> #include "ARMBaseRegisterInfo.h"
> +#include "ARMConstantPoolValue.h"
> #include "ARMInstrInfo.h"
> #include "ARMMachineFunctionInfo.h"
> #include "ARMTargetMachine.h"
> @@ -1481,10 +1482,20 @@ static uint32_t AlignToARMConstant(uint32_t Value) {
> // stack limit.
> static const uint64_t kSplitStackAvailable = 256;
>
> +void
> +ARMFrameLowering::adjustForSegmentedStacks(MachineFunction &MF) const {
> + const ARMSubtarget *ST = &MF.getTarget().getSubtarget();
> + if(ST->isThumb()) {
> +adjustForSegmentedStacksThumb(MF);
> + } else {
> +adjustForSegmentedStacksARM(MF);
> + }
> +}
> +
> // Adjust function prologue to enable split stack.
> // Only support android and linux.
> void
> -ARMFrameLowering::adjustForSegmentedStacks(MachineFunction &MF) const {
> +ARMFrameLowering::adjustForSegmentedStacksARM(MachineFunction &MF) const {
>const ARMSubtarget *ST = &MF.getTarget().getSubtarget();
>
>// Doesn't support vararg function.
> @@ -1697,3 +1708,174 @@
> ARMFrameLowering::adjustForSegmentedStacks(MachineFunction &MF) const {
>MF.verify();
> #endif
> }
> +
> +void
> +ARMFrameLowering::adjustForSegmentedStacksThumb(MachineFunction &MF) const {
> +// const ARMSubtarget *ST = &MF.getTarget().getSubtarget();
> +
> + // Doesn't support vararg function.
> + if (MF.getFunction()->isVarArg())
> +report_fatal_error("Segmented stacks do not support vararg functions.");
> +
> + MachineBasicBlock &prologueMBB = MF.front();
> + MachineFrameInfo* MFI = MF.getFrameInfo();
> + const ARMBaseInstrInfo &TII = *TM.getInstrInfo();
> + ARMFunctionInfo* ARMFI = MF.getInfo();
> + DebugLoc DL;
> +
> + // Use R4 and R5 as scratch register.
> + // We should save R4 and R5 before use it and restore before
> + // leave the function.
> + unsigned ScratchReg0 = ARM::R4;
> + unsigned ScratchReg1 = ARM::R5;
> + uint64_t AlignedStackSize;
> +
> + MachineBasicBlock* prevStackMBB = MF.CreateMachineBasicBlock();
> + MachineBasicBlock* postStackMBB = MF.CreateMachineBasicBlock();
> + MachineBasicBlock* allocMBB = MF.CreateMachineBasicBlock();
> + MachineBasicBlock* getMBB = MF.CreateMachineBasicBlock();
> + MachineBasicBlock* mcrMBB = MF.CreateMachineBasicBlock();
> + MachineBasicBlock* magicMBB = MF.CreateMachineBasicBlock();
> +
> + for (MachineBasicBlock::livein_iterator i = prologueMBB.livein_begin(),
> + e = prologueMBB.livein_end(); i != e; ++i) {
> +allocMBB->addLiveIn(*i);
> +getMBB->addLiveIn(*i);
> +magicMBB->addLiveIn(*i);
> +mcrMBB->addLiveIn(*i);
> +prevStackMBB->addLiveIn(*
Re: [rust-dev] Pointer to trait method?
You'll always need a concrete type in order to get the trait method
for that type. Something like this may work for you though:
trait A {
fn foo(Self);
}
impl A for int { fn foo(a: int) {} }
fn main() {
let f: fn(int) = A::foo;
}
On Fri, Feb 14, 2014 at 2:14 PM, Tommy M. McGuire wrote:
> Suppose I have a trait T:
>
> trait A {
> fn fun(t:T); // <- [1]
> }
>
> Is there a way to get a pointer to the implementation of fun for a
> specific T? How would I go about calling it?
>
> (Yeah, I know I'm kinda far off the reservation.)
>
> [1] Not necessarily an instance method, but that would be useful, too.
>
>
> --
> Tommy M. McGuire
> mcgu...@crsr.net
> ___
> 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] [rustc-f039d10] A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)
For android, we provide the +v7 feature by default in order to allow LLVM to lower these 64-bit atomics to actual instructions. If you compile with `-C target-feature=+v7` then it shouldn't make a function call to __kernel_cmpxchg64. On Fri, Feb 14, 2014 at 10:31 AM, Ian Daniher wrote: > Targetting ARM hard float, v7 CPU. > > Any ideas how to go about addressing this? > -- > From My Tiny Glowing Screen > > > On Fri, Feb 14, 2014 at 10:20 AM, Alex Crichton wrote: >> >> Are you targeting a platform other than x86? I recently added support >> for 64-bit atomics on all platforms, and without the right cpu or >> target feature set LLVM will lower them to intrinsic calls, and it's >> possible that you're missing an intrinsic somewhere. >> >> On Fri, Feb 14, 2014 at 9:48 AM, Ian Daniher >> wrote: >> > Hey All, >> > >> > I'm attempting to run rustc on a 3.0.36 kernel. Within the last few >> > weeks, >> > it started complaining about __kernel_cmpxchg64. Unfortunately, like >> > many, >> > the systems on which I'd like to use Rust are beyond my control, so >> > simply >> > upgrading the kernel's not an especially viable option. >> > >> > Anyone know the root cause of this issue? >> > >> > Thanks! >> > -- >> > Ian >> > >> > ___ >> > 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] [rustc-f039d10] A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)
Are you targeting a platform other than x86? I recently added support for 64-bit atomics on all platforms, and without the right cpu or target feature set LLVM will lower them to intrinsic calls, and it's possible that you're missing an intrinsic somewhere. On Fri, Feb 14, 2014 at 9:48 AM, Ian Daniher wrote: > Hey All, > > I'm attempting to run rustc on a 3.0.36 kernel. Within the last few weeks, > it started complaining about __kernel_cmpxchg64. Unfortunately, like many, > the systems on which I'd like to use Rust are beyond my control, so simply > upgrading the kernel's not an especially viable option. > > Anyone know the root cause of this issue? > > Thanks! > -- > Ian > > ___ > 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] Help: type `std::comm::Chan` does not implement any method in scope named `clone`
Can you supply the output of `rustc -v`? The snippet complies ok for
me off master.
On Thu, Feb 13, 2014 at 8:17 AM, Liigo Zhuang wrote:
> I compiled the lasted rustc from source yesterday.
>
> 2014年2月13日 下午8:17于 "Alex Crichton" 写道：
>
>> What version of the compiler are you using? The clone-able Chan only
>> very recently landed, so you'll need a very up-to-date compiler to get
>> the change.
>>
>> On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang wrote:
>> > Hi Rusties,
>> >
>> > When try to compile tmp.rs, I got the error:
>> >
>> > ```
>> > tmp.rs:8:10: 8:19 error: type `std::comm::Chan` does not implement
>> > any
>> > method in scope named `clone`
>> > tmp.rs:8 let _ = c.clone();
>> > ^
>> > ```
>> >
>> > But I don't know how to do. Please help me. Thank you.
>> >
>> > tmp.rs:
>> > ```
>> > #[deriving(Clone)]
>> > pub struct A {
>> > dummy: uint,
>> > }
>> >
>> > pub fn main() {
>> > let (p, c) = Channew();
>> > let _ = c.clone();
>> > }
>> > ```
>> >
>> > --
>> > 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] RFC: Conventions for "well-behaved" iterators
For reference, this topic was discussed last August as well: https://mail.mozilla.org/pipermail/rust-dev/2013-August/005113.html On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin wrote: > Hi, > > The Rust documentation currently makes iterators behavior undefined after > .next() has returned None once. > > http://static.rust-lang.org/doc/master/std/iter/trait.Iterator.html >> >> The Iterator protocol does not define behavior after None is >> returned. A concrete Iterator implementation may choose to behave >> however it wishes, either by returning None infinitely, or by doing >> something else. > > > http://static.rust-lang.org/doc/master/guide-container.html >> >> In general, you cannot rely on the behavior of the next() method >> after it has returned None. Some iterators may return None forever. >> Others may behave differently. > > > > This is unfortunate. Code that accepts any iterator as input and does with > it anything more complicated than a single 'for' loop will have to be > defensive in order to not fall into undefined behavior. > > The type system can not enforce anything about this, but I'd like that we > consider having conventions about "well-behaved" iterators. > > --- > > Proposal: > > 0. An iterator is said to be "well-behaved" if, after its .next() method has > returned None once, any subsequent call also returns None. > > 1. Iterators *should* be well-behaved. > > 2. Iterators in libstd and other libraries distributed with rustc *must* be > well-behaved. (I.e. not being well-behaved is a bug.) > > 3. When accepting an iterator as input, it's ok to assume it's well-behaved. > > 4. For iterator adaptors in particular, 3. means that 1. and 2. only apply > for well-behaved input. (So that, eg. std::iter::Map can stay as > straightforward as it is, and does not need to be coded defensively.) > > --- > > Does the general idea sound like something y'all want? I'm not overly > attached to the details. > > -- > 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] Help: type `std::comm::Chan` does not implement any method in scope named `clone`
What version of the compiler are you using? The clone-able Chan only
very recently landed, so you'll need a very up-to-date compiler to get
the change.
On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang wrote:
> Hi Rusties,
>
> When try to compile tmp.rs, I got the error:
>
> ```
> tmp.rs:8:10: 8:19 error: type `std::comm::Chan` does not implement any
> method in scope named `clone`
> tmp.rs:8 let _ = c.clone();
> ^
> ```
>
> But I don't know how to do. Please help me. Thank you.
>
> tmp.rs:
> ```
> #[deriving(Clone)]
> pub struct A {
> dummy: uint,
> }
>
> pub fn main() {
> let (p, c) = Channew();
> let _ = c.clone();
> }
> ```
>
> --
> 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] Fwd: Problems building rust on OSX
This problem has been fixed on master, so I would recommend using master or uninstalling LLVM temporarily from the system (a non-standard gcc in the path may also mess with compilation) On Sun, Feb 9, 2014 at 1:15 PM, Martin Koch wrote: > Hi List > > I'm trying to get rust to compile, but I'm apparently running into this bug: > > https://github.com/mozilla/rust/issues/11162 > > So my question is: How do I manually download and use this snapshot: > > rust-stage0-2014-01-20-b6400f9-macos-x86_64-6458d3b46a951da62c20dd5b587d44333402e30b.tar.bz2 > > Thanks, > > /Martin Koch > > > ___ > 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] Fwd: user input
> Is there any way we can get rid of the need to create a buffered reader? It
> feels too enterprisey.
There's really no way to efficiently define a `read_line` method on a
reader that doesn't have an underlying buffer. For that reason, I
think that we'll always require that the stream be buffered somehow.
Despite that, we could return a buffered stdin by default. We could
also have task-local stdin handles which hide the ability to be
buffered. This will not play nicely at all with multiple tasks reading
stdin, but I don't think the current solution plays very nicely so I'd
be fine glossing over that use case.
> Ah, that's interesting. In most languages whenever you ask for user input
> (read on stdin) it automatically triggers a flush on stdout and stderr
That's a good point that I hadn't thought of. If we go towards a
task-local stdin then we could make the read methods on the local
stdin handle flush the local output handles, which would probably
solve this problem.
On Sun, Feb 9, 2014 at 3:26 AM, Matthieu Monrocq
wrote:
>
>
>
> On Sun, Feb 9, 2014 at 12:15 PM, Renato Lenzi wrote:
>>
>>
>>
>> Always talking about read & write i noticed another interesting thing:
>>
>> use std::io::buffered::BufferedReader;
>> use std::io::stdin;
>>
>> fn main()
>> {
>> print!("Insert your name: ");
>> let mut stdin = BufferedReader::new(stdin());
>> let s1 = stdin.read_line().unwrap_or(~"nothing");
>> print!("Welcome, {}", s1);
>> }
>>
>> when i run this simple code the output "Insert your name" doesn't appear
>> on the screen... only after typing and entering a string the whole output
>> jumps out... am i missing some "flush" (ala Fantom) or similar? I am using
>> Rust 0.9 on W7.
>
>
> Ah, that's interesting. In most languages whenever you ask for user input
> (read on stdin) it automatically triggers a flush on stdout and stderr to
> avoid this uncomfortable situation.
>
> I suppose it would not be took difficult to incorporate this in Rust.
>
> -- Matthieu.
>
>>
>>
>>
>> On Sun, Feb 9, 2014 at 2:40 AM, Patrick Walton
>> wrote:
>>>
>>> On 2/8/14 3:35 PM, Alex Crichton wrote:
>>>>
>>>> We do indeed want to make common tasks like this fairly lightweight,
>>>> but we also strive to require that the program handle possible error
>>>> cases. Currently, the code you have shows well what one would expect
>>>> when reading a line of input. On today's master, you might be able to
>>>> shorten it slightly to:
>>>>
>>>> use std::io::{stdin, BufferedReader};
>>>>
>>>> fn main() {
>>>> let mut stdin = BufferedReader::new(stdin());
>>>> for line in stdin.lines() {
>>>> println!("{}", line);
>>>> }
>>>> }
>>>>
>>>> I'm curious thought what you think is the heavy/verbose aspects of
>>>> this? I like common patterns having shortcuts here and there!
>>>
>>>
>>> Is there any way we can get rid of the need to create a buffered reader?
>>> It feels too enterprisey.
>>>
>>> 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
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] user input
We do indeed want to make common tasks like this fairly lightweight,
but we also strive to require that the program handle possible error
cases. Currently, the code you have shows well what one would expect
when reading a line of input. On today's master, you might be able to
shorten it slightly to:
use std::io::{stdin, BufferedReader};
fn main() {
let mut stdin = BufferedReader::new(stdin());
for line in stdin.lines() {
println!("{}", line);
}
}
I'm curious thought what you think is the heavy/verbose aspects of
this? I like common patterns having shortcuts here and there!
On Sat, Feb 8, 2014 at 3:06 PM, Renato Lenzi wrote:
> I would like to manage user input for example by storing it in a string. I
> found this solution:
>
> use std::io::buffered::BufferedReader;
> use std::io::stdin;
>
> fn main()
> {
> let mut stdin = BufferedReader::new(stdin());
> let mut s1 = stdin.read_line().unwrap_or(~"nothing");
> print(s1);
> }
>
> It works but it seems (to me) a bit verbose, heavy... is there a cheaper way
> to do this simple task?
>
> Thx.
>
> ___
> 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] Rust's 2013 issue churn
Some of you may have already seen GitHub's new State of the Octoverse 2013 at http://octoverse.github.com/ I'd just like to point out that the rust repository closed the second most number of issues (6408) on all of GitHub. Just to reiterate, out of the millions of repositories on GitHub, we closed the *second highest* number of issues! Congratulations to everyone, this was truly a community effort. I look forward to closing even more issues this year! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Handling I/O errors
I'd recommend one of two solutions, one is a match guard:
match reader.read(buf) {
Ok(cnt) => { /* ... */ }
Err(ref e) if e.kind == io::EndOfFile => { /* ... */ }
Err(e) => return Err(e)
}
and the other would be to home-grow your own macro if you find
yourself writing the same pattern frequently.
On Mon, Feb 3, 2014 at 7:25 PM, Palmer Cox wrote:
> I like this change quite a bit. However, is there a more succinct way than
> the following to take an action on EOF:
>
> match reader.read(buff) {
> Ok(cnt) => {
> // Do something
> }
> Err(io_error) => match io_error.kind {
> EndOfFile => {
> // Do something for EOF
> }
> _ => return Err(io_error)
> }
> }
>
> -Palmer Cox
>
>
>
> On Mon, Feb 3, 2014 at 9:19 PM, Alex Crichton wrote:
>>
>> > By returning a Result from all function calls, it's not much cleaner
>> > to handle errors
>>
>> Oops, wrong word there, I meant to indicate that it *is* much cleaner
>> to handle errors with Result rather than conditions.
>> ___
>> 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] Nick Cameron joins the Rust team at Mozilla
Welcome Nick! I can't wait to see that 1.0 issue count go down! On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson wrote: > Hi Rusties, > > I'm just thrilled to announce today that Nick Cameron (nrc) has joined > Mozilla's Rust team full-time. Nick has a PhD in programming language theory > from Imperial College London and has been hacking on Gecko's graphics and > layout for two years, but now that he's all ours you'll be seeing him > eradicate critical Rust bugs by the dozens. Good luck, Nick, and welcome to > the party. > > Regards, > Brian > ___ > 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] Handling I/O errors
> By returning a Result from all function calls, it's not much cleaner > to handle errors Oops, wrong word there, I meant to indicate that it *is* much cleaner to handle errors with Result rather than conditions. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Handling I/O errors
Greetings Rustaceans!
Upon updating your nightly builds tonight some of you may realize that
all I/O code will fail to compile. Fear not, this simply means that
#11946 has landed! The summary of this change is the same as its
title, "remove io::io_error". This is quite a far-reaching change,
despite its simple summary.
All I/O now returns a value of type `io::IoResult` which is just a
typedef to `Result`. By returning a Result from all
function calls, it's not much cleaner to handle errors (condition
syntax is quite awkward), less overhead (registering a condition
handler was expensive), and clearer what I/O should do now (should you
raise? should you return a "0 value"?).
Handling errors is always a tricky situation, so the compiler now
provides you two tools to assist you in handling errors:
1. The new unused_must_use lint. This lint mode will tell you when you
don't use an IoResult. The purpose of this lint is to help you find
out where in your program you're silently ignoring errors (often by
accident). If you want even more warnings, you can turn on the
unused_result lint which will warn about *all* unused results, not
just those of type Result/IoResult.
2. The new if_ok!() macro. This macro has a fairly simple definition
[0], and the idea is to return-early if an Err is encountered, and
otherwise unwrap the Ok value. Some sample usage looks like:
fn fun1() -> io::IoResult { ... }
fn fun2() -> io::IoResult { ... }
fn fun3() -> io::IoResult<()> { ... }
fn foo() -> io::IoResult {
if_ok!(fun3());
let val = if_ok!(fun1()) as uint + if_ok!(fun2());
Ok(val)
}
These two tools are in place to help you handle errors unobtrusively
as well as identify locations where you've forgotten to handle errors.
Sorry about the awful rebasings you'll have to do in advance, but it's worth it!
[0] - https://github.com/mozilla/rust/blob/master/src/libstd/macros.rs#L202-L204
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] static mut and owning pointers
Our discussion in a recent meeting concluded that statics will not be
allowed to contain types with destructors, and you also won't be able
to move out of static items:
https://github.com/mozilla/rust/issues/10577#issuecomment-32294407
On Tue, Jan 28, 2014 at 3:34 PM, Kevin Ballard wrote:
> At first glance it seems reasonable to prohibit moving out of a mutable
> static, but I'm not sure it really makes sense to try and put restrictions on
> mutable statics when we can't make them safe.
>
> -Kevin
>
> On Jan 28, 2014, at 3:26 PM, Niko Matsakis wrote:
>
>> Probably this should yield an error -- I tend to think we should only
>> permit moves that we cannot enforce from `*` pointers, just to add an
>> extra barrier.
>>
>>
>> Niko
>>
>> On Tue, Jan 28, 2014 at 12:12:23PM -0800, Kevin Ballard wrote:
>>> Your code is moving the contents of Option<~MyStruct> into the match arm.
>>> It just so happens that this seems to be zeroing out the original pointer
>>> in memory, and that happens to be the same representation that None does
>>> for the type Option<~MyStruct> (since ~ pointers are non-nullable), so the
>>> act of moving the value just happens to be transforming it into a None.
>>>
>>> Normally you couldn't do this, but mutable statics are weird (which is why
>>> you need the unsafe block to access it).
>>>
>>> When you remove the ~, the lines end up printing the same because MyStruct
>>> is implicitly copyable, so your match arm is now copying instead of moving.
>>>
>>> The correct fix here is to use `Some(ref data)` instead of `Some(data)`.
>>> This will take a reference to the data instead of moving it, and the static
>>> will remain unchanged.
>>>
>>> -Kevin
>>>
>>> On Jan 28, 2014, at 11:48 AM, Alexander Stavonin
>>> wrote:
>>>
Hi all! I'm not sure is it an error or "static mut" variables
misunderstanding from my side. The source:
struct MyStruct {
val: int
}
static mut global_data: Option<~MyStruct> = None;
fn test_call() {
unsafe {
match global_data {
Some(data) => { println!("We have data {:?}", data);}
None => { println!("We don't have data");}
}
}
}
fn main() {
unsafe {
global_data = Some(~MyStruct{val: 42});
}
test_call();
test_call();
}
and output:
We have data ~MyStruct{val: 42}
We don't have data
But if I'm changing global_data from Option<~MyStruct> to Option
output is changed also:
We have data ~MyStruct{val: 42}
We have data ~MyStruct{val: 42}
Is it normal behaviour and owning pointers cannot be stored in global
variables or an error?
___
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] Why focus on single-consumer message passing?
> Shared memory is already far more solid and less experimental than the > existing concurrency and I/O support. > Rust is making a lot of semantic sacrifices for the sake of > performance. I see most of it as being under the assumption that it > will eventually perform well rather than being based on hard numbers. These two comments are examples of inflammatory remarks that Brian mentioned are not welcome. These are both vague and unspecific. As Patrick mentioned, software doesn't become high quality overnight, but rather it takes a lot of time and effort to reach that point. The Rust standard libraries are still fledgling in their existence and have much work do to. Constant negative energy against the development of a library is a terrible way for it to make progress. On Sun, Jan 26, 2014 at 5:13 AM, Daniel Micay wrote: > On Fri, Jan 24, 2014 at 2:37 PM, Brian Anderson wrote: >> Thanks for your well thought-out considerations about Rust's message passing >> strategy. >> >> >> On 01/24/2014 07:32 AM, Daniel Micay wrote: >>> >>> The language documentation currently takes a very opinionated view on >>> concurrency. It focuses on message passing and at times makes the >>> claim that Rust does not have shared memory between tasks. I don't >>> think the language should be taking a position like this but rather >>> providing useful tools to implement a concurrent application as the >>> developer sees fit. >> >> >> Yes, Rust has always promoted message passing as the preferred way to do >> concurrency. Rust also provides useful tools to implement concurrency as the >> developer sees fit. I believe that recommending message passing by default >> is reasonable since it is widely applicable and easy to use. Perhaps we can >> update language in various documentation to not claim absolutely that Rust >> has no shared memory, but it is important to express that Rust protects >> developers from the pitfalls of shared memory. > > I think shared memory is widely applicable and easy to use too. It's > often much harder to use message passing. > >>> The library should be offering the `Arc` and `MutexArc` types in >>> `libstd` along with other useful concurrent data structures. A >>> concurrent hash table split into shards is a very scalable primitive >>> and quite trivial to implement. There's no reason to encode keyed >>> inserts/searches/removals with message passing when it's faster and >>> easier to do it directly. >> >> >> Possibly, yes. Instead of putting everything in std though I would rather >> foster a culture of using small crates. It is easier to accept more >> experimental code into the standard distribution if they are in seperate >> packages that can be developed independently. A concurrency crate would be >> more attractive to me than putting specialized data structures in the >> standard library. > > Why not move message passing to another crate then? It doesn't have to > be in the standard library either. The standard library could provide > only native I/O and threading like C++, with the contentious stuff > moved to other crates and built on top of it. If it proves to be > useful, then the community will use it. > > Shared memory is already far more solid and less experimental than the > existing concurrency and I/O support. > >> I don't know what 'API sacrifices made at the performance altar' means. This >> sort of unspecific, inflammatory criticism is not necessary or welcome. Many >> people (myself included) have put an enormous amount of work into >> discovering how to build abstractions in this new language. It is a long, >> iterative process, there are many tradeoffs, and mistakes are occassionally >> made. Please try to be nice. > > Rust is making a lot of semantic sacrifices for the sake of > performance. I see most of it as being under the assumption that it > will eventually perform well rather than being based on hard numbers. > >> I believe the single-consumer restriction has to do with the complexity of >> implementing 'select' with multiple consumers. Do you have that implemented >> in rust-core? > > I have an implementation for Windows and Linux but haven't pushed it > into rust-core. I haven't set up a FreeBSD install so I don't have a > working implementation with kqueue. It's significantly (20-30%+) > slower in the case where the condition variable is being hit a lot due > to imbalance in consumption/production. It also currently only > supports selection over channels as I don't really see a way to do > cross-platform AIO with acceptable performance. Linux is only going to > be able to select on non-blocking sockets, unless it's all shoved > behind more `eventfd` descriptors hooked up to a thread pool... > ___ > 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] Avoiding partially moved values error when consuming a struct with multiple fields
You'll want to do destructuring assignment here. This means that you
take ownership of all fields in parallel:
fn into_test2(self) -> Test2 {
let Test1 { a, b } = self;
Test2 {
c: a,
d: b as f64
}
}
On Sun, Jan 26, 2014 at 9:32 AM, Vladimir Matveev
wrote:
> Hi all,
>
> Consider this code:
>
> struct Test1 {
> a: ~str,
> b: f32,
> }
>
> struct Test2 {
> c: ~str,
> d: f64
> }
>
> impl Test1 {
> fn into_test2(self) -> Test2 {
> Test2 {
> c: self.a,
> d: self.b as f64
> }
> }
> }
>
>
> In into_test2() method I want to consume Test1 struct completely. But
> because ~str is not implicitly copyable, self.a is moved out of self,
> and on Test2.d field assignment I get the following error:
>
> main.rs:15:16: 15:21 error: use of partially moved value: `self`
> main.rs:15 d: self.b as f64
> ^
> main.rs:14:16: 14:22 note: `self.a` moved here because it has type
> `~str`, which is non-copyable (perhaps you meant to use clone()?)
> main.rs:14 c: self.a,
> ^~
>
> I know that I can, say, do self.a.clone() to avoid moving, but I don't
> want extra allocations. And it is also possible to reorder Test2
> fields assignments and it will work, but it won't if both fields are
> not copyable.
>
> So, the question is: how to correctly correctly move several pieces of
> data out from a struct without using clone()? Is it possible at all?
>
> 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] should fail to compile or not?
Rust has the idea of "implicit copyability", a property of a type
formalized by the Pod trait. An implicitly copyable type is either a
primitive, or a structure/enum which is built from implicitly copyable
types (plus some extra rules in play here).
When you add a destructor (implementation of the Drop trait) to a
type, it is no longer implicitly copyable. With the Drop
implementation commented out, your value 'inner' is implicitly
copyable, so when you create 'outer' it copies the contents (in this
case there are none). When you have Drop, the creation of 'outer'
*moves* the 'inner' value (because it is no longer implicitly
copyable), hence the method call is no longer valid.
Hope that helps!
On Tue, Jan 21, 2014 at 2:18 PM, Igor Karablin wrote:
> Hello,
>
> I'm learning rust and trying to understand why rust allows me to compile
> this piece of code. When Drop impl is uncommented - rustc complains about
> 'use of moved value', which is ok i think. My question is - why it compiles
> code when Drop is not implemented for Inner struct? If its behaves as
> intended - where i can read about this difference?
>
> struct Inner;
> impl Inner {
> fn innerFn(&mut self) {
> println!("Inner::innerFn"); // just for tracing
> }
> }
>
> struct Outer {
> i: Inner
> }
>
> // uncomment it, and we get error: use of moved value: `inner`
> /*
> impl Drop for Inner {
> fn drop(&mut self) {
> println!("Inner::drop"); // just for tracing
> }
> }
> */
>
> fn main() {
> let mut inner = Inner;
> let mut outer = Outer { i: inner }; // inner is moved into outer.i ?
> inner.innerFn();// why then i can call its method?
> outer.i.innerFn();
> }
>
> ___
> 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@mozilla.org
> What's the reason ~T not coerced to &T the same way as in the main()
> function and borrow3 -- ie. why isn't it automatically converted to &**v as
> it is in these cases? The conversion is identical, no? The inability in
> this particular context seems rather arbitrary.
Sadly this is correct. Right now type coercion does not happen in all
places, where the return expression is one of them. Coercion is
allowed in let expressions through type ascription and around method
calls.
The conversion is indeed similar, and we've talked about refining this
sort of behavior in the past. This is partly the topic of
https://github.com/mozilla/rust/issues/10504, but specifically
concerning return type coercion I don't think a bug exists.
It can be argued though that coercion on the return type is a little
different than coercion on a function call, though. You've explicitly
listed the return type as &int, but then you return something of type
~int. This reasoning isn't very strong though, and I think I would
personally like to see coercion *everywhere* as opposed to just a few
locations.
> Wow, thanks...this worked (surprisingly to me).
> fn do_borrow_ary<'a, T>(t : &'a [T]) -> &'a [T] {
> t
> }
> ...
>
> fn borrow3<'a>(&'a self) -> &'a [int] {
> match (self) {
> // WORKS
> &FooVec(ref v) => do_borrow_ary(*v)
> }
> }
>
> This leads to multiple points of confusion for me. It seems that [T] is
> special-cased in a way that prevents it from being used as a regular type.
> In particular,
That is correct. Sadly you cannot instantiate a type parameter T with
something that looks like [U] (but soon you will be able to)!
This is the source of a number of difficulties throughout the stdlib
and language, which is why we definitely intend to fix it!
> 1. How did do_borrow_ary manage to coerce ~[T] to &[T] when the other
> methods (eg. automatic insertion of &*) failed? Is this special-cased by
> the compiler? Is there some way to trigger this coercion without requiring
> an intermediate function like do_borrow_ary (say, if one wants to return a
> static array value type, not a slice)?
This sort of coercion is special-cased in the compiler to allow it to
be possible.
> 2. Why did
>
> fn do_borrow<'a, T>(t : &'a T) -> &'a T
> fail to match types? Isn't [S] a type T and of the same kind? (Any other
> language also exhibit this dichotomy?) This prevents one from being able to
> write a truly generic function -- one must duplicate the code for T and [T]
> variations.
Ah, it appears I answered this above! I would recommend reading
http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/,
the most recent development in DST and it should explain how we intend
to allow this in the future. Soon, hopefully!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
rust-dev@mozilla.org
> fn borrow1<'a>(&'a self) -> &'a int {
> match (self) {
> // error: mismatched types: expected `&'a int` but found `~int`
> // (expected &-ptr but found ~-ptr)
> &Foo(ref v) => *v
> }
> }
This doesn't work because the local variable v has type &~int, when
you dereference this you get something of type ~int which if you load
is a move so you're not allowed to do that. Additionally, the return
type wants &int when you're giving it ~int
> fn borrow2<'a>(&'a self) -> &'a int {
> match (self) {
> // WORKS
> &Foo(ref v) => &**v
> }
> }
This works because you're going from &~int => ~int => int => &int via
the * => * => & ordering
> fn borrow3<'a>(&'a self) -> &'a int {
> match (self) {
> // WORKS
> &Foo(ref v) => do_borrow(*v)
> }
> }
> }
The reason this works and borrow1 doesn't is a little tricky. As I
said above, the intermediate value has type ~int. The function
do_borrow takes something of type &int, so the compiler will coerce
the value of type ~int. The compiler silently does this so you don't
have to. This is equivalent to writing (as in this is what the
compiler automatically injects)
do_borrow(&**v)
> impl FooVec {
> fn borrow1<'a>(&'a self) -> &'a [int] {
> match (self) {
> // error: mismatched types: expected `&'a [int]` but found
> // `~[int]` ([] storage differs: expected &'a but found ~)
> &FooVec(ref v) => *v
> }
> }
This doesn't work due to the same reasons as the above borrow1
>
> fn borrow2<'a>(&'a self) -> &'a [int] {
> match (self) {
> // error: type ~[int] cannot be dereferenced
> &FooVec(ref v) => &**v
> }
> }
There's a subtle reason that this doesn't work. You'll note in the
above borrow2 I mentioned that you transformed ~int => int => &int. If
the same thing were to happen here, it would look like ~[int] => [int]
=> &[int]. This kind of promotion is not allowed yet (namely
dereferencing something of type ~[T]), but it will hopefully be
enabled soon with something called dynamically sized types (DST).
> fn borrow3<'a>(&'a self) -> &'a [int] {
> match (self) {
> // error: mismatched types: expected `&'a [int]` but found
> // `&` (expected vector but found &-ptr)
> &FooVec(ref v) => do_borrow(*v)
> }
> }
> }
This doesn't work because the do_borrow function takes something of
type &int, not ~[int] (which is the type of *v). You'd need to rewrite
the borrow function to take &[int] instead of &int.
Another solution for vectors is to return v.as_slice() which is a
function that will convert all forms of vectors to its slice
representation (&[T])
Hope that helps!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] wrapping a C library (ownership/mutability questions)
> Any way to prevent this, so that only I am allowed to create FieldDef
> structs but can still return references to them in my public API?
You'll want something like:
pub struct FieldDef {
priv field: int,
}
That way everyone can name your struct, but no one other than you can
construct it because it has private fields.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] wrapping a C library (ownership/mutability questions)
>> The problem with this is that it requires that the *owner* of a type
>> have a *mutable slot*, and you cannot prevent owners from declaring
>> their slots as mutable. In the example you gave, you could write "let
>> mut var2 = Box { x: 2 }" and it would compile, there's nothing
>> preventing usage of the "mut" at the owner.
>
> Are you saying (if I may lapse into C++ vocab for a moment) that I can't
> hide the copy constructor? Anyone can copy my non-mut struct into a
> mut struct at any time and I don't have any say in the matter?
I'm not very familiar with what exactly a C++ copy constructor is, but
rust-wise it mostly has to do with ownerships and moves. Let's say you
have one type, Box. This type has &mut and & methods (dictating when
they're call-able). The problem is that &mut is dictated by the
*owner* of the box. So if your clone() method hands out another Box,
then if whomever owns the box decides to declare it as mutable "let
mut box = orig_blox.clone()", then they'll be able to call the '&mut'
methods.
You need to provide some method of forbidding calling &mut methods,
which would probably involve leveraging the type system in one way or
another. One way is to have two types. The other I know of is to have
the shadow type parameters below. You basically need to forbid "&mut
self" from ever being possible. Something like Arc can accomplish this
because the Arc *owns* the data. The arc then decides to never hand
out &mut pointers, only & pointers. This is along the same lines as a
second type for you though, which I think you're right in trying to
avoid.
Using a shadow type parameter is kinda like having the ancient rust
idea of "type state", although I don't know how that worked or how
equivalent it is to shadow type parameters.
>> With something like this you can write code that works over generic
>> boxes (immutable or mutable), but you have a clear separation of what
>> a mutable box can do and what a frozen box can do.
>
> Hmm, this looks promising. Not as nice as mut/non but not as bad as
> two unrelated types. What does the declaration/use of these types
> look like syntactically? Does the user write out Mutable and Frozen?
Using this implementation, it's not super-elegant, but it's perhaps
better than having two types:
let mut x = Box::new();
x.set_x(100);
let x = x.freeze();
let y = x.clone();
do spawn { use(&y) }
use(&x);
The difficult comes up whenever you have to name the type
fn foo(t: Box) {} // only works on frozen boxes
fn bar(t: Box) {} // only works on mutable boxes
fn baz(t: Box) {} // works on any flavor of box
I would probably say that the shadow type parameter route is the
direction that you'd want to go in, but maybe I'm missing something!
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] wrapping a C library (ownership/mutability questions)
> This is the part that I don't follow; why can't I just mark
> my mutable-only methods as taking a mutable self?
The problem with this is that it requires that the *owner* of a type
have a *mutable slot*, and you cannot prevent owners from declaring
their slots as mutable. In the example you gave, you could write "let
mut var2 = Box { x: 2 }" and it would compile, there's nothing
preventing usage of the "mut" at the owner.
One possible solution is to use a thing called "shadow type parameters"
pub enum Mutable {}
pub enum Frozen {}
pub struct Box {
priv x: i32,
}
// methods that only work on a mutable box
impl Box {
fn new() -> Box { Box { x: 2 } }
fn set_x(&mut self, val: i32) -> { self.x = val; }
fn freeze(self) -> Box { Box { x: self.x } }
}
// methods that work on all boxes (mutable and immutable)
impl Box {
fn x(&self) -> i32 { self.x }
}
impl Clone for Box { ... }
impl Drop for Box { ... }
With something like this you can write code that works over generic
boxes (immutable or mutable), but you have a clear separation of what
a mutable box can do and what a frozen box can do.
>> impl Clone for MyImmutableStruct {
>> fn clone(&self) -> MyImmutableStruct {
>> unsafe { my_c_ref_function(self.ptr); }
>> MyImmutableStruct { ptr: self.ptr }
>> }
>> }
>>
>> impl Drop for MyImmutableStruct {
>> fn drop(&mut self) {
>> unsafe { my_c_unref_funtion(self.ptr); }
>> }
>> }
>
> This looks about right. What I was asking is how to furnish
> the second parameter to my ref/unref functions: the "owner".
> In my API all refs have an "owner", which is simply a
> "const void*" that must be distinct from all other ref owners
> for this object. It's a debugging facility that makes it
> easier to track down ref leaks. In C or C++, I usually use
> the address of the variable that is storing the pointer to
> my MessageDef object as the ref owner.
Sadly this doesn't translate to rust. In your example, you're
declaring the owner as a stack pointer, but then that stack pointer is
invalidated as soon as the function returns. You'll probably not want
to implement the trait Clone or you'll want to find some other way to
track owners perhaps.
> However I am wondering if there is any way to actually take
> the address of a Rust variable as I did above (and if it is
> possible, to guarantee that the address is stable over the
> lifetime of the object).
Without making an explicit allocation, you have no guarantee about the
stability of an address because objects can be moved from place to
place.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] wrapping a C library (ownership/mutability questions)
> Hi Rust experts,
How flattering!
> This seems like a great match for Rust, because an object could be
> created as "mut" and local to a single task, but then "become" non-mut
> and be sharable between tasks once frozen. And the refcounting scheme
> sounds like a great match for the Arc model.
I agree! You may want to think about things a little differently
though. Using something like Arc means that the refcounting is managed
in rust, whereas it sounds like you're already dealing with it in your
library. You just want to write *wrapper* types which perform the
relevant calls to C.
What you'll likely end up having is two types. Both types internally
are just an unsafe C pointer (which is initialized in your library)
which allow interfacing with the underlying C object. You'll have a
Mutable version for mutable methods and then an Immutable version for
the methods which don't mutate (where creating the immutable version
consumes the mutable version in rust code).
I've answered some specific questions below, but if you have any more,
feel free to ask! You can reach out to me as acrichto on IRC, and I
always love to read code :)
> 1. Can I write a "freeze" function in Rust where my mut pointers
> "become" non-mut pointers in a way that the mut pointers are no longer
> accessible?
I think Erick answered this well. Rust allows you to specify whether a
function requests a mutable pointer "&mut self", or an immutable
pointer "&self", but there only way to forbid methods is to just have
a type that doesn't have those methods.
> 2. Is my notion of freezing the same as Rust's "Freeze" trait? Is
> there a pattern I should follow to make my type "fit in" with the
> stdlib better?
Not quite. The rust Freeze trait is a "kind" which basically means
that the compiler will infer it based on the structure of a type. This
kind is the notion that an object cannot be mutated through a &self
pointer (for example Cell is *not* Freeze).
Your object does indeed ascribe to Freeze, but you don't need to worry
about dealing with the Freeze trait itself. Your library already deals
with freezing internally, so when you write Rust bindings the best way
to expose this would be to have separate types for the
mutable/immutable methods. As Erick suggested, creating the immutable
would consume the mutable type. Under the hood it would look like:
pub struct MyMutableBuilder {
priv ptr: *my_c_type_t
}
pub struct MyImmutableStruct {
priv ptr: *my_c_type_t
}
> 3. I think I can write a very Arc-like interface to my refcounting.
> Will my individual refcounting wrappers let me take their address so I
> can pass it to the second param of my ref/unref functions?
I'm a little confused by this question because this sounds like you
want to *port* your library to Rust rather than *wrap* your library
with Rust. If you're porting, then I would certainly recommend Arc. If
you're wrapping, then you wouldn't need Arc because you're already
doing that atomic refcounts yourself.
What you'll probably want is something like:
impl Clone for MyImmutableStruct {
fn clone(&self) -> MyImmutableStruct {
unsafe { my_c_ref_function(self.ptr); }
MyImmutableStruct { ptr: self.ptr }
}
}
impl Drop for MyImmutableStruct {
fn drop(&mut self) {
unsafe { my_c_unref_funtion(self.ptr); }
}
}
Basically, when you clone() your object, it bumps the refcount. You
can then send the clone'd object to another thread. When the objects
go out of scope (get destroyed) they'll deref the refcount, allowing
you to safely clean things up.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] general onlookers questions on rust development
> 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? The mailing list we use is pretty standard, and it's archived/searchable on other mirrors (gmane I think mirrors our mailing list) > 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, ..." This is certainly a subjective topic rather than an objective one, and we have long since made this decision. There are many reasons as to why we chose this, along with many other things that then fell out because of this decision. At this point it would be a little difficult to go back to the core reason, but it's not too interesting any more because this is pretty much set in stone at this point. > 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"? You certainly can! You can build dynamic or static rust libraries with functions tagged with `#[no_mangle]` so python can see the symbols. There's at least one (and I think a few more) ruby extension which is using rust to power it. > 4. Why is the BSD implementation almost 3 times faster then the linux and > mac-versions ? > http://huonw.github.io/isrustfastyet/buildbot/ This is just an artifact of BSD running a vastly stripped down version of the test suite (it's running on a very slow AWS bot). The BSD implementation is not actually 3x faster than everything else. > 5. When will we see a Rust version of the Linux kernel? Just joking! ;-) > Keep up the good > work! In all seriousness, there are actually a fairly large and growing number of kernels written in rust! Most of them are "demo quality" in the sense that they're not production kernels, but Rust is turning out to be a good language to write kernels in. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Porting rust to DragonFlyBSD
The snapshots themselves are all "static binaries" in the sense that they have no dynamic rust dependencies and only the "necessary" system dependencies. Rustc does not generate 0-dependency static binaries right now that depend on libstd (as that would involve rewriting libc and writing a syscall interface for all platforms). When porting to a new architecture, the general idea is to add support in the compiler and standard libraries, then use cross compilation from a supported platform to generate a snapshot for the target platform, then take the snapshot and bootstrap on the target platform. A new platform hasn't shown up in awhile, but this sounds pretty cool! On Tue, Jan 7, 2014 at 7:37 AM, Michael Neumann wrote: > Hi there, > > At the moment rust "only" supports Linux/FreeBSD/Windows/MacOSX. I'd like to > be > able to compile it on DragonFlyBSD [1]. > > I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet > with no success. > Is it possible to generate a static rustc binary somehow? Or what in general > is the procedure > to "port" rustc to a different platform? > > Regards, > > Michael > > [1]: http://www.dragonflybsd.org/ > ___ > 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] Using libgreen/libnative
This is currently a bug in rustpkg, and I've opened up
https://github.com/mozilla/rust/issues/11243 about this bug.
On Tue, Dec 31, 2013 at 6:36 AM, Madhu Srinivasan
wrote:
> This is great !!
>
> Quick question - it seems like rustpkg is still unaware of libnative and
> libgreen ?
>
> I am trying to compile the example code from alex (and some other examples)
> with rustpkg with the following error:
>
>> rustpkg build test
>
> WARNING: The Rust package manager is experimental and may be unstable
>
> error: Package test depends on native, but I don't know how to find it
>
> task '' failed at 'explicit failure',
> /private/tmp/rust-yVG2/src/librustpkg/util.rs:528
>
> task '' failed at 'receiving on a closed channel',
> /private/tmp/rust-yVG2/src/libstd/comm/mod.rs:728
>
>
> However, rustc does it just fine ...
>
>
>> rustc -o bin/test src/test/main.rs
>
>>
>
>
> Wondering if there is a pending issue with rustpkg ? I am happy (and prefer)
> to use rustc anyways!
>
> Great work !!
>
> Dr. Madhu Srinivasan
>
>
>> Date: Sat, 28 Dec 2013 17:15:54 -0800
>> From: bander...@mozilla.com
>> To: rust-dev@mozilla.org
>> Subject: Re: [rust-dev] Using libgreen/libnative
>
>>
>> Thanks for writing this up, Alex. The improvements you've made to the
>> runtime recently are very impressive. Now we've got nearly complete and
>> reasonably fast I/O, fast message passing, a scheduler-agnostic standard
>> library, and very soon an embeddable runtime and a standard library that
>> can be used in almost any environment. After years of iteration I'm
>> hopeful that we're finally converging on a good design for the runtime.
>>
>>
>> On 12/28/2013 10:37 AM, Alex Crichton wrote:
>> > Greetings rusticians!
>> >
>> > Recently pull request #10965 landed, so the rust standard library no
>> > longer has
>> > any scheduling baked into it, but rather it's refactored out into two
>> > libraries.
>> > This means that if you want a 1:1 program, you can jettison all M:N
>> > support with
>> > just a few `extern mod` statements. A brief overview of the current
>> > state of
>> > things is:
>> >
>> > 1. All programs not using std::rt directly should still continue to
>> > operate as
>> > usual today
>> > 2. All programs still start up in M:N mode, although this will likely
>> > change
>> > once 1:1 I/O work has been completed
>> > 3. There are two more libraries available, libgreen and libnative, which
>> > allow
>> > custom fine-grained control over how programs run.
>> > 4. Whenever a new task is spawned, it is by default spawned as a
>> > "sibling" which
>> > means that it is spawned in the same mode as the spawning thread. This
>> > means
>> > that if a green thread spawns a thread then it will also be a green
>> > thread,
>> > while a native thread will spawn another OS thread.
>> >
>> > With this migration, there have been a few changes in the public APIs,
>> > and
>> > things still aren't quite where I'd like them to be. PR #11153 is the
>> > last major
>> > step in this process as it allows you to link to both libnative and
>> > libgreen,
>> > yet still choose which one is used to boot your program. Some breaking
>> > changes
>> > you may notice are:
>> >
>> > * it's still not possible to easily start up in 1:1 mode - This is fixed
>> > by
>> > #11153. In the meantime, you can use #[start] with native::start in
>> > order to
>> > boot up in 1:1 mode. Be warned though that the majority of I/O is still
>> > missing from libnative (see PR #11159 for some progress)
>> >
>> > https://gist.github.com/8162357
>> >
>> > * std::rt::{start, run} are gone - These are temporarily moved into
>> > green/native
>> > while #[boot] is getting sorted out. The green/native counterparts
>> > perform as
>> > you would expect.
>> >
>> > https://gist.github.com/8162372
>> >
>> > * std::rt::start_on_main_thread is gone - This function has been removed
>> > with no
>> > direct counterpart. As a consequence of refactoring the green/native
>> > libraries, the "single threaded" spawn mode for a task has been removed
>> > (this
>> > doesn't make sense in 1:1 land). This behavior can be restored by
&g
[rust-dev] Using libgreen/libnative
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod` statements. A brief overview of the current state of
things is:
1. All programs not using std::rt directly should still continue to operate as
usual today
2. All programs still start up in M:N mode, although this will likely change
once 1:1 I/O work has been completed
3. There are two more libraries available, libgreen and libnative, which allow
custom fine-grained control over how programs run.
4. Whenever a new task is spawned, it is by default spawned as a "sibling" which
means that it is spawned in the same mode as the spawning thread. This means
that if a green thread spawns a thread then it will also be a green thread,
while a native thread will spawn another OS thread.
With this migration, there have been a few changes in the public APIs, and
things still aren't quite where I'd like them to be. PR #11153 is the last major
step in this process as it allows you to link to both libnative and libgreen,
yet still choose which one is used to boot your program. Some breaking changes
you may notice are:
* it's still not possible to easily start up in 1:1 mode - This is fixed by
#11153. In the meantime, you can use #[start] with native::start in order to
boot up in 1:1 mode. Be warned though that the majority of I/O is still
missing from libnative (see PR #11159 for some progress)
https://gist.github.com/8162357
* std::rt::{start, run} are gone - These are temporarily moved into green/native
while #[boot] is getting sorted out. The green/native counterparts perform as
you would expect.
https://gist.github.com/8162372
* std::rt::start_on_main_thread is gone - This function has been removed with no
direct counterpart. As a consequence of refactoring the green/native
libraries, the "single threaded" spawn mode for a task has been removed (this
doesn't make sense in 1:1 land). This behavior can be restored by directly
using libnative and libgreen. You can use libgreen to spin up a pool of
schedulers and then use libnative for the main task to do things like GUI
management.
https://gist.github.com/8162399
And of course with the removal of some features comes the addition of new ones!
Some new things you may notice are:
* libstd is no longer burdened with libgreen and libnative! This means that the
compile times for libstd should be a little faster, but most notably those
applications only using libstd will have even less code pulled in than before,
meaning that libstd is that much closer to being used in a "bare metal"
context. It's still aways off, but we're getting closer every day!
* libgreen has a full-fleged SchedPool type. You can see a bit of how it's used
in gist I posted above. This type is meant to represent a dynamic pool of
schedulers. Right now it's not possible to remove a scheduler from the pool
(requires some more thought and possibly libuv modifications), but you can add
new schedulers dynamically to the pool.
This type supercedes the ThreadPool type in libextra at this point, and
management of a SchedPool should provide any fine-grained control needed over
the 'M' number in an M:N runtime.
* libgreen and libnative can be used directly to guarantee spawning a green or a
native task, regardless of the flavor of task that is doing the spawning.
In the coming months, I plan on filling out more native I/O to bring it up to
speed with the M:N implementation. I also plan on rewriting the core components
of extra::comm to be performant in both scheduling modes in order to bring the
extra::{comm, arc, sync} primitives up to date with their std::comm
counterparts.
If there are any questions about any of this, feel free to ask me! This thread
is always available, and I'm also reachable as acrichto on IRC or alexcrichton
on github.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Iterator naming convention
In the past we have explicitly attempted to drop as many suffixes as
possible (see #8090). This is a little bit of a tricky topic, and to
me it depends on how you name the iterator. To me, iter::Map and
container::Map are clearly different if they are named that way. If
they are imported and then named via Map, then I can see how there
would be some confusion. I have a preference to naming things through
a module instead of importing giant numbers of capital-letter things
at the top of a file.
We already have an open issue about reorganizing libstd (#9208) with a
major goal of reducing stuttering all over the place (which adding
Iterator suffixes would add in a few places).
Mostly just food for thought.
On Fri, Dec 20, 2013 at 8:51 PM, Palmer Cox wrote:
> I noticed recently that there seem to be 3 distinct Iterator naming
> conventions currently in use:
>
> 1. Use the "Iterator" suffix. Examples of this are SplitIterator and
> DoubleEndedIterator.
> 2. Use the "Iter" suffix. Examples of this are ChunkIter and ComponentIter.
> 3. Use no particular suffix. Examples of this are Invert and Union.
>
> Iterators are somewhat special objects, so, it makes sense to me that they
> have a suffix in common to denote their common behavior. It seems non-ideal,
> however, that there appear to be 3 separate conventions in use since that is
> just confusing. Personally, I think I prefer #1 because its far and away the
> most common and and because I think #2 and #3 have issues:
>
> #2 ("Iter" suffix): If we used this suffix, would we rename
> DoubleEndedIterator to DoubleEndedIter? That looks awkward since we
> abbreviated Iterator without abbreviating anything else. However,
> DblEndedIter is a monstrosity. So, this convention seems non-ideal to me.
>
> #3 (no suffix): I think its pretty confusing while reading through code that
> there are both iter::Map and container::Map since they are completely
> unrelated. I'm also not a big fan of Union since I think as a union as a
> collection of information that I can iterate multiple times. However, since
> Union is itself an Iterator, I can only iterate it once. This means I would
> have to be careful passing a Union around to make sure I don't pass around
> an already iterated Union object.
>
> So, I opened up https://github.com/mozilla/rust/pull/11001 to standardize on
> #1 - all Iterators have an Iterator suffix.
>
> Thoughts?
>
> -Palmer Cox
>
>
> ___
> 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] Some questions about dead-code elimination pass
> 1. Is doing part (b) necessary? That is, does LLVM's optimization > already eliminate unused code? I don't believe that it is from a final binary point of view. Unreachable functions will be flagged as internal, and LLVM can do whatever it wants with internal symbols. I would imagine that it would discard these symbols and functions. That being said, we still go through all the time of generating code for the unused functions, and LLVM probably optimizes them at least a little bit. This is such a small percentage of code, however, that I wouldn't worry about doing this step. > 2. My code marks `RuntimeGlue` struct in libstd/task/spawn.rs as dead. > This is because the struct is private and never used directly. > Instead, it contains static methods that are used, so it's not > desirable to warn it. Currently, when my code sees, e.g., > `RuntimeGlue::kill_task`, it would mark the `kill_task` method > definition as live. What I would like to do in addition is mark the > `RuntimeGlue` struct definition as live, but I'm unable to find a way > to look up a struct given its method. How do I do that? I personally do not know of a method to do this in the compiler right now (although one may surely exist), but if it doesn't this would probably be a table calculated as part of the resolve pass. > 3. My code also marks the function `load_argc_and_argv` in > libstd/os.rs as dead when in fact it isn't. I would guess it's because > that function is only used when compiling the rustc source code on > Mac, whereas I'm compiling it on Linux. How do I modify my code to > take account of that? The function should probably be #[cfg(target_os = "linux")] > 4. I'm unable to finish compiling rustc because my addition spots a > number of dead codes in rustc source code. Assuming they are not false > positive, I then have three options: (i) remove the dead code, (ii) > comment it out, or (iii) put an `#[allow(dead_code)];` at the top of > the module. As I'm unfamiliar with the codebase, it's hard to decide > what to do in each case (I'm thankful to dbaupp for much help in this > area). When in doubt, which would be best to do? I would recommend removing whatever possible, but allow(dead_code) is indicative of a bug in the analysis pass or a change which needs to be present in the code. I would not recommend commenting out code (that's what a git history is for). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing some autoref magic
Additionally, we discussed this today at our weekly meeting, and the minutes can be found here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Removing some autoref magic
Hello rust-dev!
Everyone's had their fair share of issues with autoref and autoderef,
and it's worth considering removing certain portions of it from the
compiler. The discussion around this has been rooted in the past, but
has recently been brought up as part of
https://github.com/mozilla/rust/issues/10504.
The current proposal is to remove all autoref except for function
invocations and indexing operations. The method of creating &T from ~T
would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't
currently benefit from the `&*foo` syntax, but they will hopefully be
able to do such once DST lands. In the meantime coercion via type
ascription will work and they also have `as_slice` methods.
There are a few reasons backing this proposal:
1. It's inconsistent to have magical autoref in some places, but not
in other places.
2. The camp of "less compiler magic is better" can fly their flag over
this change.
3. Code readability does not necessarily benefit from autoref on arguments:
let a = ~Foo;
foo(a); // reading this code looks like it moves `a`
fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!
let mut a = ~[ ... ];
sort(a); // not only does this not move `a`, but it mutates it!
The basic idea is that reasoning about code is no longer a local
function decision, but rather you must understand all the pointer-ness
of the called signatures to understand when a move happens or not.
With no autoref, the code would look like
let a = ~Foo;
foo(&*a); // clearly not passing by value
let mut a = ~[ ... ];
sort(a.as_mut_slice()); // clearly loaning a mutable reference
That being said, this proposal is not yet set in stone. I don't think
that there are many people that are fans of `&*foo` or `&mut *foo`;
both cases look fairly ugly. So far the general agreement is that
local small ugliness is the price we pay for local readability, and
the discussions have been unable to unearth a better system.
I'm curious if others have a better idea of how to go about doing
this, or if others just think it's a terrible idea in the first place.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
>> * #[link(...)] becomes the new method of specifying linkage semantics on >> extern >> blocks, and it may be used similarly to link_args today > > I'd kind of like for this to be available at the crate level too since most > libraries don't use OS X two-level namespaces and it's more convient to me to > just put all the linkage at the top of the crate. Of course this conflicts > with the `link` attribute of crates, which I think is poorly named anyway. What purpose did you have in mind for the #[link] attribute at the top of the crate? Is the crate saying how it should be linked to other crates? > I don't really understand what 'once' implies in `link(once)` and how it > relates to statics. If a static library *must* be linked, then dynamic > libraries may not be linked? Why is that? If 'once' implies 'static', can we > just say 'link(static)'? I assume some argument propagation is going to come > into play here ... > > Will also need to accomodate some other common features like, e.g. > `link(framework = "foo")` or something for OS X frameworks. What this ended up turning out as is #[link(name = “foo”, kind = “static”)]. I think that a “framework” kind would fit quite well for this use case. > .rlib files also need the crate metadata. I agree > What happens when two upstream crates link to the same native static library? > In the final link step they are both going to be linked in, and I presume > there's some kind of conflict? Right now they’re both linked in. I didn’t envision this as a use case for rustc to complain about, but it would be simple enough to iterate over all upstream crates and see if the same static library were linked twice. My implementation requires metadata about the linkage regardless. > How does one opt into linking to dynamic libraries? Without some further > mechanism everybody will be linking to the static libstd. I’ve reserved another -Z flag for ‘-Z prefer-dynamic' > I took this to mean that we would just be packaging up the static libraries > to save them for the final link step (since the rlib is just a .o file, not > pre-linked to it's static lib dependencies). The effect of this though may be > that all downstream crates implicitly have access to all the static library's > symbols. This actually what currently happens. The resulting rlib file already contains all of the static native libraries bundled inside of it. This is achieved via ld’s -r option. It is true that all of the symbols leak through, however, and this is unfortunate. I’d like to explore methods of preventing this, but I only know of one way currently. We’d create a list of all symbols in the rust library (an actual file on the filesystem), and then pass that to the linker saying “here are all the exported symbols, discard everything else.” ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does string formatting in Rust have to be different from other languages?
Rust’s old fmt! syntax also used % instead of {}. The reason for the switch was
to primarily support compatibility with an internationalization-style scheme of
string formatting. The main benefit of {} of % is that you can nest {} inside
of another format, whereas with % you’re limited to just one format. That being
said, this effort has not gone underway just yet.
As Daniel also pointed out, the syntax was drawn from other languages instead
of inventing one fresh, so it should be familiar to at least some programmers.
If you’re curious about how the format syntax works, there’s documentation
which can be found at http://static.rust-lang.org/doc/master/std/fmt/index.html.
Hope that clears up any confusion!
On Nov 17, 2013, at 11:02 PM, Derek Chiang wrote:
> Hi all,
>
> I'm a newcomer to Rust. One of the things that I find confusing is the use
> of {} in formatted strings. In all other languages I've ever used, it's
> always %. So instead of writing "%d", you write "{:d}" in Rust. Why is this
> so? What benefits do we get?
>
> Thanks,
> Derek
> ___
> 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] Rethinking Linking in Rust
You would be required to specify that the native library would be static via
#[link(name = "foo", static)]
extern { ... }
And then rustc would bundle libfoo.a with libmycomp.a. libmycomp.a
would also include any upstream rust dependencies (libstd.a,
libextra.a, etc.)
On Fri, Nov 15, 2013 at 12:00 PM, Vadim wrote:
> So in the case of --staticlib, if my Rust library, libmycomp.a, depended on
> non-Rust local native library, libfoo.a, would Rust then bundle all modules
> from libfoo into libmycomp? Or would it only do so for Rust libraries,
> e.g. libstd.a?
>
>
> On Fri, Nov 15, 2013 at 12:09 AM, Alex Crichton wrote:
>>
>> I've been thinking about static linking recently, along with a little bit
>> of
>> linking in general, and I wanted to see what others thought.
>>
>> # The Goal
>>
>> Primarily, I believe that if desired, rustc should be able to generate an
>> executable or dynamic library with no dependence on any rust libraries.
>> This
>> includes things like librustrt and libextra. Rust shouldn't be striving to
>> lift
>> dependence on system libraries, that'll come at later times if need be.
>>
>> Additionally, rustc should be able to generate libfoo.a where libfoo.a has
>> no
>> dependence on any rust libraries. This library can then be statically
>> linked to
>> another application.
>>
>> # Intermediate static libraries
>>
>> I personally know of no way to create a static library from a dynamic one,
>> so to
>> achieve this we would need to distribute libstd and libextra in some form
>> that
>> is not a shared library. This problem not only applies to libstd, but also
>> to
>> any rust library which wants to be statically linked.
>>
>> The first natural conclusion for for an intermediate format would be a .a
>> file
>> itself. Why not distribute libstd.a along with libstd.so. After all, a .a
>> is
>> only an archive which in our case would contain one .o file. In thinking
>> about
>> this though, I don't think that this is the best format. The main idea of
>> providing intermediate .a files is to allow linkage to them via the normal
>> system linker. To be usable, this would mean that all .a files rust
>> generates
>> would have to have their own statically linked version of libstd or
>> otherwise
>> everyone will have to find where libstd is guess the name and hash
>> attached to
>> it. This is infeasible for arbitrary libraries which could have
>> arbitrarily many
>> dependencies.
>>
>> # Native Libraries
>>
>> One part of linking which rust cannot forget is native libraries. Right
>> now,
>> native libraries are always linked against when compiling a local crate,
>> but no
>> native library dependencies are propagated among crates.
>>
>> Due to the nature of a static library and what I assume is the file format
>> itself, a static rust library cannot link to its dependent dynamic
>> libraries. We
>> can, however, resolve all native static dependencies at compile time.
>>
>> # A Scheme for Linking
>>
>> With the above knowledge, I would propose the following linkage model for
>> rust.
>>
>> There are four types of files that the rust compiler will generate:
>>
>> 1. An executable
>> 2. A dynamic library (.so, .dylib, .dll)
>> 3. A "rust" static library (.rlib)
>> 4. A regular static library (.a, .lib)
>>
>> The "rust language" would ship with dynamic library files as well as .rlib
>> files. There would be no .a files in the distribution.
>>
>> A rust static library would be a format defined by rust that is not
>> available
>> for or intended for external use. It is meant to be beneficial to the rust
>> compiler and that's it. It just so happens that their first incarnation
>> would be
>> created similarly to `cp foo.o foo.rlib`.
>>
>> In addition to these changes, the linkage attributes would change to be as
>> follows:
>>
>> * #[link_args] becomes gated behind a feature flag. I believe that this is
>> still
>> a very useful ability to pass arbitrary flags to the linker, but this is
>> *not*
>> a sanctioned way of doing so at all because of how platform specific it
>> is
>>
>> * #[link(...)] becomes the new method of specifying linkage semantics on
>> extern
>> blocks, and it may be used similarly to link_args today
>>
>> * #[link(name = "foo")] specifies that this crate links to native
>> library
>> `foo
Re: [rust-dev] Rethinking Linking in Rust
>> To this end, I mainly >> point out that rust should roll in local native static libraries, and >> just live with global native dynamic libraries. > > How does rustc know the difference? Because the "local native" libraries > are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?) You're correct, this is the reason that I added the #[link(once)]. I don't want rustc to start guessing about LD_LIBRARY_PATH and weird business like that, so I'd rather that the author just be explicitly about the native library. I also agree that #[link(static)] is clearer. > Is this just a matter of changing what is hashed when we construct the > symbol name (or dropping the symbol hashes entirely)? That doesn't > seem very far. Are there are a lot of other things standing in the > way that immediately come to mind? Can we try and document what those > issues are? This is correct. This is tangentially related to https://github.com/mozilla/rust/issues/10207 along with https://github.com/mozilla/rust/issues/10208. I have many thoughts on this, although they don't quite relate to static linking, so I'll try to write them up later. The main idea is that the SVH from 10207 is in all symbol names, and the SVH is a hash of "all reachable things" which includes many things you may not initially consider (many of which you pointed out). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
>> Hm, I suppose I should re-phrase. Rust's linkage model should not >> attempt to lift dependence on global native libraries. These global >> libraries (like libm and librt on linux) should be assumed to be >> everywhere. Our result artifacts must always be linked against them >> (if their functionality is used). On the other hand, any build >> artifacts that are a result of a local build process should not be >> considered downstream dependencies as well. To this end, I mainly >> point out that rust should roll in local native static libraries, and >> just live with global native dynamic libraries. > > This can't be assumed if we want to support freestanding use. Removing > the need for rust-core means support for environments without features > like floating point and amenities provided by a kernel to user-land > processes. Perhaps I'm misunderstanding what you mean here. In saying this is what I think that rust should do, I should also mention that I know of no other method of doing this. If rustc creates a static library, then it may have no dynamic dependencies encoded anywhere. Global dependencies are not a problem which can be solved by static linking or not, they are a problem of the standard library itself. Here's a little example. On linux, the libm library is a global system dynamic library (if I'm wrong, just assume it is). Rust's stdlib has a requirement on this library, acos. This is defined on floating point values (the acos) function, and this will eventually call the corresponding libm function. In this scenario, it is impossible to distribute a libstd which does *not* have a dependence on libm if you use the acos function (or at least it's impossible within the limits of my knowledge). Now that being said, all is not lost. First off, if we have a static libstd.rlib, then I believe that this would "just work". In my scheme, let's say you want to create a static library with no dependence on any global dynamic libraries. This means that you will statically link to libstd.rlib, creating libfoo.a. In doing so, the compiler will warn you about the dynamic library dependencies of libstd, in this case that includes libm. The compiler will *not* bring in any of them as dependencies (because it can't). When you link libfoo.a into your application, you will get an undefined reference error if you used the acos function, or you will get no error at all if you did not use the acos function. If you receive an error, you learn that the dynamic dependencies which were not linked are probably needed for those symbols. All in all, a major goal of this redesign is to support freestanding usage of rust. Rust's linkage model should not prevent you from using rust in virtually any location. This redesign is not a "silver bullet" in making freestanding rust work, there is more changes which need to happen elsewhere. Rust currently has a number of dynamic library dependencies on various platforms, and we need to figure out how to drop them in some situations. For example, perhaps the introduction of the libm dependency should only be done if you compile the num::f64 module, and perhaps this module shouldn't be compiled in the --cfg freestanding version of libstd. Does that make sense? I want to make sure that *linkage* does not block freestanding rust. If all of this were implemented tonight, I don't believe that rust would be "completely ready" for freestanding use, but it would be a whole lot closer. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
>> Primarily, I believe that if desired, rustc should be able to generate an >> executable or dynamic library with no dependence on any rust libraries. This >> includes things like librustrt and libextra. Rust shouldn't be striving to >> lift >> dependence on system libraries, that'll come at later times if need be. > > It seems like you *are* striving to lift dependencies on non-rust > libraries, though. For example, you mention having libuv be statically > imported into a .rlib file etc. Or did I misunderstand? Hm, I suppose I should re-phrase. Rust's linkage model should not attempt to lift dependence on global native libraries. These global libraries (like libm and librt on linux) should be assumed to be everywhere. Our result artifacts must always be linked against them (if their functionality is used). On the other hand, any build artifacts that are a result of a local build process should not be considered downstream dependencies as well. To this end, I mainly point out that rust should roll in local native static libraries, and just live with global native dynamic libraries. > Does this imply that all Rust programs will be executed with whatever > specific version of libsundown and libuv was produced as part of the > Rust compiler build process? (I'm not implying this is a bad thing, > necessarily, just trying to understand) Correct. We as distributors of the rust compile could choose to make libsundown a dynamic library which is then distributed and upgradeable. We may also choose to link it statically to show that it cannot be in-place upgraded. >> I would propose that the compiler automatically favors static >> linkage over dynamic linkage due to various rust ABI issues. > > Could you elaborate? What issues are you thinking of? I should rephrase. I'm not an ABI expert, and my concerns actually aren't really that related to ABI (although I know that many others do have concerns about this). My primary concern is the current fragility of a symbol in rust. If I add a doc-comment in libstd, I will likely change many symbols in the output dynamic library. This is another problem entirely, but it has repercussions for this right now. In favoring dynamic libraries, rust is stating that it is available for an in-place upgrade. The rust compiler is currently sufficiently far from this goal that I do not believe that we should be favoring dynamic linking. By favoring static linking instead, we are lifting ourselves from this burden. When we upgrade the rust compiler a year from now (2.0, woo!), all previous rust executables will continue to run just fine (assuming they weren't linked dynamically). Additionally, any application which has a linked version of rust will continue to work. Does that make sense? This is a fairly major decision, and I want to make sure that everyone's on board with it. > Unless I'm missing something, it seems like what we would want to do > is to have the .rlib file contain LLVM IR, at least for the Rust code > that was compiled / statically linked against. If we can, I think we > should just make LTO happen by default whenver you statically link, > rather than having it be a separate option Interesting idea! Sounds like this definitely along the right lines, and so long as we don't advertise our .rlib format it sounds like we can silently do this at any time in the future. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rethinking Linking in Rust
I've been thinking about static linking recently, along with a little bit of linking in general, and I wanted to see what others thought. # The Goal Primarily, I believe that if desired, rustc should be able to generate an executable or dynamic library with no dependence on any rust libraries. This includes things like librustrt and libextra. Rust shouldn't be striving to lift dependence on system libraries, that'll come at later times if need be. Additionally, rustc should be able to generate libfoo.a where libfoo.a has no dependence on any rust libraries. This library can then be statically linked to another application. # Intermediate static libraries I personally know of no way to create a static library from a dynamic one, so to achieve this we would need to distribute libstd and libextra in some form that is not a shared library. This problem not only applies to libstd, but also to any rust library which wants to be statically linked. The first natural conclusion for for an intermediate format would be a .a file itself. Why not distribute libstd.a along with libstd.so. After all, a .a is only an archive which in our case would contain one .o file. In thinking about this though, I don't think that this is the best format. The main idea of providing intermediate .a files is to allow linkage to them via the normal system linker. To be usable, this would mean that all .a files rust generates would have to have their own statically linked version of libstd or otherwise everyone will have to find where libstd is guess the name and hash attached to it. This is infeasible for arbitrary libraries which could have arbitrarily many dependencies. # Native Libraries One part of linking which rust cannot forget is native libraries. Right now, native libraries are always linked against when compiling a local crate, but no native library dependencies are propagated among crates. Due to the nature of a static library and what I assume is the file format itself, a static rust library cannot link to its dependent dynamic libraries. We can, however, resolve all native static dependencies at compile time. # A Scheme for Linking With the above knowledge, I would propose the following linkage model for rust. There are four types of files that the rust compiler will generate: 1. An executable 2. A dynamic library (.so, .dylib, .dll) 3. A "rust" static library (.rlib) 4. A regular static library (.a, .lib) The "rust language" would ship with dynamic library files as well as .rlib files. There would be no .a files in the distribution. A rust static library would be a format defined by rust that is not available for or intended for external use. It is meant to be beneficial to the rust compiler and that's it. It just so happens that their first incarnation would be created similarly to `cp foo.o foo.rlib`. In addition to these changes, the linkage attributes would change to be as follows: * #[link_args] becomes gated behind a feature flag. I believe that this is still a very useful ability to pass arbitrary flags to the linker, but this is *not* a sanctioned way of doing so at all because of how platform specific it is * #[link(...)] becomes the new method of specifying linkage semantics on extern blocks, and it may be used similarly to link_args today * #[link(name = "foo")] specifies that this crate links to native library `foo` * #[link(once)] implies that the native library is a static library, hence it *must* be linked against in the current compilation, regardless of the output format Omission of `link(once)` assumes that the library is available at all destinations, and it may not be linked against in the current compilation unit. ## The Linkage Step To see how this affects how artifacts are created, I'd like to go into detail about how each of the four output artifacts all interact with one another by describing the linkage phase of each output. For each of these, remember that the compiler's output is one .o file for each crate. Also remember that all rust libraries will always link to all upstream rust libraries. ### Linking Executables and Dynamic Libraries These two cases are very similar because they are creating the actual "result artifact" in terms of a file which will have no more linkage performed on it. The following components must be linked in to produce the artifact: * The local .o file * All local native dependencies * All upstream rust libraries (dynamic and static) * All non-once (dynamic) native libraries of upstream static crates. More on this later The result artifact needs to be a fully resolved destination artifact. The point of this is to have a dynamic dependency on all upstream dynamic libraries, and all upstream static libraries will have been sucked in to create the target. ### Creating rust static libraries (.rlib files) As mentioned above, these files are similar to the compiler's .o output. The only other component which can be consi
