Re: [rust-dev] First impressions of Rust

2014-10-10 Thread Alex Crichton
 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 RcT 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

2014-10-09 Thread Alex Crichton
 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: Boxint = box 45i;
 let b: Rcint = 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

2014-10-08 Thread Alex Crichton
 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: Boxint = box 45i;
let b: Rcint = box(RC) 54i;

And furthermore, you can extend it even further:

   let c: Boxint = box(HEAP) 1i;
   let d: MyPointerint = 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

2014-07-31 Thread Alex Crichton
 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

2014-07-30 Thread Alex Crichton
 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

2014-07-30 Thread Alex Crichton
 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


[rust-dev] Migrating libs out of rust-lang/rust

2014-07-29 Thread Alex Crichton
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] Migrating libs out of rust-lang/rust

2014-07-29 Thread Alex Crichton
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 thadgui...@gmail.com 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


Re: [rust-dev] How to get the file descriptors of standard I/O types?

2014-07-14 Thread Alex Crichton
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 nat.pr...@gmail.com 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] Seemingly Poor Scalability of M:N Scheduler

2014-07-11 Thread Alex Crichton
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 chandru...@gmail.com 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] Impending change in RPATH behavior when linking to Rust dynamic libraries

2014-07-11 Thread Alex Crichton
 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] Impending change in RPATH behavior when linking to Rust dynamic libraries

2014-07-09 Thread Alex Crichton
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
errordevelo...@gmail.com 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 bander...@mozilla.com 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] Issue running documented functions from doc code w/ rustdoc

2014-07-09 Thread Alex Crichton
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 olson.jeff...@gmail.com 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 
 anon:5:5: 5:15 error: unresolved name `under_test`.
 anon:5 under_test();
  ^~
 error: aborting due to previous error
 task 'foo::under_test_0' failed at 'BoxAny',
 /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] Stack usage of green tasks

2014-07-09 Thread Alex Crichton
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 chandru...@gmail.com 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 'unknown' 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] Met with a terrible fate

2014-07-03 Thread Alex Crichton
 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] ref binding for parameters of functions?

2014-07-02 Thread Alex Crichton
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
s.gesem...@gmail.com 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: Vecint) {...}

 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] Rust 0.11.0 Released

2014-07-02 Thread Alex Crichton
 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 aa...@aaronraimist.com
Aaron Turon atu...@mozilla.com
Adolfo Ochagavía aochagavi...@gmail.com
Adrien Tétar adri-from...@hotmail.fr
Ahmed Charles ahmedchar...@gmail.com
Alan Andrade alan.andra...@gmail.com
Alan Williams mral...@gmail.com
Alex Crichton a...@alexcrichton.com
Alexandre Gagnon alxg...@gmail.com
Alexei Sholik alcosho...@gmail.com
Ali Smesseim smesseim@gmail.com
Andrew Gallant jams...@gmail.com
Anton Löfgren anton.lofg...@gmail.com
Arcterus arcte...@mail.com
Ariel Ben-Yehuda arie...@mail.tau.ac.il
Axel Viala axel.vi...@darnuria.eu
Ben Noordhuis i...@bnoordhuis.nl
Benjamin Adamson adamson.benja...@gmail.com
Benjamin Herr b...@0x539.de
Björn Steinbrink bstei...@gmail.com
Boris Egorov jight...@gmail.com
Brandon Waskiewicz brandon.waskiew...@gmail.com
Brendan McLoughlin btmclough...@gmail.com
Brendan Zabarauskas bjz...@yahoo.com.au
Brian Anderson bander...@mozilla.com
Cameron Zwarich zwar...@mozilla.com
Chris Morgan m...@chrismorgan.info
Chris Shea cms...@gmail.com
Christoph Burgdorf christoph.burgd...@bvsn.org
Christopher Bergqvist spamb...@digitalpoetry.se
Christopher Kendell ckend...@outlook.com
Clark Gaebel cg.wowus...@gmail.com
Conrad Kleinespel conr...@conradk.com
Corey Richardson co...@octayn.net
Daniel Brooks db...@db48x.net
Daniel Fagnan dnfag...@gmail.com
Daniel Micay danielmi...@gmail.com
David Creswick dcr...@gyrae.net
Derek Chiang (Enchi Jiang) derekchian...@gmail.com
Dirk Leifeld leif...@posteo.de
Dmitry Promsky dmi...@willworkforcookies.com
Douglas Young rcxd...@gmail.com
Dylan Braithwaite m...@dylanb.me
Eduard Bopp eduard.b...@aepsil0n.de
Eduard Burtescu edy.b...@gmail.com
Edward Wang edward.yu.w...@gmail.com
Emanuel Rylke ema-...@web.de
Erick Tryzelaar erick.tryzel...@gmail.com
Falco Hirschenberger falco.hirschenber...@gmail.com
Falco Hirschenberger hirsc...@itwm.fhg.de
Felix S. Klock II pnkfe...@pnkfx.org
Flavio Percoco flape...@gmail.com
Florian Gilcher florian.gilc...@asquera.de
Florian Hartwig florian.j.hart...@gmail.com
Florian Zeitz flo...@babelmonkeys.de
Gary M. Josack g...@byoteki.com
Guillaume Pinot texi...@texitoi.eu
Gábor Lehel glaebho...@gmail.com
Hanno Braun m...@hannobraun.de
Heather cyn...@gentoo.org
Herman J. Radtke III hermanrad...@gmail.com
HeroesGrave heroesgr...@gmail.com
Huon Wilson dbau.pp+git...@gmail.com
Ivan Petkov ivanppet...@gmail.com
J.C. Moyer jmoyer1...@gmail.com
Jacob Hegna jacobhe...@gmail.com
Jakub Wieczorek ja...@jakub.cc
James Laverack ja...@jameslaverack.com
James Miller ja...@aatch.net
James Sanders sande...@gmail.com
Jeong YunWon je...@youknowone.org
Jihyeok Seo m...@limeburst.net
Jim Radford radf...@blackbean.org
John Clements cleme...@racket-lang.org
John Fresco john.fre...@utah.edu
John Schmidt john.schmid...@gmail.com
John Simon j...@johnsoft.com
Jonathan Bailey jbailey@jbailey-20809.local
Jonathan Bailey jbai...@mozilla.com
Jonathan Reem jonathan.r...@gmail.com
Jonathan S geree...@gmail.com
Jordi Boggiano j.boggi...@seld.be
Jorge Aparicio japa...@linux.com
Joseph Crail jbcr...@gmail.com
JustAPerson jprie...@ymail.com
Justin Noah justinn...@gmail.com
Jyun-Yan You jyyou...@gmail.com
Kang Seonghoon public+...@mearie.org
Kasey Carrothers kaseyc@gmail.com
Keegan McAllister kmcallis...@mozilla.com
Keegan McAllister mcallister.kee...@gmail.com
Kevin Ballard ke...@sb.org
Kevin Butler haq...@gmail.com
Kevin Cantu m...@kevincantu.org
Kiet Tran ktt...@gmail.com
Liigo Zhuang com.li...@gmail.com
Luqman Aden la...@csclub.uwaterloo.ca
Luqman Aden m...@luqman.ca
Manish Goregaokar manishsm...@gmail.com
Marvin Löbel loebel.mar...@gmail.com
Matt Brubeck mbrub...@limpet.net
Meyer S. Jacobs meyerma...@gmail.com
Michael Dagitses dagit...@google.com
Michael Darakananda pon...@gmail.com
Michael Fairley michaelfair...@gmail.com
Michael Pratt mich...@pratt.im
Michael Reinhard mcreinh...@users.noreply.github.com
Michael Woerister michaelwoerister@posteo
Michael Zhou m...@google.com
Mihnea Dobrescu-Balaur mih...@linux.com
Mike Boutin mike.bou...@gmail.com
Ms2ger ms2...@gmail.com
Nathan Typanski ntypan...@gmail.com
Nick Cameron ncame...@mozilla.com
Nicolas Silva nical.si...@gmail.com
Nikita Pekin cont...@nikitapek.in
Niklas Koep niklas.k...@gmail.com
Niko Matsakis n...@alum.mit.edu
Noam Yorav-Raphael noamr...@gmail.com
OGINO Masanori masanori.og...@gmail.com
P1start rewi-git...@whanau.org
Patrick Walton pcwal...@mimiga.net
Paul Stansifer paul.stansi...@gmail.com
Pawel Olzacki p.olzac...@samsung.com
Phil Ruffwind r...@rufflewind.com
Piotr Czarnecki piocz...@gmail.com
Piotr Jawniak sawye

