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 com.li...@gmail.com
`use crate foo; ` looks good to me. i always
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
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
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
Hello Philip,
Le 18 déc. 2013 à 16:41, Philip Herron redbr...@gcc.gnu.org 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
Ah woo thanks that solves it.
--Phil
On 18 December 2013 15:46, Léo Testard leo.test...@gmail.com wrote:
Hello Philip,
Le 18 déc. 2013 à 16:41, Philip Herron redbr...@gcc.gnu.org a écrit :
Hey all
Been writing more rust to learn more. And i have been attempting to
write python bindings
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
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
On 19 Dec 2013, at 1:26 am, Benjamin Striegel ben.strie...@gmail.com 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:
On 19 Dec 2013, at 5:17 am, Kevin Ballard ke...@sb.org 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 -
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
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 like
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/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
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,
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
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,
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
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
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
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 (to
avoid blocking on the send). However, if I do care about the size, usually I
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
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
23 matches
Mail list logo
