On 01/13/2014 06:48 PM, Brian Anderson wrote:
# Synchronous and bounded channels
Let's add `SyncChan` which is a bounded multi-producer single-consumer
queue backed by a ring buffer. This supports `send`, which blocks by
default, and `try_send` which returns an enum representing whether the
On 01/24/2014 11:38 AM, Gábor Lehel wrote:
On Fri, Jan 24, 2014 at 4:51 PM, Benjamin Striegel
mailto:ben.strie...@gmail.com>> wrote:
No one's saying usability can't be discussed. If there are
problems, we DESPERATELY DESPERATELY NEED to be made aware. Even
if it's just "the names of
On Fri, Jan 24, 2014 at 4:51 PM, Benjamin Striegel
wrote:
> No one's saying usability can't be discussed. If there are problems, we
> DESPERATELY DESPERATELY NEED to be made aware. Even if it's just "the names
> of these types confuse me", that's valuable feedback. But belaboring the
> point throu
No disrespect intended. Crowdsourced *development* is one of our great
strengths, because things like adding test cases, implementing features,
optimizing benchmarks, reproducing bugs, etc. are all tasks with objective
criteria. When goals are clear, the collective can divide and conquer. But
desig
On 24/01/14 13:34, Benjamin Striegel wrote:
Anyway, if we've devolving into bikeshedding then it might be time to
abandon this thread. Usability isn't something that can be crowdsourced.
Well, what you're essentially saying here (assuming you don't mean to
disrespect non-core folks by calling
Consider my +1 for Source/Sink more as a -1 for Port/Chan. I don't really
care what it ends up as so long as I don't have to look up which is which
every time. Sender/Receiver wfm.
As far as concerns about the proposal itself, my only remaining issue is
that Chan isn't a trait and so the actual
> Channel should be a struct
This is feasible:
let Chan { send, recv } = Chan::new();
...but it seems needlessly verbose, given that literally 100% of the time
you will want to separate the sending end from the receiving end. It makes
no conceptual sense to have a `Chan` as a discrete entity
On 24/01/14 03:16, Strahinja Markovic wrote:
On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik
mailto:st...@steveklabnik.com>> wrote:
I don't think that `new` not returning a `Channel` is a big deal.
Conceptually, you are, both ends 'make up' a channel.
I agree it's not a big deal, but
On 24/01/14 03:54, Brandon Sanderson wrote:
I would expect Channel::new() to create a channel object that either
lets me send and receive, or lets me get a source and sink to send and
receive with. Borrow rules may prevent this, but my point is that
Channel::new() would generally be expected
I regularly send/receive things to/from channels at work, and it seems
you can do the same with real-world ports.
I really have no idea what Rust means by a port does, vs. what it means
by a channel, without reading the details in docs. I'd assume the port,
channel ordering reads left-to-righ
My biggest gripe with port and channel is that a port can both send and
receive things, and a channel is what this things travel along. Also, I
believe there is precedent in other languages for source/sink, though that
may be only for pipes, which are unrelated to this discussion.
Regardless, I a
Am 24.01.2014 04:16, schrieb Strahinja Markovic:
On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik
mailto:st...@steveklabnik.com>> wrote:
I don't think that `new` not returning a `Channel` is a big deal.
Conceptually, you are, both ends 'make up' a channel.
I agree it's not a big deal,
I've opened an issue on the naming problem
https://github.com/mozilla/rust/issues/11765
On 01/23/2014 08:55 PM, Benjamin Striegel wrote:
If we're going to quibble over names we might as well call the types
Sender and Receiver.
Really though, EVERYONE is fine with the proposed semantics from t
My vote, FWIW
let (sender, receiver) = Chan::open();
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Thu, Jan 23, 2014 at 8:55 PM, Benjamin Striegel
wrote:
> If we're going to quibble over names we might as well call the types
> Sender and Receiver.
>
+1 on that
> Really though, EVERYONE is fine with the proposed semantics from the
> original thread? Really? Speak up if you have anything va
If we're going to quibble over names we might as well call the types Sender
and Receiver.
Really though, EVERYONE is fine with the proposed semantics from the
original thread? Really? Speak up if you have anything valuable to add that
isn't bikeshedding! :)
On Thu, Jan 23, 2014 at 11:13 PM, don
Hi, as a not contributing listen-in,
i would like to voice that source and sink share the same initial and
therefore source and drain might be more useful.
I hope i didn't offend by voicing my opinion,
keep up the good work!
Regards Don
Am 24.01.2014 04:54, schrieb Brandon Sanderson:
I wou
Also, +1 for source and sink, I still get port and channel mixed up.
On Thursday, January 23, 2014, Jason Fager wrote:
> open() feels like the clear winner here. Channel::new_pipe is annoying
> because it's long and because channels and pipes are different things (
> http://en.m.wikipedia.org/w
open() feels like the clear winner here. Channel::new_pipe is annoying
because it's long and because channels and pipes are different things (
http://en.m.wikipedia.org/wiki/Pipe_flow),
And aren't we down to naming? I thought the design sounded mostly settled
from the last conversation, and brson
I would expect Channel::new() to create a channel object that either lets
me send and receive, or lets me get a source and sink to send and receive
with. Borrow rules may prevent this, but my point is that Channel::new()
would generally be expected to return a struct, and not a tuple.
On Jan 23, 2
On Thu, Jan 23, 2014 at 7:29 PM, Benjamin Striegel
wrote:
> And Chan::open() doesn't map to anything that's as intuitive.
>
Like File::open? :P
--
Tony Arcieri
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
This all seems a bit silly. A channel *is*, conceptually, a tuple of a
sender and a receiver. If I call Chan::new(), that's what I expect to get.
And Chan::open() doesn't map to anything that's as intuitive.
Is naming really all that's left to argue about? How does everyone feel
about the semantic
On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri wrote:
> I have a crazy idea...
>
> Channel::open()
>
That's a better name for the function, agreed.
>
>
> https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif
>
> --
> Tony Arcieri
>
On Thu, Jan 23, 2014 at 7:16 PM, Strahinja Markovic wrote:
> Why the cognitive load? Channel::new_pipe() returning (Source, Sink) is a
> usability win we get for free.
>
> I know I don't have to convince anyone here just how critical good naming
> is.
>
I have a crazy idea...
Channel::open()
h
On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik
wrote:
> I don't think that `new` not returning a `Channel` is a big deal.
> Conceptually, you are, both ends 'make up' a channel.
>
I agree it's not a big deal, but I still think it's something we might want
to change. Why introduce a mental speed
I don't think that `new` not returning a `Channel` is a big deal.
Conceptually, you are, both ends 'make up' a channel.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Good idea.
How about Channel::new_ends() returns (SendEnd, RecvEnd) ?
2014年1月24日 上午6:57于 "Val Markovic" 写道：
> On Thu, Jan 23, 2014 at 2:32 PM, Vadim wrote:
>
>> Well maybe then channel() -> (SendEnd, RecvEnd) ? Or, channel() ->
>> (Source, Drain) ?
>>
>
> When there are two concepts, one for
On Thu, Jan 23, 2014 at 2:32 PM, Vadim wrote:
> Well maybe then channel() -> (SendEnd, RecvEnd) ? Or, channel() ->
> (Source, Drain) ?
>
When there are two concepts, one for "data comes out of this" and one for
"data goes into this", the names I have most often encountered are "Source"
and "Si
Maybe we can borrow some inspiration from the haskell pipes library?
On Thu, Jan 23, 2014 at 2:32 PM, Vadim wrote:
> Well maybe then channel() -> (SendEnd, RecvEnd) ? Or, channel() ->
> (Source, Drain) ?
>
>
> On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson wrote:
>
>> On 01/13/2014 10:15 PM
Well maybe then channel() -> (SendEnd, RecvEnd) ? Or, channel() ->
(Source, Drain) ?
On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson wrote:
> On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
>
>> People should rethink the Chan api that Chan::new() does not returns a
>> value of type Chan (instead,
On Thu, Jan 23, 2014 at 2:33 PM, Brian Anderson wrote:
> On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
>
>> People should rethink the Chan api that Chan::new() does not returns a
>> value of type Chan (instead, a tuple), which is strange, and inconsistent
>> with other Type::new().
>>
>>
> Agree, th
On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
People should rethink the Chan api that Chan::new() does not returns a
value of type Chan (instead, a tuple), which is strange,
and inconsistent with other Type::new().
Agree, though I haven't heard any great suggestions yet. The core
problem is t
I don't understand why you think the type of the channel needs to encode
information as to whether it's shared. It doesn't encode any other information
about how you expect to use the channel. Merging Chan and SharedChan together
so users don't even know there's a difference under the hood seems
I was working under the assumption that we'd add UniqueChan -> SharedChan
promotion back. I assumed that would be possible since a unified Chan would
be doing it internally.
Does an auto-promoting Chan really do that much for reducing cognitive
load?
The only thing the programmer can skip understa
You can't promote a Chan to a SharedChan currently (like you could
with the old API), so if the caller needs to make the decision, all
the APIs will have to return SharedChan to be flexible. I don't think
traits help with that problem (they do help with passing in Chans). If
we want flexible APIs t
As a follow up, what situation would arise where you'd have to actually
return a Chan trait object?
Constructors are going to return the concrete type UniqueChan/SharedChan.
Functions acting on channels can just use generics, which will allow
returning.
On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed
fn foo() -> T
On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt wrote:
> You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
> Well, unless DST fixes this. I assume this is the same reason we
> return specific instances of iterators instead of an Iteratable trait
> object.
>
> jac
You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
Well, unless DST fixes this. I assume this is the same reason we
return specific instances of iterators instead of an Iteratable trait
object.
jack.
On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed wrote:
> How would that make us l
How would that make us lose stack allocated return values?
On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt wrote:
> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
> > `SharedChan`?
>
> I suppose the main downside of that solution is that you lose stack
> allocated return val
> Good point. Make `Chan` a trait with implementers `UniqueChan` and
> `SharedChan`?
I suppose the main downside of that solution is that you lose stack
allocated return values.
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.o
Good point. Make `Chan` a trait with implementers `UniqueChan` and
`SharedChan`?
On Tue, Jan 14, 2014 at 4:52 PM, Jack Moffitt wrote:
> > I'm skeptical about combining Chan and SharedChan. Maintaining that
> > distinction is useful for expressing the programmer's intent and would
> > certainly
> I'm skeptical about combining Chan and SharedChan. Maintaining that
> distinction is useful for expressing the programmer's intent and would
> certainly make any analysis that cared to distinguish between single and
> multiple producers easier to implement (off the top of my head, knowing
> you'r
On 15 Jan 2014, at 9:35 am, Eric Reed wrote:
> I'm skeptical about combining Chan and SharedChan. Maintaining that
> distinction is useful for expressing the programmer's intent and would
> certainly make any analysis that cared to distinguish between single and
> multiple producers easier to
I'm skeptical about combining Chan and SharedChan. Maintaining that
distinction is useful for expressing the programmer's intent and would
certainly make any analysis that cared to distinguish between single and
multiple producers easier to implement (off the top of my head, knowing
you're the only
On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote:
> Let's add `SyncChan` which is a bounded multi-producer single-consumer
> queue backed by a ring buffer. This supports `send`, which blocks by
> default, and `try_send` which returns an enum representing whether the send
> succeeded, the chan
People should rethink the Chan api that Chan::new() does not returns a
value of type Chan (instead, a tuple), which is strange, and inconsistent
with other Type::new().
2014/1/14 Brian Anderson
> In light of the general consensus that unbounded channels are not so hot,
> here's a new proposal f
This is a great proposal, Brian.
I have no criticisms of the proposal itself, feeling that it's a
level-headed response to the previous threads on this issue.
But I do have a request (something I know Daniel Micay brought up in
#rust): What would it take to get shared-Port like functionality in a
In light of the general consensus that unbounded channels are not so
hot, here's a new proposal for how Rust's channels should operate. This
is based on the following assumptions:
* Running out of memory is an awful failure mode for debugging.
* Choosing an appropriate bounded queue size is har
48 matches
Mail list logo