Re: [rust-dev] Met with a terrible fate

2014-07-02 Thread Alex Crichton
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 cont...@bitpuffin.com 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] 0.11.0 prerelease testing

2014-06-28 Thread Alex Crichton
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

2014-06-16 Thread Alex Crichton
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 valerii.hi...@gmail.com 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?

2014-06-04 Thread Alex Crichton
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 hallimanearav...@gmail.com 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

2014-05-31 Thread Alex Crichton
 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?

2014-05-26 Thread Alex Crichton
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 cont...@urbanhafner.com 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] chaining #[start] methods

2014-05-15 Thread Alex Crichton
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 jayh...@cs.ucsc.edu 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] Any way to wake up rust task?

2014-05-15 Thread Alex Crichton
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 p...@colomiets.name 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] Any way to wake up rust task?

2014-05-15 Thread Alex Crichton
 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] how to capture de-reference to ~int

2014-05-13 Thread Alex Crichton
The ~int type has since moved to Boxint, 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: Boxint = 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 jayh...@cs.ucsc.edu 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 DerefResult {
 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] PipeStream.by_ref() - Multiple applicable methods problem

2014-04-30 Thread Alex Crichton
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 mneum...@ntecs.de 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: RefReaderPipeStream = 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] Symbol visibility problem

2014-04-30 Thread Alex Crichton
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 farcal...@gmail.com 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] Symbol visibility problem

2014-04-30 Thread Alex Crichton
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 farcal...@gmail.com 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 farcal...@gmail.com
 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 a...@crichton.co 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 farcal...@gmail.com
 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
 




 --
 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] PipeStream.by_ref() - Multiple applicable methods problem

2014-04-29 Thread 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!)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Make use of the LLVM ExecutionEngine

2014-04-28 Thread Alex Crichton
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 hasteb...@gmail.com 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

2014-04-22 Thread Alex Crichton
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 farcal...@gmail.com wrote:
 The problem is that mrc is generated unless target is thumb1, but cortex-m3
 is thumb2 that still doesn't support mrc:
 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka398.html,
 so an additional check to ST-TargetTriple.Data is required to verify it's
 not thumbv7m.

 Do I need to submit patch against https://github.com/rust-lang/llvm or send
 it to upstream?


 On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov farcal...@gmail.com
 wrote:

 Hm, it seems to have precautions to stop mrc from materializing on Thumb1.
 I guess I need to take a better look into what's going wrong on my side.
 I'll see what I can do with that.


 On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton a...@crichton.co wrote:

 The split stack patches for ARM were recently upstreamed, and they
 were modified when being upstreamed as well. Primarily the location of
 the split stack is no longer at a magic address for thumb, but rather
 it uses the same instruction as ARM (some thumb processors do indeed
 have the coprocessor). More information is in the long thread starting
 at the initial attempt to upstream [1].

 For now you'll have to use no_split_stack because the thumb split
 stack will always use a coprocessor, but I'm sure that the upstream
 LLVM devs would be quite welcoming to tweaks to the slit-stack support
 (I'd also be willing to help). You can find the initial commit for
 support at rust-lang/llvm [2].

 [1] -
 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html
 [2] - https://github.com/rust-lang/llvm/pull/4

 On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com
 wrote:
  Starting recently (no more than two weeks), rustc is generating a
  broken
  prologue for arm. Here's the sample assembly:
 0x0f44 +0: push {r4, r5}
  = 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3}
 0x0f4a +6: mov r5, sp
 0x0f4c +8: b.n 0xa78 main+2616
 0x0f4e +10: ands r4, r0
 0x0f50 +12: cmp r4, r5
 0x0f52 +14: bcc.n 0xf66
 
  _ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34
 0x0f54 +16: movs r4, #16
 0x0f56 +18: movs r5, #0
 0x0f58 +20: push {lr}
 0x0f5a +22: bl 0x19d8 __morestack
 0x0f5e +26: ldr.w lr, [sp], #4
 0x0f62 +30: pop {r4, r5}
 0x0f64 +32: bx lr
 
  The problem is at 0x0f46, where code tries to read from coprocessor
  15
  register 13, which is process id register. Well, coprocessor 15
  (actually,
  all of the coprocessors) are missing from my target thumbv7m-linux-eabi
  (with added flavour of -Ctarget-cpu=cortex-m3, which should be
  redundant
  anyway), so I'm getting hardfaults in every function that rust doesn't
  inline.
 
  Any ideas on what might be going wrong? I assume that this is actually
  llvm's fault, as llvm should not materialize machine code which is not
  available for target anyway.
 
  Wrapping everything in #[no_split_stack] is a temporary workaround and
  surely not a long-term strategy.
 
  --
  Sincerely,
  Vladimir Farcaller Pouzanov
  http://farcaller.net/
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev
 




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Cloning Generic Structs/Enums with lifetime parameters

