On Tue, Oct 23, 2012 at 6:10 PM, Patrick Walton pwal...@mozilla.com wrote:
Something like 'x'u8 perhaps?
That would suit my use case.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
Rust-dev mailing list
Rust-dev@mozilla.org
On Tue, Oct 23, 2012 at 5:35 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
Because of the special treatment of `for` loops in Rust, I'd need a more
specific example of what you're trying to do.
Looping over a part of an array by index and moving on immediately
when a “not interested”
Hi,
I'm starting with rust, although I've been looking inside for a while its
the first time I try writing real rust code.
So, I pulled from master yesterday and wrote this simple server
http://pastebin.com/MMiNpXYG
No tasks, no concurrency, a single-threaded, single-tasked server, that to
my
On 24 October 2012 08:41, arkai...@gmail.com arkai...@gmail.com wrote:
AFAIK, rust is not going to support traditional socket handling, everything
is going to go over libuv, is this statement correct?
Rust will (and already does) support blocking IO, it just won't try to
automatically make it
Hi,
On Wed, Oct 24, 2012 at 11:50 AM, Lucian Branescu lucian.brane...@gmail.com
wrote:
On 24 October 2012 08:41, arkai...@gmail.com arkai...@gmail.com wrote:
AFAIK, rust is not going to support traditional socket handling,
everything
is going to go over libuv, is this statement correct?
On 24 October 2012 10:52, arkai...@gmail.com arkai...@gmail.com wrote:
On 24 October 2012 08:41, arkai...@gmail.com arkai...@gmail.com wrote:
AFAIK, rust is not going to support traditional socket handling,
everything
is going to go over libuv, is this statement correct?
Rust will (and
I think you'd get back the same situation as in C with a scheduler
that ran each task in its own thread, or at least that's what I was
told.
On 24 October 2012 16:58, Glenn Willen gwil...@nerdnet.org wrote:
Well, it's worse than that I think? You will have far more than the usual
problems of
That sounds about right, yes. (That's just not the scheduler that exists now.
And this is the first I've heard of the idea that Rust might get such a
scheduler, although it seems like a useful thing to have.)
Glenn
On Oct 24, 2012, at 9:13 AM, Lucian Branescu wrote:
I think you'd get back
See times, timesi (implemented for uint and int), and int::range (i.e., these
all already exist)
On Oct 24, 2012, at 11:23 AM, Dave Halperin wrote:
Python doesn't have c style for loops and the way you'd do this is use xrange
to create an iterator over a range of numbers, then use a high
It's an interesting
question. I am not sure whether "most" functions can be pure under the
definition I gave in that blog post, but likely a great many.
There is also some question of whether we should have purity at all.
pcwalton and I have been thinking about an alternative which would
See the section of the tutorial on for and do - they are desugared to use
functions of that sort (i.e., the body is a closure which is the last parameter
of the function used).
The following code compiles:
fn main() {
for 5.timesi |i| {
if i % 2 == 0 {
loop;
}
On Wed, Oct 24, 2012 at 9:49 AM, Niko Matsakis n...@alum.mit.edu wrote:
It's an interesting question. I am not sure whether most functions can
be pure under the definition I gave in that blog post, but likely a great
many.
There is also some question of whether we should have purity at all.
On 10/24/12 11:51 AM, Nathan wrote:
Therefore I'd propose that the purity keyword must be present and match
the purity inference in every context where a type signature must be
present to match the type inference.
-1 on this. I think that it's often quite useful to reserve the right to
make a
On 10/24/2012 12:41 AM, arkai...@gmail.com wrote:
Hi,
I'm starting with rust, although I've been looking inside for a while
its the first time I try writing real rust code.
So, I pulled from master yesterday and wrote this simple server
http://pastebin.com/MMiNpXYG
No tasks, no concurrency, a
Hi
On Wed, Oct 24, 2012 at 9:11 PM, Brian Anderson bander...@mozilla.comwrote:
For reference, here is the server test case in net::tcp:
https://github.com/mozilla/**rust/blob/incoming/src/libstd/**
net_tcp.rs#L1560https://github.com/mozilla/rust/blob/incoming/src/libstd/net_tcp.rs#L1560
In
Patrick
I think what you're saying -1 on here is some kind of purity inference?
That doesn't seem to be what was proposed, though.
In fact, I *believe* Nathan's point was merely that it's useful
sometimes to document "purity" in order to express the intention of the
API, and that in those
The problem with modes was
not that they were trying to push low-level decisions onto the
developer. In contrast, they were trying to hide low-level decisions,
but they did an imperfect job. As a result, it was particularly
confusing when mismatches between things like ++, +, and
modes would
Patrick Walton wrote:
Oh, in that case I totally agree. I thought Nathan was asking for the
purity specified in the function signature to always match the
inferred purity of the function--in particular, for the compiler to
enforce that a pure function is never marked impure. That was what I
On Wed, Oct 24, 2012 at 2:05 PM, Patrick Walton pwal...@mozilla.com wrote:
Oh, in that case I totally agree. I thought Nathan was asking for the
purity specified in the function signature to always match the inferred
purity of the function--in particular, for the compiler to enforce that a
Thanks. I wasn't so much looking to make a DSL as I was making a code
generator that spits out Rust code. It could be called and executed at
runtime, or spit out code to stdout or to a file for later compilation. I
just don't know how practical it is to build a big string and then inject
it into
20 matches
Mail list logo
