shadowmint

Seems like it's been quite a while since the survey closed?

Anyone know how it's getting along in terms of processing the submissions / when the results will be out?

Just and FYI for anyone who wasn't watching this closely, because things were looking pretty bleak a few days ago.

http://www.kicktraq.com/projects/1346708779/arachne-rapid-web-development-for-clojure/#chart-daily

Exciting to see where it goes from here~

I naively assumed this was the case, but... I often encounter statistically extremely unlikely coincidences in the game, if you say the draw is entirely random.

For example, I've several times discarded two cards to start, and got... the same two cards back. Both legendary.

Statistically, the chances of this happening are like 1/29 * 1/28 -> about 1/812. That's a bit less common than a Full House in poker (1/695).

Just anecdotally, a lot of people I've talked to have noticed:

• 1. Play game, dont see any of card XXX or card YYY
• 2. Play game 2 immediately afterwards, get multiple instances of XXX and YYY, often in starting hand.

or

• 1. Play game
• 2. Get down to < 10 cards

I've spent a considerable amount of time in the last few days getting this working.

I could write a whole blog post about how crazy the build system is, but I think I'll just leave this here for now:

https://github.com/shadowmint/ue4-static-plugin/

It's a UE4 plugin that directly imports a rust library using fake C headers; it also shows how to use external C++ libraries in the same way.

Hopefully it'll make the life of the next person who needs to do this a bit easier. :)

(Example project using the plugin here: https://github.com/shadowmint/ue4-sample-project)

Don't forget to initialize your submodules if you play with it~

So...

I've read https://wiki.unrealengine.com/Unity3D_Developer%27s_Guide_to_Unreal_Engine_4

...and I thought to myself, why not, this sounds like it'll be an interesting thing to play with. Let's give it a whirl shall we?

I have to say, nothing but disappointment here.

Here's a quick list of things that weren't awesome:

• The engine has gone out of its way to make using 'blueprints' the preferred way for scripting.

However, the power of having the source for the engine and being able to 'debug' issues directly only applies if you don't actually use blue prints.

Blue prints are cool, but only when you actually write C++ for them to use. I'm so completely not interested in writin

So the nightly with this lint has landed. It's pretty harsh:

• box isnt stable
• io isnt stable
• random isnt stable
• fs isnt stable
• string slices aren't stable
• timer isnt stable
• sync isnt stable
• fmt::Show isn't stable

(full list: http://doc.rust-lang.org/std/stability.html)

Ouch.

I know there are going to be a bunch of last minute changes before the alpha lands, but as a first pass, this is far far worse than I was expecting.

What's the process of gathering feedback as to what api's will become stable / will remain unstable during the alpha?

That list looks pretty scarey at the moment to me; I can't see how anyone is going to be writing anything that's 1.0 compatible at the

Is there a master list somewhere, of what feature gates will disappear by/in 1.0?

I know it's only a few days away from the first stable alpha, but in the 'getting ready for 1.0', I've been slowly trying to roll back the feature gates I use in my various crates and I'm still seeing errors when I remove them, notably for unsafe_destructor and macro_rules?

Similarly, is there a cargo flag for 'lint for use of unstable api'? I see rustc has --warn unstable, but I'm just been trawling through cargo issues about passing flags to rustc and I can't see any obvious way of doing it?

I was looking through the source for Any, and I see this in the comments:

//! Traits for dynamic typing of any `'static` type (through runtime reflection)
//!
//! This module implements the `Any` trait, which enables dynamic typing
//! of any `'static` type through runtime reflection.

...but no justification for that. Digging a bit deeper, it seems it might be because it uses TypeId::of::<T>(), which is an intrinsic:

extern "rust-intrinsic" {
    ...
    /// Gets an identifier which is globally unique to the specified type. This
    /// function will return the same value for a type regardless of whichever
    /// crate it is invoked in.
    p

I keep stumbling on an slightly annoying use-case that has me copy-pasting code when I feel like there should be a better way.

Basically, imagine you have a trait Logs:

pub trait Logs {
    fn log(&mut self, msg:&String);
}

Now, you implement that Logs for a bunch of log handler types: ConsoleLogger, FileLogger, NetworkLogger, SqliteLogger, etc.

I seem to find myself writing tests like this:

#[cfg(test)]
mod test {

    use super::FooLogger;
    use logger::Logs;

    fn instance() -> Box<Logs + Send> {
        return box FooLogger::new() as Box<Logs + Send>;
    }

    #[test]
    fn test_logs_empty_value() {
  

Can someone explain clearly to me what Cargo.lock is, and why it exists?

The guide (http://crates.io/faq.html#why-do-binaries-have-cargo.lock-in-version-control,-but-not-libraries?) says:

The purpose of a Cargo.lock is to describe the state of the world at the
time of a successful build. It is then used to provide deterministic 
builds across whatever machine is building the project by ensuring that 
the exact same dependencies are being compiled.

...but my cargo.toml has explicit versions in it:

 [dev-dependencies.fixture]
 git = "https://github.com/shadowmint/rust-fixture"
 tag = "0.1.2"

There's no confusion here.

Why do you need a separate file that just