What is the current status of ARM support in Rust? In particularly I
am interested in running the compiler on an ARM Chromebook.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I've yet to see or hear of a rustc running native on ARM, though it
shouldn't be impossible to cross-build rustc for native ARM: we can
already target ARM just fine.
On Mon, Oct 21, 2013 at 2:01 AM, Igor Bukanov i...@mir2.org wrote:
What is the current status of ARM support in Rust? In
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.
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
determine stack size is going to fail on any reasonable program. I would just
leave it out. If you're feeling ambitious, you could implement it as an LLVM
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
determine stack size is going to fail on any reasonable program. I would
just
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
On Mon, Oct 21, 2013 at 12:28 PM, Alex Crichton a...@crichton.co wrote:
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
On Oct 21, 2013, at 9:11 AM, Corey Richardson co...@octayn.net wrote:
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
On Mon, Oct 21, 2013 at 1:08 PM, Kevin Ballard ke...@sb.org wrote:
On Oct 21, 2013, at 9:11 AM, Corey Richardson co...@octayn.net wrote:
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty
I have code which (greatly simplified) boiled down to:
```
fn attempt_1T(action: fn() - T) - T {
action()
}
fn call_attempt_1() - ~str {
let mut index = 0;
let string = ~str;
do attempt_1 {
// No problem here. We have a stack closure.
index += 1;
// Error:
* Steven Blenkinsop:
On Saturday, 19 October 2013, Florian Weimer wrote:
The problem is that if err is of type error, err != nil is true
after the assignment of a pointer value to err. So the usual error
checking idiom doesn't work if your function returns a
pointer-to-struct (that
* Patrick Walton:
* I can pretty much guarantee you that that simple of a static
analysis to determine stack size is going to fail on any reasonable
program.
It's needed to show total correctness, and often done with tool
support in the embedded space. GCC has some support for it.
It seems to me that trying to determine max stack size is incompatible with
dynamic linking. So even if you disallow recursion, any function that calls
a function outside of its own crate is not going to be able to trust its
calculated max stack size.
The maximum stack size needs to
On 10/21/2013 07:30 AM, Corey Richardson 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
In my opinion, there are two main reasons why one would prefer an immutable
API over a mutable one: aliasing and sharing substructures. Given that
unique pointers and references have mostly solved the first one, in my
opinion we should prefer mutable APIs unless the API is going to take
advantage
chain-oriented APIs (methods like `fn frob(self) - Frob`)
What about:
~~~
fn frob(self) - Frob {
let mut x = self;// not sure if you need `cast::transmute_mut` here
x.thing = foo();
x
}
~~~
That would solve the 'copying' problem.
I was actually considering doing this as a way
Bumping this, because my deadline for choosing a master's project is 25th.
Would appreciate it if somebody could give me a brief answer about my
concerns with regards to the runtimeless rust thing, at least. If I am
unclear please ask for clarifications.
It's mainly about getting help with
On Mon, Oct 21, 2013 at 4:10 PM, Brendan Zabarauskas bjz...@yahoo.com.auwrote:
chain-oriented APIs (methods like `fn frob(self) - Frob`)
What about:
~~~
fn frob(self) - Frob {
let mut x = self;// not sure if you need `cast::transmute_mut` here
x.thing = foo();
x
}
~~~
On Sun, Oct 20, 2013 at 5:28 AM, Gábor Lehel illiss...@gmail.com wrote:
On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton pwal...@mozilla.comwrote:
I think it's unfortunately too late to overhaul the language like this.
This will require redesigns of all Rust code in existence.
I do like
Nope. Guard zones, not guard page (singular!). Except in the face of
loading things from dynamic libs at runtime (which is unsafe right now
anyway), you can always determine the maximum stack frame used by a
given executable crate.
On Mon, Oct 21, 2013 at 8:37 PM, Keegan McAllister
Hi Brian,
Can you please elaborate on why segmented stacks fell out of favor? Maybe
it's been discussed among the core Rust team, but external people like me
are probably wondering why.
It seems to me that segmented stacks would be essential for async I/O and
actor-based architectures, no?
I will be giving the talk at CodeMash. Here's my RuPy slides:
http://steveklabnik.github.io/nobody_knows_rust/#/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 10/21/13 8:48 PM, Daniel Micay wrote:
Segmented stacks result in extra code being added to every function,
loss of memory locality, high overhead for calls into C and
unpredictable performance hits due to segment thrashing.
They do seem important for making the paradigm of one task per
On Tue, Oct 22, 2013 at 12:37 AM, Vadim vadi...@gmail.com wrote:
Ok, so maybe they should be disabled by default. But to eliminate them
outright would be shortsighted, IMHO. Can we leave them as an option for
people who do care about this sort of stuff?
Segmented stacks aren't actually
24 matches
Mail list logo
