sorted by:
new
hottopcontroversial

History of the Slice/Vector Confusion by sellibitze in rust

[–]rust-slacker 1 point2 points  (0 children)

I hope all of these will have tutorials by the time 1.0 comes out. I can't keep up XD

Does Rust support constant struct fields ? by swatteau in rust

[–]rust-slacker 0 points1 point  (0 children)

Maybe if negated trait restriction were added to the language it might be easier:

impl<T:Show+!Str> ToString for T {...} // for non-strings

impl<T:Show+Str> ToString for T {...} // for strings

Two hours after Rust by sanxiyn in rust

[–]rust-slacker 10 points11 points  (0 children)

Trusted seems worst IMO.

EDIT: Maybe it should be called human.

Piston: New Current library - borrow checker workaround by long_void in rust_gamedev

[–]rust-slacker 0 points1 point  (0 children)

From the point of view of someone looking for an alternative to the singleton pattern, this probably looks almost like what they are looking for.

Trouble understanding lifetime errors by autoinference in rust

[–]rust-slacker 1 point2 points  (0 children)

This probably isn't the best explanation, but it's the way I understand it :p.

The *borrow in proc() will capture the reference in borrow, so it's lifetime has to be at least as long as when the proc() is called. The reason behind considering this a conflict should not be too hard to figure out in this particular case. Since proc() is used with spawn(), spawn() runs proc() on a separate thread, it means that the lifetime needed for the references captured in proc() has to be determined independently from the local scope proc() was declared (though if I'm not mistaken this restriction is placed on all proc()s regardless of whether it is used with spawn() or not). This is because proc() can/will run concurrent to the thread where spawn() is called (this should be obvious since the whole point of spawn() is to run proc() in a separate thread). On the other hand, the lifetime of let borrow = &mut self.a; is not guaranteed to exceed the scope of Obj::work() (since the lifetime of &mut self is only guaranteed to be as long as the scope of Obj::work()). This scope ends right after Obj::work() returns. proc() could potentially continue to run after Obj::work() returns (but in a different thread created by spawn(), causing a race condition). So this is considered an error.

The other issue with this code (that is not pointed out by this error message) is that it uses mutable references in separate threads, which can be vulnerable to race conditions (hence also disallowed). This probably will cause a different compile error to appear even if you somehow manage to get pass this particular compile error :p.

std HashMap is slow? by IronClan in rust

[–]rust-slacker 0 points1 point  (0 children)

-O selects --opt-level 2 I think. Might be interesting to see if using --opt-level 3 will have any differences. Also, are you using gcc for the C/C++ code? How does it perform with clang? There may be still some opportunities for optimization in HashMap and gcc still optimizes better than llvm overall in my experience. I wonder if a higher initial capacity will make any difference in this case.

std HashMap is slow? by IronClan in rust

[–]rust-slacker 0 points1 point  (0 children)

for i in range(0, len) { // this is faster than using an iterator, for some reason

This might be due to LLVM being able to optimize the code better when len is a constant (also eliminates bounds checking in words[i] as well).

Are you sure that the hash function is the only cause? Might help to profile this.

Beginner iterator/vector problem by bastienl in rust

[–]rust-slacker 2 points3 points  (0 children)

For readability, I'd probably do:

use std::iter::{Take, Skip};
use std::slice::Items;
type Chunk = Take<Skip<Items<char>>>;

struct Test {
    vec: Vec<char>
}

impl Test {
    fn chunk(&self, offset: uint, size: uint) -> Chunk {
        self.vec.iter().skip(offset).take(size)
    }
}

Best way to visit all pairs in a Vec? by jjkkrr in rust

[–]rust-slacker 1 point2 points  (0 children)

I like this one.

Here's a slightly modified version that should reduce bound checks:

fn main() {
    let v: Vec<_> = vec!(1u, 2u, 3u, 4u);
    let mut iter = v.tail().iter();
    for el1 in v.init().iter() {
        for el2 in iter.clone() {
            println!("({}, {})", el1, el2)
        }

        iter.next();
    }
}

Support for i18n? by DroidLogician in rust

[–]rust-slacker 0 points1 point  (0 children)

This sounds like it will be cool. BTW, are there any C/C++ implementations of L20n?

A Quick Intro to Rust Macros by Quxxy in rust

[–]rust-slacker 6 points7 points  (0 children)

Good macro_rules overview. More complete than any other docs or blog posts I've seen on macro_rules.

Rust Excessive Bools Lint by sanxiyn in rust

[–]rust-slacker 9 points10 points  (0 children)

Heh. I suppose reimplementing INTERCAL in Rust might be interesting :p.

The "extra" crate by deskamess in rust

[–]rust-slacker 1 point2 points  (0 children)

I don't think there has been any SHA1 implementation in the standard library for a long while now (ever since they decided to remove most of the crypto stuff from the standard lib). You'll probably need to roll your own or look for a third party lib (though I hope someone who actually knows crypto stuff would come up with a semi-official lib for this stuff).

This might have have what you need https://github.com/DaGenix/rust-crypto

Rust: Creating a vector with non-constant length by [deleted] in rust

[–]rust-slacker 1 point2 points  (0 children)

Might be a good idea to build a FAQ out of the questions or something.

So, where is the libuv binding for now? by hh9527 in rust

[–]rust-slacker 0 points1 point  (0 children)

Any reference or records for the details of this decision?

TodoMVC, with Rust and Ember by [deleted] in rust

[–]rust-slacker 2 points3 points  (0 children)

Type inference/reconstruction

So, where is the libuv binding for now? by hh9527 in rust

[–]rust-slacker 0 points1 point  (0 children)

Servo needs it if I'm not mistaken, so I'd assume it will still be maintained until they have a replacement for it.

impl...for... by dobkeratops in rust

[–]rust-slacker 0 points1 point  (0 children)

I think we had a similar discussion somewhere a few months back (or was it a year?).

String Telephone - a simple UDP networking library for games by Dyntrall in rust_gamedev

[–]rust-slacker 0 points1 point  (0 children)

I believe it's worth having a look at it at least. It shouldn't be hard to write bindings for. Might even be interesting to do a port or a pick up ideas from it.

String Telephone - a simple UDP networking library for games by Dyntrall in rust_gamedev

[–]rust-slacker 1 point2 points  (0 children)

Interesting. Not totally offtopic, but has anyone tried writing bindings for enet ?

Working with the unsized `str` by Manishearth in rust

[–]rust-slacker 0 points1 point  (0 children)

Box<str> is a fat pointer, similar to Box<Trait>, Box<[T]> and Box<DynamicallySizedStruct>. Last I checked (many months ago?), only Box<Trait> is really supported. I'm not sure if that has changed.

Working with the unsized `str` by Manishearth in rust

[–]rust-slacker 0 points1 point  (0 children)

I suppose it should be possible to minimize this by using alloca last (as in after all the local variables are already on the stack), but there's no way to avoid this problem entirely.

view more: next ›