2014-04-21 Thread Alex Crichton
 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] morestack prologue contains broken machine code

2014-04-21 Thread Alex Crichton
The split stack patches for ARM were recently upstreamed, and they
were modified when being upstreamed as well. Primarily the location of
the split stack is no longer at a magic address for thumb, but rather
it uses the same instruction as ARM (some thumb processors do indeed
have the coprocessor). More information is in the long thread starting
at the initial attempt to upstream [1].

For now you'll have to use no_split_stack because the thumb split
stack will always use a coprocessor, but I'm sure that the upstream
LLVM devs would be quite welcoming to tweaks to the slit-stack support
(I'd also be willing to help). You can find the initial commit for
support at rust-lang/llvm [2].

[1] - 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html
[2] - https://github.com/rust-lang/llvm/pull/4

On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com wrote:
 Starting recently (no more than two weeks), rustc is generating a broken
 prologue for arm. Here's the sample assembly:
0x0f44 +0: push {r4, r5}
 = 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3}
0x0f4a +6: mov r5, sp
0x0f4c +8: b.n 0xa78 main+2616
0x0f4e +10: ands r4, r0
0x0f50 +12: cmp r4, r5
0x0f52 +14: bcc.n 0xf66
 _ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34
0x0f54 +16: movs r4, #16
0x0f56 +18: movs r5, #0
0x0f58 +20: push {lr}
0x0f5a +22: bl 0x19d8 __morestack
0x0f5e +26: ldr.w lr, [sp], #4
0x0f62 +30: pop {r4, r5}
0x0f64 +32: bx lr

 The problem is at 0x0f46, where code tries to read from coprocessor 15
 register 13, which is process id register. Well, coprocessor 15 (actually,
 all of the coprocessors) are missing from my target thumbv7m-linux-eabi
 (with added flavour of -Ctarget-cpu=cortex-m3, which should be redundant
 anyway), so I'm getting hardfaults in every function that rust doesn't
 inline.

 Any ideas on what might be going wrong? I assume that this is actually
 llvm's fault, as llvm should not materialize machine code which is not
 available for target anyway.

 Wrapping everything in #[no_split_stack] is a temporary workaround and
 surely not a long-term strategy.

 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Per-process arenas and ARCs

2014-04-21 Thread Alex Crichton
 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] Announcing the newest member of Mozilla's Rust team, Aaron Turon

2014-04-21 Thread Alex Crichton
Welcome Aaron! I'm so excited to have you with us!

On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson bander...@mozilla.com 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] Shouldn't task::try(...).unwrap() fail to compile?

2014-04-17 Thread Alex Crichton
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 edward.yu.w...@gmail.com wrote:
 It current can compile, but judging from signatures:

 std::task::try is pub fn tryT: Send(f: proc(): Send - T) - ResultT,
 ~Any:Send
 std::result::unwrap on the other hand is implT, E: Show ResultT, E { 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


[rust-dev] Keeping up with Breaking Changes

2014-04-16 Thread Alex Crichton
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] Storing Handle (for Select) in a collection causes a crash

2014-04-16 Thread Alex Crichton
   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


Re: [rust-dev] does not fulfill `Send` error since last pull request

2014-04-10 Thread Alex Crichton
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
philippe.delr...@free.fr 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): (SenderBaseImpl, ReceiverBaseImpl) = 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

2014-04-04 Thread Alex Crichton
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
`Optionextern fn()` can indeed be null. You'll probably want
something along the lines of:

#[link_section = .isr_vector]
pub static ISR_VECTOR_TABLE: [Optionextern unsafe fn(), ..N] =
[Some(...), None, Some(...), ...];

On Fri, Apr 4, 2014 at 12:53 PM, Vladimir Pouzanov farcal...@gmail.com 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

2014-04-03 Thread Alex Crichton
: 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 adri-from...@hotmail.fr
Alan Andrade alan.andra...@gmail.com
Alex Crichton a...@alexcrichton.com
Alex Whitney aw1...@ic.ac.uk
a_m0d damien.sch...@gmail.com
Andre Arko an...@arko.net
Andrew Chin ac...@eminence32.net
aochagavia aochagavi...@gmail.com
Arcterus arcte...@mail.com
Axel Viala axel.vi...@darnuria.eu
aydin.kim aydin@samsung.com
b1nd clint.ry...@gmail.com
Ben Harris m...@bharr.is
Ben Noordhuis i...@bnoordhuis.nl
Ben Striegel ben.strie...@gmail.com
Birunthan Mohanathas birunt...@mohanathas.com
Björn Steinbrink bstei...@gmail.com
Brendan Zabarauskas bjz...@yahoo.com.au
Brian Anderson bander...@mozilla.com
Brian Leibig brian.lei...@gmail.com
Bruno de Oliveira Abinader brun...@partner.samsung.com
Byron Williams by...@112percent.com
Cadence Marseille cadencemarsei...@gmail.com
Carl-Anton Ingmarsson ca.ingmars...@gmail.com
Chris Morgan m...@chrismorgan.info
Chris Wong lambda.fa...@gmail.com
chromatic chroma...@wgz.org
Clark Gaebel cg.wowus...@gmail.com
Cole Mickens cole.mick...@gmail.com
Colin Sherratt colin.sherr...@gmail.com
comex com...@gmail.com
Corey Richardson co...@octayn.net
Daniel Fagnan dnfag...@gmail.com
Daniel MacDougall dmacdoug...@gmail.com
Daniel Micay danielmi...@gmail.com
Dave Hodder d...@dmh.org.uk
David Manescu david.mane...@gmail.com
Davis Silverman sinistersn...@gmail.com
Derek Chiang derekchian...@gmail.com
Derek Guenther dguenth...@gmail.com
Div Shekhar d...@pagerduty.com
Dmitry Promsky dmi...@willworkforcookies.com
Dmitry Vasiliev d...@hlabs.org
Douglas Young rcxd...@gmail.com
Dylan Braithwaite dylanbraithwai...@gmail.com
Eduard Bopp eduard.b...@aepsil0n.de
Eduard Burtescu edy.b...@gmail.com
Edward Wang edward.yu.w...@gmail.com
Edward Z. Yang ezy...@cs.stanford.edu
Ehsanul Hoque ehsa...@ehsanul.com
Erick Tryzelaar erick.tryzel...@gmail.com
Eunchong Yu kroi...@gmail.com
Felix Crux fel...@felixcrux.com
Felix S. Klock II pnkfe...@pnkfx.org
Flavio Percoco flape...@gmail.com
Florian Hahn f...@fhahn.com
Florian Zeitz flo...@babelmonkeys.de
Gábor Lehel glaebho...@gmail.com
Gary M. Josack g...@byoteki.com
gentlefolk cemac...@gmail.com
Geoffroy Couprie geo.coup...@gmail.com
George Papanikolaou g3orge@gmail.com
gifnksm makoto.nksm+git...@gmail.com
Guillaume Pinot texi...@texitoi.eu

