On 26/04/2013 17:06, Patrick Walton wrote:
On 4/25/13 10:42 PM, james wrote:
If not, I wonder if there should be more effort on the AIO layer first,
and then consider a synchronous shim on top.
That's exactly what's being done.
Patrick
OK. It wasn't clear whether the AIO layer was
On 27/04/13 13:33, Graydon Hoare wrote:
On 26/04/2013 6:47 PM, Huon Wilson wrote:
This change would double or triple throughput of random f64 generation
on 64-bit platforms compared to using the 32-bit algorithm (and
increase it 10-20x compared to calling the rng in the runtime, as is
done
On 27/04/13 15:28, Andrei de Araújo Formiga wrote:
As I have some interest in using RNGs in Rust, I'd like to chime in on
this.
The extra traits like RandomDistribution would be a good thing,
especially if it would be possible to plug a different, custom
generator than the one provided and
Hi everyone,
The reactions to this bug on impls [1] have caused me to think that the
current treatment of paths in generic type and trait implementations is
something of a wart and perhaps should be reworked. Specifically, the
problem is that this:
implT MyTypeT {
fn newU() -
Just thought I'd give the mailing list a heads up that ~string,
besides being ugly, is generally inefficient: it allocates a string on
the heap and frees it when it goes out of scope. There are no
optimizations that eliminate the allocation.
If you need to compare a `~str` against a constant
On 28/04/13 18:45, Patrick Walton wrote:
If you need to compare a `~str` against a constant string, use .equiv():
use core::cmp::Equiv;
fn main() {
let x = ~foo;
if foo.equiv(x) {
println(yep);
}
}
This should admittedly be imported by default.
On 4/28/13 10:57 AM, Lee Braiden wrote:
Really? Strings can't just be compared with == ? To be honest, that
alone is almost enough to put me off the language -- not only is it ugly
and unwieldy, but it suggests a lot of limitations in the language's
memory model / type system / operator
On Sun, Apr 28, 2013 at 1:57 PM, Lee Braiden leebr...@gmail.com wrote:
On 28/04/13 18:45, Patrick Walton wrote:
If you need to compare a `~str` against a constant string, use .equiv():
use core::cmp::Equiv;
fn main() {
let x = ~foo;
if foo.equiv(x) {
It seems to me that, by default, what we'd want is a sync api which
under the hood, creates one task per drive accessed, or maybe
max(drives_in_use, number_of_cores). I think the OS will make them
async with the drive hardware anyway, though, so number_of_cores doesn't
matter.
I don't think
It is very easy to create a language that is unwieldy, but hard to create something KISS simple that can be adopted, and that will be praised for its cleanliness and elegance.If the basic things are not simple, a language will be relegated to academia, and will not be as popular as hoped.We really
On 4/28/13 12:45 PM, her...@gmail.com wrote:
It is very easy to create a language that is unwieldy, but hard to
create something KISS simple that can be adopted, and that will be
praised for its cleanliness and elegance.
If the basic things are not simple, a language will be relegated to
Le 28/04/2013 21:49, Patrick Walton a écrit :
As Daniel pointed out, it isn't so bad. I didn't realize that we already
borrow on the left hand side, so you can write:
fn main() {
let x = ~foo;
if foo == x {
println(yep);
}
}
Using `if
On Sun, Apr 28, 2013 at 10:45 AM, Patrick Walton pwal...@mozilla.comwrote:
If you need to compare a `~str` against a constant string, use .equiv():
I have some code where I'm trying to match an owned string against a set of
constant strings, and it's not clear to me how to take your advice
In which case, would special-casing == and !=, as you mentioned
earlier, be a bad thing to do? (Sincere question; from a user pov it
would make sense, but I don't know whether it would make operator
overloading conceptually more ugly to have that special case in there)
martin
On Sun, Apr 28,
Really? Strings can't just be compared with == ? To be honest, that alone
is almost enough to put me off the language -- not only is it ugly and
unwieldy, but it suggests a lot of limitations in the language's memory
model / type system / operator overloading, which would also make my own
Hi,
Rust seems like a really excellent language. One feature that Rust doesn't
seem to have is a built-in list-comprehension syntax. Wikipedia points out
that macros can be used to simulate this feature, but the resulting syntax
is a bit clunky. Are there plans to add such a syntax to the
But you can't. In fact, you can't call static methods *at all* through
typedefs, meaning that this doesn't work:
This has bitten me a few times already, so I'm definitely in favor of
making it work if possible. The rest of your proposal sounds good to
me, although I can't speak for how easy it
On 04/28/2013 10:38 AM, Patrick Walton wrote:
Hi everyone,
The reactions to this bug on impls [1] have caused me to think that
the current treatment of paths in generic type and trait
implementations is something of a wart and perhaps should be reworked.
Specifically, the problem is that
Kenji Rikitake did similar work in Erlang a few years ago, suggesting
SIMD--oriented Fast Mersenne Twister (SFMT) as a replacement for the
random number generator in Erlang. I believe he also worked on
updating the old Wichmann-Hill generator code from a 1982 version of
the algorithm to a newer
On Sat, Apr 27, 2013 at 4:23 AM, Graydon Hoare gray...@mozilla.com wrote:
I think it has to be opt-in, yeah. Sadly. I mean, I wish we were living in
the world of hardware garbage collection and tagged memory words too, and
hensel codes had won out over floating point, and all our languages had
Ruby is one example of a language where == is not symmetric.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Was this some unsafe-language benchmark shootout? Even if those are
important due to some Rust is slow, clinical tests prove it bogo-PR
effect, I assume you would disable overflow checking along with array-bounds
checks in unsafe Rust code.
Clojure basically does this. By default, math
Apparently, you really DO NOT want to install Collabnet Subversion client
on your Windows system, or Tortoise SVN , because both of these default to
checking out with Windows style End Of Line: CRLF. Instead of UNIX style:
LF which is the default for Cygwin's installation.
My Subversion client
23 matches
Mail list logo
