I submitted a PR yesterday in response to this thread that fixes `sudo make
install` to drop the root privs for everything except the actual installation:
https://github.com/rust-lang/rust/pull/17009
-Kevin
On Sep 5, 2014, at 5:00 AM, John McKown john.archie.mck...@gmail.com wrote:
On Thu,
I’m still seeing bad transmutes.
fn from_str'a(s: 'a str) - RawIobuf'a {
unsafe {
let bytes: mut [u8] = mem::transmute(s.as_bytes());
RawIobuf::of_buf(BorrowedBuffer(bytes))
}
}
This is taking a `str`, converting to `[u8]`, and then transmuting to `mut
[u8]`. Besides
not appropriate for
localization, or template engines.
-Kevin Ballard
On Aug 24, 2014, at 2:48 PM, Vadim Chugunov vadi...@gmail.com wrote:
Hi,
Is there any way to make Rust's fmt module to consume format template
specified at runtime?
This might be useful for localization of format!'ed strings
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote:
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would
This is pretty awesome. I notice that http://crates.io doesn’t link to the
GitHub repo though. Seems like that might be a useful thing to add.
-Kevin
On Jun 23, 2014, at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The
I would not expect this to be “mapped” over the slice. I encourage you to come
up with an appropriate syntax to describe that and submit an RFC, although I
wonder how you plan on dealing with things like key vs value in Maps, and
further nesting (e.g. slices of slices, etc).
As for applying it
On May 30, 2014, at 12:12 AM, Vladimir Matveev dpx.infin...@gmail.com wrote:
2014-05-30 5:37 GMT+04:00 Kevin Ballard ke...@sb.org:
It shouldn't.
The for-loop desugaring looks like
match mut st.execute_query() {
__i = loop {
match __i.next() {
None = break
= st.execute_query()
for i in query_result {
...
and in this case, the query_result lives outside the loop
the compiler can not distinguish these two usages ?
Thanks
2014-05-30 9:17 GMT+02:00 Kevin Ballard ke...@sb.org:
On May 30, 2014, at 12:12 AM, Vladimir Matveev dpx.infin...@gmail.com
, at 3:12 PM, Kevin Ballard ke...@sb.org wrote:
I'm assuming that Statement has its own lifetime parameter? And that's the 'a
you're using here?
Try using a new lifetime.
pub fn execute_query'b('b mut self) - ResultSelf'b;
-Kevin
On May 30, 2014, at 1:54 AM, Christophe Pedretti
Not only this, but match patterns are also extremely often used intentionally
to move values. The trivial example is something like
match some_opt_val {
Some(x) = do_something_with(x),
None = default_behavior()
}
By-ref matching is actually the more infrequent type of matching in my
This is a very long bikeshed for something which there's no evidence is even a
problem. I propose that we terminate this thread now.
If you believe that .len() needs to be renamed, please go gather evidence
that's compelling enough to warrant breaking tradition with practically every
I suspect a more generally interesting solution would be a Counted iterator
adaptor that keeps track of how many non-None values it's returned from next().
You could use this to validate that your Take iterator returned the expected
number of values.
pub struct CountedT {
iter: T,
///
On May 28, 2014, at 11:37 PM, Aravinda VK hallimanearav...@gmail.com wrote:
I wonder if chars() available for String itself, so that we can avoid running
as_slice().chars()
This is a temporary issue. Once DST lands we will likely implement Derefstr
for String, which will make all str methods
On May 29, 2014, at 11:22 AM, Vladimir Matveev dpx.infin...@gmail.com wrote:
Hi, Christophe,
Won't wrapping the first `for` loop into curly braces help? I suspect
this happens because of `for` loop desugaring, which kind of leaves
the iterator created by `execute_query()` in scope (not
It's .len() because slicing and other related functions work on byte indexes.
We've had this discussion before in the past. People expect there to be a
.len(), and the only sensible .len() is byte length (because char length is not
O(1) and not appropriate for use with most string-manipulation
() and be explicit about their desire to index via code
units.
On Wed, May 28, 2014 at 1:12 PM, Kevin Ballard ke...@sb.org wrote:
It's .len() because slicing and other related functions work on byte indexes.
We've had this discussion before in the past. People expect there to be a
.len
, May 28, 2014 at 2:42 PM, Kevin Ballard ke...@sb.org wrote:
Breaking with established convention is a dangerous thing to do. Being too
opinionated (regarding opinions that deviate from the norm) tends to put
people off the language unless there's a clear benefit to forcing the
alternative
On May 28, 2014, at 1:26 PM, Benjamin Striegel ben.strie...@gmail.com wrote:
Unicode is not a simple concept. UTF-8 on the other hand is a pretty simple
concept.
I don't think we can fully divorce these two ideas. Understanding UTF-8 still
implies understanding the difference between
On May 28, 2014, at 3:24 PM, Huon Wilson dbau...@gmail.com wrote:
Changing the names of methods on strings seems very similar how Path does not
implement Show (except with even stronger motivation, because strings have at
least 3 sensible interpretations of what the length could be).
I
On May 28, 2014, at 6:00 PM, Benjamin Striegel ben.strie...@gmail.com wrote:
To reiterate, it simply doesn't make sense to ask what the length of a string
is. You may as well ask what color the string is, or where the string went to
high school, or how many times the string rode the roller
On May 28, 2014, at 5:38 PM, Oleg Eterevsky o...@eterevsky.com wrote:
4. It looks like vectors can be concatenated with + operations, but
strings can't. Is it deliberate?
Partially. It's fallout of all the changes that strings have been going through
lately. And [PR #14482][] reintroduces +
On May 28, 2014, at 9:16 PM, Bardur Arantsson s...@scientician.net wrote:
Rust:
$ cat
fn main() {
let l = hï.len(); // Note the accent
println!({:u}, l);
}
$ rustc hello.rs
$ ./hello
3
No matter how defective the notion of length may be, personally I
think that
What's the use-case for this?
-Kevin
On May 27, 2014, at 3:24 AM, Tommi rusty.ga...@icloud.com wrote:
Could we add to the standard library a macro, say 'include_sized_bin', that
would be similar to std::macros::builtin::include_bin except that you'd also
give it a sized type to return
On May 27, 2014, at 6:05 AM, Benjamin Striegel ben.strie...@gmail.com wrote:
The use of taking S: Str is for taking things like [S], where you want
to take both str and String (such as in the other post about getops()).
I wouldn't be bothered with leaving the API as-is, but I don't
vector literal syntax, but it killed the compilation time and my computer ran
out of memory.
On 27 May 2014, at 19:50, Kevin Ballard ke...@sb.org wrote:
What's the use-case for this?
-Kevin
On May 27, 2014, at 3:24 AM, Tommi rusty.ga...@icloud.com wrote:
Could we add
It actually makes radius a f32.
-Kevin
On May 27, 2014, at 10:42 AM, Tommi Tissari rusty.ga...@icloud.com wrote:
Thanks. I had failed to realize that 'ref radius' would make 'radius' a
Boxf32 value.
On 27 May 2014, at 20:29, Oleg Eterevsky o...@eterevsky.com wrote:
As far as I
for function arguments, specifically so String
will auto-slice to str the same way ~str used to (although someone still needs
to write up an RFC for this).
-Kevin
On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard ke...@sb.org wrote:
On May 27, 2014, at 6:05 AM, Benjamin Striegel ben.strie
I think getopts has an old API. All the methods that take [String] should
probably be rewritten to be generic with S: Str and take [S] instead, which
will allow taking either a slice of Strings or a slice of str's.
-Kevin
On May 26, 2014, at 12:16 PM, Benjamin Striegel ben.strie...@gmail.com
captures() should not take S: Str. That's unnecessary, it should just take
str as it does now. The use of taking S: Str is for taking things like [S],
where you want to take both str and String (such as in the other post about
getops()).
For the time being, the answer is to use .as_slice()
to also
be able to pass a slice of chars. It doesn't look like char implements Str.
getopts could define a new trait, Text or something, for all 3...
On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard ke...@sb.org wrote:
I think getopts has an old API. All the methods that take [String] should
PM, Gulshan Singh gsingh2...@gmail.com wrote:
On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard ke...@sb.org wrote:
All the methods that take [String] should probably be rewritten to be
generic with S: Str and take [S] instead, which will allow taking either a
slice of Strings or a slice of str's
Matthieu's code shows subtraction. It works via addition by making the input
the type that uses addition, and the output the base type.
-Kevin
On May 25, 2014, at 10:55 AM, Isak Andersson cont...@bitpuffin.com wrote:
Hey, thanks for the reply!
(minor correction for myself, I meant to say
This looks like a legitimate problem. Have you filed an issue on the GitHub
issues page? https://github.com/mozilla/rust/issues/new
-Kevin
On May 23, 2014, at 6:04 AM, Paulo Sérgio Almeida pssalme...@gmail.com wrote:
Hi all, (resending from different email address; there seems to be a
Rust doesn't like this because datatype() is not a method on T. It's a method
on MySendable. There are various proposals that will fix this (including UFCS,
and a proposal to make T::datatype() work as you just tried).
But for the time being, you basically cannot have a trait method that does
On May 15, 2014, at 9:54 PM, Daniel Micay danielmi...@gmail.com wrote:
On 16/05/14 12:48 AM, Tommi wrote:
On 2014-05-16, at 7:35, Steven Fackler sfack...@gmail.com wrote:
Type annotations are not there for the compiler; they're there for people
reading the code. If I want to use some
If you want that, you'll need to use a custom pointer type instead of ~. You
can use ~ internally, and implement Deref/DerefMut to do the desired capturing.
pub struct PtrT {
value: ~T // assuming 0.10 here, master would be BoxT
}
implT PtrT {
pub fn new(val: T) - PtrT {
Ptr {
This fixed code is wrong. Instead of taking a reference to the borrow, it
actually destructs it and copies the referenced Test. Since it's not keeping a
reference anymore, that's why it works.
The issue with the original code is test.match_fn() borrow test, and Some(mut
borrow_test) keeps that
On Apr 9, 2014, at 11:25 PM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 10 Apr 2014, at 07:55, Corey Richardson co...@octayn.net wrote:
range doesn't return a forward iterator. RangeA also implements
DoubleEndedIterator.
Ok, I didn't realize that. But it still should't require AddA, A
for AdditiveIdentity, they're
going to look for Zero.
-Kevin
On Apr 9, 2014, at 6:29 AM, Liigo Zhuang com.li...@gmail.com wrote:
Zero is a bad name here, it should be renamed or removed
2014年4月9日 上午1:20于 Kevin Ballard ke...@sb.org写道：
On Apr 7, 2014, at 1:02 AM, Tommi Tissari rusty.ga...@icloud.com wrote
, Kevin Ballard ke...@sb.org wrote:
The number 0 is the additive identity for numbers. But informally, the
additive identity for other things can be called zero without problem.
Heck, even the wikipedia page on Additive Identity uses this example for
groups:
Let (G, +) be a group and let 0
On Apr 9, 2014, at 9:50 PM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote:
FWIW, my point about range is it relies on One being the number 1, rather
than being the multiplicative identity. AFAIK there's nothing special about
1
On Apr 7, 2014, at 1:02 AM, Tommi Tissari rusty.ga...@icloud.com wrote:
On 07 Apr 2014, at 08:44, Nicholas Radford nikradf...@googlemail.com wrote:
I think the original question was, why does the zero trait require the add
trait.
If that was the original question, then my answer would be
to just process the
vector and throw it away that's fine, but if I'm going to keep it around for a
while then this is terrible.
The only reasonable solution is to return the VecT and let the caller decide
if they want to shrink-to-fit or not.
-Kevin Ballard
On Apr 2, 2014, at 3:01 PM, Huon Wilson dbau...@gmail.com wrote:
On 03/04/14 08:54, Patrick Walton wrote:
What about strings? Should we be using `StrBuf` as well?
I don't see why not. The same arguments apply.
I agree. I was actually quite surprised to see that the type was named StrBuf,
, I don't believe we have any
precedence for a semantic behavior change when replacing a constant string with
a non-constant expression.
-Kevin Ballard
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Apr 2, 2014, at 10:14 PM, Daniel Micay danielmi...@gmail.com wrote:
Perhaps we should have `print` and `println` back in the prelude and
call these `printf!` and `printfln!`. I think it would be a lot clearer,
as people always ask how these are different from `print` and `println`.
I would
AFAIK there is no solution to this at the moment.
One proposal was to add a `close()` method to `TcpStream` that would close it
immediately without waiting for it to go out of scope. This seems like the
simplest solution, if someone wants to implement it.
A better (but much more complicated)
On Mar 4, 2014, at 5:23 AM, Tommi rusty.ga...@icloud.com wrote:
I agree with the spirit of your proposal. But I would change that first
clause above to read:
An iterator is said to be well-behaved when its .next() method always
returns None if the iterator logically has no elements to
On Mar 3, 2014, at 8:44 PM, Nathan Myers n...@cantrip.org wrote:
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
On Feb 28, 2014, at 8:10 PM, Kang Seonghoon some...@mearie.org wrote:
2014-03-01 6:24 GMT+09:00 John Grosen jmgro...@gmail.com:
On Friday, February 28, 2014 at 11:15 AM, Matthieu Monrocq wrote:
Maybe one way of preventing completely un-annotated pieces of data would be
a lint that just
I too was under the impression that you could not read from a mutably-borrowed
location.
I am looking forward to the ability to move out of a mut (as long as the value
is replaced again),
if the issues around task failure and destructors can be solved.
-Kevin
On Feb 25, 2014, at 12:19 PM,
improvement here that I'm missing?
On Tue, Feb 25, 2014 at 4:23 PM, Kevin Ballard ke...@sb.org wrote:
I too was under the impression that you could not read from a
mutably-borrowed location.
I am looking forward to the ability to move out of a mut (as long as the
value is replaced again
On Feb 25, 2014, at 4:04 PM, Eric Reed ecr...@cs.washington.edu wrote:
Would a mut that could move enable us to write insertion into a growable
data structure that might reallocate itself without unsafe code? Something
like OwnedVector.push() for instance.
The problem with that is you
This definitely seems to be a bug. If you can, you should file this at
https://github.com/mozilla/rust/issues.
-Kevin
On Feb 25, 2014, at 10:12 PM, Phil Dawes rustp...@phildawes.net wrote:
Hi Ashish,
Yes that works fine. Splitting out 'args' into a separate variable fixes the
behaviour.
On Feb 21, 2014, at 12:20 PM, Brian Anderson bander...@mozilla.com wrote:
On 02/19/2014 02:37 AM, György Andrasek wrote:
On Wed, Feb 19, 2014 at 1:40 AM, Brian Anderson bander...@mozilla.com
wrote:
Backwards-compatibility is guaranteed.
Does that include ABI compatibility?
Second, the
My understanding is that .lines() exists primarily to make quick-and-dirty I/O
as easy as it is in, say, a scripting language. How do scripting languages
handle I/O errors when iterating lines? Do they raise an exception? Perhaps
.lines() should fail!() if it gets a non-EOF error. Then we could
On Feb 19, 2014, at 12:28 PM, Corey Richardson co...@octayn.net wrote:
This is a pretty bad idea, allowing *arbitrary unreviewed anything* to
run on the buildbots. All it needs to do is remove the contents of its
home directory to put the builder out of commission, afaik. It'd
definitely be
On Feb 19, 2014, at 2:34 PM, Lee Braiden leebr...@gmail.com wrote:
Then we could introduce a new struct to wrap any Reader that translates
non-EOF errors into EOF specifically to let you say “I really don’t care
about failure”.
It sounds like a very specific way to handle a very general
On Feb 19, 2014, at 3:40 PM, Jason Fager jfa...@gmail.com wrote:
Can you point to any scripting langs whose lines equivalent just silently
ignores errors? I'm not aware of any; even perl will at least populate $!.
No, because I typically don’t think about errors when writing quick
No, this is likely to crash. `.to_c_str()` constructs a CString, which you are
then promptly throwing away. So your subsequent access to `c_path` is actually
accessing freed memory.
Try something like this:
pub fn read_file(self, path: Optionstr) {
let path = path.map(|s| s.to_c_str());
This is not going to work in the slightest.
Most PRs don't have an associated issue. The pull request is the issue. And
that's perfectly fine. There's no need to file an issue separate from the PR
itself. Requiring a referenced issue for every single commit would be extremely
cumbersome, serve
What if the state's fields are private, and in a different module than the
players, but exposes getters to query the state? Then the players can't modify
it, but if the component that processes the actions has visibility into the
state's fields, it can modify them just fine.
-Kevin
On Feb 14,
at 2:47 PM, Kevin Ballard ke...@sb.org wrote:
What if the state's fields are private, and in a different module than the
players, but exposes getters to query the state? Then the players can't
modify it, but if the component that processes the actions has visibility
into the state's fields
On Feb 13, 2014, at 11:56 AM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org wrote:
Hi,
The Rust documentation currently makes iterators behavior undefined after
.next() has returned None once.
On Feb 1, 2014, at 2:39 PM, Corey Richardson co...@octayn.net wrote:
The immediate, and most pragmatic, problem is that in today's Rust one cannot
easily search for implementations of a trait. Why? `grep 'impl Clone'` is
itself not sufficient, since many types have parametric polymorphism. Now
initiates the write?
On Wed, Jan 29, 2014 at 2:11 PM, Kevin Ballard ke...@sb.org wrote:
This solution will not work for what I need stream splitting for. Namely, I
need to be in the middle of reading from a socket when I decide that I need
to write. I cannot be waiting on the read future
On Jan 29, 2014, at 4:16 PM, Vadim vadi...@gmail.com wrote:
On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard ke...@sb.org wrote:
Any number of things.
The use case here is an interactive protocol where writes go in both
directions, and can be initiated in response to external events
On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com wrote:
On 01/29/2014 06:35 PM, Patrick Walton wrote:
On 1/29/14 6:34 PM, Samuel Williams wrote:
Perhaps this has been considered already, but when I'm reading rust code
let mut just seems to stick out all over the place. Why
Keeping it around means maintaining it, and it means tempting people to use it
even though it's deprecated.
My suggestion would be, if you really need rustpkg, then extract it into a
separate repo and maintain it there. But get it out of the mozilla/rust tree.
-Kevin
On Jan 28, 2014, at 11:28
Your code is moving the contents of Option~MyStruct into the match arm. It
just so happens that this seems to be zeroing out the original pointer in
memory, and that happens to be the same representation that None does for the
type Option~MyStruct (since ~ pointers are non-nullable), so the act
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any special
annotations. This seems like a bad idea to me. I understand why it's
attractive, but it means that seemingly harmless changes to a function's
That's pretty cool. http://www.rust-ci.org/kballard/rust-lua/doc/lua now
contains documentation for rust-lua!
Although there are two issues with the documentation as it exists now. Both are
caused by the fact that the docs link actually embeds the real documentation in
an iframe.
The first
On Jan 16, 2014, at 8:13 AM, Tommy M. McGuire mcgu...@crsr.net wrote:
let file = File::open_mode(Path::new(test), Truncate, Write);
match file {
Some(mut f) = f.write_str( hello ),
None = fail!(not a file)
}
This is fine, because you’re consuming `file` and moving
The relevant issue for this is https://github.com/mozilla/rust/issues/4334.
-Kevin
On Jan 15, 2014, at 7:26 AM, Michael Neumann mneum...@ntecs.de wrote:
Am 15.01.2014 16:23, schrieb Evan G:
I'm not weighing in on whether this is something rust should do or not, but
we could mimic the 16i,
On Jan 10, 2014, at 10:18 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 1/10/14 7:20 AM, Nakamura wrote:
I'm new to rust, and tried going through some of the examples from the
OS class[0] that was taught in rust. However, I got tripped up by the
exercise, make a function that takes an
That path does not exist in Xcode 5.0 or Xcode 5.1 DP3. Are you sure you aren't
looking at an older Xcode (say, Xcode 4.6)?
-Kevin
On Jan 9, 2014, at 4:04 AM, Alexander Stavonin a.stavo...@gmail.com wrote:
FYI. Apple doesn't remove GDB in 10.9. They has removed symlink for it So,
you can
On Dec 31, 2013, at 7:40 PM, Jason Fager jfa...@gmail.com wrote:
If you're pushing to an unbounded vec in a tight loop you've got fundamental
design issues.
Or you’re processing user input. A rather trivial example here is parsing a
file into lines. If I have 2GB of RAM and I throw a 4GB
Some of what you said I agree with, and some I don’t. But in particular, I
disagree with your thesis. A language is successful if it attracts enough
programmers. It may very well be true that the best way to do that is to
produce a high-quality language, but the ineffable “quality” of a
, 2013, at 4:59 PM, Vadim vadi...@gmail.com wrote:
For the same reason we currently have to say `mut i` in main() - to
explicitly acknowledge that the callee may mutate i. By the same logic, this
should be done everywhere.
On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard ke...@sb.org wrote
is needed within foo() since the type of i is
already mut int”.
Correct.
-Kevin
Ashish
On Dec 28, 2013 1:33 PM, Kevin Ballard ke...@sb.org wrote:
We have to say `mut i` in main() because `i` is non-mutable. We’re
explicitly taking a mutable borrow.
But once it’s in foo(), it’s already
On Dec 28, 2013, at 7:10 PM, Vadim vadi...@gmail.com wrote:
You could have said Well, I've already declared my variable as mutable, i.e.
`let mut i = 0`. Since is already mutable, why do I have to say mut again
when borrowing? The compiler could have easily inferred that. I believe
the
On Dec 24, 2013, at 10:23 PM, Daniel Micay danielmi...@gmail.com wrote:
3. Having a bound of 1 by default. The default should allow for parallelism.
A bound of 1 by default seems pretty stupid. I've never understood why
Go does this... it belongs in a separate type.
Go actually has a
On Dec 25, 2013, at 5:17 PM, Vadim vadi...@gmail.com wrote:
I agree that unexpected mutation is undesirable, but:
- requiring 'mut' is orthogonal to requiring '' sigil, IMHO,
- as currently implemented, Rust does not always require mut when callee
mutates the argument, for example:
fn
Even with refutable `let`s, I think there's still a good case for having
`.unwrap()`-style APIs on enums, which is that often you need to unwrap an enum
inside a larger expression. A refutable `let` only works if you're actually
using a `let`-binding to begin with.
-Kevin
On Dec 23, 2013, at
On Dec 20, 2013, at 8:59 AM, Carter Schonwald carter.schonw...@gmail.com
wrote:
agreed! Applications that lack explicit logic for handling heavy workloads
(ie producers outpacing consumers for a sustained period) are the most common
culprit for unresponsive desktop applications that become
, 2013, at 12:55 PM, Carter Schonwald carter.schonw...@gmail.com
wrote:
kevin, what sort of applications and workloads are you speaking about. Eg in
your example irc server, whats the typical workload when you've used it?
cheers
-Carter
On Fri, Dec 20, 2013 at 12:54 PM, Kevin Ballard
On Dec 18, 2013, at 10:49 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Dec 19, 2013 at 1:23 AM, Kevin Ballard ke...@sb.org 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
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
On Dec 19, 2013, at 10:25 AM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
On Thu, Dec 19, 2013 at 7:23 PM, Kevin Ballard ke...@sb.org 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
On Dec 19, 2013, at 10:38 AM, Matthieu Monrocq matthieu.monr...@gmail.com
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
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 ke...@sb.org wrote:
Here’s an example from where I use an infinite queue.
I have an IRC bot, written
On Dec 19, 2013, at 11:23 AM, Gábor Lehel glaebho...@gmail.com 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
On Dec 19, 2013, at 11:23 AM, Gábor Lehel glaebho...@gmail.com wrote:
- Having only one type of queue, which is bounded,
- and whose default capacity is just small enough that it would be hit
before exhausting resources, but is otherwise still ridiculously large
(effectively unbounded)
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
On Dec 18, 2013, at 7:55 PM, Nathan Myers n...@cantrip.org 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,
, which I think is a good idea.
-Kevin
On Dec 18, 2013, at 9:36 PM, Patrick Walton pcwal...@mozilla.com 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.
To reiterate, there is a meta-point here: Blessing
On Dec 17, 2013, at 11:37 AM, Stefan Plantikow stefan.planti...@gmail.com
wrote:
Hi,
Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net:
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
Hi,
Am 09.12.2013 um 16:53 schrieb Damien
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
crate foo`.
-Kevin
On Dec 17, 2013, at 12:19 PM, Kevin Ballard ke...@sb.org 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. My general feeling
On Dec 9, 2013, at 7:19 PM, Corey Richardson co...@octayn.net 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
1 - 100 of 175 matches
Mail list logo