[rust-dev] Reminder: ~[T] is not going away

2014-04-02 Thread Alex Crichton
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 VecT and ~[T].

# VecT

In a post-DST world, VecT 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 VecT, 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 VecT and ~[T]

Conversions between these two types will be provided, and the default
implementations will be free. Converting from VecT to ~[T] will be simply
forgetting the capacity, and converting from ~[T] to VecT will set the
capacity to the length.

Helper methods will likely be provided to perform a forceful reallocating
shrink when going from VecT to ~[T], but it will not be the default.

## The cost of VecT = ~[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 VecT and ~[T]

Primarily, if you need a growable vector, you should use VecT. 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 VecT 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 VecT and ~[T], this will
need to be done on a case-by-case basis to evaluate whether apis should take or
consume VecT 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 VecT.
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 VecT - ~[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
VecT! 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

[rust-dev] 0.10 prerelease testing

2014-04-01 Thread Alex Crichton
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?

2014-03-24 Thread Alex Crichton
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 farcal...@gmail.com 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 co...@octayn.net 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 farcal...@gmail.com
 wrote:
  So it doesn't work in the end.
 
  rustc --emit bc with flags set for cortex-m0 provides exact same bc with
  only difference in target triple (which makes perfect sense)
 
  However, replacing llc step with rustc --emit asm provides a different
  assembler file, which requires __morestack.
 
  Should I expect rustc to generate freestanding code given some
  additional
  options?
 
 
  On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.com
  wrote:
 
  Nevermind, I lost -O somewhere in between copying and pasting command
  line
  flags. Optimised version doesn't have any morestack references (which
  is
  strange concept though).
 
 
  On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov
  farcal...@gmail.com
  wrote:
 
  Figured out I can use --target thumbv6m-linux-eabi, which implies
  -mthumb. Now the problem is that if I use
 
  rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o
 
  instead of three-step process I mentioned before, I get a valid object
  file for cortex-m0, but functions have big prologues and symbol table
  is
  much bigger:
 
   U STACK_LIMIT
   U _GLOBAL_OFFSET_TABLE_
   D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E
  0008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E
   r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E
  0004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E
  0078 t _ZN4main10__rust_abiE
   t _ZN4wait20h53ffb23463e08f19Maa4v0.0E
   U __aeabi_unwind_cpp_pr0
   U __morestack
  004c T main
 
  vs.
 
   D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E
   T main
 
  in the initial version. Also, I now need to provide __morestack (no
  idea
  what's that about).
 
 
  On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co
  wrote:
 
  You should be able to assemble standalone objects for any triple
  through rustc itself, you'll likely have to specify a different
  linker
  or assembler though:
 
  rustc foo.rs --target arm-non-linux-gnueabi \
  -C linker=arm-non-linux-gnueabi-ld \
  -C ar=arm-non-linux-gnueabi-ar
 
  As you discovered, you can pass through arguments to LLVM via the -C
  llvm-args=foo command line option to rustc. If you get complaints
  that it's an unknown command line argument, it's LLVM telling you
  those complaints, not rustc.
 
  On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov
  farcal...@gmail.com
  wrote:
   I'm trying to experiment with rust and some embedded code.
   Currently I
   have
   to do a three-pass compilation:
  
   rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc
   llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o
   main.s
   arm-none-linux-gnueabi-as main.s -o main.o
  
   First, I'm not sure how relevant is --target flag for rustc. I
   seems
   to
   change target datalayout/triple in generated bc, but that should be
   overriden by llc -mtriple anyway, right?
  
   Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down
   -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed
   with
   rustc: Unknown command line argument '--march=thumb'.
  
   Any hints on how can I drop explicit llc and as steps here?
  
   --
   Sincerely,
   Vladimir Farcaller Pouzanov
   http://farcaller.net/
  
   ___
   Rust-dev mailing list
   Rust-dev@mozilla.org
   https://mail.mozilla.org/listinfo

Re: [rust-dev] Fork in Rust

2014-03-17 Thread Alex Crichton
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 jon...@proinbox.com 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

2014-03-14 Thread Alex Crichton
 Can someone explain why this is necessary?

 static FOO: OptionCellint = 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] Work week minutes and upcoming RFCs

2014-03-14 Thread Alex Crichton
 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] #[link] using absolute path?

2014-03-05 Thread Alex Crichton
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 douglas.lin...@gmail.com 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?

2014-02-25 Thread Alex Crichton
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 fyhu...@gmail.com 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): (Portint, Chanint) = 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


Re: [rust-dev] unique vector patterns are no longer supported at head

2014-02-20 Thread Alex Crichton
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 mich...@dagits.es 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)

2014-02-19 Thread Alex Crichton
 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] [PATCH] Add stack overflow check for ARM Thumb instruction set.

2014-02-16 Thread Alex Crichton
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 svetos...@neykov.name 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 svetos...@neykov.name
 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().getSubtargetARMSubtarget();
 +  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().getSubtargetARMSubtarget();

