[rust-dev] Rust compiler running on ARM?
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
Re: [rust-dev] Rust compiler running on ARM?
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 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] On Stack Safety
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
Re: [rust-dev] On Stack Safety
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 pass to eliminate stack bounds checks on recursion-free leaves of the call graph. (LLVM is the right place to do it, as it can make these decisions post-inlining, and also knows the exact amount of stack space each function takes up.) * Why not have the crate-level stack checking attribute be a function-level attribute instead? That way you could implement tainting easily: just require that any function tagged with no stack check be marked unsafe. Overall, this is great--I like this direction :) Patrick 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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 leave it out. If you're feeling ambitious, you could implement it as an LLVM pass to eliminate stack bounds checks on recursion-free leaves of the call graph. (LLVM is the right place to do it, as it can make these decisions post-inlining, and also knows the exact amount of stack space each function takes up.) Yep. It's mostly for the case where recursion and dynamic dispatch is going to be denied, which seems to be the case for some embedded/realtime contexts, afaict from the available research. * Why not have the crate-level stack checking attribute be a function-level attribute instead? That way you could implement tainting easily: just require that any function tagged with no stack check be marked unsafe. It's not obvious to me that one could have multiple functions in a crate, each having a different stack safety strategy, working at once. No stack check on a function level would be easy to implement though, yes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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
Re: [rust-dev] On Stack Safety
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 no safety one) involves changes in LLVM. The only change I can see necessary is querying the maximum stack frame size (for guard zones). Daniel mentioned this in IRC yesterday. 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. So the crate would use a different value for `#[stack_safety=...];`, rather than `#[stack_safety=segmented];` The idea isn't to enable different implementations of __morestack, the idea is to enable entirely different concepts of stack safety entirely. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 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 pass to eliminate stack bounds checks on recursion-free leaves of the call graph. (LLVM is the right place to do it, as it can make these decisions post-inlining, and also knows the exact amount of stack space each function takes up.) Yep. It's mostly for the case where recursion and dynamic dispatch is going to be denied, which seems to be the case for some embedded/realtime contexts, afaict from the available research. 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. -Kevin smime.p7s Description: S/MIME cryptographic signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 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 pass to eliminate stack bounds checks on recursion-free leaves of the call graph. (LLVM is the right place to do it, as it can make these decisions post-inlining, and also knows the exact amount of stack space each function takes up.) Yep. It's mostly for the case where recursion and dynamic dispatch is going to be denied, which seems to be the case for some embedded/realtime contexts, afaict from the available research. 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 stack limit would be in the crate metadata, but I can see how it'd be possible to violate safety with this. But in the cases you'd want this analysis, you wouldn't be using dynamic linking anyway. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] What does `once fn` mean?
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: cannot move out of captured outer variable
// Makes sense. Compiler can't tell the action will only be invoked
// once.
string
}
}
```
So, I heard there are things called `once fn`, which seem to be what I
need. Even though the compiler warned me away from them, I thought I'd give
them a try in the spirit of investigation:
```
fn attempt_2T(action: once fn() - T) - T {
action()
}
fn call_attempt_2() - ~str {
let mut index = 0;
let string = ~str;
do attempt_2 {
// Error: cannot assign to immutable captured outer variable in a
heap closure
// It seems that `once fn` is a _heap_ closure? Makes no sense...
It
// would have made sense if it was an `~once fn`, but there's no way
// that `action_2` should be able to store somewhere a reference to
an
// `once fn`, so a stack closure should be fine!
index += 1;
string
}
}
```
So, obviously `once fn` doesn't do what I expected it to do, which is to
simply assert this fn is only called once. It seems it does that but also
carries some extra baggage of also saying force me to be a heap closure.
It isn't clear to me _why_ these two should be conflated - after all, one
could just say `~once fn` if one wanted a heap closure. Can someone
enlighten me on this?
At any rate, I then resorted to:
```
fn attempt_2T(action: fn() - T) - T {
action()
}
fn call_attempt_2() - ~str {
let mut index = 0;
let string = ~str;
let string_cell = Cell::new(string);
do attempt_1 {
// No problem here. We have a stack closure.
index += 1;
// Dynamic assertion that the action is only invoked once. Costs in
// both extra ugly source code lines and in run-time overhead.
string_cell.take()
}
}
```
So, this works, but boy is it ugly, not to mention inefficient Can someone
suggest a better way to achieve this, and shed some light on the status of
the `once fn` construct in general?
Thanks,
Oren Ben-Kiki
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Should I/O use conditions?
* 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 implements the error interface) instead of a (relatively opaque) error interface value. Don't do that. Return an error, not a naked error implementation. If people want to inspect it rather than treat it as a string, they'll do a type assertion rather than just a nil check. Then the Go-level interface doesn't tell the programmer that the type assertion continues working (i.e., that there is something to which the caller can attach its extra information). Don't do that. Return either a nil error or a valid value of your error type. Seriously, the nil interface vs nil contents thing is only a tripping point for novices who don't understand what interfaces are, it's not something you run into once you've familiarized yourself with the language. We'll see if that's true once we've got at analyzer that flags this. :-) That's not a chaining mechanism. You're going to need to explain what you mean by this, then, and how it would apply to Rust. Note that if it's something very particular to how Go code is written, it's probably not constructive here. Java exceptions have a getCause() mechanism which returns another exception. When you've got a piece of got that needs to provide further context to exceptions that might be thrown by lower layers, it can at a catch-all exception handler (well, usually for Exception, not Throwable, so it's not quite catch-all) and throw a new exception, specifying the existing exception as a cuase. Traceback printing uses this information and suppresses identical parts of the call stack, which often results in fairly useful output, without resorting to more elaborate debugging mechanisms. In contrast, I'm worried that error value threading (even when done properly, not swallowing any errors) destroys potentially valuable information about the context while the stack is (manually) unwound, leaving little more than a bare error message when it's finally reported or logged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
* 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. Obviously, it only works with fairly restricted language subsets, but such is life if you're after verifiable total correctness. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 be computed dynamically, in a C++ global constructor placed by rustc in all crate compiled libraries/executables that would write the computed value in suitable global variables. The check only needs to be done by task creation routines, by function calls contained in a recursion cycle, by closures and by stubs put in ~Trait/@Trait vtables (where Trait is public and thus implementable by other crates). Note that the latter two cannot really be avoided by taking the max over all implementations dynamically because a new dynamic library could be loaded between the check and the indirect call. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 there's consensus that this is a good idea. Thanks for writing this up! I agree with Patrick that static analysis isn't worth trying. As to the dynamic checks, I'd suggest just throwing out segmented stacks. Let's decide once and for all that they're a losing proposition; the tide seems to have turned against them. At that point the choice for checking stack overflow is between guard pages and the __morestack prologue, but why offer both options? Let's just pick one and keep it simple. The prospect of disabling stack safety on a crate level is interesting, but it's not clear to me what the use case is for combining unsafe crates with safe crates. The only reason I see for wanting to turn off the stack checks is for embedded cases that don't want to use tasks and don't want to link to morestack.a (assuming we use __morestack for the check). I'd like to know more about the reasoning here. The harder problem, not addressed here, is what to do when we run out of stack. For various reasons recovering in this situation is very hard, and right now the best we can do is abort. So my opinion of what to do with stacks is different: * Keep aborting when running out of stack via __morestack (we're already doing this) * Start using mmapping to map pages of stack on demand (this happens automatically on some linux configurations but needs to be done explicitly to guarantee lazy allocation). * Consider switching to guard pages for the stack check - this has some downsides in that the point of failure is arbitrary (not in the fn prologue) so much harder to recover from. Can we commit to making stack overflow a process abort? If we use guard pages for the check then there's not even any code gen difference between stack-safe Rust and stack-unsafe Rust; it's just a matter of runtime setup. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] mutable vs. functional APIs
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 of structure sharing. I don't think it makes a lot of sense to
have immutable APIs like this:
fn frob(mut self) { ... }
fn frobed(self) - Frob { let x = self.clone(); x.frob(); x }
It's a lot more straightforward for the users to write `let y = x.clone();
y.frob();`, and it protects us from another combinatorial explosion of
methods.
All that being said, I feel there is an open question on whether or not to
prefer statement oriented mutable APIs (methods like `fn frob(mut self)`)
and chain-oriented APIs (methods like `fn frob(self) - Frob`). Does anyone
have a good argument for one over the other?
On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson eric.samp...@gmail.comwrote:
Date: Fri, 18 Oct 2013 10:54:23 -0700
From: Jeff Petkau j...@google.com
On my code (disclaimer: only toy projects to learn Rust so far), I've
been
pretty happy with a mut_ prefix for mutable versions.
newthing = oldthing.push(foo)
anything.mut_push(foo)
x = bagofun.sort()
bagosadness.mut_sort()
etc.
Advantages:
- consistent meaning with the 'mut' keyword.
- works with pretty much any name.
- makes mutable versions just a bit uglier than immutable code.
Disadvantages:
- If an API is inherently mutable, it gets pretty noisy.
- A bit ugly, probably turns off newcomers.
- If the compiler warns on ignoring return values, and mutating methods
return (), then a convention might be unnecessary.
--Jeff
What about establishing a convention that mutable methods start with an
uppercase letter while non-mutating methods start with a lowercase letter?
It would be lightweight in terms of character count/looks and at the same
time give mutable methods a slight visual emphasis, which makes sense I
think.
I know this convention is already used by Traits, but when I looked
through some code with the above proposal in mind it would be easy to
distinguish between these two uses of the same convention due to the
differing contexts they're used in.
-Eric
___
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] mutable vs. functional APIs
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 of initialising an object in a
fluent style:
~~~
let perlin = Perlin::from_seed_str(Kittens)
.with_frequency(2.0)
.with_octaves(3);
~~~
~Brendan
On 22/10/2013, at 9:18 AM, Erick Tryzelaar erick.tryzel...@gmail.com wrote:
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 of
structure sharing. I don't think it makes a lot of sense to have immutable
APIs like this:
fn frob(mut self) { ... }
fn frobed(self) - Frob { let x = self.clone(); x.frob(); x }
It's a lot more straightforward for the users to write `let y = x.clone();
y.frob();`, and it protects us from another combinatorial explosion of
methods.
All that being said, I feel there is an open question on whether or not to
prefer statement oriented mutable APIs (methods like `fn frob(mut self)`)
and chain-oriented APIs (methods like `fn frob(self) - Frob`). Does anyone
have a good argument for one over the other?
On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson eric.samp...@gmail.com wrote:
Date: Fri, 18 Oct 2013 10:54:23 -0700
From: Jeff Petkau j...@google.com
On my code (disclaimer: only toy projects to learn Rust so far), I've been
pretty happy with a mut_ prefix for mutable versions.
newthing = oldthing.push(foo)
anything.mut_push(foo)
x = bagofun.sort()
bagosadness.mut_sort()
etc.
Advantages:
- consistent meaning with the 'mut' keyword.
- works with pretty much any name.
- makes mutable versions just a bit uglier than immutable code.
Disadvantages:
- If an API is inherently mutable, it gets pretty noisy.
- A bit ugly, probably turns off newcomers.
- If the compiler warns on ignoring return values, and mutating methods
return (), then a convention might be unnecessary.
--Jeff
What about establishing a convention that mutable methods start with an
uppercase letter while non-mutating methods start with a lowercase letter? It
would be lightweight in terms of character count/looks and at the same time
give mutable methods a slight visual emphasis, which makes sense I think.
I know this convention is already used by Traits, but when I looked through
some code with the above proposal in mind it would be easy to distinguish
between these two uses of the same convention due to the differing contexts
they're used in.
-Eric
___
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] master's project work on rust - ideas
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 formulating a set of targets (bundle of issues) given my resources so i can submit a proposal. If I can't do that in the time left, I will have to choose something else. Many thanks, Dan On Thu, Oct 17, 2013 at 11:04 AM, Dan Cristian Octavian danoctavia...@gmail.com wrote: Hello, I've spend some time looking at proposed master's projects by my uni to understand how this one compares and to understand the time resources that I have available (roughly 3 months of solid work and roughly 3 months of part-time during term-time work until project submission deadline, of course i could continue working afterwards to get things done ): Correct me if I'm wrong on the following: the main issues about runtimeless rust are: * supporting std functionality (to various degrees depending on the environment) * the stacks issue One of my concerns is that suppose I choose to do this, it's part of an active development effort and the aforementioned issues seem to be connected to many other problems (the stack problem) and it's kind of hard to just crop a big issue out and say yup this is a standalone project, you go do it. I am just worried I will have a hard time saying I've done this and I will only be able to say I've been a contributor to Rust for a while working mainly on this and that doesn't add up to be a master's project. I would really like to work on this, though. Do you think it can be formulated as a set of targets that are useful to the Rust project (they are actually used) and at the same time constitute a valid master's project? Would picking an issue that is milestoned for after 1.0 release be a good cure for this problem since their are not as interconnected with currently developed features? I've browsed through the interesting-project tagged issues. Aside from runtimeless I was interested in the following: compile time stack size https://github.com/mozilla/rust/issues/4389 proper REPL https://github.com/mozilla/rust/issues/9898 parallel multi-crate compiler driver https://github.com/mozilla/rust/issues/3431 sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 But there's also the issue of having something sizeable enough. Again any suggestions welcome. Many thanks, Dan On Tue, Oct 1, 2013 at 12:07 PM, Alex Crichton a...@crichton.co wrote: One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. As others have said, I don't believe that Rust is currently at the point of being runtimeless. In addition to what Brian mentioned about not being able to use core-language features easily (vectors, strings, convenient I/O), the story of stacks is also a little sad in runtimeless rust. Currently a runtimeless program is still forced to link to librustrt along with our own libmorestack to provide the __morestack function needed by LLVM's segmented stacks. It always seemed a little silly to me that runtimeless rust still links to the runtime... Various bits of discussion can be found on https://github.com/mozilla/rust/pull/8955 https://github.com/mozilla/rust/issues/8345 But in summary the story of how stacks are allocated is currently not sufficient for writing something like a kernel module or a kernel itself. I do believe that this is certainly within the realm of possibility, but it certainly needs to be done carefully. I'm not sure if it's too small of a master's project, but I personally consider this to be a fairly substantial undertaking to get right. The various modes discussed in those two issues would be useful to have. This also may not be limited to a runtimeless rust, because the current stack situation is a bit in flux with rust currently. Our segmented stacks are disabled in the new runtime (not implemented yet) and there's some unease about the fixed_stack_segment macro and how it can be more useful. For reference, here's some issues: Runtimeless rust: https://github.com/mozilla/rust/issues/3608 newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 revised stack attributes: https://github.com/mozilla/rust/issues/8822 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] mutable vs. functional APIs
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
}
~~~
You don't need the `transmute_mut` here, doing `let mut x = self;` works
just fine.
That would solve the 'copying' problem.
I was actually considering doing this as a way of initialising an object
in a fluent style:
~~~
let perlin = Perlin::from_seed_str(Kittens)
.with_frequency(2.0)
.with_octaves(3);
~~~
I agree, it's great for initialization, I've used this approach too for
https://github.com/erickt/rust-elasticsearch for building up JSON objects.
I could see some logic to us using chaining by default. It has some nice
symmetry with the iterator protocol:
```
fn frob(xs: ~[int]) - ~[int] {
xs
.push(0)
.push(1)
.push(2)
.move_iter().map(|x| x + 1).collect()
}
```
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unified function/method call syntax and further simplification
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 unified function/method call syntax, but I think it can be done
in a backwards compatible way.
This is up to you and the rest of the Rust team, of course. But in my very
humble opinion, it feels shortsighted to impose backwards compatibility
constraints at this point. All Rust code in existence is still (hopefully!)
a negligibly small fraction of the code that is yet to be written. I know
there's a desire to get 1.0 out the door as soon as possible, and I
understand it (I want to be using Rust instead of C++, too!), but if Rust
is still in use years or decades from now, decisions made now about the
design of the language will echo far louder than whether it was released a
few months earlier or later. I think it would be unfortunate to start
suffering a C++-like fate sooner than absolutely necessary.
The Go team has been able to make incompatible language library changes
by providing a tool that updates existing programs. Since Go's
pretty-printer fully defines the appearance of source code (indenting, line
wrapping, etc.), the updater can't mess up such things (and there are no
debates about them).
That was a general argument, and it only matters if something is
considered a good idea on the merits. In this case, it seems we disagree
about that:
On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton pwal...@mozilla.comwrote:
I was thinking not. The dot operator should still have special name
lookup rules: it searches through associated impls and all traits in scope.
It cannot call anything that is not attached to an impl.
This does make functions and methods somewhat less unified, but it makes
methods feel more like OO methods from a scoping POV. I feel the draws of
methods are not only that they switch the order of the receiver and action
but also that they allow functions associated with a type to be called
without explicitly importing their names.
Aha. That's exactly the thing I don't like, and thought would be
beneficial to change. It's different from everything else for no great
reason (is being like OO a great reason?), and carries baggage with warts
and thorny issues in it. (Needing special language constructs to write
methods; normal `fn`s feel like second-class citizens; can't selectively or
rename-import methods; can't write method-syntax functions in a different
crate without introducing spurious abstraction boundaries; the whole `impl
T { fn(self) }` versus `impl T { fn(self) }` ugliness; traits and generic
types in paths raise awkward questions; ...)
--
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Jerry
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 kmcallis...@mozilla.com wrote: * Consider switching to guard pages for the stack check What if your overflowing stack frame is bigger than a page and you access the far end of it first? I think we'd still need __morestack checks for functions that use a lot of stack. keegan ___ 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] On Stack Safety
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? Vadim On Mon, Oct 21, 2013 at 3:05 PM, Brian Anderson bander...@mozilla.comwrote: 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/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. Thanks for writing this up! I agree with Patrick that static analysis isn't worth trying. As to the dynamic checks, I'd suggest just throwing out segmented stacks. Let's decide once and for all that they're a losing proposition; the tide seems to have turned against them. At that point the choice for checking stack overflow is between guard pages and the __morestack prologue, but why offer both options? Let's just pick one and keep it simple. The prospect of disabling stack safety on a crate level is interesting, but it's not clear to me what the use case is for combining unsafe crates with safe crates. The only reason I see for wanting to turn off the stack checks is for embedded cases that don't want to use tasks and don't want to link to morestack.a (assuming we use __morestack for the check). I'd like to know more about the reasoning here. The harder problem, not addressed here, is what to do when we run out of stack. For various reasons recovering in this situation is very hard, and right now the best we can do is abort. So my opinion of what to do with stacks is different: * Keep aborting when running out of stack via __morestack (we're already doing this) * Start using mmapping to map pages of stack on demand (this happens automatically on some linux configurations but needs to be done explicitly to guarantee lazy allocation). * Consider switching to guard pages for the stack check - this has some downsides in that the point of failure is arbitrary (not in the fn prologue) so much harder to recover from. Can we commit to making stack overflow a process abort? If we use guard pages for the check then there's not even any code gen difference between stack-safe Rust and stack-unsafe Rust; it's just a matter of runtime setup. __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Audio for Rust: A Friendly Introduction now available
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
Re: [rust-dev] On Stack Safety
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 connection viable for servers, but it's hard to balance that with other needs. I'm not sure they're that important even for that use case. Is 4 kB (page size) per connection that bad? You won't compete with nginx's memory usage (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB stacks), but you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on 64 bit). Besides, if we really wanted to go head-to-head with nginx we could introduce microthreads with very small stack limits (256 bytes or whatever) that just fail if you run off the end. Such a routine would be utterly miserable to program correctly but would be necessary if you want to compete with nginx in the task model anyhow :) Realistically, though, if you are writing an nginx killer you will want to use async I/O and avoid the task model, as even the overhead of context switching via userspace register save-and-restore is going to put you at a disadvantage. Given what I've seen of the nginx code you aren't going to beat it without counting every cycle. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] On Stack Safety
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 implemented in the new runtime, so they would have to be implemented rather than just not eliminated. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
