On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman wrote:
> If you don't mind changing ntimes to not return a closure:
>
> fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T {
> match times {
> 0u => x,
> _ => ntimes(|x| f(x), times - 1u, f(x))
> }
> }
>
> fn main() {
> p
Hi,
just checking performance wise, is num::cast() doing a dynamic type cast or
a static cast.
I'm writing some template code that works on Real and I need sometime to
divide T:Real by 2 or compate with 0 or 1.
I've been using num::zero() and num::one() so far but how about dividing by
2?
shoul
Yes, it's a static cast, so llvm should optimise that out.
Do note however that the API has changed in 0.9-pre, and num::cast now returns
an Option. So your code would be:
~~~
let res: T = aVariable / num::cast(2).unwrap();
~~~
LLVM should resolve the conditional at statically - I haven't check
Hello rust hackers,
In section 8.1.7 of the Rust manual ("Recursive types"), there is an
example of a List definition which is recursive. Here I define a very
simple arithmetic expression which consists of numbers and add
expressions. When I compile it I get errors..
enum Expr
{
Num(int),
I assume the compiler suggests you replace @Expr with Rc (Rc is
defined in std::rc). This means you wouldn't be able to create cycles (that
is, expressions must form a tree, or at most a DAG), and that there would
be the overhead of reference counting when you create new expressions,
clone the poin
Yes, Oren is right here. You probably want to be using ~s rather than @s.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
If you use ~Expr instead of @Expr, then the expressions would have to form
a tree (A = B + C). If you use Rc, you could build a DAG (A = B + B).
With @Expr (if that worked), in principle you could allow for cycles (A = B
+ A), which is probably not what you want.
On Mon, Oct 28, 2013 at 8:25 PM,
On Mon, Oct 28, 2013 at 2:27 PM, Oren Ben-Kiki wrote:
> If you use ~Expr instead of @Expr, then the expressions would have to form
> a tree (A = B + C). If you use Rc, you could build a DAG (A = B + B).
> With @Expr (if that worked), in principle you could allow for cycles (A = B
> + A), which is
Right, it would have to be @mut Expr to allow for cycles... and you'd have
to really work hard to construct the cycle. At any rate, this isn't what
you'd want - very probably just using ~Expr would be enough.
On Mon, Oct 28, 2013 at 8:29 PM, Daniel Micay wrote:
> On Mon, Oct 28, 2013 at 2:27 PM
On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote:
> On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman
> >
> wrote:
> > If you don't mind changing ntimes to not return a closure:
> >
> > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T {
> > match times {
> > 0u => x,
> >
On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote:
> On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman
> >
> wrote:
> > If you don't mind changing ntimes to not return a closure:
> >
> > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T {
> > match times {
> > 0u => x,
> >
On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote:
> On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman
> >
> wrote:
> > If you don't mind changing ntimes to not return a closure:
> >
> > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T {
> > match times {
> > 0u => x,
> >
Hi,
Just a mail to inform about updates on "Default arguments and keyword
arguments" feature request.
Since the creation of the pad, a lot of text has been written on the
pad, here is a small summary:
- Pros / Cons about the feature (actually, there is more pros than cons)
- Indications about feat
Welcome to another issue of *This Week in Rust!* This week marks the addition
of some more feature gates, removal of `std::io`, and some feature proposals.
# What's cooking on master?
47 PRs were merged this week, and we passed issue number 1.
## Breaking Changes
- Most of the crypto in the
Hi Corey,
I just wanted to thank you for the "This Week in Rust" notes. I love
reading them and I am sure that I am not the only one who appreciates the
effort that you put into each one.
Cadence
On Mon, Oct 28, 2013 at 5:48 PM, Corey Richardson wrote:
> Welcome to another issue of *This Wee
> I just wanted to thank you for the "This Week in Rust" notes. I love
> reading them and I am sure that I am not the only one who appreciates the
> effort that you put into each one.
+1!
These are great. They are the easiest way for us on the Servo team to
estimate how much work we'll need to d
Greetings fellow Rustians!
First of all, thanks for working on such a great language. I really like
the clean syntax, increased safety, separation of data from function
definitions, and freedom from having to declare duplicate method prototypes
in header files.
I've been working on an alternate w
I've written up more thoughts on stack safety at
http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one
objects to it (meeting tomorrow!) or has any better ideas, I'll start
implementing it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
ht
Hi Simon ,
You may want to test the througput of tasks first to set a base line.
Disruptor is faster but normally runs in a tight loop ( or a yield loop) so
pretty much tying up a core ( even when yielding it will run again very
soon , its the fact that its always running which makes it very fas
19 matches
Mail list logo
