[rust-dev] Autiincrement values in loops
Have we a pretty looks solution for auto incrementation counters during loops? I mean something like C/C++ style for loop.I found an example in the manual 10.5 For loops but it looks ugly with counter outside the loop. Is it only way for solving problem? Thanks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autiincrement values in loops
The int/uint::range methods would seem to do the job: for
uint::range(0, 10) |i| { io::println(fmt!(%u, i)); }
Cheers,
Josh
On 1 February 2013 12:14, Alexander Stavonin a.stavo...@gmail.com wrote:
Have we a pretty looks solution for auto incrementation counters during
loops? I mean something like C/C++ style for loop.I found an example in the
manual 10.5 For loops but it looks ugly with counter outside the loop. Is
it only way for solving problem?
Thanks.
___
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] Autiincrement values in loops
Actually my first suggestion won't work except in trivial
circumstances (ie. starting from zero). Sorry.
On 1 February 2013 12:32, Josh Matthews j...@joshmatthews.net wrote:
Well, constant increments of N can be simulated with |let i = i * N;|
in the body of the loop. There's an issue open right now about making
range do the right thing when presented with a range going in reverse.
Cheers,
Josh
On 1 February 2013 12:28, Alexander Stavonin a.stavo...@gmail.com wrote:
Thanks, it better than nothing, but… It works only for i++; how can I write
i += 2 or i--?
On Feb 1, 2013, at 9:23 PM, Josh Matthews j...@joshmatthews.net wrote:
The int/uint::range methods would seem to do the job: for
uint::range(0, 10) |i| { io::println(fmt!(%u, i)); }
Cheers,
Josh
On 1 February 2013 12:14, Alexander Stavonin a.stavo...@gmail.com wrote:
Have we a pretty looks solution for auto incrementation counters during
loops? I mean something like C/C++ style for loop.I found an example in the
manual 10.5 For loops but it looks ugly with counter outside the loop. Is
it only way for solving problem?
Thanks.
___
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] Autiincrement values in loops
Le 01/02/2013 13:28, Alexander Stavonin a écrit :
Thanks, it better than nothing, but… It works only for i++; how can I
write /i += 2 /or /i--/?
The range() function is very simple:
https://github.com/mozilla/rust/blob/release-0.5/src/libcore/int-template.rs#L48
#[inline(always)]
/// Iterate over the range [`lo`..`hi`)
pub fn range(lo: T, hi: T, it: fn(T) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += 1 as T;
}
}
It’s quite easy to write your own variant with a step parameter:
pub pure fn range_step(lo: int, hi: int, step: int,
it: fn(int) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += step;
}
}
Maybe range_step() could be added to libcore?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autiincrement values in loops
It's also possible to write something like python's enumerate, to get:
for enumerate(some_vector) Ii, e| { ... }
In general, rust loops are closer to Python's and functional map than C++'s
looping constructs.
On 1 February 2013 12:37, Simon Sapin simon.sa...@exyr.org wrote:
Le 01/02/2013 13:28, Alexander Stavonin a écrit :
Thanks, it better than nothing, but… It works only for i++; how can I
write /i += 2 /or /i--/?
The range() function is very simple:
https://github.com/mozilla/**rust/blob/release-0.5/src/**
libcore/int-template.rs#L48https://github.com/mozilla/rust/blob/release-0.5/src/libcore/int-template.rs#L48
#[inline(always)]
/// Iterate over the range [`lo`..`hi`)
pub fn range(lo: T, hi: T, it: fn(T) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += 1 as T;
}
}
It’s quite easy to write your own variant with a step parameter:
pub pure fn range_step(lo: int, hi: int, step: int,
it: fn(int) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += step;
}
}
Maybe range_step() could be added to libcore?
--
Simon Sapin
__**_
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] Autiincrement values in loops
I guess, the solution will not work for -1 … -10
On Feb 1, 2013, at 9:37 PM, Simon Sapin simon.sa...@exyr.org wrote:
Le 01/02/2013 13:28, Alexander Stavonin a écrit :
Thanks, it better than nothing, but… It works only for i++; how can I
write /i += 2 /or /i--/?
The range() function is very simple:
https://github.com/mozilla/rust/blob/release-0.5/src/libcore/int-template.rs#L48
#[inline(always)]
/// Iterate over the range [`lo`..`hi`)
pub fn range(lo: T, hi: T, it: fn(T) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += 1 as T;
}
}
It’s quite easy to write your own variant with a step parameter:
pub pure fn range_step(lo: int, hi: int, step: int,
it: fn(int) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += step;
}
}
Maybe range_step() could be added to libcore?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autiincrement values in loops
Le 01/02/2013 13:38, Lucian Branescu a écrit :
It's also possible to write something like python's enumerate, to get:
for enumerate(some_vector) Ii, e| { ... }
In general, rust loops are closer to Python's and functional map than
C++'s looping constructs.
Python’s enumerate() works on any iterable, not just lists. Is it
possible to chain rust for-loops to get something that works not just on
vectors?
The best I can think of (untested) is:
fn enumerateT(inner_loop: fn(fn(T) - bool),
it: fn(uint, T) - bool) {
let i = 0u;
for inner_loop |el| {
if !it(i, el) { break }
i += 1;
}
}
for enumarate(|it| { some_str.each_char(it) }) |i, ch| { … }
… but it’s not pretty, and doesn’t work with eg. vec::each2 which gives
two arguments to its own `it`.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autiincrement values in loops
There's already a function to do this:
fn main() {
for int::range_step(0, 10, 2) |i| {
log(error, i);
}
for int::range_step(10, 0, -1) |i| {
log(error, i);
}
}
On Fri, Feb 1, 2013 at 7:28 AM, Alexander Stavonin a.stavo...@gmail.comwrote:
Thanks, it better than nothing, but… It works only for i++; how can I
write *i += 2 *or *i--*?
On Feb 1, 2013, at 9:23 PM, Josh Matthews j...@joshmatthews.net wrote:
The int/uint::range methods would seem to do the job: for
uint::range(0, 10) |i| { io::println(fmt!(%u, i)); }
Cheers,
Josh
On 1 February 2013 12:14, Alexander Stavonin a.stavo...@gmail.com wrote:
Have we a pretty looks solution for auto incrementation counters during
loops? I mean something like C/C++ style for loop.I found an example in the
manual 10.5 For loops but it looks ugly with counter outside the loop.
Is it only way for solving problem?
Thanks.
___
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] Autiincrement values in loops
Though note that this function is relatively new, you'll need to be on a
recent unstable version rather than 0.5.
On Fri, Feb 1, 2013 at 8:48 AM, Benjamin Striegel ben.strie...@gmail.comwrote:
There's already a function to do this:
fn main() {
for int::range_step(0, 10, 2) |i| {
log(error, i);
}
for int::range_step(10, 0, -1) |i| {
log(error, i);
}
}
On Fri, Feb 1, 2013 at 7:28 AM, Alexander Stavonin
a.stavo...@gmail.comwrote:
Thanks, it better than nothing, but… It works only for i++; how can I
write *i += 2 *or *i--*?
On Feb 1, 2013, at 9:23 PM, Josh Matthews j...@joshmatthews.net wrote:
The int/uint::range methods would seem to do the job: for
uint::range(0, 10) |i| { io::println(fmt!(%u, i)); }
Cheers,
Josh
On 1 February 2013 12:14, Alexander Stavonin a.stavo...@gmail.com
wrote:
Have we a pretty looks solution for auto incrementation counters during
loops? I mean something like C/C++ style for loop.I found an example in the
manual 10.5 For loops but it looks ugly with counter outside the loop.
Is it only way for solving problem?
Thanks.
___
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] trait and lifetime
What you want is something like this (and corresponding changes to the
impl):
pub trait TupleValT {
pub pure fn _1(self) - self/T;
pub pure fn _2(self) - self/T;
}
The `self` declaration is called an explicit self declaration. What
you have currently written is called implicit self and is deprecated.
Explicit self also tells the compiler what sort of pointer you expect:
in this case, a borrowed pointer to the receiver. The lifetime of this
borrowed pointer is always called self. Therefore, the return type
`self/T` says: a pointer with the same lifetime as the receiver to T.
Note that this syntax is likely to change in the future, although the
precise form is not yet finalized. I suspect it will be something like:
pub trait TupleValT {
pub pure fn _1('v self) - 'v T;
pub pure fn _2('v self) - 'v T;
}
which makes the connection between the lifetime of the self pointer and
the lifetime of the return value more explicit.
Niko
Alexander Stavonin wrote:
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 http://test.rs:31 let (a, _) = self;
^~~~
test.rs:35:21: 35:25 error: moving out of self reference
test.rs:35 http://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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rust 0.5 for Windows
I'm having problems with the installer for 0.5 on Windows. I end up with folders containing a mix of normal length files and zero length files. When I try to run rustc.exe I get a dialog about some libgcc*.dll not being present Any clues? Kind regards, Bruce. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Misc questions
Am 30.01.2013 00:43, schrieb Brian Anderson:
On 01/29/2013 04:47 AM, Michael Neumann wrote:
Am 29.01.2013 03:01, schrieb Brian Anderson:
On 01/28/2013 05:29 PM, Graydon Hoare wrote:
On 13-01-28 04:56 PM, Brian Anderson wrote:
I think libuv is doing too much here. For example, if I don't
want to
remove the socket from the event
queue, just disable the callback, then this is not possible. I'd
prefer when I could just tell libuv that
I am interested in event X (on Windows: I/O completion, on UNIX: I/O
availability).
Yet the optimization you suggest has to do with recycling the buffer,
not listening for one kind of event vs. another.
In general I'm not interested in trying to get underneath the
abstraction uv is providing. It's providing an IOCP-oriented
interface,
I would like to code to that and make the rust IO library not have to
worry when it's on windows vs. unix. That's the point of the
abstraction
uv provides, and it's valuable. If it means bouncing off epoll a
few too
many times (or reallocating a buffer a few too many times), I'm not
too
concerned. Those should both be O(1) operations.
Is it possible to do this optimization later or do we need to plan
for
this ahead of time? I would prefer to use the uv API as it's
presented
to start with.
The optimization to use a caller-provided buffer should (a) not be
necessary to get us started and (b) be equally possible on either
platform, unix or windows, _so long as_ we're actually sleeping a task
during its period of interest in IO (either the pre-readiness sleep
or a
post-issue, pre-completion sleep). In other words, if we're simulating
sync IO, then we can use a task-local buffer. If we're _not_
simulating
sync IO (I sure hope we do!) then we should let uv allocate and free
dynamic buffers as it needs them.
But I really hope we wind up structuring it so it simulates sync IO.
We're providing a task abstraction. Users _want_ the sync IO
abstraction
the same way they want the sequential control flow abstraction.
Presenting the scheduler-originating I/O as synchronous is what I
intend. I am not sure that we can guarantee that a task is actually
waiting for I/O when an I/O event occurs that that task is waiting
for. A task may block on some other unrelated event while the event
loop is doing I/O. Pseudocode:
let port = IOPort::connect(); // Assume we're doing I/O reads using
something portlike
while port.recv() {
// Block on a different port, while uv continues doing I/O on
our behalf
let intermediate_value = some_other_port.recv();
}
This is why I'm imagining that the scheduler will sometimes need to
buffer.
I don't think so. Let me explain.
This anyway is only a problem (which can be solved) iff we want to be
able to treat I/O like a
port and want to wait for either one to resume our thread. And I
assume we want this, so
that we can listen on an I/O socket AND for example for incoming
messages at the same time.
The kernel provides a way to do (task-local) blocking I/O operations.
There is no way for the
task to return from a read() call unless data comes in or in case of
EOF (or any other error
condition).This behaves basically like a blocking POSIX read() call,
just that it is converted
into asynchronous read by libuv under the hood. To expose I/O as
port, we have to start
a new task:
let fd = open(...);
let (po, ch) = streams::pipe();
do task::spawn {
loop {
let buf: ~[u8] = vec::from_fn(1000, || 0);
let nread = fd.read(buf, 1000);
if nread 0 {
ch.send(Data(buf))
}
else if nread == 0 {
ch.send(EOF)
}
else {
ch.send(Error)
}
}
}
Yes, a single call to 'read' will not return until some I/O arrives,
but after 'read' returns I/O continues to arrive and that I/O needs to
be stored somewhere if the task doesn't immediately block in another
call to 'read' on that same fd. Taking the above example:
loop {
// This will block until data arrives at which point the task will
be context-switched in and the data returned.
let nread = fd.read(buf, 1000);
// This will put the task to sleep waiting on a message on cmd_port
let command = cmd_port.recv();
}
Until data arrives on cmd_port the task cannot be scheduled. While the
task is asleep the I/O loop can't be blocked since other tasks are
using it too. So in the meantime uv continues to receive data from the
open fd and it needs to live somewhere until the task calls 'read'
again on the same fd. Perhaps there's something I don't understand
about the uv API here, but I think that once we start reading uv is
going to continually provide us with data whether we are ready for it
or not.
// now we can treat `po` as a Port and call select() on it
But I don't think channel I/O will be used that often.
Note that one big advantage is that we can specify the buffer size
ourself!
When we would let libuv create a buffer for us, how would
Re: [rust-dev] Autiincrement values in loops
Le 01/02/2013 14:50, Benjamin Striegel a écrit : Though note that this function is relatively new, you'll need to be on a recent unstable version rather than 0.5. Is it a bug that it’s not documented? http://static.rust-lang.org/doc/core/int.html -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.5 for Windows
On 13-02-01 06:39 AM, Bruce M. Axtens wrote: I'm having problems with the installer for 0.5 on Windows. I end up with folders containing a mix of normal length files and zero length files. When I try to run rustc.exe I get a dialog about some libgcc*.dll not being present The 0-length files are build artifacts (they act as sequence-points for make, since it cannot easily guess the actual hash-based output filenames of the libraries); they're harmless and we're just not being terribly precise in avoiding them when building the package. The absence of libgcc DLLs has to do with our dependency on mingw. As outlined in the getting started page: https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust we currently depend on a very specific version of mingw. We're hoping to move to mingw-w64 in the near future and then (eventually) to no longer depend on mingw at all; it's only being used for running the PE linker and a small number of runtime library features presently; we should eventually be able to make do without it. -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.5 for Windows
On Fri, Feb 1, 2013 at 10:13 AM, Graydon Hoare gray...@mozilla.com wrote: On 13-02-01 06:39 AM, Bruce M. Axtens wrote: I'm having problems with the installer for 0.5 on Windows. I end up with folders containing a mix of normal length files and zero length files. When I try to run rustc.exe I get a dialog about some libgcc*.dll not being present The 0-length files are build artifacts (they act as sequence-points for make, since it cannot easily guess the actual hash-based output filenames of the libraries); they're harmless and we're just not being terribly precise in avoiding them when building the package. I added this to the FAQ, btw: https://github.com/mozilla/rust/wiki/Doc-usage-FAQ and would welcome any suggestions from anyone as to how to organize the FAQs on the wiki better; they're not the easiest thing to navigate right now. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.5 for Windows
On Fri Feb 1 19:13:03 2013, Graydon Hoare wrote:
(they act as sequence-points for make, since it cannot easily guess
the actual hash-based output filenames of the libraries)
I was idly wondering about those hashy filenames: Is the long term plan
to continue to encoding hashes into the filenames? Or is there
non-zero chance that the infrastructure of Rust will change so that one
can easily predict the output file name for a library, to accommodate
tools like make.
(Sorry if the answer to the above question is already documented
somewhere obvious, I had not noticed it addressed when I was going
through the documentation.)
I suppose I might just as well implement the empty-file work-around
myself, I had not really thought terribly hard about the problem and
was just doing make clean; make whenever I needed to in my little
Rust experiments so far.
Cheers,
-Felix
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.org
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Container framework?
strcat and I have been casually brainstorming about container traits. Has there been previous discussion about standardizing a container trait hierarchy and method naming convention? Below is a rough sketch of a simple container framework, inspired by Scala, Python, and C++ STL. Scala has a well-organized trait hierarchy, but I'm partial to C++ STL's method names because they are short and consistent. :) * trait Container * trait Iterable? * trait Map * struct LinearMap (and any future hash-based maps) * trait OrderedMap? (range queries, forward/reverse iteration) * struct TreeMap * struct TrieMap? * trait Set * struct LinearSet (and any future hash-based sets) * struct BitSet (includes bit op methods like flip() and to_uint()) * trait OrderedSet? * struct TreeSet * struct TrieSet? * trait Seq (Sequence) * struct Stack * trait Queue * trait List (or trait Deque?) * struct Deque? (vec-based. Vec? VecDeque? ArrayDeque like Java?) * struct LinkedList * struct PriorityQueue Links: * Brainstorming wiki: https://etherpad.mozilla.org/h7KjhELWXk * Scala collections: http://www.scala-lang.org/docu/files/collections-api/collections.html * Python containers: http://www.python.org/dev/peps/pep-3119/#abcs-for-containers-and-iterators * C++ STL containers: http://en.cppreference.com/w/cpp/container chris ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.5 for Windows
On 13-02-01 10:21 AM, Felix S Klock II wrote: On Fri Feb 1 19:13:03 2013, Graydon Hoare wrote: (they act as sequence-points for make, since it cannot easily guess the actual hash-based output filenames of the libraries) I was idly wondering about those hashy filenames: Is the long term plan to continue to encoding hashes into the filenames? Or is there non-zero chance that the infrastructure of Rust will change so that one can easily predict the output file name for a library, to accommodate tools like make. Yes the plan is to continue hashing metadata into filename suffixes; it's to prevent short-name collisions. It's actually not a lot of work to make that name something you can _query_ though. We just haven't put a command-line option on rustc. -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Container framework?
On 13-02-01 10:36 AM, Chris Peterson wrote: strcat and I have been casually brainstorming about container traits. Has there been previous discussion about standardizing a container trait hierarchy and method naming convention? Not much; what we've had was encoded mostly in the core::iter and core::container libraries. Below is a rough sketch of a simple container framework, inspired by Scala, Python, and C++ STL. Scala has a well-organized trait hierarchy, but I'm partial to C++ STL's method names because they are short and consistent. :) * trait Container * trait Iterable? * trait Map * struct LinearMap (and any future hash-based maps) * trait OrderedMap? (range queries, forward/reverse iteration) * struct TreeMap * struct TrieMap? * trait Set * struct LinearSet (and any future hash-based sets) * struct BitSet (includes bit op methods like flip() and to_uint()) * trait OrderedSet? * struct TreeSet * struct TrieSet? * trait Seq (Sequence) * struct Stack * trait Queue * trait List (or trait Deque?) * struct Deque? (vec-based. Vec? VecDeque? ArrayDeque like Java?) * struct LinkedList * struct PriorityQueue Very happy to have people looking at organizing this stuff! It's been disorganized for a while. A few bits of preference: - I think Queue and Stack are both traits, extensions of Seq. - I think the double-ended circular vec struct (implemented unsafely) should probably be called Buf. It's the replacement for DVec. Alternatively call it Queue and come up with another name for the can access at either end trait. Deque is enough of a C++-ism that I'm ok leaving it behind. - I think of List and DoubleList as concrete types, not traits. - I am still against calling HashMap LinearMap. It's too specific; like requiring LLRBTree or AATree when over TreeMap. It's fine to have these as submodules implementing the same outer interface but to most users, HashMap is as specific as they'll want to get. - I'd prefer List as a concrete type implementing Seq - Need to differentiate owned types from persistent / managed types; many or most of these types need both forms. Thanks for taking an interest! -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Container framework?
FYI, I'm in the process of converting fun_treemap into an AA Tree and
implement much of the container traits. In the process, I've extracted out
the mutation functions from Map and Set into their own Mutable{Map,Set}
trait, and added Immutable{Map,Set} traits for persistent types. So
please talk to me before any of you start handling the mutable/persistent
type issue.
On Fri, Feb 1, 2013 at 11:24 AM, Graydon Hoare gray...@mozilla.com wrote:
On 13-02-01 10:36 AM, Chris Peterson wrote:
strcat and I have been casually brainstorming about container traits.
Has there been previous discussion about standardizing a container trait
hierarchy and method naming convention?
Not much; what we've had was encoded mostly in the core::iter and
core::container libraries.
Below is a rough sketch of a simple container framework, inspired by
Scala, Python, and C++ STL. Scala has a well-organized trait hierarchy,
but I'm partial to C++ STL's method names because they are short and
consistent. :)
* trait Container
* trait Iterable?
* trait Map
* struct LinearMap (and any future hash-based maps)
* trait OrderedMap? (range queries, forward/reverse iteration)
* struct TreeMap
* struct TrieMap?
* trait Set
* struct LinearSet (and any future hash-based sets)
* struct BitSet (includes bit op methods like flip() and
to_uint())
* trait OrderedSet?
* struct TreeSet
* struct TrieSet?
* trait Seq (Sequence)
* struct Stack
* trait Queue
* trait List (or trait Deque?)
* struct Deque? (vec-based. Vec? VecDeque? ArrayDeque
like Java?)
* struct LinkedList
* struct PriorityQueue
Very happy to have people looking at organizing this stuff! It's been
disorganized for a while. A few bits of preference:
- I think Queue and Stack are both traits, extensions of Seq.
- I think the double-ended circular vec struct (implemented unsafely)
should probably be called Buf. It's the replacement for DVec.
Alternatively call it Queue and come up with another name for the
can access at either end trait. Deque is enough of a C++-ism
that I'm ok leaving it behind.
- I think of List and DoubleList as concrete types, not traits.
- I am still against calling HashMap LinearMap. It's too specific;
like requiring LLRBTree or AATree when over TreeMap. It's fine
to have these as submodules implementing the same outer interface
but to most users, HashMap is as specific as they'll want to get.
- I'd prefer List as a concrete type implementing Seq
- Need to differentiate owned types from persistent / managed types;
many or most of these types need both forms.
Thanks for taking an interest!
-Graydon
___
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] Container framework?
On 2/1/13 11:24 AM, Graydon Hoare wrote: - I think the double-ended circular vec struct (implemented unsafely) should probably be called Buf. It's the replacement for DVec. Alternatively call it Queue and come up with another name for the can access at either end trait. Deque is enough of a C++-ism that I'm ok leaving it behind. - I think of List and DoubleList as concrete types, not traits. So List would be a singly-linked list? I thought List might be a reasonable synonym for Deque. I like Buf. chris ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Container framework?
On 2/1/13 11:48 AM, Erick Tryzelaar wrote:
FYI, I'm in the process of converting fun_treemap into an AA Tree and
implement much of the container traits. In the process, I've extracted
out the mutation functions from Map and Set into their own
Mutable{Map,Set} trait, and added Immutable{Map,Set} traits for
persistent types. So please talk to me before any of you start
handling the mutable/persistent type issue.
Is it necessary to differentiate Mutable- and Immutable- container
traits when mutating methods would take `mut self` and read-only
accessors take `self`?
chris
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Container framework?
On Friday, February 1, 2013, Chris Peterson wrote: Is it necessary to differentiate Mutable- and Immutable- container traits when mutating methods would take `mut self` and read-only accessors take `self`? Well, we need the MutableMap-style traits, but we could fold the ImmutableMap-style insert into a copy methods to Map. I don't think we can rely on mut self helping us out because it could be a source of bugs. For example, if w forget a hashmap is currently immutable and do m.remove(x); nothing actually happened. It'd be safer if either we have different method names between persistent insert/remove and mutating insert/remove, or just say if a type is mutable and you want a copy you do let n = copy m; n.insert(x). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] idea for Rust playground - seeking comments
See also http://codemirror.net/mode/rust/ . Unfortunately, the syntax has changed massively since I wrote that highlighting mode. On the bright side, I believe the syntax became somewhat more regular, so (though I'm not sure about this) a lot of the complexity in the highlighter (and believe me, it is complex) might no longer be needed. Best, Marijn On Fri, Feb 1, 2013 at 10:51 PM, Dean Thompson deansherthomp...@gmail.com wrote: Rust Dev, Pablo Fernandez and I are planning to build a simple Rust playground -- a site where people can try running small Rust programs and then record examples of working or broken Rust code. We wrote down our current strawman approach at https://github.com/rusthub/rustpad . We would greatly value feedback from this group before we begin. Dean ___ 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] Compilation Error in Rust in Nesting of Modules
Hi,
I am getting compilation error while implementing the nesting of modules as
per the Rust Language tutorial.
Below is the description of my code structure.
Inside example directory,I created a file orig.rs and declared 3 modules a,
b and c inside it. Inside module c, I declared another module inner_mod. I
created 3 files a.rs, b.rs and c.rs and one directory c, all inside the
example directory.Also, I created another file inner_mod.rs and kept it in
c directory. In c.rs, I defined a function *C_func* as below.
pub fn *c_func*() {
io::println(I am in c);
}
I called the function c_func in file test_orig.rs which is in example
directory.
As per the tutorial, I can create c.rs file and c directory both, but
nothing is mentioned about the location of c.rs with respect to c directory
i.e. whether c.rs will be kept inside c directory or outside of it at the
same level as c directory inside example directory. I tried both and got
the below error in each case when compiled:
*test_orig.rs:8:0: 8:15 error: unresolved name: orig::c::c_func
test_orig.rs:8 orig::c::c_func();*
Tar file of the code is attached.Please suggest a solution to this.
thanks
Ranvijay
example.tar
Description: Unix tar archive
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] idea for Rust playground - seeking comments
Is that the same syntax highlighter that github uses for their gists? Pablo On Fri, Feb 1, 2013 at 7:02 PM, Marijn Haverbeke mari...@gmail.com wrote: See also http://codemirror.net/mode/rust/ . Unfortunately, the syntax has changed massively since I wrote that highlighting mode. On the bright side, I believe the syntax became somewhat more regular, so (though I'm not sure about this) a lot of the complexity in the highlighter (and believe me, it is complex) might no longer be needed. Best, Marijn On Fri, Feb 1, 2013 at 10:51 PM, Dean Thompson deansherthomp...@gmail.com wrote: Rust Dev, Pablo Fernandez and I are planning to build a simple Rust playground -- a site where people can try running small Rust programs and then record examples of working or broken Rust code. We wrote down our current strawman approach at https://github.com/rusthub/rustpad . We would greatly value feedback from this group before we begin. Dean ___ 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: Explicit stack switching
On 02/01/2013 09:23 AM, Matthieu Monrocq wrote:
On Fri, Feb 1, 2013 at 12:09 PM, Michael Neumann mneum...@ntecs.de
mailto:mneum...@ntecs.de wrote:
Am 31.01.2013 23:37, schrieb Patrick Walton:
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();
}
wouldn't it be possible for this case to just do:
extern mod lib_c {
#[rust_stack]
fn c_function_1();
#[rust_stack]
fn c_function_2();
#[rust_stack]
fn c_function_3();
}
and then calling it like above with *one* do stackswitch?
The default would still be to do a stack switch. If you need to
call c_function_1 sometimes with a stack switch, and sometimes
in a group of other functions (with just one stack switch for that
group), we could have something like this:
extern mod lib_c {
// This is the default
fn c_function_1();
#[rust_stack]
fn c_function_1() as rs_c_function1();
}
Then use lib_c::c_function_1() when you want a stack switch, or
rs_c_function1() without. One could go further
and auto generate for mod lib_c a sub module called rs (for rust
stack), where each function has a #[rust_stack]
directive in front of it, so you don't have to declare it twice.
This woudl give use: lib_c::c_function_1() and
lib_c::rs::c_function_1().
Regards,
Michael
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I would have a stupid proposal: what if the C function declaration was
annotated not with #[rust_stack] but with #[stack 5k] instead. That
is, instead of having a single blunt tool, let the programmer declare
how much stack is necessary for the C function and let the compiler
reason about it to guarantee that enough stack is available.
extern mod lib_c {
#[stack 4k]
fn c_function_1();
#[stack unlimited]
fn c_function_2();
#[stack 16k]
fn c_function_3();
}
I do imagine we will eventually want precise control to declare how much
stack we need. I originally wanted this for optimizations in core, but
as more of core is written in Rust this probably isn't going to matter
much. There is an issue open on this subject:
https://github.com/mozilla/rust/issues/4481
Then when the compiler sees a bunch of C functions:
fn func(x: int) {
c_function_1();
c_function_1();
c_function_1();
c_function_3();
}
= if one is marked as unlimited, then it performs stack switching
(once); this can deferred to the branch the function is called in if
judged better.
= otherwise, it evaluates the maximum amount of stack needed and
prepares it at the beginning of the function, as usual
This sounds like it requires the compiler to have yet more knowledge
about stack switching, and a goal of pcwalton's proposal is to get the
stack switching logic out of the compiler (into a syntax extension).
Advantages:
+ Code is not invalidated, only the function declarations are, and
it's easy enough to do a bulk replace #[rust_stack] - #[stack 4k]
+ The
Re: [rust-dev] trait and lifetime
Thank you! But I still can not compile it:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 pub pure fn _2(self) - self/T;
4 }
5
6 impl T(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 pure fn _2(self) - self/T {
12 let (_, b) = self;
13 b
14 }
15 }
test.rs:8:12: 8:18 error: mismatched types: expected `self/('a,'a)`, found
tuple
test.rs:8 let (a, _) = self;
^~
On Feb 1, 2013, at 11:38 PM, Niko Matsakis n...@alum.mit.edu wrote:
What you want is something like this (and corresponding changes to the impl):
pub trait TupleValT {
pub pure fn _1(self) - self/T;
pub pure fn _2(self) - self/T;
}
The `self` declaration is called an explicit self declaration. What you
have currently written is called implicit self and is deprecated. Explicit
self also tells the compiler what sort of pointer you expect: in this case, a
borrowed pointer to the receiver. The lifetime of this borrowed pointer is
always called self. Therefore, the return type `self/T` says: a pointer
with the same lifetime as the receiver to T.
Note that this syntax is likely to change in the future, although the precise
form is not yet finalized. I suspect it will be something like:
pub trait TupleValT {
pub pure fn _1('v self) - 'v T;
pub pure fn _2('v self) - 'v T;
}
which makes the connection between the lifetime of the self pointer and the
lifetime of the return value more explicit.
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] trait and lifetime
You need let (a, _) = *self or let (a, _) = self. self is a
pointer to a tuple, not a tuple.
Niko
Alexander Stavonin wrote:
Thank you! But I still can not compile it:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 pub pure fn _2(self) - self/T;
4 }
5
6 implT(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 pure fn _2(self) - self/T {
12 let (_, b) = self;
13 b
14 }
15 }
test.rs:8:12: 8:18 error: mismatched types: expected `self/('a,'a)`, found
tuple
test.rs:8 let (a, _) = self;
^~
On Feb 1, 2013, at 11:38 PM, Niko Matsakisn...@alum.mit.edu wrote:
What you want is something like this (and corresponding changes to the impl):
pub trait TupleValT {
pub pure fn _1(self) - self/T;
pub pure fn _2(self) - self/T;
}
The `self` declaration is called an explicit self declaration. What you have currently written is called
implicit self and is deprecated. Explicit self also tells the compiler what sort of pointer you expect: in this
case, a borrowed pointer to the receiver. The lifetime of this borrowed pointer is always called self. Therefore,
the return type `self/T` says: a pointer with the same lifetime as the receiver to T.
Note that this syntax is likely to change in the future, although the precise
form is not yet finalized. I suspect it will be something like:
pub trait TupleValT {
pub pure fn _1('v self) - 'v T;
pub pure fn _2('v self) - 'v T;
}
which makes the connection between the lifetime of the self pointer and the
lifetime of the return value more explicit.
Niko
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] trait and lifetime
Thank you very much! I guess had better extend your Borrowed pointers
tutorial with information about traits. At least for me it's unclear from the
tutorial.
On Feb 2, 2013, at 9:08 AM, Niko Matsakis n...@alum.mit.edu wrote:
You need let (a, _) = *self or let (a, _) = self. self is a pointer to
a tuple, not a tuple.
Niko
Alexander Stavonin wrote:
Thank you! But I still can not compile it:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 pub pure fn _2(self) - self/T;
4 }
5
6 impl T(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 pure fn _2(self) - self/T {
12 let (_, b) = self;
13 b
14 }
15 }
test.rs:8:12: 8:18 error: mismatched types: expected `self/('a,'a)`, found
tuple
test.rs:8 let (a, _) = self;
^~
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] trait and lifetime
I made changes as you told me:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 /*pub pure fn _2(self) - self/T;*/
4 }
5
6 impl T(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 /*pure fn _2(self) - self/T {*/
12 /*let (_, b) = self;*/
13 /*b*/
14 /*}*/
15 }
16
17 fn main() {
18 let pair = (1, 2);
19 let left = *pair._1();
20 io::println(fmt!(pair left: %u, left));
21 /*let r = pair._2();*/
22 }
But:
test.rs:9:9: 9:10 error: illegal borrow: borrowed value does not live long
enough
test.rs:9 a
^
test.rs:7:33: 10:5 note: borrowed pointer must be valid for the lifetime self
as defined on the block at 7:33...
test.rs:7 pure fn _1(self) - self/T {
test.rs:8 let (a, _) = self;
test.rs:9 a
test.rs:10 }
test.rs:7:33: 10:5 note: ...but borrowed value is only valid for the block at
7:33
test.rs:7 pure fn _1(self) - self/T {
test.rs:8 let (a, _) = self;
test.rs:9 a
test.rs:10 }
error: aborting due to previous error
Did I miss something?
On Feb 2, 2013, at 9:08 AM, Niko Matsakis n...@alum.mit.edu wrote:
You need let (a, _) = *self or let (a, _) = self. self is a pointer to
a tuple, not a tuple.
Niko
Alexander Stavonin wrote:
Thank you! But I still can not compile it:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 pub pure fn _2(self) - self/T;
4 }
5
6 impl T(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 pure fn _2(self) - self/T {
12 let (_, b) = self;
13 b
14 }
15 }
test.rs:8:12: 8:18 error: mismatched types: expected `self/('a,'a)`, found
tuple
test.rs:8 let (a, _) = self;
^~
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] idea for Rust playground - seeking comments
Is that the same syntax highlighter that github uses for their gists? No, Github uses Pygments for their syntax highlighting. And though there exists a Rust highlighter in Pygments, it's a newer version of Pygments that Github's Ruby-based Pygments wrapper doesn't yet support. Though note that Marijn's CodeMirror plugin is 100% Javascript, and is in fact designed to be embedded in web pages. It's quite a lovely client-side code editor. On Fri, Feb 1, 2013 at 5:13 PM, pablo fernandez fernandezpabl...@gmail.comwrote: Is that the same syntax highlighter that github uses for their gists? Pablo On Fri, Feb 1, 2013 at 7:02 PM, Marijn Haverbeke mari...@gmail.comwrote: See also http://codemirror.net/mode/rust/ . Unfortunately, the syntax has changed massively since I wrote that highlighting mode. On the bright side, I believe the syntax became somewhat more regular, so (though I'm not sure about this) a lot of the complexity in the highlighter (and believe me, it is complex) might no longer be needed. Best, Marijn On Fri, Feb 1, 2013 at 10:51 PM, Dean Thompson deansherthomp...@gmail.com wrote: Rust Dev, Pablo Fernandez and I are planning to build a simple Rust playground -- a site where people can try running small Rust programs and then record examples of working or broken Rust code. We wrote down our current strawman approach at https://github.com/rusthub/rustpad . We would greatly value feedback from this group before we begin. Dean ___ 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] trait and lifetime
Sorry, I told you wrong. When you write:
let (a, _) = self;
a
You are actually copying the value out of `self` and into the stack
variable `a`. The error message is telling you that you are returning a
pointer into your stack frame, which is of course unsafe.
What you actually want is this:
let (ref a, _) = self;
a
The `ref` keyword indicates that the `a` variable should be a pointer
into the value being matched (here, `self`) and not copied out.
Niko
Alexander Stavonin wrote:
I made changes as you told me:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 /*pub pure fn _2(self) - self/T;*/
4 }
5
6 implT(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let(a, _) = self;
9a
10 }
11 /*pure fn _2(self) - self/T {*/
12 /*let(_, b) = self;*/
13 /*b*/
14 /*}*/
15 }
16
17 fn main() {
18 let pair = (1, 2);
19 let left = *pair._1();
20 io::println(fmt!(pair left: %u, left));
21 /*let r = pair._2();*/
22 }
But:
test.rs:9:9: 9:10 error: illegal borrow: borrowed value does not live long
enough
test.rs:9a
^
test.rs:7:33: 10:5 note: borrowed pointer must be valid for the lifetimeself
as defined on the block at 7:33...
test.rs:7 pure fn _1(self) - self/T {
test.rs:8 let(a, _) = self;
test.rs:9a
test.rs:10 }
test.rs:7:33: 10:5 note: ...but borrowed value is only valid for the block at
7:33
test.rs:7 pure fn _1(self) - self/T {
test.rs:8 let(a, _) = self;
test.rs:9a
test.rs:10 }
error: aborting due to previous error
Did I miss something?
On Feb 2, 2013, at 9:08 AM, Niko Matsakisn...@alum.mit.edu wrote:
You need let (a, _) = *self or let(a, _) = self. self is a pointer to a
tuple, not a tuple.
Niko
Alexander Stavonin wrote:
Thank you! But I still can not compile it:
1 pub trait TupleValT {
2 pub pure fn _1(self) - self/T;
3 pub pure fn _2(self) - self/T;
4 }
5
6 implT(T, T): TupleValT {
7 pure fn _1(self) - self/T {
8 let (a, _) = self;
9 a
10 }
11 pure fn _2(self) - self/T {
12 let (_, b) = self;
13 b
14 }
15 }
test.rs:8:12: 8:18 error: mismatched types: expected `self/('a,'a)`, found
tuple
test.rs:8 let (a, _) = self;
^~
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Explicit stack switching
On 02/01/2013 03:14 PM, Brian Anderson wrote:
On 02/01/2013 09:23 AM, Matthieu Monrocq wrote:
On Fri, Feb 1, 2013 at 12:09 PM, Michael Neumann mneum...@ntecs.de
mailto:mneum...@ntecs.de wrote:
Am 31.01.2013 23:37, schrieb Patrick Walton:
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();
}
wouldn't it be possible for this case to just do:
extern mod lib_c {
#[rust_stack]
fn c_function_1();
#[rust_stack]
fn c_function_2();
#[rust_stack]
fn c_function_3();
}
and then calling it like above with *one* do stackswitch?
The default would still be to do a stack switch. If you need to
call c_function_1 sometimes with a stack switch, and sometimes
in a group of other functions (with just one stack switch for
that group), we could have something like this:
extern mod lib_c {
// This is the default
fn c_function_1();
#[rust_stack]
fn c_function_1() as rs_c_function1();
}
Then use lib_c::c_function_1() when you want a stack switch, or
rs_c_function1() without. One could go further
and auto generate for mod lib_c a sub module called rs (for
rust stack), where each function has a #[rust_stack]
directive in front of it, so you don't have to declare it twice.
This woudl give use: lib_c::c_function_1() and
lib_c::rs::c_function_1().
Regards,
Michael
___
Rust-dev mailing list
Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I would have a stupid proposal: what if the C function declaration
was annotated not with #[rust_stack] but with #[stack 5k] instead.
That is, instead of having a single blunt tool, let the programmer
declare how much stack is necessary for the C function and let the
compiler reason about it to guarantee that enough stack is available.
extern mod lib_c {
#[stack 4k]
fn c_function_1();
#[stack unlimited]
fn c_function_2();
#[stack 16k]
fn c_function_3();
}
I do imagine we will eventually want precise control to declare how
much stack we need. I originally wanted this for optimizations in
core, but as more of core is written in Rust this probably isn't going
to matter much. There is an issue open on this subject:
https://github.com/mozilla/rust/issues/4481
After thinking about this more, I like this direction and think it will
matter for core because core should entirely be able to avoid big stack
switches once the runtime is rewritten.
I want to stop thinking about this as 'stack switching' and instead as
'reserving stack'. At some point I intend to remove the distinction
between the C stack and Rust stack segments, and they will be cached in
a pool on the scheduler. It will be considerably simpler than the
current arrangement that employs two very different strategies for
creating and caching stacks.
I am thinking a two-pronged approach of library functions plus syntax
extensions.
extern-ABI functions don't switch stacks by default.
In the library we add this sort of function that simply
Re: [rust-dev] RFC: Explicit stack switching
On 02/01/2013 11:02 PM, Brian Anderson wrote:
On 02/01/2013 03:14 PM, Brian Anderson wrote:
On 02/01/2013 09:23 AM, Matthieu Monrocq wrote:
do reserve_stack(Standard) { rust_task_fail(); }
Of course that's
do reserve_stack(Standard) { unsafe { rust_task_fail(); } }
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
