[rust-dev] Hash Table
How can we implement hash table in rust ..or there is any built-in type for it. -- Piyush Agarwal Please don’t print this e-mail unless you really need to! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Hash Table
Le 31/01/2013 09:39, piyush agarwal a écrit : How can we implement hash table in rust ..or there is any built-in type for it. Hi, Have you looked into the std::map module? If that does not fit your use case, I think the underlying hash is in core::hash. http://static.rust-lang.org/doc/std/map.html http://static.rust-lang.org/doc/core/hash.html Cheers, -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and manageable.
More on:
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
___
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] Lifetime notation
Would using a dot '.' instead of a quote ' also resolve the ambiguity,
without introducing an extra sigil into the language?
{.lt}T
T{.lt}
--
Ziad
On Thu, Jan 31, 2013 at 6:33 AM, Benjamin Striegel
ben.strie...@gmail.comwrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
On Thu, Jan 31, 2013 at 8:58 AM, Niko Matsakis n...@alum.mit.edu wrote:
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of http://smallcultfollowing.com/**
babysteps/blog/2012/12/30/**lifetime-notation/http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from https://mail.mozilla.org/**pipermail/rust-dev/2013-**
January/002942.htmlhttps://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and
manageable. More on:
http://www.reddit.com/r/rust/**comments/17ka3b/meeting_**
weekly_20130129_region_syntax_**impl_type/c86t7wghttp://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
__**_
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-devhttps://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] Lifetime notation
I expect it would, but at the expense of no longer being able to make as
simple a statement in the language tutorial as this:
The notation 'foo means a lifetime called foo.
To me, it seems nicer for a newbie to wonder how is that lifetime being
used? than to wonder what's that thing after the dot?
Dean
From: Ziad Hatahet hata...@gmail.com
Date: Thursday, January 31, 2013 6:53 AM
To: Benjamin Striegel ben.strie...@gmail.com, Niko Matsakis
n...@alum.mit.edu
Cc: rust-dev@mozilla.org rust-dev@mozilla.org
Subject: Re: [rust-dev] Lifetime notation
Would using a dot '.' instead of a quote ' also resolve the ambiguity,
without introducing an extra sigil into the language?
{.lt}T
T{.lt}
--
Ziad
On Thu, Jan 31, 2013 at 6:33 AM, Benjamin Striegel ben.strie...@gmail.com
wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
On Thu, Jan 31, 2013 at 8:58 AM, Niko Matsakis n...@alum.mit.edu wrote:
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and
manageable. More on:
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_
syntax_impl_type/c86t7wg
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region
_syntax_impl_type/c86t7wg
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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] Lifetime notation
Wouldn't the sigil be .identifier instead of 'identifier? Anyhow, I
have some thoughts on this, but no time to reply atm.
Niko
Lucian Branescu wrote:
I would also find it valuable to have a particular sigil for
lifetimes, as there is for the various pointers.
On 31 January 2013 15:11, Dean Thompson deansherthomp...@gmail.com
mailto:deansherthomp...@gmail.com wrote:
I expect it would, but at the expense of no longer being able to
make as simple a statement in the language tutorial as this:
The notation 'foo means a lifetime called foo.
To me, it seems nicer for a newbie to wonder how is that lifetime
being used? than to wonder what's that thing after the dot?
Dean
From: Ziad Hatahet hata...@gmail.com mailto:hata...@gmail.com
Date: Thursday, January 31, 2013 6:53 AM
To: Benjamin Striegel ben.strie...@gmail.com
mailto:ben.strie...@gmail.com, Niko Matsakis n...@alum.mit.edu
mailto:n...@alum.mit.edu
Cc: rust-dev@mozilla.org mailto:rust-dev@mozilla.org
rust-dev@mozilla.org mailto:rust-dev@mozilla.org
Subject: Re: [rust-dev] Lifetime notation
Would using a dot '.' instead of a quote ' also resolve the
ambiguity, without introducing an extra sigil into the language?
{.lt}T
T{.lt}
--
Ziad
On Thu, Jan 31, 2013 at 6:33 AM, Benjamin Striegel
ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote:
+1 to this. Option 8 was always the best-case syntax, and
prefixing an apostrophe on lifetime names is entirely inoffensive.
On Thu, Jan 31, 2013 at 8:58 AM, Niko Matsakis
n...@alum.mit.edu mailto:n...@alum.mit.edu wrote:
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell
unambiguous and manageable. More on:
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___ Rust-dev mailing
list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto: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] Lifetime notation
I meant that ' is not overloaded with anything, whereas things like . are.
On 31 January 2013 15:44, Niko Matsakis n...@alum.mit.edu wrote:
Wouldn't the sigil be .identifier instead of 'identifier? Anyhow, I have
some thoughts on this, but no time to reply atm.
Niko
Lucian Branescu wrote:
I would also find it valuable to have a particular sigil for lifetimes, as
there is for the various pointers.
On 31 January 2013 15:11, Dean Thompson deansherthomp...@gmail.comwrote:
I expect it would, but at the expense of no longer being able to make as
simple a statement in the language tutorial as this:
The notation 'foo means a lifetime called foo.
To me, it seems nicer for a newbie to wonder how is that lifetime being
used? than to wonder what's that thing after the dot?
Dean
From: Ziad Hatahet hata...@gmail.com
Date: Thursday, January 31, 2013 6:53 AM
To: Benjamin Striegel ben.strie...@gmail.com, Niko Matsakis
n...@alum.mit.edu
Cc: rust-dev@mozilla.org rust-dev@mozilla.org
Subject: Re: [rust-dev] Lifetime notation
Would using a dot '.' instead of a quote ' also resolve the ambiguity,
without introducing an extra sigil into the language?
{.lt}T
T{.lt}
--
Ziad
On Thu, Jan 31, 2013 at 6:33 AM, Benjamin Striegel
ben.strie...@gmail.com wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
On Thu, Jan 31, 2013 at 8:58 AM, Niko Matsakis n...@alum.mit.eduwrote:
Interesting. That would indeed address the ambiguity issue.
Niko
Sanghyeon Seo wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and
manageable. More on:
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
___
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
___
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] Lifetime notation
On Thu, Jan 31, 2013 at 7:11 AM, Dean Thompson deansherthomp...@gmail.comwrote: I expect it would, but at the expense of no longer being able to make as simple a statement in the language tutorial as this: The notation 'foo means a lifetime called foo. To me, it seems nicer for a newbie to wonder how is that lifetime being used? than to wonder what's that thing after the dot? Dean True; however, is it worth to introduce more visual noise in order to be able to make a statement like that in the tutorial? At least the dot operator is not being used for package scopes, like Java or C# for instance. -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 1/31/13 6:33 AM, Benjamin Striegel wrote: +1 to this. Option 8 was always the best-case syntax, and prefixing an apostrophe on lifetime names is entirely inoffensive. I like this as well. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Hash Table
On 01/31/2013 12:49 AM, Simon Sapin wrote: Le 31/01/2013 09:39, piyush agarwal a écrit : How can we implement hash table in rust ..or there is any built-in type for it. Hi, Have you looked into the std::map module? If that does not fit your use case, I think the underlying hash is in core::hash. http://static.rust-lang.org/doc/std/map.html http://static.rust-lang.org/doc/core/hash.html Cheers, On the Rust master branch the `core::hashmap::linear::LinearMap` type is the preferred hashmap (it uses `core::hash`). LinearMap is an owned type that has a more 'Rusty' design than `std::map`. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 13-01-31 11:27 AM, Patrick Walton wrote:
On 1/31/13 6:33 AM, Benjamin Striegel wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
I like this as well.
As awkward as it is to be a source of direct contradiction, much less
one on syntax (sigh) I have to express my objection: I'm fine with the
use of a variable-sigil like 'a but putting the whole thing in {} is
terribly offputting to my eyes -- indeed, bringing any other bracketing
forms into the type language at all. Particularly when combining with
type parameters:
Foo{'lt}X,Y
seems past the point of tolerable reading. I'm sympathetic to the points
raised in the reddit thread concerning introducing lifetime names via
the binder on a function call, as well as the lower value of 'a
vs. 'a. I'm am ok with 'a T (or even 'aT) rather than 'aT if
there's strong preference there; the preference I expressed in the
meeting for the latter was only minor.
I would strongly prefer no more uses of brackets though.
/BDFL-syntax-bikeshed
-Graydon
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 1/31/13 11:43 AM, Graydon Hoare wrote:
On 13-01-31 11:27 AM, Patrick Walton wrote:
On 1/31/13 6:33 AM, Benjamin Striegel wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
I like this as well.
As awkward as it is to be a source of direct contradiction, much less
one on syntax (sigh) I have to express my objection: I'm fine with the
use of a variable-sigil like 'a but putting the whole thing in {} is
terribly offputting to my eyes -- indeed, bringing any other bracketing
forms into the type language at all. Particularly when combining with
type parameters:
Foo{'lt}X,Y
seems past the point of tolerable reading.
Totally fair, and agreed.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 01/31/2013 08:46 PM, Patrick Walton wrote:
On 1/31/13 11:43 AM, Graydon Hoare wrote:
On 13-01-31 11:27 AM, Patrick Walton wrote:
On 1/31/13 6:33 AM, Benjamin Striegel wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
I like this as well.
As awkward as it is to be a source of direct contradiction, much less
one on syntax (sigh) I have to express my objection: I'm fine with the
use of a variable-sigil like 'a but putting the whole thing in {} is
terribly offputting to my eyes -- indeed, bringing any other bracketing
forms into the type language at all. Particularly when combining with
type parameters:
Foo{'lt}X,Y
seems past the point of tolerable reading.
Totally fair, and agreed.
Patrick
I really prefer Foo{'lt}X,Y over Foo'ltX,Y - the former makes it
visually clearer to me where each section of the declaration starts and
ends.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 1/31/13 12:56 PM, Malte Schütze malte.schue...@fgms.de wrote:
I really prefer Foo{'lt}X,Y over Foo'ltX,Y - the former makes it
visually clearer to me where each section of the declaration starts and
ends.
The non-curly choice is Foo'lt,X,Y. How does that grab you?
Dean
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
On 01/31/2013 09:58 PM, Dean Thompson wrote:
On 1/31/13 12:56 PM, Malte Schütze malte.schue...@fgms.de wrote:
I really prefer Foo{'lt}X,Y over Foo'ltX,Y - the former makes it
visually clearer to me where each section of the declaration starts and
ends.
The non-curly choice is Foo'lt,X,Y. How does that grab you?
Dean
I'm worried that it might be confusing to read when it becomes longer.
Foo'lt,X,Y still is readable, but Foo'lt,'xy,X,Y,Z isn't anymore.
Having it in curly braces (Foo{'lt,'xy}X,Y,Z) breaks it down in
smaller parts and makes it easier to understand in my opinion.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lifetime notation
Makes sense. One counter point though, which I find more persuasive: the
more common case by far is surely a single lifetime parameter and a single
type parameter. In which case Foo'lt,X seems less noisy than
Foo{'lt}X.
Having said that, Graydon gently invoked BDFL rights to push against using
the curlies. :-) So that ship has presumably sailed.
On 1/31/13 1:37 PM, Malte Schütze malte.schue...@fgms.de wrote:
On 01/31/2013 09:58 PM, Dean Thompson wrote:
On 1/31/13 12:56 PM, Malte Schütze malte.schue...@fgms.de wrote:
I really prefer Foo{'lt}X,Y over Foo'ltX,Y - the former makes it
visually clearer to me where each section of the declaration starts and
ends.
The non-curly choice is Foo'lt,X,Y. How does that grab you?
Dean
I'm worried that it might be confusing to read when it becomes longer.
Foo'lt,X,Y still is readable, but Foo'lt,'xy,X,Y,Z isn't anymore.
Having it in curly braces (Foo{'lt,'xy}X,Y,Z) breaks it down in
smaller parts and makes it easier to understand in my opinion.
___
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] Lifetime notation
Personally, Foo'lt, 'xy, X, Y, Z is perfectly readable, and far less
noisy-looking than having two delimited lists one after another. It
will be even more readable with syntax highlighting.
If multiple lifetime parameters were really a common thing I might
have liked a second separator, maybe Foo'lt, 'xy | X, Y Z or
Foo'lt, 'xy / X, Y, Z, but that's a very minor issue.
martin
On Thu, Jan 31, 2013 at 1:37 PM, Malte Schütze malte.schue...@fgms.de wrote:
On 01/31/2013 09:58 PM, Dean Thompson wrote:
On 1/31/13 12:56 PM, Malte Schütze malte.schue...@fgms.de wrote:
I really prefer Foo{'lt}X,Y over Foo'ltX,Y - the former makes it
visually clearer to me where each section of the declaration starts and
ends.
The non-curly choice is Foo'lt,X,Y. How does that grab you?
Dean
I'm worried that it might be confusing to read when it becomes longer.
Foo'lt,X,Y still is readable, but Foo'lt,'xy,X,Y,Z isn't anymore. Having
it in curly braces (Foo{'lt,'xy}X,Y,Z) breaks it down in smaller parts and
makes it easier to understand in my opinion.
___
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] Lifetime notation
(Not sure if anyone cares about my opinion, but: if apostrophes are a
given, the braces of option 8 aren't obviously preferable to me any
more. The appeal of option 8 was that it visually distinguished
lifetime parameters, and just overall looked nice, gave the right
impression. With apostrophes the lifetimes are already distinguished
by the apostrophes, and it no longer looks as nice. It's not clearly
better to me than angle brackets with a consolidated lifetime + type
parameter list. So if I had a vote, I would probably cast it for the
latter, because at least it's simpler.)
On Thu, Jan 31, 2013 at 1:54 PM, Sanghyeon Seo sh4@samsung.com wrote:
UtherII on Reddit /r/rust suggested an idea I like:
{'lt} T
T{'lt}
Basically option 8 of
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
with ' from
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002942.html
This does need a lookahead but as far as I can tell unambiguous and
manageable. More on:
http://www.reddit.com/r/rust/comments/17ka3b/meeting_weekly_20130129_region_syntax_impl_type/c86t7wg
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Explicit stack switching
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a change
to the way C functions work.
Currently, we generate a shim and a stack switch for every function call
from Rust to C and likewise from C to Rust, except for functions
annotated with `#[rust_stack]`. These wrappers result in a significant
performance overhead. For some workloads this performance overhead is
acceptable in order to maintain small stacks. For some workloads the
performance overhead is undesirable.
For instance, the DOM in Servo requires lots of very small calls from
JavaScript to Rust. The overhead of stack switching swamps most of the
time here. Popular Web benchmarks will do things like
`someElement.clientX;` over and over, which require calls from
JavaScript to Rust to retrieve a cached value. So we must carefully
consider every CPU cycle spent in the C-to-Rust transition.
To address these issues I would like to propose a somewhat radical
change: don't have the compiler generate stack switching stubs at all.
Instead, the scheduler can expose a primitive that generates the stack
switch, and it's the programmer's responsibility to perform the stack
switch to call out to C functions. To avoid the obvious footgun here, I
propose a lint pass, on by default, that ensures that functions not
annotated with `#[rust_stack]` are called inside a stack switching helper.
The rationale here is as follows:
1. It should be possible to group many C calls under a single stack
switching operation. For example:
do stackswitch {
c_function_1();
c_function_2();
c_function_3();
}
This amortizes the cost of the stack switch over many native function calls.
2. It should be possible to have sections of Rust code that run on a big
C stack and do not use segmented stacks; for example, the new Rust
scheduler (which is to be written in Rust), or the Servo DOM as
mentioned above.
3. If (2) is possible, the Rust compiler never knows whether there's
enough stack space available to safely call a C function. Therefore,
performing the stack switch ought to be under the programmer's control.
4. We should have a lint pass that ensures that stack switches are
performed properly, because we do not want programmers to accidentally
shoot themselves in the foot.
5. Because C functions are always unsafe in the Rust sense, Rust code
will almost always wrap functionality provided by foreign libraries into
safe Rust abstractions. The stack switch can be moved into these
abstractions.
6. C functions are always unsafe, so this does not, formally, add any
new unsafety.
Whatever decision we come to, we should make this decision soon (before
0.6), because this will break code. Thoughts?
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Explicit stack switching
On 01/31/2013 02:37 PM, Patrick Walton wrote:
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a
change to the way C functions work.
Currently, we generate a shim and a stack switch for every function
call from Rust to C and likewise from C to Rust, except for functions
annotated with `#[rust_stack]`. These wrappers result in a significant
performance overhead. For some workloads this performance overhead is
acceptable in order to maintain small stacks. For some workloads the
performance overhead is undesirable.
For instance, the DOM in Servo requires lots of very small calls from
JavaScript to Rust. The overhead of stack switching swamps most of the
time here. Popular Web benchmarks will do things like
`someElement.clientX;` over and over, which require calls from
JavaScript to Rust to retrieve a cached value. So we must carefully
consider every CPU cycle spent in the C-to-Rust transition.
To address these issues I would like to propose a somewhat radical
change: don't have the compiler generate stack switching stubs at all.
Instead, the scheduler can expose a primitive that generates the stack
switch, and it's the programmer's responsibility to perform the stack
switch to call out to C functions. To avoid the obvious footgun here,
I propose a lint pass, on by default, that ensures that functions not
annotated with `#[rust_stack]` are called inside a stack switching
helper.
The rationale here is as follows:
1. It should be possible to group many C calls under a single stack
switching operation. For example:
do stackswitch {
c_function_1();
c_function_2();
c_function_3();
}
This amortizes the cost of the stack switch over many native function
calls.
I think this API requires #4479 and #4480 to be safe. Currently, the
execution environment after the stack switch is very different, so
running arbitrary Rust code there is dangerous. We may want to think of
'stack switching' instead as 'make sure I'm running on a stack segment
that is big'. Then whatever code executes after that doesn't matter - if
it's C code it will run till it runs off the stack, if it's Rust code it
will request a new segment when it hits the end.
https://github.com/mozilla/rust/issues/4479
https://github.com/mozilla/rust/issues/4480
An API that was more like `stackswitch!(function, args)` wouldn't have
that problem.
2. It should be possible to have sections of Rust code that run on a
big C stack and do not use segmented stacks; for example, the new Rust
scheduler (which is to be written in Rust), or the Servo DOM as
mentioned above.
3. If (2) is possible, the Rust compiler never knows whether there's
enough stack space available to safely call a C function. Therefore,
performing the stack switch ought to be under the programmer's control.
I don't strictly agree with this but also don't think it invalidates
your argument. My pull request #4691 makes the decision to do the stack
switch dynamic in a way that it should work correctly whether it's in
task context or not. There is overhead though.
4. We should have a lint pass that ensures that stack switches are
performed properly, because we do not want programmers to accidentally
shoot themselves in the foot.
This does force more work on programmers in the common case, and it
doesn't just punish the person declaring the functions but every caller.
That's a difficult trade off.
5. Because C functions are always unsafe in the Rust sense, Rust code
will almost always wrap functionality provided by foreign libraries
into safe Rust abstractions. The stack switch can be moved into these
abstractions.
Sure. Alleviates the problem I mentioned above.
6. C functions are always unsafe, so this does not, formally, add any
new unsafety.
Whatever decision we come to, we should make this decision soon
(before 0.6), because this will break code. Thoughts?
I do want 'extern fn's (the ones that call into Rust from C) to be plain
C ABI functions, but I think this is solvable just with #4479 and #4480.
Under that scenario calling into Rust via C would not ever have a stack
switch. Instead, it would simply be relying on the segmented stack
prologue to determine if there was enough stack.
I also though would like to move the stack switching machinery out of
trans, and I want access to foreign function pointers, and I think a
syntax extension is doable, but I'm worried about how inconvenient it
might be. I also am reluctant surfacing the stack switching in the
language. Maybe we can phrase it a way that isn't tied to the
implementation, like 'prepare_foreign_call' (just spitballing here).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Explicit stack switching
On 01/31/2013 03:35 PM, Brian Anderson wrote:
On 01/31/2013 02:37 PM, Patrick Walton wrote:
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a
change to the way C functions work.
Currently, we generate a shim and a stack switch for every function
call from Rust to C and likewise from C to Rust, except for functions
annotated with `#[rust_stack]`. These wrappers result in a
significant performance overhead. For some workloads this performance
overhead is acceptable in order to maintain small stacks. For some
workloads the performance overhead is undesirable.
For instance, the DOM in Servo requires lots of very small calls from
JavaScript to Rust. The overhead of stack switching swamps most of
the time here. Popular Web benchmarks will do things like
`someElement.clientX;` over and over, which require calls from
JavaScript to Rust to retrieve a cached value. So we must carefully
consider every CPU cycle spent in the C-to-Rust transition.
To address these issues I would like to propose a somewhat radical
change: don't have the compiler generate stack switching stubs at
all. Instead, the scheduler can expose a primitive that generates the
stack switch, and it's the programmer's responsibility to perform the
stack switch to call out to C functions. To avoid the obvious footgun
here, I propose a lint pass, on by default, that ensures that
functions not annotated with `#[rust_stack]` are called inside a
stack switching helper.
The rationale here is as follows:
1. It should be possible to group many C calls under a single stack
switching operation. For example:
do stackswitch {
c_function_1();
c_function_2();
c_function_3();
}
This amortizes the cost of the stack switch over many native function
calls.
I think this API requires #4479 and #4480 to be safe. Currently, the
execution environment after the stack switch is very different, so
running arbitrary Rust code there is dangerous. We may want to think
of 'stack switching' instead as 'make sure I'm running on a stack
segment that is big'. Then whatever code executes after that doesn't
matter - if it's C code it will run till it runs off the stack, if
it's Rust code it will request a new segment when it hits the end.
https://github.com/mozilla/rust/issues/4479
https://github.com/mozilla/rust/issues/4480
An API that was more like `stackswitch!(function, args)` wouldn't have
that problem.
There's also the problem with failure after switching stacks. Right now
there is a guard in the stack switch that catches exceptions thrown by
foreign code and aborts the process, which makes this bogus:
do stackswitch {
fail;
}
We could remove that guard and leave the behavior undefined ...
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Explicit stack switching
On 1/31/13 3:41 PM, Brian Anderson wrote:
There's also the problem with failure after switching stacks. Right now
there is a guard in the stack switch that catches exceptions thrown by
foreign code and aborts the process, which makes this bogus:
do stackswitch {
fail;
}
We could remove that guard and leave the behavior undefined ...
Could we implement unsafe `catch` to make this work? Then the stack
switching code could catch the failure and abort.
The scheduler probably needs the ability to catch anyway, right?
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Explicit stack switching
On 01/31/2013 03:41 PM, Brian Anderson wrote:
On 01/31/2013 03:35 PM, Brian Anderson wrote:
On 01/31/2013 02:37 PM, Patrick Walton wrote:
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a
change to the way C functions work.
Currently, we generate a shim and a stack switch for every function
call from Rust to C and likewise from C to Rust, except for
functions annotated with `#[rust_stack]`. These wrappers result in a
significant performance overhead. For some workloads this
performance overhead is acceptable in order to maintain small
stacks. For some workloads the performance overhead is undesirable.
For instance, the DOM in Servo requires lots of very small calls
from JavaScript to Rust. The overhead of stack switching swamps most
of the time here. Popular Web benchmarks will do things like
`someElement.clientX;` over and over, which require calls from
JavaScript to Rust to retrieve a cached value. So we must carefully
consider every CPU cycle spent in the C-to-Rust transition.
To address these issues I would like to propose a somewhat radical
change: don't have the compiler generate stack switching stubs at
all. Instead, the scheduler can expose a primitive that generates
the stack switch, and it's the programmer's responsibility to
perform the stack switch to call out to C functions. To avoid the
obvious footgun here, I propose a lint pass, on by default, that
ensures that functions not annotated with `#[rust_stack]` are called
inside a stack switching helper.
The rationale here is as follows:
1. It should be possible to group many C calls under a single stack
switching operation. For example:
do stackswitch {
c_function_1();
c_function_2();
c_function_3();
}
This amortizes the cost of the stack switch over many native
function calls.
I think this API requires #4479 and #4480 to be safe. Currently, the
execution environment after the stack switch is very different, so
running arbitrary Rust code there is dangerous. We may want to think
of 'stack switching' instead as 'make sure I'm running on a stack
segment that is big'. Then whatever code executes after that doesn't
matter - if it's C code it will run till it runs off the stack, if
it's Rust code it will request a new segment when it hits the end.
https://github.com/mozilla/rust/issues/4479
https://github.com/mozilla/rust/issues/4480
An API that was more like `stackswitch!(function, args)` wouldn't
have that problem.
There's also the problem with failure after switching stacks. Right
now there is a guard in the stack switch that catches exceptions
thrown by foreign code and aborts the process, which makes this bogus:
do stackswitch {
fail;
}
We could remove that guard and leave the behavior undefined ...
I'm going to stop replying to myself, but with return-based unwinding
the story here will be changing. Probably we can thread the return flag
through the stack switch and leave the DWARF unwinding case undefined.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Tuples and to_str()
I'm trying to convert tuple of uints to string using to_str() module like this: io::println((1,2).to_string()); Looks like it should work as to_str has implementation for (A, B), but: test.rs:11 io::println((1,2).to_string()); ^~ error: aborting due to previous error Is it compiler error or I've missed something? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tuples and to_str()
Hi Alexander Looks like a typo. The function your code calls is to_string() instead of to_str(). Tried the statements below and both worked: io::println(fmt!(%s, (1,2).to_str())); io::println((1,2).to_str()); Andrew On Thu, Jan 31, 2013 at 10:07 PM, Alexander Stavonin a.stavo...@gmail.comwrote: Full error report: test.rs:11:16: error: type `(VI2,VI3)` does not implement any method in scope named `to_string` test.rs:11 io::println((1,2).to_string()); ^~ error: aborting due to previous 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
Re: [rust-dev] Tuples and to_str()
I'm trying to convert tuple of uints to string using to_str() module like
this:
io::println((1,2).to_string());
Is it compiler error or I've missed something?
Did you mean .to_str()? The following program works for me.
fn main() {
io::println((1, 2).to_str());
}
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tuples and to_str()
As others mentioned, it is to_str() instead of to_string(). You can also use the %? format string qualifier: io::println(fmt!(Tuple is %?, (1, 2))); -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tuples and to_str()
Yes, you're right, just typo.Thanks! 2013/2/1 Andrew Rink andrewr...@gmail.com Hi Alexander Looks like a typo. The function your code calls is to_string() instead of to_str(). Tried the statements below and both worked: io::println(fmt!(%s, (1,2).to_str())); io::println((1,2).to_str()); Andrew ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] trait and lifetime
I want to add function like _1(), _2(), etc for Rust tuple. Unfortunately I
do not understand how to tell compiler lifetime of returning result in case
of `trait`
pub trait TupleValT {
pub pure fn _1() - T;
pub pure fn _2() - T;
}
impl T(T, T): TupleValT {
pure fn _1() - T {
let (a, _) = self;
a
}
pure fn _2() - T {
let (_, b) = self;
b
}
}
And the errors:
test.rs:31:21: 31:25 error: moving out of self reference
test.rs:31 let (a, _) = self;
^~~~
test.rs:35:21: 35:25 error: moving out of self reference
test.rs:35 let (_, b) = self;
^~~~
error: aborting due to 2 previous errors
How can I tell the compiler returning values lifetime? Actually it couldn't
be more than lifetime of self.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
