+1 I just subscribed yesterday and I really appreciates this overview :)
-
Gaetan
2013/10/29 Jack Moffitt j...@metajack.im
I just wanted to thank you for the This Week in Rust notes. I love
reading them and I am sure that I am not the only one who appreciates the
effort that you
You can use the `--emit-llvm` flag with rustc to check out the IR. To increase
the optimisation amount, you can use `--opt-level LEVEL`, or just `-O` for an
optimisation level of 2.
~Brendan
On 29/10/2013, at 6:00 AM, Rémi Fontan remifon...@yahoo.fr wrote:
Thanks.
I hope that llvm its
Indeed. It is invaluable in helping me decide when to pull a new master and
be prepared for what I need to fix in my code. Many thanks for doing this!
On Tue, Oct 29, 2013 at 10:51 AM, Gaetan gae...@xeberon.net wrote:
+1 I just subscribed yesterday and I really appreciates this overview :)
Incidentally, my preferred way to return a closure is to use
an impl like so:
struct ntimesT(times: uint, value: T) - T;
implT:Clone ntimesT {
fn call(mut self) - OptionT {
if self.times == 0 {
None
} else {
self.times -= 1;
You may just want to enable the garbage-collection feature gate by
adding `#[feature(managed_boxes)];` to the top of the file. We have
currently made `@T` types opt-in because we expect the syntax to
change (as the message notes) and we expect the collector to change
from a ref-counting to a
If I understand correctly, what you are proposing is to offer fixed
size stacks and to use a guard page to check for stack overflow (vs a
stack preamble)?
My two thoughts are:
1. I do think segmented stacks offer several tangible benefits:
- Recursion limited only by available memory / address
struct ntimesT(times: uint, value: T) - T;
Does this syntax work at the moment?
~Brendan
On 29/10/2013, at 9:33 PM, Niko Matsakis n...@alum.mit.edu wrote:
Incidentally, my preferred way to return a closure is to use
an impl like so:
struct ntimesT(times: uint, value: T) - T;
On 29 October 2013 12:08, Niko Matsakis n...@alum.mit.edu wrote:
1. I do think segmented stacks offer several tangible benefits:
- Recursion limited only by available memory / address space
This is a weak argument. If one needs that much memory, then using an
explicit stack is a must as it
On Tue, Oct 29, 2013 at 04:21:35PM +0100, Igor Bukanov wrote:
This is a weak argument. If one needs that much memory, then using an
explicit stack is a must as it allows for significantly more compact
memory presentation.
I considered this when I wrote the e-mail. I partially agree but not
On Tue, Oct 29, 2013 at 10:14:13PM +1100, Brendan Zabarauskas wrote:
struct ntimesT(times: uint, value: T) - T;
Does this syntax work at the moment?
My mistake, I meant to leave off the `- T`. It would just be:
struct ntimesT(times: uint, value: T) - T;
implT:Clone ntimesT {
On 29 October 2013 12:08, Niko Matsakis n...@alum.mit.edu wrote:
One non-technical difficulty to failing on overflow is how to handle
user-defined destructors when there is no stack to run them on
From C++ experience the need to handle recursion comes from code like
parsers or tree-like
On 29 October 2013 16:43, Niko Matsakis n...@alum.mit.edu wrote:
But I've been watching the code I write now and I've found that many
times a recursion-based solution is much cleaner. Moreover, since we
integrate recursion specially with the type system in the form of
lifetimes, it can also
On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis n...@alum.mit.edu wrote:
If I understand correctly, what you are proposing is to offer fixed
size stacks and to use a guard page to check for stack overflow (vs a
stack preamble)?
My two thoughts are:
1. I do think segmented stacks offer
Stack overflow gets a mention in this article:
http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences:)
--
Ziad
On Tue, Oct 29, 2013 at 1:24 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis
I don't think anything but (correct) strict static analysis would have
helped in that case. Embedded systems often avoid dynamic memory allocation
completely, because dynamic out-of-memory conditions would be unacceptable.
That's likely why there was so much data on the stack in the first place. A
SpiderMonkey uses recursive algorithms in quite a few places. As the
level of recursion is at mercy of JS code, checking for stack
exhaustion is a must. For that the code explicitly compare an address
of a local variable with a limit set as a part of thread
initialization. If the limit is
On Tue, Oct 29, 2013 at 04:24:49PM -0400, Daniel Micay wrote:
If we want to unwind on task failure, we'll need to disable the `prune-eh`
pass that bubbles up `nounwind` since every function will be able to
unwind. I think it will cause a very significant increase in code size.
That's too bad,
I certainly like the idea of exposing a low stack check to the user
so that they can do better recovery. I also like the idea of
`call_with_new_stack`. I am not sure if this means that the default
recovery should be *abort* vs *task failure* (which is already fairly
drastic).
But I guess it is a
Note pre fetch and non temporal instructions really help with this..
I'm not deeply familiar with Disruptor, but I believe that it uses bounded
queues. My general feeling thus far is that, as the general 'go-to' channel
type, people should not be using bounded queues that block the sender when
19 matches
Mail list logo
