Skip to content
This repository

All Categories:

Rust meeting

  • LLVM bump (graydon)
  • hash function (graydon)
  • buildbot status (graydon)
  • remove modes? (graydon)
  • mutability / sendable maps (nmatsakis)
  • minor nomenclature shift (graydon)
  • operator overloading w/ coherence (pcwalton)
  • linked failure status, interface (bblum)
  • runtime-enabled condition variables (bblum)


  • graydon: various weird LLVM bugs, one of which prevents building w/ gcc 4.7...
  • graydon: ...and hence all modern linuxes and also mingw cannot build
  • graydon: will migrate to a more modern LLVM
  • eholk: can we use a canned LLVM release?
  • graydon: going to try 3.1 or 3.2
  • pcwalton: but we will still have patches on top of that, due to GC

Hash fn

  • graydon: everyone writes them and all of them use bad hash fns
  • graydon: turns out that there is a nice, new generic hash fn with nice properties that we can hopefully use everywhere (short input, cryptographic, can be keyed to a pseudo-random # per hashtable)
  • graydon: so if you find yourself writing a hash fn, stop, and try this one instead
  • graydon: basically the same construct used in the SHA3 candidates, real fast
  • nmatsakis: what about uninitialized / unused data
  • graydon: current just hashes a bucket of bytes, code adapting our data will have that problem
  • graydon: can we maybe just not have uninitialized bits?
  • nmatsakis: well, padding etc --- not unachievable just painful, runtime cost
  • pcwalton: a minor complication, one optimization I would like to start doing at some point is to save space when allocation a @variant that is immutably bound. Important for DOM nodes since size varies considerably.
  • nmatsakis: yeah, that'll complicate something like is_pod
  • graydon: deal with that when we come to it
  • pcwalton: how complete is the visitor? would love if we could throw away shape glue
  • graydon: haven't tested profoundly, but one thing it definitely doesn't do: interface instances ...
  • graydon: a little bit of a trade between code that drives visitation and the client code, since client code can decide when to recurse
  • graydon: not sure if it handles interfaces properly right now
  • pcwalton: one of the first things we could do is use it for hashing
  • pcwalton: the way I envision this working eventually is to have a hash trait with a default impl based on visitors
  • pcwalton: like Haskell's deriving but more extensible
  • nmatsakis: boxed interfaces are self-describing... should be able to work like other @T
  • graydon: what about closures?
  • nmatsakis: fn@ and fn~ should work, fn& no
  • pcwalton: maybe we don't even need that?
  • nmatsakis: by definition, everything in there is a borrowed ptr so GC won't care...
  • graydon: should basically work
  • nmatsakis: what about comparing pairs of values?
  • graydon: basic interface just visits types and knows nothing else
  • graydon: built on top of that various examples in the test suite, one of which visits pairs of pointers
  • graydon: now that the snapshot contains reflection interface should be able to move those into libcore
  • graydon: idea was to have a library in core called reflect which would abstract over the usual cases (walk data, value, etc)

Buildbot status

  • graydon: got a security review, security team did not find it particularly secure (sadly)
  • graydon: so in limbo right now discussing how to mitigate that problem, most likely by moving things (bot master?) into the data center
  • graydon: current plan is perhaps to publicly expose only HTTP

Removing modes

  • Need a transition plan
  • ...
  • nmatsakis: Summary of the plan
    • make an attribute that changes the default
    • send out an e-mail explaining the semantics of the options
    • also, develop a plan for things like vec::each() and vec::each_ptr()

Mutabilty / sending maps

  • ...
  • nmatsakis: will write up a blog post

Nomenclature Shift

  • graydon: rename shared boxes to managed boxes
  • graydon: could then rename ARC to shared

Operator Overloading and Coherence

  • pcwalton: if we add ability to export metadata... (which we need)
  • pcwalton: what we could do is say that there are some "magic" traits that implement the built-in operators
  • pcwalton: for example, an add trait Add with a method plus(T) and perhaps a plusEquals(T) method
  • pcwalton: if you want to override an operator, you implement that trait for your type
  • pcwalton: to reduce magic-ness, these would be in core and annotated with some special "intrinsic-plus-trait" annotation. only one such trait is permitted across all crates.
  • graydon: what does this buy us?
  • pcwalton: this buys us a way to do operator-overloading in a coherent setting
  • pcwalton: ensures that you can never have multiple methods in scope and never need to import the plus trait
  • graydon: this is a corrolary to inherent methods on a type...?
  • pcwalton: well, resolve is already somewhat involved, when you see a method call a.b(), resolve goes around and finds the traits that define b() (considering also inherent methods) and comes up with a candidate set. Type check is then based on this candidate set.
  • pcwalton: so this would change it so that if you have a + b the + method would always yield the method from the plus trait
  • pcwalton: to me the benefits are
    • never have to import traits for plus
    • plus-equals as a default method
    • simpler grammer (no methods)
    • mildly simpler resolve
  • eholk: some of the benefits of plusEquals() could be obtained by plus
  • pcwalton: ...might be that uniques are moved by default...
  • eholk: ...or at least uniques by default...
  • eholk: I sort of prefer writing fn+()
  • pcwalton: we can keep that around too, whatever people prefer
  • eholk: would be nice to be able to key on the type of the RHS
  • pcwalton: that's real, real overloading
  • graydon: I don't want to do that unless we have to
  • nmatsakis: we kind of have it, in the sense that you can setup ifaces that lead to overloading, but we fail to solve them so we don't have it


  • bblum: one thing that doesn't work is multiple generations of unidirectional failure
  • bblum: e.g. if grandkid dies but kid doesn't parent should die (But doesn't now)
  • bblum: You can:
    • link tasks bidirectionally (create a task group)
    • spawn tasks unlinked (their own group)
    • spawn tasks supervised (new task group, but if parent task group dies, new group dies) (spawning with failure prop error from self to new task)
  • bblum: method chaining interface is in (e.g., task().unlinked()....spawn())
  • bblum: various top-level spawns exist as shorthand (e.g., spawn_unlinked())
  • bblum: migrated code to use that instead of old builder interface, currently migrating servo
  • nmatsakis: what happens if I request notification, the task completes, and then someone else in the task group dies
  • bblum: non-deterministic, though you should only get one message
  • nmatsakis: maybe we can add an enhancement so that you can get a message when a task-group dies instead of an individual message? then you can choose what you want
  • bblum: task group is not a reified thing
  • bblum: graydon wanted ability to spawn into a task group, but I couldn't quite get it to make sense
  • ...
  • bblum: on a related note, exclusive arcs are currently protected by this rust_cond_lock thing which is basically a pthread mutex
  • bblum: condition variable behavior is totally broken (and currently disable) but mutex behavior is only a little bit broken. It does disable mutual exclusion but cannot accommodate yields since scheduler is not aware of locks that you hold.
  • pcwalton: one more reason that exclusive arcs are evil
  • bblum: same problem for cond. vars, since this really requires scheduler interfacing
  • bblum: I have a scheme for fixing this but code will have to be very, very clever to interact "properly" with task killing
  • nmatsakis: what is desired interaction with task killing?
  • bblum: let's say you've taken a cond lock and waited, and then your task group fails:
    • you should awaken and them immediately die
  • bblum: if you are contending on a mutex
  • ... complicated semantics discussion ensues ...
  • take it offline!
Something went wrong with that request. Please try again.