// 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().getSubtargetARMSubtarget();
 +
 +  // 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.getInfoARMFunctionInfo();
 +  DebugLoc DL;
 +
 +  // Use R4 and R5

Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb instruction set.

2014-02-15 Thread Alex Crichton
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 svetos...@neykov.name 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().getSubtargetARMSubtarget();
 +  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().getSubtargetARMSubtarget();

// 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().getSubtargetARMSubtarget();
 +
 +  // 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.getInfoARMFunctionInfo();
 +  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(*i);
 +postStackMBB-addLiveIn(*i);
 +  }
 +
 +  

Re: [rust-dev] [rustc-f039d10] A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)

2014-02-14 Thread Alex Crichton
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 explodingm...@gmail.com 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)

2014-02-14 Thread Alex Crichton
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 explodingm...@gmail.com 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 a...@crichton.co 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 explodingm...@gmail.com
 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::ChanA` does not implement any method in scope named `clone`

2014-02-13 Thread 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 com.li...@gmail.com wrote:
 Hi Rusties,

 When try to compile tmp.rs, I got the error:

 ```
 tmp.rs:8:10: 8:19 error: type `std::comm::ChanA` 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) = Chan::A::new();
 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

2014-02-13 Thread Alex Crichton
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 simon.sa...@exyr.org 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::ChanA` does not implement any method in scope named `clone`

2014-02-13 Thread Alex Crichton
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 com.li...@gmail.com wrote:
 I compiled the lasted rustc from source yesterday.

 2014年2月13日 下午8:17于 Alex Crichton a...@crichton.co写道:

 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 com.li...@gmail.com wrote:
  Hi Rusties,
 
  When try to compile tmp.rs, I got the error:
 
  ```
  tmp.rs:8:10: 8:19 error: type `std::comm::ChanA` 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) = Chan::A::new();
  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: user input

2014-02-09 Thread Alex Crichton
 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
matthieu.monr...@gmail.com wrote:



 On Sun, Feb 9, 2014 at 12:15 PM, Renato Lenzi rex...@gmail.com 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 pcwal...@mozilla.com
 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] Fwd: Problems building rust on OSX

2014-02-09 Thread Alex Crichton
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 m...@issuu.com 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] user input

2014-02-08 Thread Alex Crichton
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 rex...@gmail.com 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

2014-02-05 Thread Alex Crichton
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


[rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
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::IoResultT` which is just a
typedef to `ResultT, IoError`. 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 IoResultT. 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::IoResultint { ... }
fn fun2() - io::IoResultuint { ... }
fn fun3() - io::IoResult() { ... }

fn foo() - io::IoResultuint {
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] Handling I/O errors

2014-02-03 Thread Alex Crichton
 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


Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla

2014-02-03 Thread Alex Crichton
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 bander...@mozilla.com 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

2014-02-03 Thread Alex Crichton
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 palmer...@gmail.com 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 a...@crichton.co 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] static mut and owning pointers

2014-01-28 Thread Alex Crichton
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 ke...@sb.org 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 n...@alum.mit.edu 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 a.stavo...@gmail.com 
 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 OptionMyStruct 
 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] should fail to compile or not?

2014-01-21 Thread Alex Crichton
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 karab...@gmail.com 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


Re: [rust-dev] Converting ~[T] embedded in struct to [T]

2014-01-19 Thread Alex Crichton
 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


Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-18 Thread Alex Crichton
 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] Converting ~[T] embedded in struct to [T]

2014-01-18 Thread Alex Crichton
 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
 // `V2` (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)

2014-01-17 Thread Alex Crichton
 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 BoxState {
priv x: i32,
}

// methods that only work on a mutable box
impl BoxMutable {
fn new() - BoxMutable { Box { x: 2 } }
fn set_x(mut self, val: i32) - { self.x = val; }
fn freeze(self) - BoxFrozen { Box { x: self.x } }
}

// methods that work on all boxes (mutable and immutable)
implT BoxT {
fn x(self) - i32 { self.x }
}

impl Clone for BoxFrozen { ... }

implT Drop for BoxT { ... }

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)

2014-01-17 Thread Alex Crichton
 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: BoxFrozen) {} // only works on frozen boxes
fn bar(t: BoxMutable) {} // only works on mutable boxes
fn bazT(t: BoxT) {} // 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] general onlookers questions on rust development

2014-01-10 Thread Alex Crichton
 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] Using libgreen/libnative

2013-12-31 Thread Alex Crichton
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
smadhuea...@outlook.com 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 'unnamed' failed at 'explicit failure',
 /private/tmp/rust-yVG2/src/librustpkg/util.rs:528

 task 'unnamed' 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
  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

[rust-dev] Using libgreen/libnative

2013-12-28 Thread Alex Crichton
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] Some questions about dead-code elimination pass

2013-11-24 Thread Alex Crichton
 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


[rust-dev] Removing some autoref magic

2013-11-19 Thread Alex Crichton
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] Removing some autoref magic

2013-11-19 Thread Alex Crichton
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


Re: [rust-dev] Why does string formatting in Rust have to be different from other languages?

2013-11-18 Thread Alex Crichton
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 derekchian...@gmail.com 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

2013-11-18 Thread Alex Crichton

 * #[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


[rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
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 considered 

Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
 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


Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
 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

2013-11-15 Thread Alex Crichton
 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

2013-11-15 Thread Alex Crichton
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 vadi...@gmail.com 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 a...@crichton.co 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`
   * #[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

Re: [rust-dev] Compiler hitting an unexpected failure path

2013-11-14 Thread Alex Crichton
It looks like you're compiling a fairly old version of the compiler, I
would recommend that you update to the master branch instead of using
older copies (we're a fast-moving target right now!)

On Thu, Nov 14, 2013 at 9:57 AM, tessy joseph tessyjoseph1...@gmail.com wrote:
 Hi

 I was trying to install RUST on my ubuntu local system.I could not complete
 after make  make install.I also tried sudo make install.Both of them
 failed .I got this note;Bug reported Compiler hitting unexpected failure
 path

 https://gist.github.com/Tessie/7470406

 Regards
 Tessy

 ___
 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] The future of M:N threading

2013-11-13 Thread Alex Crichton
The situation may not be as dire as you think. The runtime is still in a state
of flux, and don't forget that in one summer the entire runtime was rewritten in
rust and was entirely redesigned. I personally still think that M:N is a viable
model for various applications, and it seems especially unfortunate to just
remove everything because it's not tailored for all use cases.

Rust made an explicit design decision early on to pursue lightweight/green
tasks, and it was made with the understanding that there were drawbacks to the
strategy. Using libuv as a backend for driving I/O was also an explicit decision
with known drawbacks.

That being said, I do not believe that all is lost. I don't believe that the
rust standard library as-is today can support *every* use case, but it's getting
to a point where it can get pretty close. In the recent redesign of the I/O
implementation, all I/O was abstracted behind trait objects that are synchronous
in their interface. This I/O interface is all implemented in librustuv by
talking to the rust scheduler under the hood. Additionally, in pull #10457, I'm
starting to add support for a native implementation of this I/O interface. The
great boon of this strategy is that all std::io primitives have no idea if their
underlying interface is native and blocking or libuv and asynchronous. The exact
same rust code works for one as it does for the other.

I personally don't see why the same strategy shouldn't work for the task model
as well. When you link a program to the librustuv crate, then you're choosing to
have a runtime with M:N scheduling and asynchronous I/O. Perhaps, though, if you
didn't link to librustuv, you would get 1:1 scheduling with blocking I/O. You
would still have all the benefits of the standard library's communication
primitives, spawning primitives, I/O, task-local-storage etc. The only
difference is that everything would be powered by OS-level threads instead of
rust-level green tasks.

I would very much like to see a standard library which supports this
abstraction, and I believe that it is very realistically possible. Right now we
have an EventLoop interface which defines interacting with I/O that is the
abstraction between asynchronous I/O and blocking I/O. This sounds like
we need a more formalized Scheduler interface which abstracts M:N scheduling vs
1:1 scheduling.

The main goal of all of this would be to allow the same exact rust code to work
in both M:N and 1:1 environments. This ability would allow authors to specialize
their code for their task at-hand. Those writing web servers would be sure to
link to librustuv, but those writing command-line utilities would simply just
omit librustuv. Additionally, as a library author, I don't really care which
implementation you're using. I can write a mysql database driver and then you as
a consumer of my library decided whether my network calls are blocking or not.

This is a fairly new concept to me (I haven't thought much about it before), but
this sounds like it may be the right way forward to addressing your concerns
without compromising too much existing functionality. There would certainly be
plenty of work to do in this realm, and I'm not sure if this goal would block
the 1.0 milestone or not. Ideally, this would be a completely
backwards-compatible change, but there would perhaps be unintended consequences.
As always, this would need plenty of discussion to see whether this is even a
reasonable strategy to take.


On Wed, Nov 13, 2013 at 2:45 AM, Daniel Micay danielmi...@gmail.com wrote:
 Before getting right into the gritty details about why I think we should think
 about a path away from M:N scheduling, I'll go over the details of the
 concurrency model we currently use.

 Rust uses a user-mode scheduler to cooperatively schedule many tasks onto OS
 threads. Due to the lack of preemption, tasks need to manually yield control
 back to the scheduler. Performing I/O with the standard library will block the
 *task*, but yield control back to the scheduler until the I/O is completed.

 The scheduler manages a thread pool where the unit of work is a task rather
 than a queue of closures to be executed or data to be pass to a function. A
 task consists of a stack, register context and task-local storage much like an
 OS thread.

 In the world of high-performance computing, this is a proven model for
 maximizing throughput for CPU-bound tasks. By abandoning preemption, there's
 zero overhead from context switches. For socket servers with only negligible
 server-side computations the avoidance of context switching is a boon for
 scalability and predictable performance.

 # Lightweight?

 Rust's tasks are often called *lightweight* but at least on Linux the only
 optimization is the lack of preemption. Since segmented stacks have been
 dropped, the resident/virtual memory usage will be identical.

 # Spawning performance

 An OS thread can actually spawn nearly as fast as a Rust task on a system with
 one 

Re: [rust-dev] Danger of throwing exceptions through Rust code

2013-11-12 Thread Alex Crichton
You're correct about the safeness of catching failure at a task
boundary. Rust's invariants about spawning a task involve knowing a
fair bit about what's allowable to share between a task boundary, and
that allows us to reason about the failure unwinding to the task
boundary being a safe operation (as opposed to stopping unwinding at
an arbitrary location).

I'm not entirely sure what you mean by throwing an exception from C (I
think there are many flavors of doing this). Right now we implement
unwinding via C++ exceptions. When a task unwinds, it actually throws
a magical uint token which then triggers all the C++ machinery for
unwinding the stack. When compiling with LLVM, we using LLVM's invoke
instruction + landing pads to generate our cleanup locations, and
LLVM will codegen the right code such that all the landing pads are
invoked during unwinding. What this means is that the C++ exception
throwing infrastructure will probably fly right past all C code
because none of it is hooked into the exception handling stuff of C++.
This may mean, however, that intermediate C++ code may have landing
pads run (not entirely sure).

All that being said, that's just how it's currently implemented today.
I don't think that we're guaranteeing this sort of behavior to always
happen. It will probably always be the case that C stack frames are
always sailed past during unwinding, but we may implement unwinding
via precise stack tables and manual stack unwinding at some point
which wouldn't trigger C++ landing pads (or use LLVM's landing pad
infrastructure the same way that we're using it today).

Right now it's basically the case that intermingling C with Rust stack
frames and then triggering failure will only trigger unwinding in rust
functions (what does it mean to unwind in C?), and I'm not sure I'd
recommend that as a safe strategy for implementing bindings to a C
function (all intermediate C allocations are leaked).

Does that make sense? It may not quite answer your question, but
hopefully that clears up at least a little bit about how it's
implemented today.

On Tue, Nov 12, 2013 at 11:07 AM, Kevin Ballard ke...@sb.org wrote:
 Right now, Rust does not support catching task failure from within a task, it 
 only supports preventing task failure from cascading into other tasks. My 
 understanding is that this limitation is done because of safety; if a task 
 unwinds through a few frames of code, and then stops unwinding, data 
 structure invariants may have been broken by the unwinding, leaving the task 
 in an unsafe state. Is this correct?

 Given this assumption, my worry now is about task unwinding outside of the 
 control of Rust. Namely, if I’m using Rust to write a library with extern “C” 
 functions, or I’m providing callbacks to C code from within Rust, (and my 
 Rust code calls back into C at some point), then it’s very possible for the 
 called C code to throw an exception that is then caught in the calling C code 
 a few frames up. The net effect is that the thread will unwind through my 
 Rust code, but it will then be caught before unwinding any further, 
 potentially leaving any data structures in an invalid state (assuming that 
 there’s still Rust code higher up on this same stack that cares).

 Has this been considered before? Is this actually a danger or am I just being 
 paranoid?

 -Kevin
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Access error for trait implemtation in multiple file

2013-11-08 Thread Alex Crichton
You should be careful to declare modules only once. It looks like you
have two instances of mod actions in the module hierarchy, and both
modules will be compiled as separate entities (although everything
will have the same name).

If you remove the `mod actions` inside of testaction.rs you should
start making some more progress. You'll probably hit some name
resolution issues, but just be sure to import the previous declaration
of the `actions` module in the top level of the crate.

On Thu, Nov 7, 2013 at 11:50 PM, Philippe Delrieu
philippe.delr...@free.fr wrote:
 Hello, rust addict.

 I have a problem with rustc. I have 3 files.
 The first one actions.rs contains a trait declaration :

 pub trait Action {
 // process the action on server side.
 fn process(self) - ~str;
 }

 The second contains a trait implementation testaction.rs:
 mod actions;


 pub struct TestAction{
 actiontype: uint
 }

 impl actions::Action for TestAction{

 fn process(self) - ~str {
 ~
 }
 }
  The third test the trait cast :
 mod actions;
 mod midi;

 let element : ~testaction::TestAction =
 ~testaction::TestAction{actiontype:1};
 let actelm: ~actions::Action = element as ~actions::Action;
 //error here
 println(process element : + actelm.process());
 = generate  error: failed to find an implementation of trait

 let actelm: ~testaction::actions::Action = element as
 ~testaction::actions::Action;  //error here
 println(process element : + actelm.process());
 = generate error: trait `Action` is inaccessible

 If I put testaction content in the test file rustc compile.

 Any idea?

 Philippe Delrieu


 ___
 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] Access error for trait implemtation in multiple file

