maybe i'm not understanding things, but is there any reason why the
standard library couldn't provide both types of channels? Its really really
not a "which should be the default", but two abstractions/data structures
which are very very different in when they're used in practice!
Looking at the d
On 12/18/2013 10:23 PM, 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
avoid blocking on the send). However, if I do care about the size, usually I
want it to be effectiv
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
> avoid blocking on the send). However, if I do care about the size, usually I
> want i
On 12/18/2013 09: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.
Dropping is dropping. If you prefer to drop old events, pull them off
the channel and drop them fast enough that new events
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
avoid blocking on the send). However, if I do care about the size, usually I
want it to be effectively infinite (and I have some code in my IRC bo
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 any communications
primitive as the One True Primitive never goes well for high-performance
code. I think we n
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
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 last two options usually result in a crashed app...
As I u
On 12/18/2013 06:29 PM, Tony Arcieri wrote:
Some context:
https://twitter.com/mentalguy/status/284776872452173824
As someone who knows a lot of people who use Erlang in production
(Erlang has unbounded mailboxes), and the maintainer of my own
actor-based concurrency framework (Celluloid, whic
On 12/18/2013 06:59 PM, Jack Moffitt wrote:
3) Make sends to a full channel an error: I'm really not a fan of this
option at all but I'm listing it for completeness. We could make everyone
check every message send for success. Ick. No thanks.
What should the default be? This makes the API a lot
>> This is unsuitable as a general purpose mechanism. Whether this is
>> appropriate is highly application specific.
>
>
> I think it's mostly a question of defaults.
I chose my words poorly. I meant that I don't think it's a good
default. Obviously it's a useful tool in many situations.
jack.
__
On 12/18/2013 06:29 PM, Tony Arcieri wrote:
Adding bounds to a channel doesn't require that sends block, and I think
Rust is doing the Right Thing(TM) here in regard to non-blocking sends and
I would never ask you to change that. There are other options for bounding
channels which don't involve
On 12/18/13 6:59 PM, Jack Moffitt wrote:
1) Drop messages on the floor: This falls into the category of "at most
once" message semantics that actor systems are typically described as having
(although there's a fun discussion about this right now on the friam mailing
list). My personal opinion is
> Processes overloaded with too many
> messages will slow down and grow in memory until they eventually exhaust
> system resources and crash.
In Erlang this is true, but Rust semantics are different. Memory is
certainly consumed but there is no mailbox scanning like Erlang nor is
there anything li
Some context:
https://twitter.com/mentalguy/status/284776872452173824
As someone who knows a lot of people who use Erlang in production (Erlang
has unbounded mailboxes), and the maintainer of my own actor-based
concurrency framework (Celluloid, which started with unbounded mailboxes
and is in the
On 19 Dec 2013, at 5:17 am, Kevin Ballard wrote:
> 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
On 19 Dec 2013, at 1:26 am, Benjamin Striegel wrote:
> Hello rusties, I was reading a blog post by Joe Armstrong recently in which
> he shows off his favorite tiny Erlang program, called the Universal Server:
>
> http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html
>
> I know t
Hi, I ported rust.ko to OSX. Maybe it'll be interesting for somebody
https://github.com/astavonin/RustyKext
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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
Ah woo thanks that solves it.
--Phil
On 18 December 2013 15:46, Léo Testard wrote:
> Hello Philip,
>
>
> Le 18 déc. 2013 à 16:41, Philip Herron a écrit :
>
>> Hey all
>>
>> Been writing more rust to learn more. And i have been attempting to
>> write python bindings to rust. And for example
>>
>
Hello Philip,
Le 18 déc. 2013 à 16:41, Philip Herron a écrit :
> Hey all
>
> Been writing more rust to learn more. And i have been attempting to
> write python bindings to rust. And for example
>
> if i create a function in rust:
>
> pub fn spam () {
> ...
> }
>
> the symbol gets mangled t
Hey all
Been writing more rust to learn more. And i have been attempting to
write python bindings to rust. And for example
if i create a function in rust:
pub fn spam () {
...
}
the symbol gets mangled to:
redbrain@pherron-mtfdev-vbox {~/workspace/python-rs} $ nm -s spam.o
t
Hello rusties, I was reading a blog post by Joe Armstrong recently in which
he shows off his favorite tiny Erlang program, called the Universal Server:
http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html
I know that Rust doesn't have quite the same task communication primitives
as
Gaetan (cc'ing rust-dev)-
On 18/12/2013 09:48, Gaetan wrote:
but I wouldn't understand why the 'mod' keyword would stay
Because a Rust module is not the same thing as a crate.
Changes to the syntax for linking to an external crate is orthogonal to
the concept of a module. So as long as we wa
I am in favor of replacing the mod keyword by crate.
#[package_id = "whoami"];
#[package_type = "lib"];
...
use crate whoamiextern
but I wouldn't understand why the 'mod' keyword would stay
-
Gaetan
2013/12/18 Liigo Zhuang
> `use crate foo; ` looks good to me. i always think it should b
25 matches
Mail list logo
