On 12/31/2013 05:46 AM, Christian Ohler wrote:
The processing is sequential, so using two tasks seems rather
contrived.
You're forgetting that Rust tasks are also the unit of isolation.
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 12/31/2013 08:06 AM, Carter Schonwald wrote:
as a counter point, in strongly typed languages (of which rust is one), the
type checker is a great aid in fixing breaking changes :). In fact it makes
addressing such breakages quite easy.
This is pretty notable in other strongly typed langs like
On 12/31/2013 06:16 AM, Patrick Walton wrote:
I am concerned that we are only hearing one side of the argument here,
and Haskell folks seem to have come down fairly strongly in favor of
unbounded channels.
Haskell also has laziness, garbage collection and immutable shared data
structures.
Without responding to everything in your message, two quick points:
For being written by someone afraid 'of the terrible level of violence, in
[your] view, present in the programming community', your message is
awfully condecending and dismissive of a huge amount of hard work by
curageous people.
On Tue, Dec 31, 2013 at 6:16 AM, Patrick Walton pcwal...@mozilla.comwrote:
Can someone address Simon Marlow's point here?
https://plus.google.com/10955911385859313/posts/FAmNTExSLtz
unbuffered channels are synchronous in the sense that both reader
and writer must be ready at the same
On 01/01/14 00:55, Armin Ronacher wrote:
Hi,
On 30/12/2013 17:29, Patrick Walton wrote:
This is the first time I've heard of this as a missing feature, and I'm
opposed. This would make typechecking significantly more complex.
I'm not saying someone should add decltype :) Just that from using
Not to re-ignite the thread about this, but one way `proc`s aren't
sufficient because they are send-able (that is, allocated on the heap).
Rust lacks a call-once stack-allocated closure types, which are immensely
useful for manipulating container elements, creating DSL-ish syntax, etc.
That's
On Tue, Dec 31, 2013 at 9:15 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
Not to re-ignite the thread about this, but one way `proc`s aren't
sufficient because they are send-able (that is, allocated on the heap). Rust
lacks a call-once stack-allocated closure types, which are immensely useful
On 01/01/14 01:15, Oren Ben-Kiki wrote:
Not to re-ignite the thread about this, but one way `proc`s aren't
sufficient because they are send-able (that is, allocated on the
heap). Rust lacks a call-once stack-allocated closure types, which are
immensely useful for manipulating container
The point is that sometimes you really *don't* want the closure to be
send-able, because you want it to access from the surrounding context both
owned pointers (- be called-once) _and also_ borrowed pointers (- be
stack-allocated). This is vital for some use cases and is impossible today
(ok,
On 12/30/13 10:43 PM, james wrote:
On 30/12/2013 17:35, Patrick Walton wrote:
We haven't discussed it, but I assume Rust 2.0 might break things.
That will presumably be a long way off though.
As an occasional Python programmer who really prefers Python 3, I'd suggest
that the experience there
On 12/31/13 6:26 AM, Oren Ben-Kiki wrote:
The point is that sometimes you really *don't* want the closure to be
send-able, because you want it to access from the surrounding context
both owned pointers (- be called-once) _and also_ borrowed pointers (-
be stack-allocated). This is vital for some
Great news... I'll admit I have no idea what unboxed closures are,
exactly, google wasn't helpful finding out a post clearly describing them.
The example in
http://www.mail-archive.com/rust-dev@mozilla.org/msg07569.html shows
passing a closure to a map, so it obviously isn't a call-once so it
On 12/31/13 6:39 AM, Oren Ben-Kiki wrote:
Great news... I'll admit I have no idea what unboxed closures are,
exactly, google wasn't helpful finding out a post clearly describing
them. The example in
http://www.mail-archive.com/rust-dev@mozilla.org/msg07569.html shows
passing a closure to a map,
It's the same as the difference between static dispatch via generics
and dynamic dispatch via boxed trait objects. At the moment, Rust only
has an equivalent to `mut Trait` for closures and no uniquely typed
unboxed closures like C++.
___
Rust-dev
On 01/01/14 01:43, Patrick Walton wrote:
On 12/31/13 6:09 AM, Huon Wilson wrote:
On 01/01/14 00:55, Armin Ronacher wrote:
Hi,
On 30/12/2013 17:29, Patrick Walton wrote:
This is the first time I've heard of this as a missing feature, and
I'm
opposed. This would make typechecking
Thanks for the explanation. Of course, the point is that you'd meed two
types, `OnceFn` which is stack-allocated (non-send-able, can take borrowed
pointers from its context) and `SendFn` which is heap-allocated (send-able,
can't take borrowed pointers from its context). Both would be able to
On 12/31/2013 01:43 PM, Till Schneidereit wrote:
Without responding to everything in your message, two quick points:
For being written by someone afraid 'of the terrible level of violence, in
[your] view, present in the programming community', your message is
awfully condecending and dismissive
In fact most haskellers building distributed/concurrent systems are
emphatically in favor of only bounded channels.
On Tuesday, December 31, 2013, György Andrasek wrote:
On 12/31/2013 06:16 AM, Patrick Walton wrote:
I am concerned that we are only hearing one side of the argument here,
and
The other day on IRC `mitsuhiko` (who I believe is actually Armin, the OP
in this thread) wrote that he would like to be able to write something like
fn my_pipelineI: IteratorT(x: I) - IteratorT { ... }
and that got stuck in my head: maybe it's not such a crazy idea. The
objections to having
Denis,
Long form email is not the best method of communication or to express your
design thoughts...I would suggest a blog link instead.
Also note that Patrick has asked the community numerous times...
Give specific alternative solutions of where you think Rust has made design
mistakes,
On Tue, Dec 31, 2013 at 10:39 AM, Gábor Lehel glaebho...@gmail.com wrote:
Speaking of which: I completely agree with Patrick that there's no point to
blocking Rust 1.0 on backwards compatible features. The reason I'm
nonetheless wary of a drive to finalize the language too soon is that there
On Tue, Dec 31, 2013 at 4:41 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Dec 31, 2013 at 10:39 AM, Gábor Lehel glaebho...@gmail.com
wrote:
Speaking of which: I completely agree with Patrick that there's no point
to
blocking Rust 1.0 on backwards compatible features. The reason
On 12/31/13 6:52 AM, Huon Wilson wrote:
fn my_pipelineI: IteratorT(x: I) -
MapIteratorFilterIteratorI,
what_do_I_write_for_the_function_type_here, and_again {
x.filter(|un| boxed).map(|also| unboxed)
}
(where the function/closure is the second param to {Map,Filter}Iterator.)
On 12/31/13 6:56 AM, Oren Ben-Kiki wrote:
Thanks for the explanation. Of course, the point is that you'd meed two
types, `OnceFn` which is stack-allocated (non-send-able, can take
borrowed pointers from its context) and `SendFn` which is heap-allocated
(send-able, can't take borrowed pointers
On 12/31/13 7:20 AM, Carter Schonwald wrote:
In fact most haskellers building distributed/concurrent systems are
emphatically in favor of only bounded channels.
Do you have a citation? Simon Marlow seemed to be firmly in the opposite
camp.
Patrick
On 12/31/13 1:53 AM, György Andrasek wrote:
Still, even STM has semaphores and bounded queues, and the user is
expected to choose the right data structure for their needs.
This is what I'm advocating here.
Patrick
___
Rust-dev mailing list
On 12/30/13 8:46 PM, Christian Ohler wrote:
To address the last sentence – bounded channels with default size 0
_do_ minimize the fallout of this design: The program would reliably
deadlock every time it is tested with a nonzero number of images,
since A will try to write to Images while B is
On Tue, Dec 31, 2013 at 6:46 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/30/13 8:46 PM, Christian Ohler wrote:
To address the last sentence – bounded channels with default size 0
_do_ minimize the fallout of this design: The program would reliably
deadlock every time it is tested
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
Patrick, the example simon marlow remarks you've alluded to (i believe its
this one https://plus.google.com/10955911385859313/posts/FAmNTExSLtz)
are a bit more nuanced than I feel you make it out to be
as a counter point, can point to steve severance's tweets at you and me
This is currently a bug in rustpkg, and I've opened up
https://github.com/mozilla/rust/issues/11243 about this bug.
On Tue, Dec 31, 2013 at 6:36 AM, Madhu Srinivasan
smadhuea...@outlook.com wrote:
This is great !!
Quick question - it seems like rustpkg is still unaware of libnative and
On 12/30/2013 08:58 PM, Patrick Walton wrote:
I'm not particularly interested in sacrificing performance by not
implementing one or the other in libstd. I think it's clear we need
both forms of channels, and they should be first-class primitives.
It's clear there are people who *want* both
On 12/31/13 1:33 PM, Nathan Myers wrote:
On 12/30/2013 08:58 PM, Patrick Walton wrote:
I'm not particularly interested in sacrificing performance by not
implementing one or the other in libstd. I think it's clear we need
both forms of channels, and they should be first-class primitives.
It's
what are some candidate data structures in that case? i'm happy to try and
hack out some prototypes for that.
On Tue, Dec 31, 2013 at 4:41 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/31/13 1:33 PM, Nathan Myers wrote:
On 12/30/2013 08:58 PM, Patrick Walton wrote:
I'm not
On 01/01/14 04:32, Patrick Walton wrote:
On 12/31/13 6:52 AM, Huon Wilson wrote:
fn my_pipelineI: IteratorT(x: I) -
MapIteratorFilterIteratorI,
what_do_I_write_for_the_function_type_here, and_again {
x.filter(|un| boxed).map(|also| unboxed)
}
(where the function/closure is
On 12/31/2013 10:41 PM, Patrick Walton wrote:
Unbounded channels have defined behavior as well. Undefined behavior has
a precise definition and OOM is not undefined behavior.
OOM is not a behavior. It's a DoS attack on the rest of the system.
___
On 12/31/13 3:15 PM, György Andrasek wrote:
On 12/31/2013 10:41 PM, Patrick Walton wrote:
Unbounded channels have defined behavior as well. Undefined behavior has
a precise definition and OOM is not undefined behavior.
OOM is not a behavior. It's a DoS attack on the rest of the system.
When
On Tue, Dec 31, 2013 at 1:50 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
what are some candidate data structures in that case? i'm happy to try and
hack out some prototypes for that.
Can I talk about the counterpoint? What if we want to accept and handle
bounds to the messaging
If you're pushing to an unbounded vec in a tight loop you've got
fundamental design issues. If you're pushing to a channel, you've got
something like a server under load. Use cases matter.
About the deadlock scenario, why aren't non-blocking sends sufficient to
address that concern? I'd
On Tue, Dec 31, 2013 at 4:40 PM, Jason Fager jfa...@gmail.com wrote:
About the deadlock scenario, why aren't non-blocking sends sufficient to
address that concern? I'd personally argue just as strenuously as for
bounded channels that robust systems shouldn't have senders that block
For the sake of concreteness, what would be an example of the live lock
scenario?
On Tuesday, December 31, 2013, Devin Jeanpierre wrote:
On Tue, Dec 31, 2013 at 4:40 PM, Jason Fager jfa...@gmail.comjavascript:;
wrote:
About the deadlock scenario, why aren't non-blocking sends sufficient to
On Tue, Dec 31, 2013 at 7:07 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
For the sake of concreteness, what would be an example of the live lock
scenario?
Suppose we have two channels, c1 and c2, and they are both full. The
deadlock scenario is where task 1 won't read from c2 until
43 matches
Mail list logo