2013-11-08 Thread Alex Crichton
I would recommend reading about Rust's module system at
http://static.rust-lang.org/doc/master/tutorial.html#crates-and-the-module-system
to get more familiar with how things work.

You may also want to read about how import statements work at
http://static.rust-lang.org/doc/master/rust.html#use-declarations to
get an idea of how to bring these names into scope.

In rust's module system, you don't really load modules per-se, but
rather insert them at certain points in the namespace hierarchy. It's
perfectly valid to insert the same module at multiple locations in the
hierarchy, but I agree that this may not always have the expected
behavior. This probably warrants a lint mode for this which is warn by
default about inserting the same file into the module hierarchy twice,

On Fri, Nov 8, 2013 at 4:15 AM, Philippe Delrieu
philippe.delr...@free.fr wrote:
 hanks for your fast answer.
 I've made some test and if I remove mod actions; in testaction.rs I have the
 error: unresolved name impl actions::Action for TestAction in testaction.rs
 If I remove the mod actions; and keep the mod testaction; in the test.rs I
 have unresolved name in the line let actelm: ~actions::Action = element as
 ~actions::Action; for actions::Action.

 I don't see what to do!!

 I didn't fully understand the module management but even if I made something
 wrong rustc in my opinion shouldn't load the same module twice and if a
 module is load once it should use it for all. It make me think about
 I#ifndef in C.

 Philippe Delrieu


 Le 08/11/2013 09:53, Alex Crichton a écrit :

 You should be careful to declare modules only once. It looks like you

 have two instances of mod actions in the module hierarchy, and both
 modules will be compiled as separate entities (although everything
 will have the same name).

 If you remove the `mod actions` inside of testaction.rs you should
 start making some more progress. You'll probably hit some name
 resolution issues, but just be sure to import the previous declaration
 of the `actions` module in the top level of the crate.

 On Thu, Nov 7, 2013 at 11:50 PM, Philippe Delrieu
 philippe.delr...@free.fr wrote:

 Hello, rust addict.

 I have a problem with rustc. I have 3 files.
 The first one actions.rs contains a trait declaration :

 pub trait Action {
  // process the action on server side.
  fn process(self) - ~str;
 }

 The second contains a trait implementation testaction.rs:
 mod actions;


 pub struct TestAction{
  actiontype: uint
 }

 impl actions::Action for TestAction{

  fn process(self) - ~str {
  ~
  }
 }
   The third test the trait cast :
  mod actions;
  mod midi;

  let element : ~testaction::TestAction =
 ~testaction::TestAction{actiontype:1};
  let actelm: ~actions::Action = element as
 ~actions::Action;
 //error here
  println(process element : + actelm.process());
 = generate  error: failed to find an implementation of trait

  let actelm: ~testaction::actions::Action = element as
 ~testaction::actions::Action;  //error here
  println(process element : + actelm.process());
 = generate error: trait `Action` is inaccessible

 If I put testaction content in the test file rustc compile.

 Any idea?

 Philippe Delrieu


 ___
 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] State of private

2013-11-08 Thread Alex Crichton
 I just want to know what the state of affairs is.

The current state of affairs in terms of visibility and privacy in the
languages is defined and implemented with possible bugs. What's
documented in the manual/tutorial is what is intended and currently
implemented in the compiler, and if there is a deviation from those
semantics then that's a bug which needs to be fixed.

That being said, nothing is truly set in stone until we're backwards
compatible (in theory), but there's a fairly large consensus that the
current set of privacy/visibility rules are what we indeed want. I
would certainly be willing to talk about other concrete proposals! It
gets more difficult to change what we have as time goes by, but if a
new idea is lightyears better than what we currently have, it's worth
knowing about at least.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Checking error at opening file

2013-11-03 Thread Alex Crichton
 Out of curiosity, why not make File::open() return a Result instead of
 Option like it does now?

This is a relic of I/O using conditions. The idea here is that if you
wanted to catch the condition, you can indeed catch it (and do
something appropriate). If you don't catch it then the task fails and
there's no need to return an Option anyway. The other idea here is
that because the error is signaled by the condition, the return value
of the function can be something that's always successful.

In this case the definition of success is returning something which is
a Reader/Seek. The I/O library provides an implementation of
Reader/Seek on OptionT: Reader, so in cases where we can't actually
return a reader (because of the error), None is returned.

