Hello,
I try to capture a closure in a task and I have the error:
error: cannot capture variable of type `|u64, T|`, which does not
fulfill `Send`, in a bounded closure
Any hint to make the closure 'send-able'?
The code I use :
pub fn Pt_startT:Send (resolution : u64, userData : T ,
On Dec 23, 2013, at 11:23 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
into the semantics. Haskell has these
Some languages support a special do notation that allows to express monadic
operations more naturally.
However, there is an even more powerful option, that I'd call in notation (I
came up with it, but it's obvious, so I'm sure there's some language that has
something like it).
The idea is
This is a very good point. Many of those same issues apply in Haskell too.
Additionally, the examples people have given for refutable let thus far all
seem to be special cases of a do notation / computation expression /
monadic abstraction.
That said, unless a special builtin trait is made,
On Tue, Dec 24, 2013 at 11:23 AM, Bill Myers bill_my...@outlook.com wrote:
Some languages support a special do notation that allows to express monadic
operations more naturally.
However, there is an even more powerful option, that I'd call in notation
(I came up with it, but it's obvious,
Every time that we've added magic, we've lived to regret it and ultimately
revert it. If there exists only a single lesson of the past few years of
language evolution, let it be this.
Furthermore, any discussions of monads and/or HKT are pie-in-the-sky at
this point. Our complexity budget is
On 12/24/13 3:41 AM, Philippe Delrieu wrote:
Hello,
I try to capture a closure in a task and I have the error:
error: cannot capture variable of type `|u64, T|`, which does not
fulfill `Send`, in a bounded closure
Any hint to make the closure 'send-able'?
Try `'static |u64, T|` or `extern
In Closure there are no unbounded channels and this talk
http://www.infoq.com/presentations/clojure-core-async starting from
minute 22 describes that Closure explicitly does not support unbounded
channels and never will.
___
Rust-dev mailing list
I think we need them to handle the Web semantics though. We can't just drop
input events.
Igor Bukanov i...@mir2.org wrote:
In Closure there are no unbounded channels and this talk
http://www.infoq.com/presentations/clojure-core-async starting from
minute 22 describes that Closure explicitly
On Tue, Dec 24, 2013 at 1:56 PM, Patrick Walton pwal...@mozilla.com wrote:
I think we need them to handle the Web semantics though. We can't just drop
input events.
It would be better to use a bounded queue and report an error when it
gets to megabytes or gigabytes in size than going
Indeed! And the producer can always have their own private backlog. There
is nothing preventing each producer having it's one internal backlog queue
that's not bounded. But such behavior should be deliberate rather than
accidental.
On Tuesday, December 24, 2013, Daniel Micay wrote:
On Tue, Dec
Hi,
For a bit of holiday fun, I want to present a Rust implementation of
Knuth's man-or-boy http://en.wikipedia.org/wiki/Man_or_boy_test compiler
test. Can this be improved?
Here'shttp://rosettacode.org/wiki/Man_or_boy_testhow it looks in
other languages.
Right off the bat, I would say that
On 12/24/13 2:42 PM, Vadim wrote:
type T's = 's || - int;
fn man_or_boy(k:int) - int {
fn A(k:int, x1:T, x2:T, x3:T, x4:T, x5:T) - int {
let mut k = k;
let mut B: T = || {fail!()};
B = || {
k -= 1;
A(k, B, x1, x2, x3, x4)
};
Right off the bat, I would say that would be prettier if we had argument
auto-borrowing
I'm again pretty nervous about this, because this is one of the
much-maligned features of C++ references.
*Why* is it maligned, though?
and if closure
assignment was in scope to be captured inside the
On Tue, Dec 24, 2013 at 6:32 PM, Kevin Cantu m...@kevincantu.org wrote:
This seems like a false dichotomy. I'd rather ask: do we want the
scheduling library code to deliberately avoid resource exhaustion or
do we want the Servo code to deliberately avoid resource exhaustion?
Kevin
Bounded
On Tue, 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.
On second thought,
On 12/24/13 11:03 AM, Daniel Micay wrote:
On Tue, Dec 24, 2013 at 1:56 PM, Patrick Walton pwal...@mozilla.com wrote:
I think we need them to handle the Web semantics though. We can't just drop
input events.
It would be better to use a bounded queue and report an error when it
gets to
On Tue, Dec 24, 2013 at 9:48 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/24/13 5:45 PM, Daniel Micay wrote:
Bounded channels present the choice between blocking (with an optional
timeout) when the channel is full or making a non-blocking call with
custom handling of the error case.
On 12/24/13 5:45 PM, Daniel Micay wrote:
Bounded channels present the choice between blocking (with an optional
timeout) when the channel is full or making a non-blocking call with
custom handling of the error case.
I prefer the latter.
Unbounded channels don't provide a
way to write robust
On Tue, Dec 24, 2013 at 8:17 PM, Vadim vadi...@gmail.com wrote:
I'm again pretty nervous about this, because this is one of the
much-maligned features of C++ references.
Why is it maligned, though?
I malign it mainly because it allows (and encourages) confusing code
that looks like it's
On Tue, Dec 24, 2013 at 10:33 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 12/24/13 7:23 PM, Daniel Micay wrote:
I think the ability to deadlock is overstated... as it's not going to
happen without two-way communication. If you have clear consumers and
producers then it's not an issue
On 12/24/13 7:23 PM, Daniel Micay wrote:
I think the ability to deadlock is overstated... as it's not going to
happen without two-way communication. If you have clear consumers and
producers then it's not an issue you can hit. If you don't, then you
can still have a well-defined communication
22 matches
Mail list logo
