On Dec 19, 2013, at 11:23 AM, Gábor Lehel wrote:
> - From a semantic perspective the only distinction is between bounded and
> unbounded queues. The capacity of a bounded queue only makes a difference
> with regards to performance.
While this may be true in most cases, I can come up with ways
and statically allocating a gigantic
> channel buffer are orthogonal issues. You can bound a linked list.
Correct, but my understanding is that Go's channels do allocate the buffer up
front.
-Kevin
> On Thu, Dec 19, 2013 at 1:23 PM, Kevin Ballard wrote:
> Here’s an example from
On Dec 19, 2013, at 10:38 AM, Matthieu Monrocq
wrote:
> Furthermore, it is relatively easy to build an unbounded channel over a
> bounded one: just have the producer queue things. Depending on whether
> sequencing from multiple producers is important or not, this queue can be
> either shared
On Dec 19, 2013, at 10:25 AM, Matthieu Monrocq
wrote:
> On Thu, Dec 19, 2013 at 7:23 PM, Kevin Ballard wrote:
> Here’s an example from where I use an infinite queue.
>
> I have an IRC bot, written in Go. The incoming network traffic of this bot is
> handled in one goroutin
Here’s an example from where I use an infinite queue.
I have an IRC bot, written in Go. The incoming network traffic of this bot is
handled in one goroutine, which parses each line into its components, and
enqueues the result on a channel. The channel is very deliberately made
infinite (via a s
On Dec 18, 2013, at 10:49 PM, Daniel Micay wrote:
> On Thu, Dec 19, 2013 at 1:23 AM, Kevin Ballard wrote:
>> In my experience using Go, most of the time when I use a channel I don't
>> particularly care about the size, as long as it has a size of at least 1 (to
>>
send is the default, which I think is a good idea.
-Kevin
On Dec 18, 2013, at 9:36 PM, Patrick Walton wrote:
> On 12/18/13 8:48 PM, Kevin Ballard wrote:
>
>> By that logic, you'd want to drop the oldest unprocessed events, not the
>> newest.
>
> Right.
>
>
On Dec 18, 2013, at 7:55 PM, Nathan Myers wrote:
> On 12/18/2013 07:07 PM, Patrick Walton wrote:
>> (dropping messages, or exploding in memory consumption, or
>> introducing subtle deadlocks) are all pretty bad. It may well
> > be that dropping the messages is the last bad option, because
>> the
That's cute, but I don't really understand the point. The sample program he
gave:
test() ->
Pid = spawn(fun universal_server/0),
Pid ! {become, fun factorial_server/0},
Pid ! {self(), 50},
receive
X -> X
end.
will behave identically if you remove universal_server from
than `use
crate foo`.
-Kevin
On Dec 17, 2013, at 12:19 PM, Kevin Ballard wrote:
> In today's meeting[1], it appears as though `extern mod foo` may become `use
> crate foo`. I have a minor worry about this, which is reserving yet another
> keyword for a very limited usage.
In today's meeting[1], it appears as though `extern mod foo` may become `use
crate foo`. I have a minor worry about this, which is reserving yet another
keyword for a very limited usage. My general feeling is we shouldn't be adding
keywords unnecessarily, especially if their scope is extremely l
On Dec 17, 2013, at 11:37 AM, Stefan Plantikow
wrote:
> Hi,
>
> Am 17.12.2013 um 20:10 schrieb Corey Richardson :
>
>> On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
>> wrote:
>>> Hi,
>>>
>>>
>>> Am 09.12.2013 um 16:53 schrieb Damien Radtke :
>>>
I have no idea if it would be feasi
My belief is that a generic interface to DBs is only useful because that way
you can write other DB-driven libraries that don't care about the details of
the DB. I don't think I've ever seen code in the wild that uses this
functionality though (although, admittedly, I haven't looked at a lot of
On Dec 9, 2013, at 7:19 PM, Corey Richardson wrote:
> - `Path::new` has been [renamed](https://github.com/mozilla/rust/pull/10796)
> back to `Path::init`.
Other way around. `Path::init` has been renamed back to `Path::new`, along with
extra::json and std::rt::deque
-Kevin
smime.p7s
Descriptio
`do` no longer works with stack closures. It now only works with the new proc()
type, which basically means you're only going to see it used with spawn().
You need to now say something like
let rc = endpoint.with_c_str(|cstr| {
unsafe {smq_bind(self.sock, cstr)}
});
I can't spec
On Dec 4, 2013, at 12:23 AM, Patrick Walton wrote:
> Yes, but I wouldn't worry about this restriction biting users of your
> structure too much. Rust data structures rarely ever store non-static
> references in them, as the stack discipline that references must follow is
> fairly limited. (I c
On Dec 3, 2013, at 12:07 PM, David Piepgrass wrote:
> > David Piepgrass wrote:
> > > Okay, well, I've never liked mailing lists at all, because:
> > >
> > > 1. In non-digest mode, My inbox gets flooded.
> > > 2. In digest mode, it's quite inconvenient to write a reply, having to
> > > cut out al
ister
> wrote:
> +1 for `expr @ place`
>
>
> On 02.12.2013 11:57, Kevin Ballard wrote:
> With @ going away another possibility is to leave ~ as the normal allocation
> operator and to use @ as the placement operator. So ~expr stays the same and
> placement looks either
nter sigil.
>
> Patrick Walton wrote:
> Still too punctuation heavy.
>
> Kevin Ballard wrote:
> What do you mean? This suggestion uses @ as an operator, not as a sigil.
>
> -Kevin
>
> On Dec 2, 2013, at 10:23 AM, Patrick Walton wrote:
>
>> Anything with
What do you mean? This suggestion uses @ as an operator, not as a sigil.
-Kevin
On Dec 2, 2013, at 10:23 AM, Patrick Walton wrote:
> Anything with @ feels like it goes too close to pointer sigils for my taste.
>
> Patrick
>
> spir wrote:
> On 12/02/2013 11:57 AM, K
On Dec 2, 2013, at 8:29 AM, Paul Nathan wrote:
> On 12/2/13 8:21 AM, David Piepgrass wrote:
>> Hey, why not set up a Discourse forum? That would be so. much. better.
>> than a mailing list. As an OSS dev I've been itching to get one myself,
>> but don't have time or much money to set it up. For M
With @ going away another possibility is to leave ~ as the normal allocation
operator and to use @ as the placement operator. So ~expr stays the same and
placement looks either like `@place expr` or `expr@place`
-Kevin Ballard
___
Rust-dev mailing
I think `box expr in place` is unnecessarily verbose. I also don't think
`box(place) expr` will be confusing in practice, because it will presumably
look something like `box(Gc) expr`, which should be pretty obvious that Gc is
how it's being boxed, not what's being boxed.
-Kevin
> On Dec 2, 20
On Nov 30, 2013, at 7:54 PM, Daniel Micay wrote:
> On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard wrote:
>> On Nov 30, 2013, at 7:28 PM, Patrick Walton wrote:
>>
>>> On 11/30/13 7:25 PM, Michael Letterle wrote:
>>>> I've got to say that
On Nov 30, 2013, at 7:28 PM, Patrick Walton wrote:
> On 11/30/13 7:25 PM, Michael Letterle wrote:
>>I've got to say that the "do" syntax is one of the things that
>>appeals to me about Rust, and will probably appeal to the people
>>that Steve Klabnik is drawing to the language with Ru
I'm still very much a fan of leaving ~ as the allocation operator. Despite what
Patrick says, I'm pretty sure the reason why users are confused about it is
purely due to sub-par documentation, and not due to any actual inherent
problems with using a non-alphabetic symbol as an operator. Heck, we
On Nov 30, 2013, at 10:20 AM, Patrick Walton wrote:
> On 11/30/13 10:05 AM, Kevin Cantu wrote:
>> While we're changing this stuff, I'd like to see lambdas allow return,
>> now that the need for forbidding that is gone, IIRC. That's more likely
>> to continually trip me up than unusual allocation
On Nov 30, 2013, at 10:02 AM, Patrick Walton wrote:
> I don't agree in general that the right solution for every problem that can
> be solved through the type system is in the type system. Every type system
> feature has a cost; when something can be done via what's already present in
> the la
On Nov 30, 2013, at 1:07 AM, David Rajchenbach-Teller
wrote:
> On 11/30/13 10:01 AM, Kevin Ballard wrote:
>> `new` isn't self-documenting. It's merely consistent with C++, but
>> consistency with C++ cannot be considered self-documentation because
>> there are a g
to
> borrow a term from linguistics. Besides, they were a very frequent source of
> confusion. Documentation is good, but being self-documenting is better.
>
> Patrick
>
> Kevin Ballard wrote:
> On Nov 29, 2013, at 11:26 PM, Patrick Walton wrote:
>
>> There's also
is too verbose, but `new(Unique)` isn't?
> Looking like C++ is a goal of Rust, in any case...
I thought C++ performance was a goal. Since when is C++ syntax considered to be
a goal?
-Kevin
> Patrick
>
> Kevin Ballard wrote:
> As I said in the IRC channel, the reason why u
ese look like allocation.
>
> Patrick
>
> Kevin Ballard wrote:
> I am very saddened by the fact that we're apparently reserving `new` as a
> keyword, and even more by the fact that the proposed placement new syntax is
> `new(foo) bar`. This looks exactly like C++, and it go
I am very saddened by the fact that we're apparently reserving `new` as a
keyword, and even more by the fact that the proposed placement new syntax is
`new(foo) bar`. This looks exactly like C++, and it goes against the strong
precedence we already have of using new() as a static function for ty
ori when writing the code) -- it would be good
> to get some clarity on this.
>
> Thanks,
> Ashish
>
>
> On Fri, Nov 29, 2013 at 10:20 PM, Kevin Ballard wrote:
>> If you're willing to use unsafe code and std::unstable, you can do it.
>>
>>
If you're willing to use unsafe code and std::unstable, you can do it.
use std::num::Zero;
use std::unstable::intrinsics;
enum Constants {
SZ = 2
}
struct Foo([T, ..SZ]);
impl Foo {
pub fn new() -> Foo {
let mut ary: [T, ..SZ];
unsafe {
ary = intrinsics::unin
On Nov 20, 2013, at 6:21 PM, Ziad Hatahet wrote:
> On Wed, Nov 20, 2013 at 5:58 PM, Tommi wrote:
> Here's why: if you make a call foo(arg) and never use arg after that, then
> you don't care if arg gets moved or borrowed. And if you try to use arg
> afterwards and foodid in fact move it previo
On Nov 20, 2013, at 8:52 AM, Corey Richardson wrote:
> I do, and I agree a lot with Niko's arguments from the meeting. I
> agree that &* is a bit ugly, but I prefer the ugly syntax to the
> ambiguity. I don't find Kevin's argument particularly convincing;
> those changes can make your code fail t
In general, I’m not a fan of &*, and I like auto-borrowing (autoref sounds like
it turns T into &T, not ~T into &T). I understand the arguments to get rid of
it though.
BTW, you said that the current proposal still includes autoref for function
invocation. That sounds to me like autoref would s
On Nov 19, 2013, at 3:08 AM, Daniel Micay wrote:
> I wouldn't mind not having `~T` in the language at all, but am not
> really opposed to including it because there's no harm. Choosing to
> special-case arbitrary non-trivial data structures like vectors and
> reference counted boxes *is* harmful
Is that really why, or are you just guessing? I'm assuming the real reason is
that people are used to languages where heap allocation is common and stack
allocation rare or nonexistant, and don't understand why boxing everything is a
bad idea. In other words, it's a problem that a proper tutori
I was initially concerned, like you, about putting such generic-sounding
libraries in /usr/local/lib, but of course that’s not the full name. On the
current machine (whose rust is slightly out of date, so this may not match the
name you have), libstd is actually
/usr/local/lib/libstd-6c65cf4b44
On Nov 13, 2013, at 3:56 PM, Daniel Micay wrote:
> On Wed, Nov 13, 2013 at 6:21 PM, David Rajchenbach-Teller
> wrote:
>> On Thu Nov 14 00:10:27 2013, Daniel Micay wrote:
The only problem is that Linux doesn't really support asynchronously
resolving file paths to inodes (aka opening fil
On Nov 12, 2013, at 10:26 PM, Kevin Ballard wrote:
> And even that restriction could be lifted if ~Trait objects could be
> represented using an array of pointers (one to each inherited struct), e.g.
> ([*A,*B,*C],*vtable) instead of just (*A,*vtable), though I suspect this is
&g
On Nov 12, 2013, at 9:01 PM, Patrick Walton wrote:
> On 11/13/13 12:18 PM, Kevin Ballard wrote:
>> The only penalty this approach has (that comes to mind) over the
>> single-inheritance model is that, because of the loss of the prefix
>> property, any field access on the tra
On Nov 12, 2013, at 1:22 PM, Patrick Walton wrote:
> On 11/13/13 3:57 AM, Kevin Ballard wrote:
>> On Nov 11, 2013, at 11:43 PM, Patrick Walton > <mailto:pcwal...@mozilla.com>> wrote:
>>
>>> We considered Go's anonymous fields but rejected them because
or implementing bindings to a C
> function (all intermediate C allocations are leaked).
>
> Does that make sense? It may not quite answer your question, but
> hopefully that clears up at least a little bit about how it's
> implemented today.
>
> On Tue, Nov 12, 2013 at 11:
Right now, Rust does not support catching task failure from within a task, it
only supports preventing task failure from cascading into other tasks. My
understanding is that this limitation is done because of safety; if a task
unwinds through a few frames of code, and then stops unwinding, data
On Nov 11, 2013, at 11:43 PM, Patrick Walton wrote:
> We considered Go's anonymous fields but rejected them because they don't
> support virtual methods at the same time as field embedding.
I don’t follow. Why do Go’s anonymous fields not support virtual methods at the
same time as field embed
On Nov 8, 2013, at 9:38 PM, Daniel Micay wrote:
> On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote:
> On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote:
>
> > I know that many people don't like the fact that, syntactically, vectors
> > and strings have a sigil in
On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote:
> I know that many people don't like the fact that, syntactically, vectors and
> strings have a sigil in front of them, but please consider that there are
> many design constraints here. What works for another language may not work
> for Rust,
On Nov 1, 2013, at 12:59 PM, Marvin Löbel wrote:
> Maybe a abbreviation of variant would work:
>
> - `ok_var()` and `err_var()`
>
> Seems to read nice at least:
>
> ~~~
> res.ok_var().get();
> res.err_var().get();
> res.err_var().expect("...");
> ~~~
"var" here makes me think "variable".
My
The path module was rewritten in between 0.8 and master. The documentation you
are looking at only applies to master. I would strongly encourage you to
upgrade.
Anyway, as long as you're using 0.8, the correct documentation is
http://static.rust-lang.org/doc/0.8/std/path/index.html.
-Kevin
On
On Oct 21, 2013, at 9:11 AM, Corey Richardson wrote:
> On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton wrote:
>> This seems generally on the right track. A couple of thoughts:
>>
>> * I can pretty much guarantee you that that simple of a static analysis to
>> determine stack size is going to f
On Oct 18, 2013, at 11:14 AM, Daniel Micay wrote:
> On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt wrote:
> In the latest Rust upgrade for Servo, I noticed that the path API is
> now mutate-in-place instead of return a new path. It used to be that
> path.push("foo") gave you a new path with an e
The new Path API still has a "return a new path" set of APIs. They're just
named differently. For example, the old path.push("foo") is now
path.join("foo"). And all the path.set_*() mutating methods have variants
path.with_*() that return a new path.
-Kevin
On Oct 18, 2013, at 9:09 AM, Jack Mo
This seems rather heavy-weight to me. I’d much prefer if such a thing was
opt-in, e.g. by a function attribute that says the return value must be handled.
-Kevin
On Oct 16, 2013, at 2:12 PM, Patrick Walton wrote:
> On 10/16/13 1:44 PM, Bill Myers wrote:
>> What about the idea of making Result
+1 here too. I agree with what Alex said about conditions. They're useful for
when you can actually recover from the error gracefully, but for generic error
reporting they're kind of a PITA.
-Kevin
On Oct 16, 2013, at 11:16 AM, Patrick Walton wrote:
> On 10/16/13 11:02 AM, Alex Crichton wrote
As a Mac developer, you should have Xcode 5.0 installed, which comes with Clang
5.0 (based on LLVM 3.3svn), which is roughly equivalent to open-source Clang
3.3.
-Kevin
On Sep 27, 2013, at 8:51 PM, KENZ gelsoft wrote:
> I tried rust-bindgen finally, and it worked excellently. Great work!!
>
On Sep 25, 2013, at 2:58 PM, Jack Moffitt wrote:
Miss it? Did it ever work? This seems like a bug though. Mutability is
inherited, so without this there's no way to do mutable destructuring
bind right?
>>> Apparently it went away in commit f9b54541 and the workaround used there
>>>
On Sep 25, 2013, at 2:42 PM, Benjamin Herr wrote:
> On Wed, 2013-09-25 at 15:23 -0600, Jack Moffitt wrote:
>>> (I miss `let mut (a, b) = ...`!)
>>
>> Miss it? Did it ever work? This seems like a bug though. Mutability is
>> inherited, so without this there's no way to do mutable destructuring
>>
Maybe we should just implement AdditiveIterator on &A as well? That way you can
just say `values.iter().sum()`.
-Kevin
On Sep 24, 2013, at 6:19 PM, Daniel Micay wrote:
> On Tue, Sep 24, 2013 at 8:37 PM, Tim Kuehn wrote:
> There's also std::iter::AdditiveIterator.
>
> fn average(values: &[T])
I ran them myself. Incidentally, the Rust version is absurdly slow if I don't
specify an optimization level. Here's what I got:
Clang (-O3): 7.99s real
Go (improved version): 9.68s real
Go (original version): 16.73s real
Rust (--opt-level=3): 13.03s real
(I ran each case 3 times and took the med
On Sep 22, 2013, at 5:27 PM, SiegeLord wrote:
> On 09/22/2013 07:45 PM, Kevin Ballard wrote:
>> It would require changing the rules for lifetimes, with no benefit (and no
>> clear new rule to use anyway). &'foo"delim" is perfectly legal today, and I
>>
It would require changing the rules for lifetimes, with no benefit (and no
clear new rule to use anyway). &'foo"delim" is perfectly legal today, and I see
no reason to change that.
-Kevin
On Sep 22, 2013, at 4:26 PM, SiegeLord wrote:
> On 09/22/2013 07:10 P
' doesn't work because 'delim is parsed as a lifetime.
-Kevin
On Sep 22, 2013, at 3:41 PM, SiegeLord wrote:
> On 09/22/2013 05:40 PM, Kevin Ballard wrote:
>> I've filed a summary of this conversation as an RFC issue on the GitHub
>> issue tracker.
>>
I've filed a summary of this conversation as an RFC issue on the GitHub issue
tracker.
https://github.com/mozilla/rust/issues/9411
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Heredocs are primarily intended for multiline strings. Raw strings are intended
for strings that have no escapes. Raw strings typically allow newlines, but
that is not their primary purpose (and in Rust, regular strings allow newlines
anyway). Trying to use a heredoc syntax for raw strings is ju
> From my point-of-view, that is the only way to get a "raw string" that really
> means raw string; otherwise, you end up having to select some exceptional
> case (e.g. the backslashes, doubled-up quotes, etc of the other options Kevin
> described).
>
> Cheers,
> -
I considered backtick as well. If that approach is used, I would suggest that a
doubled-up backtick represent a single backtick in the string, i.e. `error:
path ``{}' failed`. This is pretty much equivalent to just using r"" as the
syntax, although backtick may be a slightly nicer syntax for it.
as it only comes to a head when needing
> *triple-quoted rawstrings* to include *their own* delimiters
> (meaning a triple-quoted rawstring which needs to include both
> triple-quoted delimiters at the same time).
>
> Even unlikelier given python will concatenate string literals
On Sep 20, 2013, at 1:13 AM, Masklinn wrote:
>>> Also,
>>>
windows file paths
>>>
>>> windows paths can also use forward slashes so that's not a very
>>> interesting justification.
>>
>> Not always. UNC paths must start with \\ (in my testing, //foo/bar/baz is
>> not interpreted as a UNC
Sep 19, 2013 at 2:37 PM, Kevin Ballard wrote:
>> I didn't look at Ruby's syntax, but what you just described sounds a little
>> too free-form to me. I believe Ruby at least requires a % as part of the
>> syntax, e.g. %q{test}. But I don't think %R{test} is
On Sep 19, 2013, at 2:13 PM, Masklinn wrote:
> On 2013-09-19, at 22:36 , Kevin Ballard wrote:
>>
>> I welcome any comments, criticisms, or suggestions.
>
> * C# also has rawstrings, which were not looked at. C#'s rawstrings
> disable escaping entirely but add a
On Sep 19, 2013, at 1:56 PM, Oren Ben-Kiki wrote:
> Just to make sure - how does the C++ syntax behave in the presence of line
> breaks? Specifically, what does it do with leading (and trailing) white space
> of each line? My guess is that they would be included in the string, is that
> correc
w does not appear in the string, e.g. if you
> had a string containing ')' you could use R{this is a string with a )
> in it} or R|this is a string with a ) in it|.
>
> martin
>
> On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard wrote:
>> One feature com
One feature common to many programming languages that Rust lacks is "raw"
string literals. Specifically, these are string literals that don't interpret
backslash-escapes. There are three obvious applications at the moment: regular
expressions, windows file paths, and format!() strings that want
We could go with `&unrestricted` instead, which has the benefit of being
semantically compatible with the C keyword `restrict` (which only a handful of
C programmers even know about). Although it's a bit unwieldy.
-Kevin
On Sep 19, 2013, at 12:03 PM, Daniel Micay wrote:
> On Thu, Sep 19, 2013
I suspect the number of C programmers who know what 'volatile' actually means
is a fairly small percentage of total C programmers these days.
-Kevin
On Sep 19, 2013, at 10:44 AM, Niko Matsakis wrote:
> On Thu, Sep 19, 2013 at 03:15:47PM +, Bill Myers wrote:
>> BTW, how about keeping it, an
This looks rather similar to the error I was getting with PR #8203, which was a
set of undefined references under Windows.
http://buildbot.rust-lang.org/builders/auto-win-32-opt/builds/1212/steps/compile/logs/stdio
I don't know if it's actually related though.
-Kevin
On Sep 13, 2013, at 2:21 P
Given the degrading effect this would have on anyone's faith in the compiler,
you could also call this "Reflections on Rusting Trust".
-Kevin
On Sep 10, 2013, at 2:02 PM, Brian Anderson wrote:
> On 09/10/2013 12:01 AM, John Mija wrote:
>> After of reading an article seen in HN "Strange Loops:
What are the intended rules for cross-module visibility of priv items? My
impression was that either parents were supposed to be able to see their
children's priv items, or children could see their parents' priv items, or
maybe both. But it seems that right now neither is true. I know that there
On Aug 26, 2013, at 2:46 PM, Daniel Micay wrote:
> On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 wrote:
>> I also think Python's argumented assignments are fine and both a += b vs a +
>> b should behave differently. I personally read a += b as an atomic,
>> thread-safe operation whereas a + b isn't
If /// was for the parent and the only way to document things, that would make
it rather problematic to document struct fields and statics.
-Kevin
On Aug 26, 2013, at 2:11 PM, Armin Ronacher wrote:
> Hi,
>
> On 26/08/2013 15:07, Niko Matsakis wrote:
>> I find I have surprisingly strong opinio
You should be able to just use .take() instead of invoking util::replace(),
although the end-result should be the same.
let root = self.levels[last].root.take();
-Kevin
On Aug 20, 2013, at 7:35 PM, Niko Matsakis wrote:
> There may be another way, but one safe option is to use util::replac
core was renamed to std quite some time ago (and std renamed to extra).
-Kevin
On Aug 18, 2013, at 2:06 PM, Amitava Shee wrote:
> I would like to kick the tires with the new rust runtime. I am currently on
> master at commit 88bd2155d780d2d7d976ff271b6bb25a9b03e119. I do not see
> libcore.
>
For reference, in my iterative proposal, I've been considering adding a
`.finished()` method to the Fuse adaptor, which would let you easily add that
capability to any iterator.
-Kevin Ballard
> On Aug 11, 2013, at 6:47 PM, Daniel Micay wrote:
>
>> On Sun, Aug 11, 2013 at
Is it `pub use`d elsewhere? That would be my first thought (can't check now as
I'm away from a computer).
-Kevin Ballard
> On Aug 11, 2013, at 4:44 PM, Corey Richardson wrote:
>
> So I came across a weird fact that is entirely inconsistent with my
> mental model of Rust
ou can say
let mut iter = iter.fuse();
// now the iterator conforms to behavior #1
-Kevin
On Aug 7, 2013, at 7:18 AM, Armin Ronacher wrote:
> Hi,
>
> On 04/08/2013 02:18, Kevin Ballard wrote:
>> I believe that #3 is the right behavior to define. This gives the most
>
Go calls methods through pointers using ., and allows for method declarations
on pointers as well as structs. It also allows for embedding one struct in
another, and method resolution will search the embedded struct if the embedding
struct doesn't have a match. This seems to be working well ther
inline]
fn idx(&self, index: uint) -> Option {
if index == 0 && self.val.is_some() {
self.val.clone()
} else {
self.iter.idx(index-1)
}
}
}
-Kevin
On Aug 4, 2013, at 8:33 PM, Kevin Ballard wrote:
> You could certainly desi
for i in iter {
> match i {
> Some(i) => foo(i);
> None => {
>//other stuff
> }
> }
> }
>
> The outer Option allows the iterator protocol to work as expected, i.e.
> iterate over all available elements in the ite
you need that kind of
> functionality, shouldn't you be hoisting the iterator's return type into its
> own Option? i.e., an Iterator should be become an Iterator>?
>
>
> On Sun, Aug 4, 2013 at 6:23 PM, Kevin Ballard wrote:
> The new for loop works with all 3 of
>
>
> On Sun, Aug 4, 2013 at 1:49 AM, Daniel Micay wrote:
> On Sat, Aug 3, 2013 at 9:18 PM, Kevin Ballard wrote:
> > The iterator protocol, as I'm sure you're aware, is the protocol that
> > defines the behavior of the Iterator trait. Unfortunately, at the mo
+1 on "Java style"
On Fri, Aug 2, 2013 at 6:28 PM, Patrick Walton wrote:
> Hi everyone,
>
> Brendan Eich emailed me expressing a preference for `GC<>` over `Gc<>`. I
> think now is as good a time as any to have the bikeshedding debate :)
>
> I've noticed two styles for acronyms in type names: J
The iterator protocol, as I'm sure you're aware, is the protocol that
defines the behavior of the Iterator trait. Unfortunately, at the moment
the trait does not document what happens if you call `.next()` on an
iterator after a previous call has returned `None`. According to Daniel
Micay, the inte
In general, I like this. Although trying to use this feature as a way
to simulate Go's struct embedding seems a bit misguided. Besides the
fact that this would allow you to say *bar to get the embedded struct,
which seems unintentional, it also won't work if you want to embed two
separate structs a
Last night I tracked down why `make check-stage2-std` no longer works
on my computer. This is documented in issue
https://github.com/mozilla/rust/issues/7772. In summary, the test
runner now uses num_cpus*2 threads instead of 4 threads, which ends up
being 16 on my machine, and this causes the proc
It's still there, but it is no longer public. I'm surprised you didn't
get an error sooner than link time.
On Tue, Jul 9, 2013 at 3:45 AM, Corey Richardson wrote:
> On Tue, Jul 9, 2013 at 5:21 AM, Fredrik Håård wrote:
>> I'm trying to migrate to 0.7, and failing - I was using
>> unicode::general
I've been thinking about string encoding support lately, and the
approach I've decided to experiment with is representing a string
encoding as a pair of external Iterators. The encoder is an
Iterator that consumes an Iterator, and the decoder is an
Iterator that consumes an Iterator. A pair of cond
If only this weren't during WWDC.
I hope we can have another meetup sometime in the near future (perhaps
in SF?) that doesn't conflict with a large conference.
-Kevin
On Wed, Jun 5, 2013 at 7:00 PM, Brian Smith wrote:
> Awesome! Looking forward to it.
>
> On Jun 5, 2013 6:22 PM, "Brian Anderson
101 - 200 of 200 matches
Mail list logo
