Re: [rust-dev] Rust Research Project Query
Finishing the DXR (https://wiki.mozilla.org/DXR) support for Rust that Nick Cameron started would be extremely valuable and intersect with your static analysis interests. https://bugzilla.mozilla.org/show_bug.cgi?id=956768 is our tracking metabug for the DXR-side work that is still required; presumably Nick (nrc on irc) can clarify the Rust-side stuff remaining. Cheers, Josh On 9 October 2014 02:22, Victor Barua victor.ba...@gmail.com wrote: I'm interested in a project from a programming languages perspective. It's an area I've recently gotten into and it would also align with the research focus of my supervisor. I think it would be interesting to work on some static analysis tooling. Sean mentioned a test coverage tool earlier in the thread which is actually a pretty good baseline for a project as it's a combination of mucking with the language internals (which I could talk about in a report) and implementing a useful tool. Your idea about proving properties of Rust programs would also make an excellent project as its a great combination of theory and implementation. I'd like to thank everyone for the ideas so far, there's a lot of good material and I'm slowly accumulating project ideas to run past my supervisor. If you've got more keep them coming. On 8 October 2014 21:36, Tony Arcieri basc...@gmail.com wrote: On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua victor.ba...@gmail.com wrote: I'm a senior Computer Science undergraduate student at the University of British Columbia. As part of my degree I have to complete an undergraduate thesis which is a project of around 220 hours between now and next April. Rust is a language that has caught my eye and I would be very interested in working on something related to it that I could contribute back to the community at the end of my project. What are you interested in? I think it'd be really cool to create a language based on Rust for proving properties about Rust programs using things like dependent types, refinement types, or otherwise. -- Tony Arcieri ___ 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] Single inheritance example
As one of the main DOM designers for Servo, I've been reading the RFCs for virtual struct proposals with interest. One problem I've had is that I have found it difficult to translate the examples included into meaningful commentary with regards to how this would impact Servo's implementation. Accordingly, I've put together https://gist.github.com/jdm/9900569, which is a minimal example of the C++ features that Servo is currently emulating (or planning to) using unsafe code. I'd appreciate it if we could lean on the example when discussing pros and cons of the various proposals, as well as when demonstrating equivalent Rust code, as that will help me provide better feedback. Cheers, Josh ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
Nope; we can't use casts of enum values in type signatures. This is discussed in https://github.com/mozilla/rust/issues/5873 . Cheers, Josh On 24 March 2014 11:26, Patrick Walton pcwal...@mozilla.com wrote: On 3/24/14 2:45 AM, Richo Healey wrote: I get a compile error: src/repository.rs:24:17: 24:54 error: expected constant expr for vector length: non-constant path in constant expr src/repository.rs:24 cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; This seems to me like it should work. The value of that enum is a compile and (if I'm reading the docs surrounding enums correctly) run time constant. Can you use `[GitCvarValue, ..GIT_CVAR_CACHE_MAX as uint]`? Patrick ___ 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] Refactor json.rs
Whoops, excluded the mailing list.
On 22 March 2014 11:53, Edward Wang edward.yu.w...@gmail.com wrote:
`to_encode_object` has type `EncodableEncoder'a` so
`to_encode_object.encode(...)`
requires an Encoder instance with lifetime 'a, the one defined in the
struct bound.
The problem I think is that I can't write:
pub fn buffer_encodeT:Encodable_(to_encode_object: T) - ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
and ask rustc to infer a proper type parameter. That would be global
inference.
-Ed
On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews j...@joshmatthews.netwrote:
m here is merely a local variable but Encoder'a requires a lifetime at
least 'a
This statement does not make sense to me. Why does m's lifetime not
satisfy the requirement?
Cheers,
Josh
On 22 March 2014 10:24, Edward Wang edward.yu.w...@gmail.com wrote:
Hi,
I'm in the process of fixing a `ty_trait` variance inference bug, which
will void the following code in json.rs:
pub struct Encoder'a {
priv wr: 'a mut io::Writer,
priv error: io::IoResult(),
}
impl'a Encoder'a {
pub fn new'a(wr: 'a mut io::Writer) - Encoder'a {
Encoder { wr: wr, error: Ok(()) }
}
pub fn buffer_encodeT:EncodableEncoder'a(to_encode_object: T)
- ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
}
If taking a close look, m here is merely a local variable but
Encoder'a requires a lifetime at least 'a. A naive fix would be:
let mut encoder = Encoder::new(cast::transmute_mut_region(mut m));
But of course, it is very uncivilized :) Any suggestion on how to
refactor this piece of code so it won't violate the lifetime requirement?
Regards,
Edward
___
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] Virtual fn is a bad idea
Is the 'all nodes consuming same amount of memory' too much memory?
Unfortunately yes, this is a very big problem. This solution has been
discussed in the past, but some of the elements types necessarily contain
far more members than others, and this would absolutely destroy memory
usage in the face of competing browsers.
Cheers,
Josh
On 12 March 2014 05:24, Maciej Piechotka uzytkown...@gmail.com wrote:
Recently I saw a video of person from scala team who regretted some
'pragmatic' choices in long run so I might be still under it's
impression regarding pragmatic choices in a language. Fortunately (or
unfortunately) I'm not in charge of Rust design.
Also last question - why not use:
struct Element {
//... element specific elements
}
struct Attribute {
//... attribute specific elements
}
enum NodeChild {
NodeAttribute(Attribute),
NodeElement(Element)
}
struct Node'r {
parent: 'r Node,
first_child: 'r Node,
last_child: 'r Node,
next_sibling: 'r Node,
last_sibling: 'r Node,
node: NodeChild
}
For static types:
struct Element'r {
elem: 'r Node
}
pub fn downcast_to_element'r(node: 'r Node) - OptionElement'r {
match (node.node) {
NodeElement(_) - Some(Element {elem: node}),
_ - None
}
}
+ impl with potentially partial methods? Is the 'all nodes consuming
same amount of memory' too much memory?
1. One word pointers - check
2. Access to fields - check
3. Downcasting and upcasting - check
4. Inheritance with prefix property - check (sort of)
5. No need for behind-the-back optimization - check
-. static dispatch (check) at the cost of match instead of jump with all
its pros and cons
Best regards
On Tue, 2014-03-11 at 19:47 -0700, Patrick Walton wrote:
I thought about tricks like this, but (a) a sufficiently smart
compiler should *not* be doing this automatically, as it makes certain
common operations like fetching the pointer more expensive as well as
violating the principle of least surprise when it comes to machine
representation, and (b) does this sort of hack really result in a
cleaner design than having some simple language extensions? Mind you,
I'm all about ways to simplify Rust, but sometimes the simplest
solution is to build stuff into the language.
On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka
uzytkown...@gmail.com wrote:
On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a
few times but I haven't
seen any details. I wrote simple bindings to
libxml2 dom
(https://github.com/uzytkownik/xml-rs -
warning - I wrote it while I was
learning ruby) and I don't think there was a
problem of OO - main
problem was mapping libxml memory management
and rust's one [I gave up
with namespaces but with native rust dom
implementation it would be
possible to solve in nicer way]. Of course - I
might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every
DOM node has 5
pointers inside (parent, first child, last child, next
sibling, previous
sibling). Using trait objects would 10 words, not 5
words, and would
constitute a large memory regression over current
browser engines.
2. Access to fields common to every instance of a trait
without virtual
dispatch. Otherwise the browser will be at a
significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for
(2).
If anyone has alternative proposals that handle these
constraints that
are more orthogonal and are pleasant to use, then I'm
happy to hear
them. I'm just saying that dismissing the feature out
of hand is not
productive.
Patrick
Ok. I see where my misunderstanding was - I was thinking
about DOM
implementation in Ruby for Ruby while you (Mozilla) were talking
about
implementation in Ruby for JavaScript.
Please feel free to ignore next paragraph as I haven't given it
much
though but my guess would be that it would be possible to avoid
the
penalty by enum + alignment + smart compiler. As data have 6
words + in
your scheme (5 described + vtable) the 4 bit alignment (assuming
32+ bit
platform) should not cause much memory waste. This allows for
using the
Re: [rust-dev] Compile-time function evaluation in Rust
Out of that list of requirements, #5 (doesn't perform I/O actions) is the
one that strikes me as least well-defined. Could you elaborate on how you
would enforce it?
Cheers,
Josh
On 28 January 2014 14:15, Pierre Talbot ptal...@hyc.io wrote:
Hi,
The Mozilla foundation proposes research internships [1] and the CTFE
optimization in the Rust compiler seems to be a really exciting project. I
wrote a proposal [2] that I'll send with my application and so I'd like to
share it with you and discuss about bringing CTFE inside Rust.
Here a non-exhaustive summary of key points in my proposal.
First of all, we need to establish when CTFE is triggered, I found two
contexts (denoted as a hole []):
* Inside a immutable static variable (static ident ':' type '=' [] ';').
* In a vector expression ('[' expr ',' .. [] ']').
Next in a similar way than with inline attributes we might want to add
these new attributes:
* #[ctfe] hints the compiler to perform CTFE.
* #[ctfe(always)] asks the compiler to always perform CTFE resulting in a
compiler error if it's impossible.
* #[ctfe(never)] asks the compiler to never perform CTFE resulting in a
compiler
error if this function is called in a CTFE context.
The rational behind this is that some functions might want to disallow
CTFE, for example if they manipulate machine-dependent data (such as
playing with endianness). Some might want to be designed only for
compile-time and so we want to disable run-time execution. Finally others
might hints the compiler to try to optimize whenever you can, of course
if the function contains infinite loop for some input, the compilation
might not terminate.
I propose some requirements on function eligible for CTFE (see the
proposal for references to the Rust manual):
1. Its parameters are evaluable at compile-time.
2. It isn't a diverging function.
3. It isn't an unsafe function.
4. It doesn't contain unsafe block.
5. It doesn't perform I/O actions.
6. The function source code is available to the compiler. It mustn't be in
an external
block, however it can be an extern function.
In this proposal, you'll also find a pseudo-coded algorithm, related work
(in D and C++), and much more :-)
If you have any suggestions or corrections, do not hesitate. Also, feel
free to ask questions.
Regards,
Pierre Talbot
[1] https://careers.mozilla.org/en-US/position/oZO7XfwB
[2] http://hyc.io/rust-ctfe-proposal.pdf
___
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] any tips and tricks for faster compilation of compiler itself?
I recommend 'make rustc-stage1' to ensure that your changes build, then 'make check-stage1' to run tests like compile-fail/run-fail/run-pass. Cheers, Josh On 27 November 2013 22:37, Ömer Sinan Ağacan omeraga...@gmail.com wrote: Hello everyone, I'm trying to make some changes on the Rust compiler(and I'll hopefully open some pull requests) but I'm suffering from incredibly long compilation times. I know some part of it is related with my computer but I don't have anything to do about that for now, so I'm looking for tips and tricks to make compilation of compiler itself faster on same hardware. Any helps would be really appreciated, currently one line of trivial change takes literally 5+ minutes to compile on my system. 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] list of all reserved keywords of the language
http://static.rust-lang.org/doc/master/rust.html#keywords Cheers, Josh On 19 November 2013 17:06, Gaetan gae...@xeberon.net wrote: hello Where can I find an exhaustive list of the keywords defined by the language? I want to add basic syntax highlighting support to the rust language to some web editors and I don't know all of them yet. Thanks. - Gaetan ___ 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] autotrace
Please note that Michael Woerister's work this summer on debug symbols has
been wildly successful, and it's worth giving it another shot before
looking into further compiler hacking:
http://michaelwoerister.github.io/2013/09/27/what-you-call-the-present.html
Cheers,
Josh
On 30 September 2013 14:00, Jason E. Aten j.e.a...@gmail.com wrote:
I was very frustrated by the lack of debug-info at the gdb prompt during
rust coding recently. I note too that people on #rust complain about the
lack of visibility into debugging rustc itself.
I think there is a lightweight, quick to implement, solution to these
problems.
I have in mind a simple facility provided by a compiler flag that injects
(logging-controlled) printf or tracing-log statement at the top and bottom
of every function. Something like:
// example:
fn fun1(a:int, b:str, c:HashMap~str, int) - HashMap~str,int {
c.insert(a,b)
}
// would effectively become, with rustc --autotrace enabled:
fn fun1(a:int, b:str, c:HashMap~str, int) {
// intro
if (global_tracking_flag) {
stack_depth = stack_depth + 1;
trace!(%s call fun1(%?, %?, %?),
indent_spaces_according_to_stack_depth(), a, b, c);
}
c.insert(a,b);
// outro : would have to be like a destructor, that is called on every
return path...
if (global_tracking_flag) {
trace!(%s return from fun1 - %?,
indent_spaces_according_to_stack_depth(), c);
stack_depth = stack_depth - 1;
}
}
Although not without cost, the --autotrace facility could even be highly
useful for runtime monitoring (and therefore better/faster/cheaper than
comprehensive debug-info). The idea being that it would be cheap enough
(surely global_tracking_flag could be persuaded to live in a register, no?)
that it could be left compiled into most non-inlined function, and
activated at runtime without bringing a production system down.
Related experience Justin Sheehy at Basho talks about how Erlang's
runtime monitoring facilities were under-appreciated when they started.
Many other features that we didn’t understand the full importance of at
the time (such as the ability to inspect and modify a live system at
run-time with almost no planning or cost) have also helped us greatly in
making systems that our users and customers trust with their most critical
data. http://basho.com/erlang-at-basho-five-years-later/
Thoughts? Is --autotrace a viable idea at all?
Jason
___
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] Out of -Z flags
We could free one up by moving basic debug-info back into the -g flag. Now that we have automated tests, it's a lot less likely to get busted and frustrate people. On 3 September 2013 14:34, Corey Richardson co...@octayn.net wrote: Right now Z flags are implemented using a bit flag stored in a uint, which is only reliably 32 bits on the platforms we use. We could extend it to a u64, or we could use an enum, but we can't continue doing this, because https://github.com/mozilla/rust/pull/8955 uses the last available bit. ___ 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] Bus error: 10
That's covered by
https://github.com/mozilla/rust/issues/4363https://github.com/mozilla/rust/issues/4363in
the issue tracker.
Cheers,
Josh
On 28 August 2013 19:39, Amitava Shee amitava.s...@gmail.com wrote:
I am getting a Bus error - please see the following.Should I file this as
an issue in github?
amitava:learn amitava$ cat app.rs
// vi:ts=4:sw=4:nu
fn main() {
// should not compile - infinite size, needs redirection
struct Foo {
child: OptionFoo
};
let c = Foo {child: None};
let p = Foo {child : Some(c) };
//printfln!(%?, p);
}
amitava:learn amitava$ make
rustc -Z debug-info -o app app.rs
app.rs:10:5: 10:6 warning: unused variable: `p` [-W unused-variable
(default)]
app.rs:10 let p = Foo {child : Some(c) };
^
make: *** [app] Bus error: 10
amitava:learn amitava$ rustc --version
rustc 0.8-pre (da96b3e 2013-08-28 14:15:37 -0700)
host: x86_64-apple-darwin
amitava:learn amitava$ uname -a
Darwin amitava.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1
17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
Thanks Regards,
Amitava
___
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] Summer of Code 2013: Rust Debug Symbol Generation
On 29 May 2013 17:00, Wojciech Matyjewicz wmatyjew...@fastmail.fm wrote: The other benefit is that DIBuilder keeps track of what metadata nodes it has generated and reuses the existing nodes instead of generating identical ones --- similar functionality from debuginfo.rs could be removed then. I don't think this is quite correct. LLVM merges identical metadata nodes without any outside intervention. The metadata cache in debuginfo.rs is strictly a performance optimization. Cheers, Josh ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [GSoC 2013] May I ask some questions about the Rust debugging symbols idea ?
Hi Greg, These questions are fine. The key point you're missing in the existing debug code is that most of the functions in debuginfo.rs are called from within functions like create_local_var. I just realized that I linked to the potentially outdated version of the file on the master branch; https://github.com/mozilla/rust/blob/incoming/src/librustc/middle/trans/debuginfo.rsis the more interesting one as it shows how some of the other functions are called in create_ty. The actual API of debuginfo.rs from the point of view of the rest of rustc is quite limited; the rest of the compiler is usually only concerned with marking high-level constructs such as variables, functions, files, and line numbers. To answer your question, yes, the primary work of the project would be to finish the obvious gaps in the existing code in debuginfo.rs (such as the unimplemented types in create_ty) and create tests that exercise them all thoroughly. From there, the goal is to get rustc itself building with full debug symbols. The `-Z extra-debug-info` argument was put in place because the debug symbol generation was incomplete, and we hide incomplete things behind -Z flags. Once we expect debug symbol generation to work for arbitrary programs, we'll fold extra-debug-info into the existing -g flag. Cheers, Josh On 22 April 2013 10:22, Greg Weng snowma...@gmail.com wrote: Sorry if I seemed too rude to ask these questions here... 1. The `debuginfo.rs` seems already implemented some LLVM debugging symbols outputting functions, like `create_vec` or `create_local_var`. But currently I can only find `create_local_var` already been used in other components, and others are missing. So, should the first step be generating LLVM debugging information in every language unit while compiling them ? 2. The Rust compiler owns the `-Z extra-debug-info` option, but it didn't work and seems related to the not yet implemented debugging symbol feature. Is this option created for outputting all language units' LLVM debugging information ? Or it's expected to do more things than this ? 3. I've did some researching works on Rustc and LLVM debugging symbol features, and will start to try to add those outputting function in other components. Is any other step should I take to prepare the project ? Greg Weng snowma...@gamil.com ___ 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] FastCGI implementation
There's a very basic POSIX socket binding at https://github.com/jdm/rust-socket. It's been neglected for a bit, I would quickly merge a PR to update it to 0.6. Cheers, Josh On 8 April 2013 02:14, Andres Osinski andres.osin...@gmail.com wrote: Are the libUV bindings for the socket API the default canonical way in Rust for managing socket communications, or will there be a future implementation or binding to the standard POSIX socket library? On Sat, Apr 6, 2013 at 1:50 PM, Thad Guidry thadgui...@gmail.com wrote: oops, that should have been the handler portion of Cherokee FastCGI ... https://github.com/cherokee/webserver/blob/master/cherokee/handler_fcgi.c more docs here: http://www.cherokee-project.com/doc/modules_handlers_fcgi.html On Sat, Apr 6, 2013 at 11:45 AM, Thad Guidry thadgui...@gmail.comwrote: Perhaps the Cherokee webserver might be useful for you to look at it's codebase... and it's implementation of fastcgi.h https://github.com/cherokee/webserver/tree/master/cherokee On Fri, Apr 5, 2013 at 9:13 PM, Andres Osinski andres.osin...@gmail.com wrote: Hi everyone, I've taken an interest in Rust as it fills a niche in programming that I've long been looking to fullfill. I'm primarily a Python web developer, so I wanted to start coding by implementing the FastCGI protocol for Rust. I know that its native task management and socket capabilities are very good, but you never know when it might be handy for someone. I just wanted to know if anyone was familiar with the FCGI protocol, and if there's any reference as to how to manage the packing and unpacking of C data structures, as well as if you know of any implementation for a similar protocol. One small question that I have is that FCGI protocol defines a struct with two char arrays whose length is defined by another field within the struct, and I was wondering how that would be modeled in Rust. Thanks -- Andrés Osinski ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad http://www.freebase.com/view/en/thad_guidry -- -Thad http://www.freebase.com/view/en/thad_guidry -- Andrés Osinski http://www.andresosinski.com.ar/ ___ 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
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