The motivation behind this strategy is to reduce boilerplate code
necessary for handling errors in I/O. Instead if checking for errors
at each operation you can check for errors during a block of
operations (or at least I believe that's the idea).

All that being said, it's likely that conditions will be removed from
the api so the return value will indeed be ResultFile, IoError as
one might expect. This is still a little in flux now (mostly on the
error portion of the result), and as a consequence this means that
almost any I/O operation will be ResultT, Error.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Checking error at opening file

2013-11-02 Thread Alex Crichton
This api is a little in flux (hopefully #10179 will land soon), but
I'm not quite sure what you mean about keeping the file descriptor
open. If there was an error opening the file, then a file descriptor
was never allocated and there's nothing to keep open. Regardless, once
my pull request lands, your example would look something like:

use std::rt::io;
use std::rt::io::File;

match io::result(|| File::open(Path::new(/some/path)) {
  Ok(file) = { /* file was successfully opened, it existed */ }
  Err(e) = { /* file couldn't be opened, error contained in e */ }
}

On Sat, Nov 2, 2013 at 5:34 PM, John Mija jon...@proinbox.com wrote:
 How to check an error at opening a file but without closing its file
 descriptor?

 use std::path;
 use std::rt::io;
 use std::rt::io::file;

 let filename = /some/path;
 let f = file::open(path::Path::new(filename), io::Open, io::Read);
 ___
 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 about std::option and std::result API

2013-11-01 Thread Alex Crichton
 # Renaming `unwrap` to `get`

I would personally find this change a little odd because we still have
a large number of `unwrap` methods thorughout the codebase. Most of
these do indeed imply destruction of the enclosing type. A change like
this would mean that when you decide to write your unwrapping method
you must internally think about whether this always implies that the
outer type would be destroyed or not. In my opinion, unwrap() on
Optionint does exactly what it should and it's just a bug vs state
of mind kind of thing. I would rather strive for consistency across
all APIs than have a special case based on whether the type just
happens to not be destroyed because the whole thing is implicitly
copyable.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] writing file

2013-10-23 Thread Alex Crichton
Right now the file I/O isn't quite what I think we want it to be in
the end, but otherwise that is roughly the code which you'll want to
write. It could be slightly shortened like this:

use std::rt::io::Writer;
use std::rt::io::file::FileInfo;
use std::rt::io;

let mut stream = Path::new(test.txt).open_writer(io::Create);
writeln!(mut stream as mut Writer, test {}, {}, {aa}, 1, 3.0, aa=2);

Or at least you could write it as such if you didn't care about
errors. Right now there's implT: Reader Reader for OptionT so
there's no need to inspect the return value of open_writer.

There are a few planned changes to this code which I would like to put
into place, however:

1. std::rt::io::Writer belongs in the prelude
2. There should be a std::rt::io::File which wraps many common
operations like opening a file, creating a file, etc, which doesn't
require importing a trait from std::rt::io::file along with importing
std::rt::io.
3. We should have object coercion so mut stream as mut Writer
isn't necessary, but rather mut stream is sufficient.

With these changes, the code would look like:

use std::rt::io::File;

let mut stream = File::create(test.txt);
writeln!(mut stream, test {}, {}, {aa}, 1, 3.0, aa=2);


Which I think looks a lot better than before! I would love to not have
to write `mut stream` or have something like `stream.write!(foo, bar,
baz)`, but I haven't thought much about changing the write! macro.

On Wed, Oct 23, 2013 at 1:22 AM, Rémi Fontan remifon...@yahoo.fr wrote:
 Hi,

 I'm learning how to open a file and write simple text data in it. I managed
 something to work but was wondering whether I had to cast my filestream as a
 writer:


 use std::path::Path;
 use std::rt::io::Writer;
 use std::rt::io::file::open;
 use std::rt::io::{Create, ReadWrite};

 let p = Path(test.txt);
 let mut stream = match open(p, Create, ReadWrite) {
 Some(s) = s,
 None = fail!(whoops! I'm sure this raised, anyways..)
 };

 writeln!(mut stream as mut Writer, test {}, {}, {aa}, 1, 3.0, aa=2);


 Is that the simplest way to open a file and write in it? I find the mut
 stream as mut Writer a bit surprising.

 cheers,

 Rémi




 ___
 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] writing file

2013-10-23 Thread Alex Crichton
 Are macros possible in traits?

Right now the grammar does not allow for this, and it may be difficult
to do so (I don't think that we're going to change that in the near
future)

 Object coercion would be great, is that a planned feature?

I believe so. I thought there was a bug open already, but I didn't
find one, so I opened https://github.com/mozilla/rust/issues/10039

 How would errors be handled in this case? Raising conditions?

We're entertaining the idea of removing conditions, so the `writeln!`
macro and related `write!` functions will probably all return a
`Result(), ~Error` or whatever the generic error type becomes.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] On Stack Safety

2013-10-21 Thread Alex Crichton
It's great to see progress in this area! I know that this has been a
tricky topic in the past, and it would be awesome to get things sorted
out.

One thing I would keep in mind is that pretty much any strategy
(except the no safety one) involves changes in LLVM. I think we all
hope to one day use clean upstream LLVM as opposed to maintaining
our own fork. This sounds like it's functionality which would
certainly be desirable from LLVM's point of view, but it may be worth
checking up with them occasionally to ensure so. Recently they're not
big fans of the idea of a no-split-stack attribute, which I thought
was a given.

Another thing to consider is that in a runtime-constrained context,
you're probably not going to want to use the default implementation of
the stack safety mechanism in place. Right now this means that you
probably don't want libmorestack.a and it's __morestack strategy. This
also means that any implementor of a stack-safety strategy needs to be
aware of the ABI of stack management. Currently this means that
maintainers of a __morestack strategy need to be aware of where the
TLS slot is on all platforms, and this doesn't necessarily map well to
something like a kernel module. All this really means though is that
it probably needs to be configurable from LLVM's point of view (hard),
or it should be documented if we expect implementations of __morestack
other than our own.

It's awesome to see work in this area, and I can't wait for the pull request!


On Mon, Oct 21, 2013 at 7:30 AM, Corey Richardson co...@octayn.net wrote:
 I've written a blog post about stack safety and a proposal for how I
 think it should be implemented in Rust:
 http://cmr.github.io/blog/2013/10/21/on-stack-safety/

 Thoughts, comments? I'm going to implement this after my (ill-kept)
 hiatus if there's consensus that this is a good idea.
 ___
 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


  1   2   >