Re: [rust-dev] rust-dev will be shut down soon

[Brian Anderson]

Tomi,

Once the new discourse instance is set up it will be publicized on the home
page, and we may also decide then to put the internals forum there as well,
since it's purpose will be less easily confused.

On Thu, Jan 22, 2015 at 10:33 PM, Tomi Pieviläinen 
wrote:

> My last comment about visibility of the discourse pretty much
> immediately side-tracked into the merits and flaws of mailing lists...
> But nobody really answered whether the absence of links from the Rust
> homepage to the discourse was intentional.
>
> Does internal use then mean that it is meant only for those "in the
> know", and only the future general discourse will be put on the home
> page? At least I'm interested in following the dev discussion, even if
> I'm not an insider, and I heard of it purely by accident.
>
> --
> Tomi Pieviläinen, +358 400 487 504
> A: Because it disrupts the natural way of thinking.
> Q: Why is top posting frowned upon?
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] rust-dev will be shut down soon

[Brian Anderson]

You likely have already noticed, but traffic to rust-dev has decreased
dramatically in recent months. This was a result of natural changes in
project coordination at first, and then an intentional effort to phase out
the list.

In the beginning of the project there were only two places to talk about
rust: #rust and rust-dev, and they served us well for all purposes for
several years. As Rust grew though the coordination of the project moved to
different venues, conversations were happening in a number of other places,
and the purpose of rust-dev became less clear. At the same time there were
also a number of heated and essentially unmoderatable discussions that
caused many to lose faith in the effectiveness of the mailing list.

For the last few weeks the existence of rust-dev has no longer been
publicly advertised, and yesterday I made the request to Mozilla IT to shut
down the list for good. The archives will remain available since they
provide information of potential historical interest. I know some people
prefer mailing lists and to them I offer my regrets.
As of now these are the recommended places to discuss Rust:

* https://discuss.rust-lang.org - Project coordination ('internals'
discussion) and design discussion
* https://github.com/rust-lang/rfcs - PR's for fully-baked near-term
proposals, and the issue tracker for longer-term designs
* https://stackoverflow.com/questions/tagged/rust - Specific questions
about how to use the language
* http://reddit.com/r/rust - Links, news, announcements, discussions
* The various IRC channels

In the coming weeks we will also set up a second Discourse instance for
general Rust discussion (compared to the current one at
discuss.rust-lang.org which is for 'internals'). The intent is to provide a
place for all types of discussion about Rust that will scale to the needs
of the project as it grows, and to replace some of the remaining role of
rust-dev as a general discussion forum. It is not intended to replace
either StackOverflow nor Reddit, but to complement them by accommodating
types and volumes of content that may be less appropriate for those venues.

Some of the recent conversations on this topic are:

* http://discuss.rust-lang.org/t/is-it-time-to-kill-the-mailing-list/611/45
*
https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-01-20.md
*
https://www.reddit.com/r/rust/comments/2t405p/weekly_meeting_20150120_goodbye_view_items_deref/

Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Cross-compilation with plugins is effectively dead?

[Brian Anderson]

I'm not familiar with this bug, but cross-compilation is very important to
Rust and I do consider this a real bug.

On Sat, Jan 10, 2015 at 4:33 PM, Vladimir Pouzanov 
wrote:

> I have some concerns related to
> https://github.com/rust-lang/rust/issues/18699 and I'd like to get some
> advice from the team.
>
> Support for cross-compiling code with plugins was broken for a few months
> now for anything but linux. Finally it seems to be broken for linux as well
> halting all our efforts.
>
> How important is cross-compilation support for rust at all? zinc is barely
> the only embedded project based on rust but we do use plugins and macros
> extensively throughout the code and we can't just stop using them,
> unfortunately; so for us any breakage of plugins system is a halt. We can
> deal with internal libs changing syntax but fixing up compiler itself is
> not that easy.
>
> Any chance we'll see it fixed before 1.0 hits?
>
> --
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] First Rust gathering in Beijing, China - 17 January 2015

[Brian Anderson]

I added rust.cc to the list of user groups on the wiki: 
https://github.com/rust-lang/rust/wiki/Docs


On 12/11/2014 02:53 AM, Fantix King wrote:
This is great! Definitely a must-to-attend! I'll post this great news 
in a local QQ group of Chinese Rustaceans (also http://rust.cc community)


Thanks a thousand for organizing this!


BR,
Fantix
--
http://about.me/fantix

On Thu, Dec 11, 2014 at 6:45 PM, Jakub Bukaj > wrote:


Hello Rustaceans!

I am pleased to inform you that there will be a Rust meet-up in
Beijing, China on Saturday, the 17th of January 2015. Mozilla China
has kindly agreed to host us at their Beijing office so we'll meet
there at 14:00.

I will be visiting Beijing at that time and will hold an introductory
session about Rust and Servo. Otherwise we'll keep it fairly free-form
and I hope there'll be lots of interesting discussions about
developments in the Rust ecosystem. If you're in Beijing and would be
interested in giving a talk about a community project or even your own
project using Rust, please do let me know! :)

See the Eventbrite page for this event:
https://www.eventbrite.com/e/rust-meet-up-in-beijing-tickets-14905925023.
There will also be more details about the gathering posted on the
community website. [0]

I hope to see you there!
Jakub

[0] http://mozilla.com.cn/
___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Compiling static binary

[Brian Anderson]

I believe it is not possible to link to glibc statically. My 
understanding is that to get a Rust binary that does not depend on a 
system-provided libc at all we need to add explicit support for 
alternate libc implementations[1].


[1]: https://github.com/rust-lang/rust/issues/7283

On 11/15/2014 01:02 PM, Kai Noda wrote:

Hi Paul,

I managed to get it working by manually tweaking linker options (this 
mustn't be the right way to go...)


Rust devs: what is the official way to do this?  Simply adding "-C 
link-args=-static" doesn't work (see my second transcript)


$ cat hello-rust.rs 
fn main() {
println!("Hello, world!");
}
$ rlibs=`rustc -Z print-link-args hello-rust.rs  
| sed -e 's/ /\n/g' | grep rlib`

$ echo $rlibs
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libnative-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libsync-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustrt-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode-4e7c5e5c.rlib'
'/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-4e7c5e5c.rlib'
$ rustc -Z print-link-args --emit obj hello-rust.rs 
$ file hello-rust.o
hello-rust.o: ELF 64-bit LSB relocatable, x86-64, version 1 
(GNU/Linux), not stripped
$ eval "gcc -static -static-libgcc hello-rust.o `tr $'\n' ' 
'<<<$rlibs` -lpthread -lm -ldl -lrt -o hello-rust"
/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.rlib(std-4e7c5e5c.o): 
In function `dynamic_lib::dl::open_internal::hda8e305d06a14b844og':
std.0.rs:(.text._ZN11dynamic_lib2dl13open_internal20hda8e305d06a14b844ogE+0x8): 
warning: Using 'dlopen' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/home/nodakai/local/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.rlib(std-4e7c5e5c.o): 
In function `io::net::addrinfo::get_host_addresses::hf208fefd6f07b89awSi':
std.0.rs:(.text._ZN2io3net8addrinfo18get_host_addresses20hf208fefd6f07b89awSiE+0xad): 
warning: Using 'getaddrinfo' in statically linked applications 
requires at runtime the shared libraries from the glibc version used 
for linking

$ file ./hello-rust
./hello-rust: ELF 64-bit LSB executable, x86-64, version 1 
(GNU/Linux), statically linked, for GNU/Linux 2.6.24, 
BuildID[sha1]=0x7fa2ba5ebdec633b220a8e9c988c4632b26a17d9, not stripped

$ ./hello-rust
Hello, world!
$ ls -l hello-rust
-rwxrwxr-x 1 nodakai nodakai 4.3M 11月 16 04:41 hello-rust*


$ x=`rustc -Z print-link-args hello-rust.rs `
$ y=`rustc -C link-args=-static -Z print-link-args hello-rust.rs 
`

$ diff <(tr ' ' $'\n' <<< $x) <(tr ' ' $'\n' <<< $y)
13d12
< '-pie'
39a39
> '-static'
$ file hello-rust
hello-rust: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, 
BuildID[sha1]=0x3a723f38042703be0ad45679b53220ce5f21787d, not stripped

$ LANG=C ./hello-rust
zsh: no such file or directory: ./hello-rust (<-- ENOENT, ie. invalid 
executable)


Regards,
Kai

野田  開 mailto:noda...@gmail.com>>

2014-11-16 0:40 GMT+08:00 Paul Colomiets >:


Hi,

Is there any way to compile static binary with rust compiler? I'm
experimenting with linux conainerisation and it would be much easier
if I could compile a binary which doesn't depend on libc.

There is also an stack overflow question with no answer:
http://stackoverflow.com/questions/26202494/portable-binaries-with-rust

Thanks in advance!

--
Paul
___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Rust 0.12.0 released

[Brian Anderson]

ie John 
Alisdair Owens 
Amy Unger 
Andreas Tolfsen 
Andrew Dunham 
Andrew Poelstra 
Angus Lees 
Anton Lofgren 
Ariel Ben-Yehuda 
Arjan Topolovec 
Arpad Borsos 
Austin Bonander 
Ben Gamari 
Ben Noordhuis 
Benjamin Adamson 
Benjamin Herr 
Bheesham Persaud 
Birunthan Mohanathas 
Björn Steinbrink 
Brendan Zabarauskas 
Brian Anderson 
Brian Campbell 
Brian Koropoff 
Cameron Zwarich 
Carol Nichols 
Chris Morgan 
Chris Nixon 
Christoph Burgdorf 
Chuck Ries 
Clark Gaebel 
Cole Mickens 
Colin Davidson 
Conrad Kleinespel 
Corey Ford 
Corey Richardson 
DJUrsus 
Damien Grassart 
Damien Radtke 
Dan Albert 
Dan Burkert 
Dan Connolly 
Dan Schatzberg 
Daniel Brooks 
Daniel Hofstetter 
Daniel Micay 
David Vazgenovich Shakaryan 
Derecho 
Derek Harland 
Dzmitry Malyshau 
Eduard Burtescu 
Eduardo Bautista 
Edward Wang 
Erick Tryzelaar 
Evan Klitzke 
Falco Hirschenberger 
Felix Raimundo 
Felix S. Klock II 
Florian Gilcher 
Florian Hahn 
Florian Zeitz 
Gioele Barabucci 
Guillaume Pinot 
Hugo Jobling 
Huon Wilson 
Ilya Dmitrichenko 
Ivan Petkov 
Jack Heizer 
Jake Kaufman 
Jake Scott 
Jakub Wieczorek 
James Hurst 
James Lal 
James Rowe 
Jason Fager 
Jason Thompson 
Jauhien Piatlicki 
Jimmie Elvenmark 
Jiří Stránský 
John Clements 
John Gallagher 
John Kåre Alsaker 
John Schmidt 
Jonas Hietala 
Jonathan Bailey 
Jonathan Boyett 
Jonathan Reem 
Jonathan S 
Jorge Aparicio 
Joseph Crail 
Joseph Martin 
Julian Orth 
Jyun-Yan You 
Kasey Carrothers 
Keegan McAllister 
Kevin Ballard 
Kevin Butler 
Kevin Mehall 
Kevin Walter 
Kiet Tran 
LemmingAvalanche 
Liigo Zhuang 
Luqman Aden 
Manish Goregaokar 
Markus Unterwaditzer 
Martin Olsson 
Marvin Löbel 
Matej Lach 
Mateusz Czapliński 
Mathijs van de Nes 
Matt Brubeck 
Matt Coffin 
Michael Gehring 
Michael Kainer 
Michael Matuzak 
Michael Neumann 
Michael Sproul 
Michael Woerister 
Mike Boutin 
Mike Robinson 
NODA, Kai 
Nathan Froyd 
Nathan Typanski 
Nick Cameron 
Nick Howell 
Niko Matsakis 
O S K Chaitanya 
OGINO Masanori 
Oren Hazi 
P1start 
Pablo Brasero 
Palmer Cox 
Paolo Falabella 
Patrick Reisert 
Patrick Walton 
Patrick Yevsukov 
Peer Aramillo Irizar 
Peter Atashian 
Peter Marheine 
Peter Minten 
Phil Dawes 
Philipp Gesang 
Piotr Czarnecki 
Piotr Jawniak 
Prudhvi Krishna Surapaneni 
Pythoner6 
Rahul Horé 
Randati 
Ricardo M. Correia 
Richard Diamond 
Richo Healey 
Robert Clipsham 
Robert Gawdzik ☢ 
Russell 
Ruud van Asseldonk 
Samuel Neves 
Santiago Pastorino 
Sebastian Zaha 
Sebastien Martini 
Seo Sanghyeon 
SiegeLord 
Simon Persson 
Simon Sapin 
Squeaky 
Steve Klabnik 
Steven Fackler 
Stuart Pernsteiner 
Ted Horst 
Till Hoeppner 
Tim Joseph Dumol 
Tobba 
Tobias Bucher 
Tom Jakubowski 
Tshepang Lekhonkhobe 
Vadim Chugunov 
Valerii Hiora 
Victor Berger 
Vinzent Steinberg 
Vladimir Pouzanov 
Yazhong Liu 
Yuri Albuquerque 
Zbigniew Siciarz 
dgoon 
donkopotamus 
fort 
gamazeps 
inrustwetrust 
jamesluke 
joaoxsouls 
klutzy 
kwantam 
masklinn 
mdinger 
mitchmindtree 
nham 
smenardpw 
tinaun 
ville-h 
wickerwaka 
zzmp 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust crypto highlights

[Brian Anderson]

Thanks for the updates, Tony.

On 09/29/2014 10:39 PM, Tony Arcieri wrote:
I've been trying to keep an eye on what's been brewing in the Rust 
crypto-world. There's a lot of parts that people have been working on 
that I'd really love to see brought together in a coherent manner, 
perhaps in the form of an (out-of-tree) common crypto library for 
Rust. Here are a few highlights:


- common.rs : a cool library with 
a terrible name! This library implements SBufs 
: secure 
buffers with guard pages, suitable for storing keying material. I 
would still love to see this extended to do RAII-style memory 
protection that sets PROT_NONE on buffer pages when they're not in use


- rust-constanttime 
: [ WARNING: 
BROKEN DO NOT USE ] a library similar to Go's crypto/subtle 
: data types that try to ensure 
constant-time operations, unfortunately LLVM is really smart and likes 
to performance optimize by adding branches even when you really don't 
want it to. If someone knew of a way to make it actually verifiably 
constant time, that would be amazing.


I've been told by LLVM folks that getting LLVM to do constant time code 
generation is essentially hopeless, and it should just be written in 
asm. One could start by compiling with LLVM, then hand-inspecting the 
output.




- suruga : a Rust implementation of 
TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have 
to use OpenSSL? ;) This seems like it could benefit from SBufs and 
rust-constanttime, if they were fully baked. Right now it does no 
memory protections around keying material or internal cipher state.


--
Tony Arcieri


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] minor problem with "amke install"

[Brian Anderson]

Thanks, Kevin!

On 09/05/2014 01:03 PM, Kevin Ballard wrote:

I submitted a PR yesterday in response to this thread that fixes `sudo make 
install` to drop the root privs for everything except the actual installation: 
https://github.com/rust-lang/rust/pull/17009

-Kevin


On Sep 5, 2014, at 5:00 AM, John McKown  wrote:

On Thu, Sep 4, 2014 at 8:59 PM, Brian Anderson  wrote:

Thanks for the report. It's probably
https://github.com/rust-lang/rust/issues/13728. This is an easy first bug to
fix if somebody wants to jump on it.


Thanks for that link. I had some minor surgery yesterday, in the
morning, and was a bit "tipsy" the rest of the day. Including when I
sent the message. Which, somewhat, explains the poor grammar and
spelling. But only somewhat. I will look at those issues in github
before asking questions again, just to be sure that I'm not wasting
anybody's time. In this particular case, the solution, for me, is a
simple "sudo find" to chown the files. I might even be good enough to
figure out how to _properly_ do that during the "make install"
processing. If I do, I'll look up how to submit a change. I imagine it
is in the documentation somewhere. And, obviously from posting a gist,
I have a github account that I can use so that the maintainers could
just do a pull from my copy.

OOPS, time to go.


--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] minor problem with "amke install"

[Brian Anderson]

Thanks for the report. It's probably 
https://github.com/rust-lang/rust/issues/13728. This is an easy first 
bug to fix if somebody wants to jump on it.


On 09/04/2014 06:57 PM, John McKown wrote:

I run as a normal user (non-root) on Linux using Fedora 20 x86_64. I
did a git clone of rust just for fun and to learn. I then did:
,.configure && make all && sudo make install

The sudo make install worked, placing tge rust programs in /var/local.
However, it also left almost 4000 files behind in subdirectories under
the rust directory in my $HOME and they are owned by root. I do _not_
consider this to be a nice thing to do. These are the rust/tmp
subdirectory and the others are scattered under rust/doc.

The file containing the output from:

find rust -user 0 -ls
iis 464K in size, 3959 lines.
compressed with xz, the compressed size is 43K. I was going to attach
that file to this email, but then felt that would be unkind and likely
violate forum rules. So I have created a public gist on github. It is
here: https://gist.github.com/JohnArchieMckown/69104fcfde6835eb4d9f

Thanks for listening.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust Meetup in Seattle Sept 8

[Brian Anderson]

I will ship stickers to anybody doing promotion for Rust. Email me your 
shipping address and the quantity in private.


On 08/27/2014 02:31 PM, Paul Nathan wrote:


Hi,

Sept 8 is the next meet up time for Rust in Seattle. While I could get 
my fine employer to host again, I think another venue would be nice 
for people who don't care to come downtown after 6.  The venue should 
be able to hold 4-10 people.


It would also be nice to get some presentations prearranged. Cargo has 
been bruited about as a black box that would be nice to learn more about.


Thanks,
Paul

P.S., this marks the fourth Seattle Rust meet up. I wonder how 
stickers could be arranged. Is there a Mozilla rep in Seattle that 
could help out here? :)




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Cleaner and more visible llvm options?

[Brian Anderson]

Right now the options are to use the default in-tree build, or your own 
out-of-tree build. The out-of-tree build is risky because it doesn't 
carry our patches and isn't tested.


You are suggesting that we also provide official LLVM snapshots. This 
has been considered many times but never done for a few reasons: the 
time and effort to set up more automation; the LLVM build happens "once" 
and then it doesn't get rebuilt (of course in practice people rebuild 
LLVM pretty often); with more people using binaries and not building 
from source the pain isn't universal. Basically, it's never been painful 
enough to fix.


I opened a bug at least: https://github.com/rust-lang/rust/issues/16796

On 08/27/2014 11:23 AM, Manish Goregaokar wrote:
A few days ago I was setting up a clean Rust build, and I wanted to 
avoid the llvm build.


For some reason, the apt-get install from the Travis file didn't work 
-- there were gpg issues. Eventually I ended up using Servo's llvm 
snapshot. Which was fine with me.


However, the only reason I knew that we could do this was because I've 
worked with Rust's travis file before and knew that llvm could be 
apt-get'ed with some gpg jugglery.


Today, a friend of mine was trying to build Rust, and he had no clue 
about this -- so went to build LLVM. LLVM takes /very/ long to compile 
-- perhaps we should make the apt-get alternative more visible 
somehow? Compile times can be a put off to newbies.


Even better, provide our own llvm snapshot on rust-lang.org 
 that gets downloaded with the right configure 
flag, perhaps even making this the default option. Servo does this for 
Rust, and it's a rather smooth experience.


-Manishearth


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] [ANN] RACER integration for Sublime Text

[Brian Anderson]

Awesome, Glenn! Thanks. Racer all the things.

On 08/25/2014 02:54 PM, Glenn Watson wrote:

Hi,

I've started a simple integration of the RACER code completion utility 
for Sublime Text 3.


Source code (and more information) is available here:
https://github.com/glennw/RustAutoComplete

You can install it through Package Control:
https://sublime.wbond.net/packages/RustAutoComplete

Pull requests for new features or fixes are welcome!

Cheers

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] SF Hack night topics

[Brian Anderson]

If I want to hack on zinc, what do I need? Should I bring some type of 
hardware? I have no experience with Arduino, etc.


On 08/13/2014 08:39 PM, Alan Andrade wrote:

Hi Rusties,

The first SF hack night is happening next Tuesday 
 and we 
still need to decide what topics we’ll jump into.
Following the lead of @cmr and his latest blog post 
http://blog.octayn.net/blog/2014/07/15/state-of-rust-0.11.0/, we will 
be hacking the following projects:


- Zinc http://zinc.rs/
- Piston http://www.piston.rs/ 
- Iron http://ironframework.io/

I setup a spreadsheet to gauge interest. Please add yourself to any 
project or add your project.


https://docs.google.com/spreadsheets/d/1tXXDOwXjL9VDr6hJMnyVe3ReBubAc6oWSMzV8VdIFh4/edit


\o/ So excited !!!

@alan-andrade


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Tokyo Rust meetup: 2014-09-27

[Brian Anderson]

Added to the calendar: 
https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles


On 08/07/2014 08:59 AM, Tetsuharu OHZEKI wrote:

Hello Rust Ninjas!

I announce the Rust Meetup in Tokyo on Sunday September 27th, 2014,
at Mozilla Japan office in Tokyo. Sign up here to attend:

https://atnd.org/events/54657

This meetup targets to learn Rust language more deeply, and communicate
with Rust guys who lives in Tokyo (or Japan).
If you find other Rust guys or try to learn Rust more, let's discuss 
together.


* Rust has not been known widely in Japan yet.
  So this time would aim to learn the basic, fundamental,
  and some introduction of Rust.

* We would talk a session with using Japanese,
  but some attendances can speak English modestly.

* Sessions has not been confirmed all yet.
  Please see more details in the above sign up page. sorry!

* We call this meetup as "Rust Samurai", inspired by a naming of
"JavaScript Ninja",  and the Tom Cruise's 2003 movie.
The pronounce difference ("R" & "L") is Japanese-English :)

Finally, I'm looking forward to see you at this meetup.

See you then!

--
Tetsuharu OHZEKI
saneyuki.s.s...@gmail.com 


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] [ANN] Rust Cross Support for PNaCl

[Brian Anderson]

Neat!

I'm particularly interested that you've ported Rust to newlib, which 
helps Rust with [this 
issue](https://github.com/rust-lang/rust/issues/7283). Do you have a 
complete working standard library that builds against newlib and not glibc?


On 07/31/2014 05:15 PM, Richard Diamond wrote:

Ladies and Gentlemen,

I am pleased to announce WIP-level cross support for le32-unknown-nacl 
targets, including x86_64-unknown-nacl (ie translated PNaCl modules). 
I say WIP because of a half-dozen number of caveats arising from 
either bugs in LLVM (though only w.r.t. PNaCl/NaCl; ie 
(x86_64|i686)-linux-gnu is unaffected relative to rust proper), 
restrictions of Pepper plugins, or idiosyncrasies of Newlib. 
Nonetheless, I've reached a MVP state and thus it is ready to be toyed 
with by the more courageous among you. PRs are welcome!


Given the needed changes to LLVM and the addition of an extra dep 
(nacl-binutils), this fork is unlikely to be upstreamed. I'm not 
opposed in any way to upstreaming, however.


The fork is located here . If 
you're curious as to what doesn't work, checkout the issue board.
Rust bindings to parts of the Pepper API are located here 
 (also a WIP).
A simple "Hello, world!" is located here 
.


Regards,
Richard Diamond


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] [ANN] rust-url

[Brian Anderson]

Thanks, Simon!

This is huge. Simon knows everything about web standards, and this is 
Servo's URL type, so it's going to be maintained and correct.


The old url crate was originally written by me, without looking at any 
specs, in order to teach Servo able to open `http://www.google.com`. It 
wasn't the best (though other people improved it).


Regards,
Brian


On 07/31/2014 08:09 AM, Simon Sapin wrote:

Hi Rustaceans,

rustc comes with an `url` crate (previously a `extra::url` module) for 
parsing an serializing URLs. This crate is now deprecated:


https://github.com/rust-lang/rust/commit/491bd299

The replacement is rust-url, which solves a number of issues that the 
old url crate had and adds some features that were missing:


http://servo.github.io/rust-url/

rust-url is not distributed with rustc, but builds easily with Cargo.

Please use the GitHub issue tracker for any feedback on the 
documentation, bugs, feature requests, etc.


Cheers,


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Place for discussions

[Brian Anderson]

Here's the current state of official project support for various forums:

* discourse.rust-lang.org is for *discussion of the development of Rust 
itself*. It is maintained by Mozilla.

* r/rust is for user discussion. It is maintained by the community.
* rust-dev is for user discussion. It is maintained by Mozilla. It used 
to be for development discussion but none of the core developers like 
working there because the signal-to-noise is awful and it is unmoderatable.

* stackoverflow is ultimately where we want users to go for help.

Discourse is an *experiment* to see if it works better than mailing 
lists for having civil conversations. If it works, we may shut off the 
mailing list. It's not clear whether we would extend discourse to 
general Rust discussion or leave reddit and stackoverflow for that.



On 07/30/2014 06:08 PM, Tobias Müller wrote:

Hello,

I'm following rust for quite a while, but the discussions are more and more
distributed between different places.
The mailing list was probably first, then with more user attention reddit
and StackOverflow, and now the discourse forum.

I understand that StackOverflow and Reddit are more for users, not
developers, but the discourse forum seems mostly redundant.

What's the reason for that split? Is the mailing list deprecated? Which one
is the future?

I for myself prefer the mailing list because of the gmane NNTP service, I
can use my usual usenet software and have all my forums in one place.

Tobi

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] London Rust meetup: 2014-08-14

[Brian Anderson]

I'm really looking forward to this!

On 07/24/2014 02:18 AM, Ilya Dmitrichenko wrote:

Hi Simon,

I and @farcaller where thinking to prepare a talk on Zinc project
(http://zinc.rs/).

What length of the talks you guys do?

Cheers,


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] A shiny test framework

[Brian Anderson]

Awesome! I'm glad to see people extending Rust's testing infrastructure 
with more expressive frameworks (I assume this translates to `#[test]` 
fns under the hood?).


On 07/22/2014 12:06 PM, Vladimir Pouzanov wrote:
I've just published a tiny test framework: shiny at 
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.


This library exists because I find it ugly to redefine all the 
initialisation code in every test case and I can't simply move it to a 
function due to problems with moving [T] out.


Here's how shiny looks:

#[cfg(test)]
mod test {
  describe!(
before_each {
  let awesome = true;
}

it "is awesome" {
  assert!(awesome);
}

it "injects before_each into all test cases" {
  let still_awesome = awesome;
  assert!(still_awesome);
}
  )
}

--
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] moving out few odd libraries from the main tree

[Brian Anderson]

As to your original question about candidate libs, here are mine:

arena
fourcc
glob
graphviz (with some rustc refactoring)
hexfloat
regex
url
uuid


On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote:

It would be great to discuss which libraries can be removed from the
main tree, I can see that there had been some progress with liburl
[1], but there appear to be a few other very dubious libraries that
can easily leave outside of the main tree.

The ones I was able to spot so far, would be:

- libfourcc
- libsemver

The main question would be where would these live on github? Should it
be under the main (`github.com/rust`) organisation or actually we
could consider creating `github.com/rust-libs`?

[1]: https://github.com/rust-lang/rust/issues/10707

Cheers,


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] moving out few odd libraries from the main tree

[Brian Anderson]

I expect moving crates out of the main tree to be important for reducing 
build cycle time.


On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote:

It would be great to discuss which libraries can be removed from the
main tree, I can see that there had been some progress with liburl
[1], but there appear to be a few other very dubious libraries that
can easily leave outside of the main tree.

The ones I was able to spot so far, would be:

- libfourcc
- libsemver

The main question would be where would these live on github? Should it
be under the main (`github.com/rust`) organisation or actually we
could consider creating `github.com/rust-libs`?

[1]: https://github.com/rust-lang/rust/issues/10707

Cheers,


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] moving out few odd libraries from the main tree

[Brian Anderson]

Doing this is a goal, but we're going to need a complete strategy - 
let's please not start doing this too hastily. Maintaining crates out of 
tree is not easy, and we need to have the systems in place that will let 
us succeed (particularly around integration). acrichto will need to be 
involved because he's the most familiar with all the systems this will 
touch.


On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote:

It would be great to discuss which libraries can be removed from the
main tree, I can see that there had been some progress with liburl
[1], but there appear to be a few other very dubious libraries that
can easily leave outside of the main tree.

The ones I was able to spot so far, would be:

- libfourcc
- libsemver

The main question would be where would these live on github? Should it
be under the main (`github.com/rust`) organisation or actually we
could consider creating `github.com/rust-libs`?

[1]: https://github.com/rust-lang/rust/issues/10707

Cheers,


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust universal build issues

[Brian Anderson]

On 07/18/2014 03:43 PM, Aljaž Srebrnič wrote:

On 17/lug/2014, at 20:08, Brian Anderson  wrote:


Thanks for your work on MacPorts. Did you use any flags to configure or 
arguments to make? What version of OS X, clang/gcc?

Yes, sorry, I’m building this on OS X 10.9.4 with system clang (5.1). After 
further inspection, I can build it with target and host set to 
x86_64-apple-darwin, but when I try to add i686-apple-darwin to the target 
list, the build fails. Is compiling for 32 bit on 64 bit host still supported?


Yes, it should work. I suspect there is some interaction with your 
(relatively new) toolchain that nobody has seen before.





On 07/17/2014 01:17 AM, Aljaž Srebrnič wrote:

Hello list,
I’m ono of the maintainers of rust on MacPorts, and I found some issues with 
the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a 
comment on line 135:

# Forcibly strip off any -arch, as that totally breaks our universal support.

Now, it looks like that script strips any -arch flags and adds -arch flags for 
*all* the supported architectures by the host compiler. As a result, some of 
the files are compiled as x86_64 only (the original arch flags) and some as a 
fat binary (i386 and x86_64). In stage3, linking fails:

I don't believe the build system is supposed to build stage3 on OS X. Seems 
suspicious.

I could be wrong about the stage number, I just inferred because the stage3 
directory had no files in it.


[…]
error: ar 'x' 
'/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a'
 failed with: exit code: 1
note: stdout ---

note: stderr ---
ar: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a
 is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a:
 Inappropriate file type or format
[…]

I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set 
RC_SUPPORTED_ARCHS=“x86_64”, but to no avail. How can I instruct compiler-rt to 
build for my architecture only?

Thanks,
Aljaž

--
Aljaž Srebrnič a.k.a g5pw
My public key:  http://bit.ly/g5pw_pubkey

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


--
Aljaž Srebrnič a.k.a g5pw
My public key:  http://bit.ly/g5pw_pubkey



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust universal build issues

[Brian Anderson]

Thanks for your work on MacPorts. Did you use any flags to configure or 
arguments to make? What version of OS X, clang/gcc?


On 07/17/2014 01:17 AM, Aljaž Srebrnič wrote:

Hello list,
I’m ono of the maintainers of rust on MacPorts, and I found some issues with 
the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a 
comment on line 135:

# Forcibly strip off any -arch, as that totally breaks our universal support.

Now, it looks like that script strips any -arch flags and adds -arch flags for 
*all* the supported architectures by the host compiler. As a result, some of 
the files are compiled as x86_64 only (the original arch flags) and some as a 
fat binary (i386 and x86_64). In stage3, linking fails:


I don't believe the build system is supposed to build stage3 on OS X. 
Seems suspicious.




[…]
error: ar 'x' 
'/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a'
 failed with: exit code: 1
note: stdout ---

note: stderr ---
ar: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a
 is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a:
 Inappropriate file type or format
[…]

I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set 
RC_SUPPORTED_ARCHS=“x86_64”, but to no avail. How can I instruct compiler-rt to 
build for my architecture only?

Thanks,
Aljaž

--
Aljaž Srebrnič a.k.a g5pw
My public key:  http://bit.ly/g5pw_pubkey

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Next week's older RFCs

[Brian Anderson]

On 07/10/2014 05:48 PM, Nick Cameron wrote:
Hi, here are the recommendations for discussion at next weeks 
meetings. There is a new section of RFCs which are ready for 
discussion but discussion has been postponed because we're waiting on 
a key person for that RFC to be present. This is mostly for RFCs which 
have been brought up for discussion in a meeting but, we've postponed. 
There are a few other RFCs not on this list where I've ignored them 
for now because the right people (mostly Niko) aren't around.


So, there a very few RFCs this week that are obvious candidates for 
closure and I we are pretty much up to date in that respect. There is 
still quite a backlog of RFCs which we should discuss at meetings and 
that backlog is only shrinking slowly. I think in general we don't 
have enough time at the general meeting to discuss more RFCs. Should 
we start discussing RFCs we might accept at triage? Or are we OK 
slowly chipping away? Or should we have another meeting or some other 
solution?


The situation doesn't seem dire to me yet. Right now there are 37 RFC 
PR's open. I don't have a sense of how that compares historically, but 
Rust has 56, and that's a higher number...

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

[Brian Anderson]

Can somebody file an issue described exactly what we should do and cc me?

On 07/14/2014 01:13 AM, richo wrote:

On 10/07/14 17:15 +, Ivan Kozik wrote:

On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki
 wrote:

While this is a good thing /all/ software projects should be doing imo,
one could still explicitly allow Archive.org by prepending:

User-agent: ia_archiver
Disallow:

?


It looks like documentation for the old versions e.g.
http://doc.rust-lang.org/0.9/ is a 404 anyway.



Which is kinda the point of letting archive.org keep a copy for 
posterity.


Not that I have a bunch of sway, but I'm +1 on not letting old docs be
searchable, and also +1 on making an exception for archive.org
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Invoking rustc as crate?

[Brian Anderson]

On 07/13/2014 12:10 AM, Christoph Husse wrote:

Hi,

I successfully managed to hook into the compiler so far. Or well it's
not that successful, because it doesn't work, but at least the code is
there ;).

Now I am trying to compile an empty file, and it gives me the weird error:

"error: can't find crate for `std`"


rustc guesses the 'sysroot' based on the location of the rustc binary. 
It expects a directory layout like


bin/
  rustc
lib/
  rustlib/

and will assume it can find libraries somewhere like ../lib/rustlib/... 
If your binary is not located in the correct location it will fail. 
Sysroot can be overridden in the session options somewhere.




Any chance there could be more insight? Normally a C++ compiler is
able to also tell you the library search paths at least, and in this
case it would be helpful to print the assumed hash code suffix that
was expected (I assume the fact that it runs in my executable instead
of the real compiler makes it somehow look for and STD with a
different hash suffix).

To zero out the chance that I did something wrong with externalizing
parts of the compiler driver into my own application, I wrote a simple
main method with the following "fallback":

rustc::driver::main_args(args.as_slice())

It will simply do what rustc does... Invoke the rustc compiler with
the arguments provided. This call will land inside of the compiler
that was used to compile the very same statement (I hope). Its using
the "rustc" crate after all.

Still the same error message ;)

So how could that be resolved? This is also an issue for custom Lint
plugins I guess, because you will definitely not want to invoke rustc
as external command and then have your plugin run in a different
process. I basically need the AST after analysis in its pure form,
like no JSON or something. Just want to continue where the compiler
left off... Instead of generating LLVM & stuff, which is not needed in
my case.

best
chris
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Brian Anderson]

On 07/11/2014 12:09 PM, Zoltán Tóth wrote:


On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson <mailto:bander...@mozilla.com>> wrote:



# Impact

Installing rustc to non-default locations will result in an
installation that puts some important libraries in a location the
dynamic linker won't find, will need to be compensated for with
LD_LIBRARY_PATH.


This is too sad.
Some Rust users may not be administrators, but even if they are, 
installing to some light custom folder is too convenient to miss it.
LD_LIBRARY_PATH is not known about by many, and even if known, editing 
it is messy practice.


What about these alternatives?

1) Link dependencies of rustc statically to it?


We could link rustc statically. Right now it's not to reduce binary size.



2) On Windows the folder of the executable is always searched for 
dependencies. Is this the case on Linux too? Then you could just let 
'make install' copy everything next to rustc.


I may have misunderstood something basic.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust Guidelines

[Brian Anderson]

Thanks, Aaron. This is going to be an important reference for authors. I 
love the sensible organization and that it's already seeded with many of 
our existing conventions.


On 07/11/2014 11:49 AM, Aaron Turon wrote:

Rustafarians,

As we head toward 1.0, we need to do do more than stabilize the 
language: we need a broad and stable base of libraries as well.


One of the key steps in that direction is reaching firm decisions on a 
number of API design questions, ranging from bikesheddy stuff like 
naming conventions to meatier stuff like when and how to use traits 
for overloading.



# THE RUST GUIDELINES DOCUMENT

I've been accumulating a set of guidelines based mostly on current 
Rust practice:


http://aturon.github.io/

but I need a lot of help from the community to bring this project to 
fruition.


As of today, the repository for the guidelines is now owned by the 
rust-lang github organization:


https://github.com/rust-lang/rust-guidelines

Each guideline is tagged with a status:

* [FIXME]: Marks places where there is clear work to be done that does 
not require further discussion or consensus.


* [OPEN]: Marks open questions that require concrete proposals for 
further discussion.


* [RFC]: Marks concrete, proposed guidelines that need further 
discussion to reach consensus.


* Untagged guidelines are considered accepted. To begin with, there 
are almost none of these!



# VIEWING THE GUIDELINES

For now, http://aturon.github.io/ will host snapshots of the current 
guidelines.


I plan to move the guidelines away from gitbook and onto something 
homegrown (built on rustdoc) soon, at which point we'll do rendering 
in some more official way as part of the nightlies.


The guidelines are also easy to browse from within github.


# HOW YOU CAN HELP

These guidelines cover a fair amount of ground, but still need a lot 
of work:


* We need to decide whether the [RFC]-status guidelines are ready to 
be accepted.


* We need to write many, many more guidelines. I've stubbed out a lot 
of these at [OPEN] status, but there are plenty of unknown-unknowns.


This project runs the risk of painting the biggest bikeshed ever. To 
help keep things managable:


  **DO NOT USE THE MAILING LIST** for discussing guidelines!

Instead:

  - Primarily, use http://discuss.rust-lang.org/ with category 
"guidelines"

  - Use the github.com/rust-lang/rust-guidelines issue tracker
  - Submit PRs!

Because guidelines are tagged with statuses, we can accept PRs at 
[RFC] status without formally "approving" them.



# CONSENSUS AND DECISIONS

The process for accepting guidelines will evolve over time, as with 
all of our processes. I'm hoping it will be a lighter-weight version 
of the RFC process:


1. Discussion on http://discuss.rust-lang.org/ and the repo for a 
given guideline goes on for a while.


2. At some point, either consensus is reached, or we simply need to 
make a decision.


3. The decision is made by the Rust team during a "library" meeting. 
For now, these are separate from the general Rust meetings.


Once a guideline is approved, its [RFC] tag will be removed. We still 
reserve the right to change the guideline later, but expect this to be 
rare.


The best part: approved guidelines can turn into (1) new github issues 
to bring libstd into line and (2) an authoritative way to resolve 
debates on libstd PRs.


Here's to having these debates one last time, and then ending them!
Aaron
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Brian Anderson]

Other programming languages do this. C and C++ do not mandate the use of 
RPATH, and Rust not applying RPATH by default doesn't exclude people 
opting into it if they want. In this context I am also considering 
@executable_path and @loader_path to be 'RPATH', and in fact 
@loader_path is the feature being disabled on OS X.


On 07/09/2014 07:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that 
I've seen requires developers to mangle these environment variables. 
On Mac, if you don't want all of RPATH to be searched, you can use 
more specific relative paths such as @executable_path or 
@loader_path in the load command. If rust does end up sticking with 
this regression, it should replace all of the tools with little shell 
scripts that set them appropriately for you and before invoking the 
real tool.


On Wednesday, July 9, 2014, Alex Crichton <mailto:a...@crichton.co>> wrote:


It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.

On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
> wrote:
> Is the following error cause by this change?
>
> % rustc -v
> dyld: Library not loaded:
>

x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
>   Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
>   Reason: image not found
    > Trace/BPT trap
>
>
> On 9 July 2014 00:53, Brian Anderson > wrote:
>> Yes, it does.
>>
    >>
    >> On 07/08/2014 04:41 PM, Simon Sapin wrote:
>>>
>>> On 08/07/14 23:57, Brian Anderson wrote:
>>>>
>>>> *Running rustc directly from the build directory will no
longer work by
>>>> default*. To do this either set LD_LIBRARY_PATH or pass
--enable-rpath
>>>> to the configure script.
>>>
>>>
>>> Does this also apply to running a (nightly) binary
distribution from where
>>> the tarball was extracted, without installing it?
>>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org 
>> https://mail.mozilla.org/listinfo/rust-dev
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org 
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Brian Anderson]

Yes, it does.

On 07/08/2014 04:41 PM, Simon Sapin wrote:

On 08/07/14 23:57, Brian Anderson wrote:

*Running rustc directly from the build directory will no longer work by
default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath
to the configure script.


Does this also apply to running a (nightly) binary distribution from 
where the tarball was extracted, without installing it?




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Brian Anderson]

Hi.

Very soon now the way rustc links crates dynamically is going to 
change[1], and it will impact the way you work with Rust in some 
important cases. The TL;DR is that rustc will no longer encode RPATH 
information in the binaries it produces, so the dynamic linker will be 
less likely to find the dynamic library (.so, .dylib) dependencies; in 
some scenarios people will need to use LD_LIBRARY_PATH or rely on 
higher-level tooling to arrange for libraries to be discovered by the 
dynamic linker at runtime.


[1]: https://github.com/rust-lang/rust/pull/14832

# Background

When the OS loads an executable, the dynamic linker searches some set of 
paths for it's dynamic library dependencies. If it doesn't find them, 
the program doesn't run, and for the most part the dynamic linker only 
searches a few system-defined locations, meaning that you're uninstalled 
development libraries won't be discovered by default. This is a common 
minor annoyance that is often solved by setting `LD_LIBRARY_PATH` to 
include the directories containing the dependencies.


Long ago Rust tried to solve this annoyance with RPATH. With RPATH you 
encode potential directories for the dynamic linker to search for 
dependencies *inside* the dependent libraries. rustc by default puts a 
few strategically-crafted RPATHs in its binaries that for the most part 
make the dynamic loading 'just work'.


Over time though we've concluded that we should not be doing this.

Firstly, this mechanism just doesn't work on Windows. For a while we 
tried to come up with a hack to simulate the behavior on Windows, but if 
there are any possibilities there they are very ugly and out of place in 
a language like Rust that tries not to do too much magic behind the 
scenes. As it stands now, the models on Unix and Windows are very 
different, which is a difficult discrepancy to justify.


Secondly, using RPATH is widely considered a bad practice. The primary 
risk with RPATH is that an attacker will place a substitute library on a 
known RPATH, injecting malicious code. I believe there are other 
considerations as well.


Finally, this behavior is inconsistent with other low-level languages, 
and inconsistent with the direction we've been moving in for e.g. 
library versioning. In general the user, or tools higher in the stack, 
should be in control over how they use their binaries, and Rust 
shouldn't be enforcing too much policy after compile-time.


So we're turning it off. The previous behavior can be restored by 
passing --rpath to rustc, or re-enabled for the Rust distribution itself 
by passing --enable-rpath to configure.


# Impact

Because static linking is the default in Rust, *by default* this change 
should have no impact on casual and new users unless they are explicitly 
opting in to dynamic linking.


Dynamic libraries installed as part of the Rust distribution should 
continue to be discovered correctly by the dynamic linker, modulo some 
potential bugs.


*Running rustc directly from the build directory will no longer work by 
default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath 
to the configure script.


Installing rustc to non-default locations will result in an installation 
that puts some important libraries in a location the dynamic linker 
won't find, will need to be compensated for with LD_LIBRARY_PATH.


Rust executables that link to dynamic Rust libraries outside of the 
system paths will not run without LD_LIBRARY_PATH.


Thanks. Have a nice day.





___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Partial meeting agenda - older RFCs

[Brian Anderson]

On 07/02/2014 11:19 AM, Gábor Lehel wrote:
Thanks, this is a good step, as is delaying taking actions by a day as 
proposed in the meeting itself.



If you have any suggestions for how this regular email or the
process in general could be improved, please let us know.


Most fundamentally, what I'm wondering is, why do most of the things 
discussed at the meetings need to be discussed separately in the first 
place?


Why not have those discussions directly in the comments for the 
respective RFC PRs? Up to and including leaving comments like "we 
suggest closing this, because {justification}, unless someone 
convinces us otherwise", "we suggest merging this because 
{justification}", and so on. In an ideal world, the meetings could 
merely ratify the decisions which were already evident from the PR 
discussions themselves. This could also help avoid situations where 
the two discussions end up disjoint in some way, e.g. according to 
this week's meeting notes @pcwalton and @aturon essentially 
recapitulated the exact same debate about the lifetime elision "self 
rule" at the meeting which @aturon and I had previously gone through 
in the PR comments.


I would like to move in this direction, but like many cultural changes 
it will be gradual. The primary reason we do so much in meetings is 
because face-to-face discussions move much faster and involve much less 
argumentation than asynchronous online discussions. In the immediate 
future I'd like to put more pressure on meeting participants to express 
their opinions on the issue ahead of meetings, which this initiative 
Nick is working on helps by making it clear what issues are coming up.





From the proposed-for-discussion list:

https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for
prefix-style type parameter lists - ben0x539
Sugary syntax for putting a group of type parameters and their
bounds before a group of functions. Motivation is our often
unwieldly lists of type parameters.
Not much feedback, but mostly positive. Generally for the
motivation, rather than the solution.
Recommend close in deference to RFC 135 (where clauses) which
solve the motivating problem here, along with other issues.


The two are complementary, not substitutive. 122 allows factoring out 
type parameter lists for multiple declarations. 135 allows writing 
them differently.



From the meeting itself, because it concerns process:

  * nrc: Do we want to keep this open? It's the |<>| to |[]| changes.
  * acrichto: It's so new, I don't think we should close it.
  * nrc: Even so, if we're not going to do it, I don't think we
should keep it open.

I don't see what could have been gained by closing it. Potential 
scenarios if it's left open:


 (1) Participants end up convincing each other than the change is not 
worth doing. (This is what ended up happening in this case.)
 (2) Contrary to expectations, a consensus emerges in favor of the 
change. Maybe there is some factor that hadn't been taken into account 
previously, or the arguments of one side end up convincing the other. 
I think this might be useful information to have learned. Then you can 
evaluate the decision on the merits.


Whereas if it's closed early:

 (3) People are left with the opinions they already had, and now might 
also have the impression that Mozilla has heavy-handedly shut down the 
debate.


I mean, possibly leave a comment like "Just so you know, we are 
extremely unlikely to do this, but feel free to keep discussing", but 
I think that was clear to everyone at the outset. I just don't see 
what could have been gained by preventing the discussion from playing 
itself out.


Cheers,
Gábor



On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron > wrote:


Hi all, there have recently been some calls to be more open about
the Rust meetings, in particular to publish the agenda beforehand.
The agenda setting has been quite informal, often not coming
together until the meeting starts. Not to say that we won't
publish an agenda in the future, but that it is not as easy as it
might seem. However, as a step towards that, I will be mailing out
the part of the agenda that is set in advance which is the set of
(usually older) RFCs where discussion has mostly ceased and where
we feel we can make a decision on progress. This email is a
relatively new convention in any case. It has been sent to most
meeting attendees at the start of the week. From now on, I'll send
it to the mailing list instead. If you have comments on the RFCs,
please comment on the RFC PR itself, please do not reply to the
mailing list.

Some explanation of the process here - each week there are two
Rust meetings where we discuss RFCs, the general Rust meeting and
the triage meeting. We only accept RFCs at the general meeting.
RFCs may be closed at either meeting. In o

Re: [rust-dev] Support for Literate Rust

[Brian Anderson]

It does seem like rustdoc could be extended to do something 
approximating literate programming without much hassle. I'd like to see 
this project built out-of-tree using the rustdoc and rustc API's.


On 06/29/2014 12:38 PM, Evan G wrote:
I'm not sure if this is exactly what you're looking for, but rust 
already has support for running code examples in documentation. If I 
remember correctly, all of the code examples in the guide are 
currently run and tested as part of make test, so this is at least 
part way towards what you want.



On Sun, Jun 29, 2014 at 2:30 PM, Nathan Typanski > wrote:


Literate Rust (.lrs)


I'm wondering if anyone else here has had the thought of supporting
literate programming in Rust. For those who don't know what this is
about, a language with good support for the concept is Haskell [1],
which normally uses bird-style (>) for code blocks. I would propose a
file extension (.lrs, most likely) that's dedicated to literate
usage.

If there's some decent feedback for this, and people seem to enjoy it,
then I will do more research and write a RFC.

[1]: 

## Who would benefit from this

### Schools teaching Rust

Universities teaching Rust would be one of my first bets as a user for
Literate Rust. While literate programming is sometimes too far a
stretch from reality for production code (which is both a good and bad
thing), pedagogical gains for literate programming are huge - you can
run the same code that's teaching you about the language or the
concept. Essays and writings that feature the code are
indistinguishable from valid Rust code.

### Documentation/books/etc.

Another use is general documentation, books about Rust, etc. where
there are real benefits to having valid code all the way through them.
When walking through a sample project, the sample project is also the
code that produced it. This makes documentation easier, since you're
more able to ensure that your examples compile properly and actually
run when the compiler updates, etc.

There's also a mental shift when doing literate programming, versus
just ///'ing within code and whatnot: your primary thought process
becomes thinking and communicating with the reader, rather than
working on the code. You focus more on the text and ensuring that it
makes sense.

## How this could work with Rustdoc for APIs

API documentation in a literate program would be included as before,
in rustdoc comments in the output. The internal comments should be the
default for text, not external API.

As an example, here's some code taken from
src/libstd/collections/hashmap.rs , and
interpreted in a literate style:

> /// Does not initialize the buckets. The caller should
ensure they,
> /// at the very least, set every hash to EMPTY_BUCKET.
> unsafe fn new_uninitialized(capacity: uint) -> RawTable {
> let hashes_size = capacity.checked_mul(&size_of::())
>   .expect("capacity overflow");
> let keys_size = capacity.checked_mul(&size_of::< K >())
> .expect("capacity overflow");
> let vals_size = capacity.checked_mul(&size_of::< V >())
> .expect("capacity overflow");
>

Allocating hashmaps is a little tricky. We need to allocate three
arrays, but since we know their sizes and alignments up front,
we just allocate a single array, and then have the subarrays
point into it.

This is great in theory, but in practice getting the alignment
right is a little subtle. Therefore, calculating offsets has been
factored out into a different function.

> let (malloc_alignment, hash_offset, keys_offset,
vals_offset, size) =
> calculate_offsets(
> hashes_size, min_align_of::(),
> keys_size,   min_align_of::< K >(),
> vals_size,   min_align_of::< V >());

The non-bird text (without the >) is what would normally go in the
comments for the code. In this case, since it's an API, the thing you
actually want in your regular documentation is still the rustdoc api
comments (///), but with the option of generating a literate
presentation of the code (perhaps by autoconversion to pandoc?) where
you read the internal comments instead of the API docs as the main
source of writing.

In other words, literate files can serve as a guide to *developers* of
the code, not necessarily just to users. Though for non-API material,
it's useful for both.

## Editor updates

- Emacs and Vim plugins would have to be updated to understand the ne

Re: [rust-dev] [ANN] Initial Alpha of Cargo

[Brian Anderson]

This is very well presented for an alpha. Nicely done. So excited to see 
projects start using it.



On 06/23/2014 10:50 PM, Yehuda Katz wrote:

Folks,

I'm happy to announce that Cargo is now ready to try out!

The Cargo repository is now at https://github.com/rust-lang/cargo and 
you can learn all about it at http://crates.io/. Don't forget to check 
out the FAQ at http://crates.io/faq.


You can build Cargo from master using the latest `rustc` and running 
`make install`. It assumes a `rustc` and `git` on the path, so you 
won't need to recompile Cargo every time you update the nightly.


Cargo is still under heavy development and features are coming 
quickly. At the moment, all dependencies are downloaded from Github, 
but we are working on a Cargo registry that you will be able to 
publish packages to. There are more details about that in the FAQ.


The next features we're planning on working on are:

  * `cargo package ` to create a new package skeleton
  * Supporting refs other than `master` from git packages
  * Support for environments (such as development, production and
test) as well as a `cargo test` command. This includes
per-environment dependencies.
  * Support for per-platform configuration.
  * More deterministic builds using a shrinkwrap file (like the
bundler Gemfile.lock or shrinkwrap.json in npm).

Since people have asked often, we plan to transparently support 
duplicates of the same package name and version in the following 
conditions:


  * From different git repositories or different branches of the same
git repository
  * In versions less than 1.0 for packages from the Cargo registry
  * For different major versions for packages from the Cargo registry

By default, we will encourage package authors to comply with semantic 
versioning and not introduce breaking changes in minor versions by 
using the single highest available minor version for each depended-on 
major version of a package from the Cargo registry.


For example, if I have three packages:

  * uno depends on json 1.3.6
  * dos depends on json 1.4.12
  * tres depends on json 2.1.0

Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. 
This makes good use of Rust's symbol mangling support, while also 
avoiding unnecessary code bloat.


This will tend to produce significantly smaller binary sizes than 
encouraging libraries to depend on precise versions of published 
packages. We tried to strike a good balance between isolating unstable 
code and avoiding binary bloat in stable libraries. As the ecosystem 
grows, we'll watch carefully and see if any tweaks are necessary.


Yehuda Katz
(ph) 718.877.1325


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Weekend buildbot maintenance

[Brian Anderson]

This weekend I'll be moving the Rust buildbot master and bors over to a 
new machine. There will be some downtime but otherwise no new changes. 
That is all.


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Brian Anderson]

On 06/18/2014 10:08 AM, Gábor Lehel wrote:


# Checked math

For (2), the standard library offers checked math in the `CheckedAdd`, 
`CheckedMul` etc. traits, as well as integer types of unbounded size: 
`BigInt` and `BigUint`. This is good, but it's not enough. The acid 
test has to be whether for non-performance-critical code, people are 
actually *using* checked math. If they're not, then we've failed.


`CheckedAdd` and co. are important to have for flexibility, but 
they're far too unwieldy for general use. People aren't going to write 
`.checked_add(2).unwrap()` when they can write `+ 2`. A more adequate 
design might be something like this:


 * Have traits for all the arithmetic operations for both checking on 
overflow and for wrapping around on overflow, e.g. `CheckedAdd` (as 
now), `WrappingAdd`, `CheckedSub`, `WrappingSub`, and so on.


 * Offer convenience methods for the Checked traits which perform 
`unwrap()` automatically.


 * Have separate sets of integer types which check for overflow and 
which wrap around on overflow. Whatever they're called: `CheckedU8`, 
`checked::u8`, `uc8`, ...


 * Both sets of types implement all of the Checked* and Wrapping* 
traits. You can use explicit calls to get either behavior with either 
types.


 * The checked types use the Checked traits to implement the operator 
overloads (`Add`, Mul`, etc.), while the wrapping types use the 
Wrapping traits to implement them. In other words, the difference 
between the types is (probably only) in the behavior of the operators.


 * `BigInt` also implements all of the Wrapping and Checked traits: 
because overflow never happens, it can claim to do anything if it 
"does happen". `BigUint` implements all of them except for the 
Wrapping traits which may underflow, such as `WrappingSub`, because it 
has nowhere to wrap around to.


Another option would be to have just one set of types but two sets of 
operators, like Swift does. I think that would work as well, or even 
better, but we've been avoiding having any operators which aren't 
familiar from C.


The general flavor of this proposal w/r/t checked arithmetic sounds 
pretty reasonable to me, and we can probably make progress on this now. 
I particularly think that having checked types that use operator 
overloading is important for ergonomics.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust CI

[Brian Anderson]

Thanks, Hans! Rust CI is a fantastic resource and I'm glad it's running 
smoothly again.


On 06/18/2014 01:11 AM, Hans Jørgen Hoel wrote:

Hi,

Rust Ci wasn't working for a period due to problems with building the
nightly PPA for the platform used by Travis (required GCC version was
bumped with no way to specify alternative to configure script).

This has been fixed for a while, but it turns out that many Travis
auth tokens has expired in the mean time.

If you want fix this for your project to start triggering builds
again, simply press the red padlock icon next to your project on the
frontpage (http://rust-ci.org/) and you will be redirected to GitHub
for authentication.

If you've got any questions, ping me on irc (hansjorg).

Regards,

Hans Jørgen
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust's documentation is about to drastically improve

[Brian Anderson]

Thanks, Steve! This is going to do wonders for our fit and finish going 
into the home stretch for 1.0.


On 06/16/2014 03:10 PM, Steve Klabnik wrote:

Hey all! I wrote up a blog post that you all should know about:
http://words.steveklabnik.com/rusts-documentation-is-about-to-drastically-improve

Here's the text, in Markdown:

Historically, [Rust](http://rust-lang.org/) has had a tough time with
documentation. Such a young programming language changes a lot, which
means that documentation can quickly be out of date. However, Rust is
nearing a 1.0 release, and so that's about to change. I've just signed
a contract with Mozilla, and starting Monday, June 23rd, I will be
devoting forty hours per week of my time to ensuring that Rust has
wonderful documentation.

A year and a half ago, I was in my hometown for Christmas. I happened
upon a link: [Rust 0.5
released](https://mail.mozilla.org/pipermail/rust-dev/2012-December/002787.html).
I've always enjoyed learning new programming languages, and I had
vaguely heard of Rust before, but didn't really remember what it was
all about. So I dug in. I loved systems programming in college, but
had done web-based stuff my entire professional life, and hadn't
seriously thought about pointers as part of my day-to-day in quite
some time.

There was just one problem: Rust was really difficult to learn. I
liked what I saw, but there was very little of it. At the same time, I
had been working on some ideas for a new toolchain for my [book on
hypermedia APIs](http://www.designinghypermediaapis.com/), but wanted
to try it out on something else before I took the time to port the
content. And so, [Rust for Rubyists](http://www.rustforrubyists.com/)
was born. I decided that the best way to teach people Rust was to
mimic how I learned Rust. And so, as I learned, I wrote. It ended up
at about fifty pages of two weeks of work. I never contributed it to
the main repository, because for me, it was really about learning,
both about my ebook toolchain as well as Rust itself. I didn't want
the burden that came with writing an official tutorial, making sure
that you cover every single feature, pleasing every single Github
contributor...

After learning Rust, I decided that I really liked it. No other
language provided such a promising successor to C++. And I really
missed low-level programming. So I kept evangelizing Rust, and every
so often, contributing official documentation. I figured that even if
my low-level chops weren't up to the task of writing actual patches, I
could at least help with my writing skills. I'd previously contributed
lots of documentation to Ruby and Rails, so it was something that was
very familiar to me. I've often found that I start with documentation
and then move into contributing code, once I get my head wrapped
around everything. Writing is part of my own process of understanding.

Rust for Rubyists was a great hit, even amongst non-Rubyists (damn my
love of alliteration!). Six months ago, on the eve of the first
anniversary of the initial release of Rust for Rubyists, I [gave a
talk](https://air.mozilla.org/rust-meetup-december-2013/) at the Bay
Area Rust meetup, specifically on the state of Rust's documentation.
In it, I laid out a plan for how I envisioned docs looking in the
future. In the last six months, a lot has improved, but a lot hasn't.
But no more! I'm now going to be able to allocate a significant amount
of my time on getting documentation done.

I'm also pleased in a meta-sense. You see, by contracting someone to
work on documentation full-time, Mozilla is indicating that they take
Rust and its future very seriously. You can (and I do) talk a lot of
trash on Microsoft, but one of the reasons that the Microsoft platform
is used by so many people around the world is that Microsoft products
often have excellent documentation. I often find that open source
'products' are technically superior, but are often much harder to use,
because they're built by a community, for free, and very few people
want to write documentation for free. Combined with the work that
Tilde is doing on [Cargo](https://github.com/carlhuda/cargo), Mozilla
is investing a significant amount of effort and dollars into ensuring
that Rust will be a fantastic platform for those developing on it.
Since I love Rust, this makes me very, very happy.

Forty hours a week is a significant amount of documentation, and I
have a lot of work in front of me. But my first area of focus will be
on the area of Rust's documentation that's the most weak, and
simultaneously the most important: the tutorial. I tackled the first
tip of that iceberg with [my 30 minute
introduction](http://doc.rust-lang.org/master/intro.html), and I'd
like to tweak it too. The main tutorial, however, is the first place
where people go to _really_ learn about Rust and how it works. And the
current tutorial is largely the same as the 0.5 days, back when I
first learned Rust. It suffers from receiving patchwork contributions

[rust-dev] The 'rust' repo has moved to the 'rust-lang' organization on GitHub

[Brian Anderson]

Hi, folks.

I've just moved the main repo from the 'mozilla' organization to 
'rust-lang': https://github.com/rust-lang/rust. This has been a while 
coming and reflects that Rust is a major project with its own community 
and culture, and not simply another project under the Mozilla umbrella.


Since GitHub sets up redirects, for the most part this should just work 
and not affect anybody. I'll spend some time updating links in 
documentation, but please let me know if you see breakage.


I've also taken this opportunity to do some house cleaning on the GitHub 
teams that have access to the repo: our dev process has changed over the 
years to not require that many people actually have write access, but 
during that time we've accumulated a long list of people who do have 
such access. I believe the only need for this now is to push to the 
`try` branch, and to tag and close issues. Accordingly, I've gone 
through the list of collaborators from the old organization and used my 
judgement to put currently-active contributors who appear to use this 
sort of access into a new 'Rust-Push' team. If you find that suddenly 
you can't do something you need to be able to do, let me know in 
private: it's not an intentional slight.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Clarification about RFCs

[Brian Anderson]

Thanks, Felix. I agree with your interpretation, and hope this gives 
some clarity on why decisions are being made as they are.


That so many RFC's don't make it through the process is disappointing I 
imagine, but is a reality of where we are in Rust's lifecycle. At this 
point the fundamental design has largely been done, and our goal must be 
to drive wider adoption while the opportunity is ripe. We are focused on 
making the core technology we've built over 4 years completely solid, 
fixing the rough edges; any changes that touch the language itself and 
that can be postponed almost certainly will be; same for other high-risk 
changes.


On 06/16/2014 07:56 AM, Felix S. Klock II wrote:

Gabor (cc’ing rust-dev)-

I have filed an issue to track incorporating the answers to these questions 
into the RFC process documentation.

   https://github.com/rust-lang/rfcs/issues/121

Here is some of my opinionated answers to the questions:

1. When an RFC PR is merged as accepted into the repository, then that implies 
that we should implement it (or accept a community provided implementation) 
whenever we feel it best.  This could be a matter of scratching an itch, or it 
could be to satisfy a 1.0 requirement; so there is no hard and fast rule about 
when the implementation for an RFC will actually land.

2. An RFC closed with “postponed” is being marked as such because we do not 
want to think about the proposal further until post-1.0, and we believe that we 
can afford to wait until then to do so.  “Evaluate” is a funny word; usually 
something marked as “postponed” has already passed an informal first round of 
evaluation, namely the round of “do we think we would ever possibly consider 
making this change, as outlined here or some semi-obvious variation of it.”  
(When the answer to that question is “no”, then the appropriate response is to 
close the RFC, not postpone it.)

3. We strive to write each RFC in a manner that it will reflect the final 
design of the feature; but the nature of the process means that we cannot 
expect every merged RFC to actually reflect what the end result will be when 
1.0 is released.  The intention, I believe, is to try to keep each RFC document 
somewhat in sync with the language feature as planned.  But just because an RFC 
has been accepted does not mean that the design of the feature is set in stone; 
one can file pull-requests to change an RFC if there is some change to the 
feature that we want to make, or need to make, (or have already made, and are 
going to keep in place).

4. If an RFC is accepted, the RFC author is of course free to submit an 
implementation, but it is not a requirement that an RFC author drive the 
implementation of the change.  Each time an RFC PR is accepted and merged into 
the repository, a corresponding tracking issue is supposed to be opened up on 
the rust repository.  A large point of the RFC process is to help guide 
community members in selecting subtasks to work on that where each member can 
be reasonably confident that their efforts will not be totally misguided.  So, 
it would probably be best if anyone who plans to work on implementing a feature 
actually write a comment *saying* that they are planning such implementation on 
the tracking issue on the rust github repository.  Having said that, I do not 
think we have been strictly following the latter process; I think currently you 
would need to also review the meeting notes to determine if someone might have 
already claimed responsibility for implementation.

5. The choice of which RFC’s get reviewed is somewhat ad-hoc at the moment.  We 
do try to post each agenda topic ahead of time in a bulleted list at the top of 
the shared etherpad ( https://etherpad.mozilla.org/Rust-meeting-weekly ) , and 
RFC’s are no different in this respect.  But in terms of how they are selected, 
I think it is largely driven by an informal estimate of whether the comment 
thread has reached a steady state (i.e. either died out or not showing any sign 
of providing further insight or improvement feedback to the RFC itself).  Other 
than that, we basically try to make sure that any RFC that we accept is 
accepted at the Tuesday meeting, so that there is a formal record of discussion 
regarding acceptance.  So we do not accept RFC’s at the Thursday meeting.  We 
may reject RFC’s at either meeting; in other words, the only RFC activity on 
Thursdays is closing the ones that have reached a steady state and that the 
team agrees we will not be adopting.

I want to call special attention to the question of "What if the author of the 
reviewed RFC isn't a participant in the meetings?”  This is an important issue, 
since one might worry that the viewpoint of the author will not be represented at 
the meeting itself.  In general, we try to only review RFC’s that at least a few 
people have taken the time to read the corresponding discussion thread and are 
prepared to represent the viewpoints presented there.

Re: [rust-dev] how is Rust bootstrapped?

[Brian Anderson]

This is an interesting idea, but I don't see it happening for a long 
time if ever:


* The current process is working fine
* rustc depends on many of the standard libraries, so restricting rustc 
means figuring out how to stick to a fixed subset of those libraries

* It's a lot of work to make the bootstrap process even *more* complicated
* For some minor benefits

On 06/09/2014 06:34 AM, James Cassidy wrote:

On Mon, Jun 09, 2014 at 12:55:00PM +, Sanghyeon Seo wrote:

Do you plan to create a cleaner full-bootstrap process?
By "cleaner" I mean dividing stage-0 to more [sub-]stages,
which would be well-defined and documented in terms of
the set of language features it implements. Currently these
sub-stages are defined by a team member's mood to instruct
the build-bots to make a snapshot. This kind of bootstrap
seems to be a black-box.

As I understand, there is no plan to do this. "Bootstrap" you are talking
about is purely theoretical, and I don't think anyone actually performed it.
In practice, Rust is bootstrapped from the downloaded binary.


I understand you do not spend resource on such tasks before 1.0,
but do you think this is a legitimate|sensible request at all?
Would it be worth the work?

Personally, I don't see any value in doing this work. C compilers are
bootstrapped from C compiler binaries. Analogously, the Rust compiler
is bootstrapped from the Rust compiler binary.

Trying to bootstrap from rustboot would be akin to trying to bootstrap
GCC from last1120c (the oldest C compiler with surviving source code).
An interesting feat of computer archaeology, but not really useful for
anything.


I think he was more referring to what language features will be allowed in the
rust compiler itself where earlier stages would be more restricted so they can
be compiled with older rust compilers, for example hopefully rustc 2.0 can be
compiled by rustc 1.0.  Then later stages could use more features since it will
be compiled with the more up to date earlier stage.

Currently what features can be used in the compiler itself are just limited to
whenever someone decides to compiler a newer stage0 compiler.


-- Jim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Taking ownership of the datetime library

[Brian Anderson]

Thanks!

On 06/08/2014 01:10 AM, Dietrich Epp wrote:

Unless there’s a good objection I’m taking ownership of the datetime library, 
as luisbg’s efforts seem to be abandoned.  I’ve read the wiki, the last mailing 
list discussion, and I’ve familiarized myself with JSR 310, Joda Time, Noda 
Time, the C++ proposal, and others.

Here is the repository: https://github.com/depp/datetime-rs

If you want to do any bikeshedding, please review the /doc folder, and feel 
free to edit the wiki or post issues or pull requests through GitHub.  Code 
review is also welcome, although there is only one module implemented yet.

—Dietrich

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Type System

[Brian Anderson]

Again, I must ask you to stop. Claiming that we are 'ignoring the 
developments of research' is *extremely* insulting.


I've turned moderation on for your account. Further messages to this 
mailing list will need to be approved by the admins.


On 06/05/2014 11:00 PM, Suminda Dharmasena wrote:

Hi,

The concept of Rust is definitely appealing at a high level. One area 
that can improve is the Type System. Instead of ignoring the 
developments and research in this area please find a way to embrace it.


Also a proper active objects based OO system would be appealing.

Suminda


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Dependent Type | Dependent Object Types

[Brian Anderson]

I appreciate your enthusiasm, but please stop creating new threads that 
simply suggest adding major new features to the type system. The vast 
majority of type system features that might benefit Rust have been 
discussed many times, in excruciating depth, for years.



On 06/05/2014 02:14 AM, Suminda Dharmasena wrote:

Hi,

Another aspect that can be considered is Dependent Types.

S


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Bring Back Type State

[Brian Anderson]

Thank you for your suggestion, but typestate is not coming back. There 
is no room in the complexity budget for another major piece of type 
system, and linear types can serve much the same purpose.


On 06/04/2014 10:11 PM, Suminda Dharmasena wrote:

Hi,

The initial Type State implementation in Rust was not a great way to 
get about it. Please reconsider adding type state like it has been 
done in the Plaid language.


Basically you can use traits mechanism to mixin and remove the trait 
when methods marked as having state transitions.


Suminda

Plaid: http://www.cs.cmu.edu/~aldrich/plaid/ 




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] 7 high priority Rust libraries that need to be written

[Brian Anderson]

Greetings, all.

Looking for ways to have an impact on Rust? The current plan for Rust 
defers the creation of some key libraries until after Rust 1.0, but that 
doesn't mean we can't start on them now if the interest is out there. 
Here are 7 libraries that need to be created soon rather than later. 
Since these are all destined to be either incorporated directly into the 
Rust distribution or to be officially-maintained cargo packages, and 
since they are targeted for inclusion in the post-1.0 timeframe, they 
need to be designed carefully and implemented thoroughly.


# Internationalization (https://github.com/mozilla/rust/issues/14494)

ECMA 402 is a standard for internationalization, dealing with the 
automatic conversion of various information based on locale. Rust's core 
libraries provide *no* internationalization. A core problem here will be 
determining how Rust should think about locales.


# Localization (https://github.com/mozilla/rust/issues/14495)

This may depend on the previous for locale support, if nothing else. 
This is largely about the human-assisted translation of strings. We 
would like to experiment with a new Moco-developed standard for this, 
called L20N. This project will be about figuring out how the L20N API 
can be adapted to Rust.


# Unicode (ICU) (https://github.com/mozilla/rust/issues/14656)

The exact path forward here may require a bit of discussion still, but I 
think the most viable approach starts with binding libicu and wrapping 
in a Rust API.


# Date/Time (https://github.com/mozilla/rust/issues/14657)

Our time crate is very minimal, and the API looks dated. This is a hard 
problem and JodaTime seems to be well regarded so let's just copy it.


# HTTP (https://github.com/teepee/teepee)

ChrisMorgan is leading an effort to implement HTTP for Rust and I'm sure 
he would love more contributions.


# Crypto (https://github.com/mozilla/rust/issues/14655)

We've previously made the decision not to distribute any crypto with 
Rust at all, but this is probably not tenable since crypto is used 
everywhere. My current opinion is that we should not distribute any 
crypto /written in Rust/, but that distributing bindings to proven 
crypto is fine.


Figure out a strategy here, build consensus, then start implementing a 
robust crypto library out of tree, with the goal of merging into the 
main distribution someday, and possibly - far in the future - 
reimplementing in Rust. There are some existing efforts along these 
lines that should be evaluated for this purpose.


There are a lot of people interested in, and working on, this subject, 
and crypto potentially interacts with many libraries (like HTTP) so 
coordination is needed.


# SQL (https://github.com/mozilla/rust/issues/14658)

Generic SQL bindings. I'm told SqlAlchemy core is a good system to learn 
from.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Using gdb on rust

[Brian Anderson]

The exact versions of the tooling here is pretty important - our ability 
to support debugging is extremely version dependent, especially when it 
comes to lldb.


On mac I believe we are not putting any particular effort into 
supporting gdb at this point since lldb is the future. Newer lldb's work 
better than older, and lldb support is still a WIP.



On 05/19/2014 02:54 PM, Isaac Hollander McCreery wrote:

Hi Ricardo,

Can you provide more information about how it fails?

OS X 10.9 no longer ships with gdb, instead preferring lldb, (the 
whole system has shifted over to LLVM's ecosystem, e.g. clang instead 
of gcc).  Have you tried lldb?


Regards,
Ike


On Mon, May 19, 2014 at 5:43 PM, Ricardo Brandão 
mailto:rbrandao...@gmail.com>> wrote:


Hi All,

Today I've tried to use gdb to debug rust programs.

I compiled with -g: rustc -g hello.rs 

and ran gdb hello

On Ubuntu it worked fine, but in Mac (OS 10.8) doesn't. Anyone
already faced this issue on Mac?

Thanks in advance

-- 
Ricardo Brandão

http://www.programonauta.com.br

__@
._  \ >_
(_) /  (_)

___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Why explicit named lifetimes?

[Brian Anderson]

On 05/15/2014 09:30 PM, Tommi wrote:

On 2014-05-16, at 7:14, Daniel Micay  wrote:


On 16/05/14 12:10 AM, Tommi wrote:

I was just wondering, why do we have to explicitly specify the lifetimes of 
references returned from functions? Couldn't the compiler figure those 
lifetimes out by itself by analyzing the code in the function?


Type inference is local to functions, so it couldn't do that. It would
be impossible to have libraries if inference needed to be global across
the entire program, and the errors would be *signicantly* harder to
understand as they would span across countless functions.


I'm sorry, but for some reason I completely fail to understand your explanation.

My thinking of how the compiler would work is that whenever it compiles a function, it 
would analyze it and in some sense "write in" the named lifetimes for that 
function. The named lifetimes would still be explicitly part of the signature of the 
function in the compiler's internal representation of the function, but not be visible in 
the source code.



I believe the compiler does this anylisis when the lifetimes in a 
signature are wrong - but just for the error message. It tries to 
suggest lifetimes that will work, but the analysis is not foolproof and 
can't be done automatically generally (idk why, ask niko).


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] New moderation policy

[Brian Anderson]

Hey!

This is a new section for our development policy covering moderation 
guidelines. It tells both community members and moderators the mechanics 
of when and how a conversation should be moderated.


This involves no changes to the Rust Code of Conduct; it is making 
explicit the informal process that is already in place for dealing with 
violations.


It is posted on the wiki: 
https://github.com/mozilla/rust/wiki/Note-development-policy#moderation


## Moderation

These are the policies for upholding our community's standards of 
conduct in our communication channels, most notably in Rust-related IRC 
channels.


1. Remarks that violate the Rust standards of conduct, including 
hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. 
(Cursing is allowed, but never targeting another user, and never in a 
hateful manner.)


2. Remarks that moderators find inappropriate, whether listed in the 
code of conduct or not, are also not allowed.


3. Moderators will first respond to such remarks with a warning.

4. If the warning is unheeded, the user will be "kicked," i.e., kicked 
out of the communication channel to cool off.


5. If the user comes back and continues to make trouble, they will be 
banned, i.e., indefinitely excluded.


6. Moderators may choose at their discretion to un-ban the user if it 
was a first offense and they offer the offended party a genuine apology.


7. If a moderator bans someone and you think it was unjustified, please 
take it up with that moderator, or with a different moderator, **in 
private**. Complaints about bans in-channel are not allowed.


8. Moderators are held to a higher standard than other community 
members. If a moderator creates an inappropriate situation, they should 
expect less leeway than others.


In the Rust community we strive to go the extra step to look out for 
each other. Don't just aim to be technically unimpeachable, try to be 
your best self. In particular, avoid flirting with offensive or 
sensitive issues, particularly if they're off-topic; this all too often 
leads to unnecessary fights, hurt feelings, and damaged trust; worse, it 
can drive people away from the community entirely.


And if someone takes issue you with something you said or did, resist 
the urge to be defensive. Just stop doing what it was they complained 
about and apologize. Even if you feel you were misinterpreted or 
unfairly accused, chances are good there was something you could've 
communicated better — remember that it's your responsibility to make 
your fellow Rustians comfortable. Everyone wants to get along and we are 
all here first and foremost because we want to talk about cool 
technology. You will find that people will be eager to assume good 
intent and forgive as long as you earn their trust.


*Adapted from the [Node.js Policy on 
Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling)*

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust by example

[Brian Anderson]

This is amazing!

I added it to the wiki https://github.com/mozilla/rust/wiki/Doc-examples

On 04/25/2014 07:25 PM, Jorge Aparicio wrote:

Hello fellow Rusticans,

I'm pleased to announce the Rust by example website [1], which is a Rust
version of the Go by example website [2], aimed at explaining rustic concepts
and giving an overview of the Rust distribution libraries with examples.

Although the website is still a WIP, it already contains 30+ examples ranging
from the classic Hello World to a simple client server program, covering core
concepts like ownership, borrowing, generics, traits, tasks, etc.

Be sure to drop by the main repo [3], and let me know what you think and/or of
any idea you have to improve it!

Cheers,

Jorge Aparicio

[1] http://japaric.github.io/rust-by-example
[2] https://gobyexample.com
[3] https://github.com/japaric/rust-by-example
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] A small announcement for zinc, the bare metal rust stack

[Brian Anderson]

This sounds very useful. Thanks for letting us know.

On 04/22/2014 09:10 AM, Vladimir Pouzanov wrote:

This is the project I've been tinkering with for a good number of
weekends — zinc, the bare metal stack for rust is available at
https://github.com/hackndev/zinc.

I've just finished a major refactoring work for LPC1768 code, so STM32F4
is kind of broken yet, and LPC1114 is totally dropped, but I'll fix that
soon.

The current code supports GPIO operations, UART and SSP in SPI mode for
NXP LPC1768, also featuring a driver for
http://mbed.org/cookbook/mbed-application-board TFT LCD and for
ILI9341-based TFT LCDs commonly found on ebay.

My plan is to fix support for STM32F4, bring it to the level of NXP part
and try to expand this to a small RTOS, which would be a nice demo of
rust capabilities for embedded development.

The code is licensed under Apache-2.0.

There's no readme yet, but you can see the demo applications written
with zinc here: https://github.com/hackndev/zinc/tree/master/apps.

--
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Private trait items

[Brian Anderson]

I'm not sure what you are asking for here. Have you submitted this as a 
pull request to http://github.com/rust-lang/rfcs?


I do realize that the RFC process takes time to get things approved, but 
some have been, and I expect the rate of approvals to continue steadily.


On 04/17/2014 08:27 PM, Tommi wrote:

Could someone please commit this RFC for me, thank you:

- Start Date: 2014-04-18
- RFC PR #:
- Rust Issue #:

# Summary

I propose the ability to set trait items (i.e. just methods currently) private 
as well as public in order to expand the scope of possible use cases of 
provided methods (i.e. default trait method implementations). I also propose 
that trait items should be private by default.

# Motivation

Sometimes a trait may be able to provide a default implementation for a method 
iff it can use a certain method which only the type that implements the trait 
is in a position to provide a definition for. Often times such a feedback 
method is supposed to be only a tool for the trait to be able to define 
provided methods with, and as such, not supposed to become a part of the public 
interface of the trait or any type which implements the trait. Therefore such a 
feedback method should be made private. Trait items should be private by 
default so that we don't have the need to reintroduce the 'priv' keyword. If in 
future we get the ability to specify that a certain provided method in a trait 
is 'final' (i.e. not overridable by the type which implements the trait), then, 
together with private trait methods, we can use the Non-Virtual Interface (NVI) 
idiom coined and described here by Herb Sutter: 
http://www.gotw.ca/publications/mill18.htm

# Detailed design

One way of looking at private trait methods (or any private trait items) is to 
see them as private dialog between a trait and a type which implements the 
trait. This view could lead to a design where no-one else except the trait and 
the type which implements it is allowed access to such private feedback item. 
But given how Rust privacy rules work at module boundaries (and also extend 
access to submodules), it would make sense that access to a private trait item 
extended from just the trait or the type which implements it to the enclosing 
module and its submodules. By this logic I suggest the following privacy rules 
for private trait items:

Given that:
1) A trait ```Tr``` specifies a private item ```priv_item``` and is defined in 
module ```mod_tr```
3) A type ```Foo``` implements ```Tr``` and is defined in module ```mod_foo```
3) A type ```Bar``` implements ```Tr``` and is defined in module 
```mod_bar_and_baz```
4) A type ```Baz``` implements ```Tr``` and is defined in module 
```mod_bar_and_baz```

It follows that:
1) ```priv_item``` is accessible from ```mod_tr``` and all its submodules.
2) ```priv_item``` is accessible from ```mod_foo``` and all its submodules iff 
it is certain at compile-time that it refers to the ```Foo```'s implementation 
```priv_item```
3) ```priv_item``` is accessible from ```mod_bar_and_baz``` and all its 
submodules iff it is certain at compile-time that it refers to either the 
```Bar```'s or ```Baz```'s implementation of ```priv_item```

And ```priv_item``` is not accessible from anywhere else.

Example:
```
// in mod_tr.rs
pub trait Tr {
 priv fn priv_item(&self);

 pub fn do_stuff(&self) {
 self.priv_item(); // OK
 }
}

pub fn do_other_stuff(a: &A) {
 a.priv_item(); // OK
}

// in mod_foo.rs
use mod_tr::Tr;

pub struct Foo;

impl Tr for Foo {
 priv fn priv_item(&self) {}
}

pub fn do_foo_stuff(foo: &Foo) {
 foo.priv_item(); // OK
}

pub fn do_incorrect_stuff(a: &A) {
 a.priv_item(); // ERROR: "A private trait item Tr::priv_item not accessible 
from mod_foo"
}
```

# Alternatives



# Unresolved questions


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Call for a "practical" Rust guide

[Brian Anderson]

Hi.

I've been convinced recently that Rust is missing crucial documentation 
of a particular nature: using Rust in practice. I would like to have 
such a standalone guide, and these are some ideas about what should be 
in it.


This is a guide that runs through creating an entire Rust project from 
installation, using the tools, writing code, through deployment, 
touching on the practical aspects of coding Rust, not glossing over 
whatever ugly bits are necessary to do real work.


Some of the topics I might expect include:

* Installation
* Running rustc
* lib.rs/bin.rs/mod.rs conventions
* Evolving a project from a single file to multi-file/mod/directory
* Picking the correct types for various problems
* Obtaining and using other crates
* Setting up a build system (not cargo to start, cargo when it's ready)
* Working with the compiler to find the correct algorithms. Show typical 
ways you might concieve the solution incorrectly and how the compiler 
helps guide you to the correct one. Particularly re: borrowck.

* Common Rust patterns (like?)
* Rust CI, other community resources?
* Using rust-bindgen to create bindings that don't already exist
* Error handling
* Practical corner cases and workarounds of various types, e.g.
  - #[path], #[link_args]?

There's some overlap here with the current tutorial, which I think is 
good, since I want to find new homes for most of the content there.


I've filed this as issue #13669, but have no plans to work on it 
personally at this time. If anybody has an interest in taking it on, 
please coordinate there.


Finally, I'd like to update folks with a few words on how I'm currently 
envisioning the Rust documentation story.


I've become convinced that relatively small and self-contained guides 
are our best format for producing standalone documentation about Rust. 
By being small, they require minimal investment by any single 
individual, so we can experiment quite freely with what docs are 
provided, what order they are presented, and the schedule on which they 
are created.


Right now I am aiming for three introductory guides, serving distinct 
purposes:


* "A 30-minute intro to Rust" - Very high-level, purely to excited 
prospective users, let them know whether Rust is for them
* "The Philosophy of Rust" - Covers about a dozen subjects that are 
crucial to understanding why Rust is like it is. It would be impossible 
to do anything useful in Rust without understanding this material: stack 
vs. heap, ownership, copying, moving, borrowing, lifetimes. Experienced 
devs will also pick up a lot of basic syntax in passing.

* "Practical Rust" - Using Rust to build real software.

After these, a new user should be well on their way to writing Rust, 
especially after reading the various other guides on more focused topics.


"The Philosophy of Rust" is a document that Sam Wright, Niko and I are 
working on. The title will almost certainly change. Sam will have a new 
pull request up soon.


As to the existing tutorial, after the new docs mature I expect to 
demote it to "The (old) Rust tutorial", then start looking for new homes 
for the material there. This won't happen for a while, until the new 
docs are a good enough substitute.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Announcing the newest member of Mozilla's Rust team, Aaron Turon

[Brian Anderson]

Hey there, Rusticators,

Grand news! Starting today Aaron Turon is joining the Rust team. Aaron 
did his PhD thesis on concurrency at Northeastern University, where he 
published widely-noted papers on 'reagents' and 'LVars'. He will be 
focusing on making Rust's standard libraries the best they can be. He's 
aturon on IRC; say 'hi' when you see him.


Welcome aboard, Aaron.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Why mod.rs files?

[Brian Anderson]

On 04/17/2014 07:39 AM, Tommi wrote:

Can someone explain me why the module system maps to the file system in the way 
it does? The problem is that you can end up with these modules named mod.rs 
instead of the more informative names. If you have the following modules:

foo
foo::lut
bar
bar::lut

...that maps to files and folders as such:

foo/mod.rs
foo/lut.rs
bar/mod.rs
bar/lut.rs

...but why not map such modules to files and folders as the following:

foo.rs
foo/lut.rs
bar.rs
bar/lut.rs

...and have each module informatively named.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



We did used to do exactly that, but it was considered very odd that part 
of a module is defined outside of it's directory and part inside. This 
structure can still be achieved in Rust with `#[path = "..."]` but it's 
not the opinionated default.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Keeping up with Breaking Changes

[Brian Anderson]

On 04/17/2014 12:21 AM, Flaper87 wrote:




2014-04-17 2:11 GMT+02:00 Alex Crichton mailto:a...@crichton.co>>:

The template which breaking changes will be required to look like is:

 First, a brief one-line summary of the change

 Second, take as long as is necessary to explain exactly what
the change is,
 why it's being changed, what it can be replaced with (if
applicable) and
 general guidelines about dealing with the change.

 In addition to a few paragraphs about the change itself, the
literal string
 "[breaking-change]" must appear at the end of the commit
message in order
 to indicate that it is a commit that has a breaking change.
This will allow
 filtering commits on this string to only take a look at
breaking changes.

 [breaking-change]



Sometimes, the breaking change is split in several commits. I'd
recommend to add to the breaking change tag the number of the GH issue
(I wanted to propose a "change tag" but I don't think that will end
well). I don't expect breaking changes to happen without a GH issue
baking them - or at least, I don't think that should happen.

Tagging the last commit of the series should probably be enough but, for
completeness, I think they should all be tagged. This will produce a
more complete output when `grepping` for breaking changes.


I hope it's not typically hard to isolate the "break" to a single 
commit, particularly when it comes to library refactoring, which is 
where most of the breakage is going to be going forward.





To get a log of breaking changes, you can use git-log:

 git log --grep breaking-change

 # Exclude bors merge commits
 git log --grep breaking-change --no-merges

# Usage of #[deprecated]

In addition to a stricter policy around commit messages, we're going
to start
encouraging more aggressive use of the #[deprecated] attribute to help
transitioning code. A good example of this recently is when the
`shuffle_mut`
function was renamed to `shuffle`. The original function had an
attribute that
looked like:

 #[deprecated = "function renamed to `shuffle`"]

We aren't yet going to require that the old function retain its
functionality,
it is acceptable to replace it with a fail!()-ing stub for now. The
compilation
warning should be a good enough indicator about what needs to be
changed.

The deprecated functions themselves aren't expected to stick around
for all
eternity. By 1.0 we will clean out all #[deprecated] functionality,
and before
then we'll likely leave in #[deprecated] functions for about a month
or so.


I think we should retain the previous functionality. Since it's already
there, I don't think it will be of any harm (in most of the cases).

Also, I think it'd be good to keep the deprecated function for at least
1 release. I believe this is a good practice and gives users of that
function enough time to migrate. This obviously doesn't make much sense
if we replace the functionality with a `fail`


# Be on the lookout!

With these two guidelines in place, we hope to ease the pain of
upgrading
through versions of rust while it's still under rapid development.
Reviewers, be
sure to keep an eye out for breaking changes in the future and make
sure that
the that these measures are followed!



I'm really happy to see this happening!

--
Flavio (@flaper87) Percoco
http://www.flaper87.com
http://github.com/FlaPer87


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing ~"foo"

[Brian Anderson]

On 04/15/2014 10:12 AM, Patrick Walton wrote:

Hi everyone,

I'd like to remove the `~"foo"` literal syntax for owned strings in both
expressions and patterns. After dynamically sized types, this syntax is
the last remnant of the strange parser behavior by which the parser does
something different for `~"foo"` and `~("foo")` (i.e. by which it looks
at the next token when it sees a sigil and does something different than
it would otherwise).

The new replacement for `~"foo"` will be `"foo".to_owned()`. You can
also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you
will likely also be able to write `Heap::from("foo")`.

This has no effect on constants since `~"foo"` is not allowed there anyway.



Thanks, Patrick. Full steam ahead. Let's get DST done.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust windows bots have transitioned to mingw-w64

[Brian Anderson]

I have a new bot up now that is *definitely* using the new toolchain. 
Haven't completed a build yet, but I think it's going to work.


On 04/11/2014 04:16 PM, Thad Guidry wrote:

LOL.  OK, and I'll keep me fingers crossed. ;)


On Fri, Apr 11, 2014 at 3:40 PM, Brian Anderson mailto:bander...@mozilla.com>> wrote:

It turns out this was premature and the bots are still using the old
toolchain. I'll keep working on it.


    On 04/10/2014 05:05 PM, Brian Anderson wrote:

After a long time coming, the Rust windows bots are now running an
up-to-date mingw-w64 toolchain. This was a very easy transition
thanks
to the efforts of our windows devs, including Vadim, Thad, and
klutzy.

The practical impact of this is that windows developers should
prefer
the mingw-w64 toolchain to the old mingw toolchain. This is the
toolchain we will be supporting on Windows for the immediate future.

I've updated the [windows instructions] and the [getting
started] page
slightly, but there's a lot of information there that I don't fully
understand. I'd appreciate if some of the more experienced
windows devs
could go over them and make sure they are accurate.

The next step will be to add 64-bit windows bots and snapshots.

[windows instructions]:
https://github.com/mozilla/__rust/wiki/Using-Rust-on-__Windows
<https://github.com/mozilla/rust/wiki/Using-Rust-on-Windows>
[getting started]:

https://github.com/mozilla/__rust/wiki/Note-getting-__started-developing-Rust

<https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust>


_
Rust-dev mailing list
Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/__listinfo/rust-dev
<https://mail.mozilla.org/listinfo/rust-dev>




--
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust windows bots have transitioned to mingw-w64

[Brian Anderson]

It turns out this was premature and the bots are still using the old 
toolchain. I'll keep working on it.


On 04/10/2014 05:05 PM, Brian Anderson wrote:

After a long time coming, the Rust windows bots are now running an
up-to-date mingw-w64 toolchain. This was a very easy transition thanks
to the efforts of our windows devs, including Vadim, Thad, and klutzy.

The practical impact of this is that windows developers should prefer
the mingw-w64 toolchain to the old mingw toolchain. This is the
toolchain we will be supporting on Windows for the immediate future.

I've updated the [windows instructions] and the [getting started] page
slightly, but there's a lot of information there that I don't fully
understand. I'd appreciate if some of the more experienced windows devs
could go over them and make sure they are accurate.

The next step will be to add 64-bit windows bots and snapshots.

[windows instructions]:
https://github.com/mozilla/rust/wiki/Using-Rust-on-Windows
[getting started]:
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Rust windows bots have transitioned to mingw-w64

[Brian Anderson]

After a long time coming, the Rust windows bots are now running an 
up-to-date mingw-w64 toolchain. This was a very easy transition thanks 
to the efforts of our windows devs, including Vadim, Thad, and klutzy.


The practical impact of this is that windows developers should prefer 
the mingw-w64 toolchain to the old mingw toolchain. This is the 
toolchain we will be supporting on Windows for the immediate future.


I've updated the [windows instructions] and the [getting started] page 
slightly, but there's a lot of information there that I don't fully 
understand. I'd appreciate if some of the more experienced windows devs 
could go over them and make sure they are accurate.


The next step will be to add 64-bit windows bots and snapshots.

[windows instructions]: 
https://github.com/mozilla/rust/wiki/Using-Rust-on-Windows
[getting started]: 
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] About Rust programming language.

[Brian Anderson]

Sorry for the curt response. The answer is that Rust is suitable for 
many of the same tasks as C. Thank you.


Please do not have this discussion here.

On 04/10/2014 11:58 AM, Brian Anderson wrote:

Thank you for your interest, but this is not a constructive topic for
this venue.

On 04/10/2014 11:35 AM, Jason Long wrote:

Hello Folks.
How are you?
I want to know something about Rust language and Is it C killer? I mean
is that in the future is it a replacement for C?

Cheers.


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] About Rust programming language.

[Brian Anderson]

Thank you for your interest, but this is not a constructive topic for 
this venue.


On 04/10/2014 11:35 AM, Jason Long wrote:

Hello Folks.
How are you?
I want to know something about Rust language and Is it C killer? I mean
is that in the future is it a replacement for C?

Cheers.


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] 0.10 prerelease testing

[Brian Anderson]

I've been worried about this decision too.

On 04/02/2014 10:34 AM, Steve Klabnik wrote:

I compiled from source just yesterday, but everything's been going swimmingly!

I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most people will
use println!, which is automatically use-able, it _is_ making my
'hello world' examples significantly more complex, since basically
every one of them needs to either import println or use println!("{}",
foo);

I'm not sure if this is a good or bad thing, just wanted to raise that
as a possible issue.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Could the mailing list send digests by time rather than volume?

[Brian Anderson]

It looks like I can set the digest size threshold very large and then 
force it to be sent every day when it never hits that threshold. I'll 
try. Let me know if anything breaks.


On 03/28/2014 09:43 AM, Steven Stewart-Gallus wrote:

The recent giant discussion over unsafe bounds checking highlights the need for
this. Instead of sending digests every few letters digests should be sent every
day or so.

Thank you,
Steven Stewart-Gallus
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: a moratorium on adding unsafe features to the safe subset of Rust

[Brian Anderson]

I appreciate your concern, but I don't think a moratoreum is necessary; 
memory safety is parament to Rust, so the idea of adding 'unsafe 
features to the safe subset of Rust' is an oxymoron.


On 03/28/2014 08:12 PM, Tony Arcieri wrote:

I really love the semantics of the safe subset of Rust.

Recently there has been a call to introduce an optional feature flag
which removes bounds checks to the *safe* subset of Rust (i.e. outside
of unsafe blocks)

I think this sort of suggestion imperils Rust's goals as a language.

Adding off switches for Rust's safety features complicates the
language's implementation and increases the likelihood a language
implementer will make a mistake and turn a safety switch off when it
should be on.

I would like to make a general proposal that the unsafe subset of Rust
be improved to the point where it can answer these sort of concerns, and
that those who make requests to flip off Rust's various safety features
in the safe subset of the language be gently guided towards the unsafe
set of the language while keeping the safe semantics exactly how they are.

--
Tony Arcieri


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

I can imagine that if you want to actually run *rustc* on these then our 
build system is insufficient to produce an arm-linux-unknown-gnueabihf 
rustc compiler from another host. *That* is a problem that needs to be 
solved for a variety of reasons, but also pretty hard.


On 03/28/2014 06:08 PM, Brian Anderson wrote:

I don't actually know what the issue is with Rust on
arm-linux-unknown-gnueabihf. Is cross-compiling to this architecture
with Rust difficult? Why do we need binaries?

One thing we could possibly do without much difficulty is let external
build slaves connect to our build master. That plus a small amount of
new master configuration may be enough to accomplish something useful here.

On 03/28/2014 06:03 PM, Ian Daniher wrote:

Any chance of getting arm-linux-unknown-gnueabihf builds?


I came here to ask this same thing - I'm doing work with rust on cheap
elinux arm boards.

Understand the not mucking with established infrastructure in the midst
of everything else - I'm willing to put up hardware with help, but right
now compiling for rustc arm-gnueabihf host is a nogo, only have target
working. If we have a working mainline build system, I'll host binary
arm-gnueabihf images.

--
Ian


On Fri, Mar 28, 2014 at 4:52 PM, Brian Anderson mailto:bander...@mozilla.com>> wrote:

Not in the near term I think, at least as long as it's I that has to
do the automation - there are many other automation changes already
in the pipeline just for linux/mac/win.

I am at this point amenable to opening up our infrastructure to one
or two trusted and motivated individuals, since I know I'm the
bottleneck on a lot of improvements that folks want to make, but
updating our automation is a tedious and risky affair currently so I
don't want to take that step lightly.



On 03/28/2014 06:16 AM, Chris Morgan wrote:

Any chance of getting arm-linux-unknown-gnueabihf builds?


_
Rust-dev mailing list
Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/__listinfo/rust-dev
<https://mail.mozilla.org/listinfo/rust-dev>




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

I don't actually know what the issue is with Rust on 
arm-linux-unknown-gnueabihf. Is cross-compiling to this architecture 
with Rust difficult? Why do we need binaries?


One thing we could possibly do without much difficulty is let external 
build slaves connect to our build master. That plus a small amount of 
new master configuration may be enough to accomplish something useful here.


On 03/28/2014 06:03 PM, Ian Daniher wrote:

Any chance of getting arm-linux-unknown-gnueabihf builds?


I came here to ask this same thing - I'm doing work with rust on cheap
elinux arm boards.

Understand the not mucking with established infrastructure in the midst
of everything else - I'm willing to put up hardware with help, but right
now compiling for rustc arm-gnueabihf host is a nogo, only have target
working. If we have a working mainline build system, I'll host binary
arm-gnueabihf images.

--
Ian


On Fri, Mar 28, 2014 at 4:52 PM, Brian Anderson mailto:bander...@mozilla.com>> wrote:

Not in the near term I think, at least as long as it's I that has to
do the automation - there are many other automation changes already
in the pipeline just for linux/mac/win.

I am at this point amenable to opening up our infrastructure to one
or two trusted and motivated individuals, since I know I'm the
bottleneck on a lot of improvements that folks want to make, but
updating our automation is a tedious and risky affair currently so I
don't want to take that step lightly.



On 03/28/2014 06:16 AM, Chris Morgan wrote:

Any chance of getting arm-linux-unknown-gnueabihf builds?


_
Rust-dev mailing list
Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/__listinfo/rust-dev
<https://mail.mozilla.org/listinfo/rust-dev>




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

Not in the near term I think, at least as long as it's I that has to do 
the automation - there are many other automation changes already in the 
pipeline just for linux/mac/win.


I am at this point amenable to opening up our infrastructure to one or 
two trusted and motivated individuals, since I know I'm the bottleneck 
on a lot of improvements that folks want to make, but updating our 
automation is a tedious and risky affair currently so I don't want to 
take that step lightly.



On 03/28/2014 06:16 AM, Chris Morgan wrote:

Any chance of getting arm-linux-unknown-gnueabihf builds?



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

On 03/28/2014 05:13 AM, Ben Noordhuis wrote:

On Fri, Mar 28, 2014 at 2:25 AM, Brian Anderson  wrote:

Hi.

I have very exciting news. Rust now has binary installers for Linux and Mac,
as well as nightly builds for Windows, Linux and Mac.

Official Rust installers now come in the following forms:

* source .tar.gz - the same old source tarball
* binary .tar.gz - Generic Unix installers, currently built for Linux and
Mac
* win .exe - 32-bit windows installers
* mac .pkg files - Mac installers in the standard .pkg format

With 0.10 coming next week, there's a pretty big risk changing the
installation mechanism now, so please do test Rust installation,
particularly on more exotic systems that need to use `--prefix`, `--libdir`,
etc.


# About the new installation system

We have a new installation script, `install.sh` that is contained in the
binary tarballs and also used for `make install`. `install.sh` takes several
arguments controlling the installation, as well as an `--uninstall` argument
that can be used to uninstall previous versions. This installation script
manages upgrades correctly.

The binary tarballs are also suitable for running rustc in place without
installing.

For convenience I've also published a little script called rustup.sh that
downloads the appropriate nightly and installs:

```
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
```

Uninstall:

```
curl -s http://www.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall
```

I don't plan to recommend this method for general use since people tend to
have security concerns with it, but I expect it to make keeping up with
master much more convenient.


# Nightly

## Source

* http://static.rust-lang.org/dist/rust-nightly.tar.gz

## Linux

*
http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz
*
http://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz

## Mac

* http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.tar.gz
* http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.tar.gz

## Windows (32-bit)

* http://static.rust-lang.org/dist/rust-nightly-install.exe


# 0.10-pre

## Source

* http://static.rust-lang.org/dist/rust-0.10-pre.tar.gz

## Linux

*
http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-unknown-linux-gnu.tar.gz
*
http://static.rust-lang.org/dist/rust-0.10-pre-i686-unknown-linux-gnu.tar.gz

## Mac

* http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.tar.gz
* http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.tar.gz

## Windows (32-bit)

* http://static.rust-lang.org/dist/rust-0.10-pre-install.exe


Brian, would it be possible to provide SHA checksums?  It's not that
I'm worried about man-in-the-middle attacks, just that it'd be nice to
check that the download isn't corrupt.



It should be fairly easy to automatically upload checksums as well, yes. 
I'll look into it over the weekend.


As strcat said, automatic signing is harder, and I don't want to solve 
the various problems there yet.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

On 03/27/2014 09:05 PM, György Andrasek wrote:

curl -s http://www.rust-lang.org/rustup.sh | sudo sh


Can we please not recommend people pipe random text from across the
internet into a fricking *root shell*?



Yes. In fact my original email said exactly that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

That's right. I didn't mention it because nothing has changed (yet) in 
the windows installers. Sorry for the confusion.


On 03/27/2014 06:59 PM, Matthew McPherrin wrote:

On Thu, Mar 27, 2014 at 6:25 PM, Brian Anderson  wrote:

I have very exciting news. Rust now has binary installers for Linux and Mac,
as well as nightly builds for Windows, Linux and Mac.


I am unclear what Windows is missing that it's in your "nightly
builds" list but not your "binary installer" list.  Or do you simply
exclude it from the first set because it already had one?



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] New Rust binary installers and nightlies

[Brian Anderson]

Hi.

I have very exciting news. Rust now has binary installers for Linux and 
Mac, as well as nightly builds for Windows, Linux and Mac.


Official Rust installers now come in the following forms:

* source .tar.gz - the same old source tarball
* binary .tar.gz - Generic Unix installers, currently built for Linux 
and Mac

* win .exe - 32-bit windows installers
* mac .pkg files - Mac installers in the standard .pkg format

With 0.10 coming next week, there's a pretty big risk changing the 
installation mechanism now, so please do test Rust installation, 
particularly on more exotic systems that need to use `--prefix`, 
`--libdir`, etc.



# About the new installation system

We have a new installation script, `install.sh` that is contained in the 
binary tarballs and also used for `make install`. `install.sh` takes 
several arguments controlling the installation, as well as an 
`--uninstall` argument that can be used to uninstall previous versions. 
This installation script manages upgrades correctly.


The binary tarballs are also suitable for running rustc in place without 
installing.


For convenience I've also published a little script called rustup.sh 
that downloads the appropriate nightly and installs:


```
curl -s http://www.rust-lang.org/rustup.sh | sudo sh
```

Uninstall:

```
curl -s http://www.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall
```

I don't plan to recommend this method for general use since people tend 
to have security concerns with it, but I expect it to make keeping up 
with master much more convenient.



# Nightly

## Source

* http://static.rust-lang.org/dist/rust-nightly.tar.gz

## Linux

* 
http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz
* 
http://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz


## Mac

* http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.tar.gz
* http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.tar.gz

## Windows (32-bit)

* http://static.rust-lang.org/dist/rust-nightly-install.exe


# 0.10-pre

## Source

* http://static.rust-lang.org/dist/rust-0.10-pre.tar.gz

## Linux

* 
http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-unknown-linux-gnu.tar.gz
* 
http://static.rust-lang.org/dist/rust-0.10-pre-i686-unknown-linux-gnu.tar.gz


## Mac

* http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.pkg
* http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.tar.gz
* http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.tar.gz

## Windows (32-bit)

* http://static.rust-lang.org/dist/rust-0.10-pre-install.exe
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] PDX-Rust meetup tomorrow

[Brian Anderson]

Good luck at the meetup tonight, Tom. The last one I attended in PDX was 
a lot of fun.


On 03/26/2014 12:01 PM, Tom Lee wrote:

Hey folks,

Per the subject, there's a Rust meetup in Portland, OR tomorrow night
from 6:30pm. Details here:

http://calagator.org/events/1250465822

I'm waiting on a speaker to get back to me, so the topic is still
unfortunately TBA. If our speaker falls through, I'll slap together an
11th hour walk-through of some Rust compiler internals. Should be fun
either way!

Cheers,
Tom

--
*Tom Lee */ http://tomlee.co  / @tglee




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Which installation options are actually required?

[Brian Anderson]

Thanks, Ben. Sounds like I'm going to need to rethink a few things to 
make sure --libdir works sanely. I can imagine how it may work correctly 
right now from a source-only installer. rustc may need some tweaks to 
make it work more generally.


On 03/22/2014 11:49 AM, Ben Noordhuis wrote:

On Sat, Mar 22, 2014 at 12:55 AM, Brian Anderson  wrote:

I'm in the process of rewriting most of the installation code and I'm at the
point where it's almost done, and I'm looking at the options to configure
that affect installation destinations and wondering which really must be
implemented.

configure supports a variety of standard options that impact install
directories, most of which we ignore because we have nothing to put into
them, and some of which just can't work currently given Rust's installation.

The relevant options that might affect Rust's installation are:

--mandir - changes where man pages go
--libdir - changes where libraries go
--rustlibdir - changes the *name* of rust's own directory under lib/

First of all, having `--rustlibdir` as an option is probably just wrong and
I don't intend to support it; I don't see any reason to make this
configurable.

Changing `--libdir` will almost certainly make rustc break since it depends
on being able to find the lib directory as a relative path from the bin
directory.


Packagers will be unhappy about the absence of a --libdir switch.  For
example, x86_64 Fedora requires that normal libraries are installed to
/usr/lib64, not /usr/lib.


Finally, `--mandir` is an option that I suspect *actually works* in the
current implementation, but I don't know if there's any reason ever to not
install to `share/man`.


FreeBSD?  It has man pages in /usr/man rather than /usr/share/man.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Which installation options are actually required?

[Brian Anderson]

I'm in the process of rewriting most of the installation code and I'm at 
the point where it's almost done, and I'm looking at the options to 
configure that affect installation destinations and wondering which 
really must be implemented.


configure supports a variety of standard options that impact install 
directories, most of which we ignore because we have nothing to put into 
them, and some of which just can't work currently given Rust's installation.


The relevant options that might affect Rust's installation are:

--mandir - changes where man pages go
--libdir - changes where libraries go
--rustlibdir - changes the *name* of rust's own directory under lib/

First of all, having `--rustlibdir` as an option is probably just wrong 
and I don't intend to support it; I don't see any reason to make this 
configurable.


Changing `--libdir` will almost certainly make rustc break since it 
depends on being able to find the lib directory as a relative path from 
the bin directory.


Finally, `--mandir` is an option that I suspect *actually works* in the 
current implementation, but I don't know if there's any reason ever to 
not install to `share/man`.


Is anybody using any of these options, and why?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Announcing the new Rust package manager, Cargo

[Brian Anderson]

Dearest Rustlers,

Today I'm super-excited to announce that Mozilla has arranged to develop 
a world-class package manager for Rust. Yehuda Katz and Carl Lerche, 
from Tilde Inc., have previously built the popular Ruby package manager, 
Bundler, and now they are going to build Rust's package manager, Cargo. 
They are *experts* at the management of packages, and will deliver a 
tool that builds off both their experience in Ruby and ours with pevious 
iterations of rustpkg.


The two of them will be talking about this project in more detail very 
soon. Please welcome them into your hearts.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] doc sprint today in San Francisco at 12pm PDT!

[Brian Anderson]

This appears to be all the doc-sprint-inspired PR's. More than I expected!

https://github.com/mozilla/rust/pull/12982
https://github.com/mozilla/rust/pull/12968
https://github.com/mozilla/rust/pull/12954
https://github.com/mozilla/rust/pull/12955
https://github.com/mozilla/rust/pull/12956
https://github.com/mozilla/rust/pull/12958
https://github.com/mozilla/rust/pull/12953
https://github.com/mozilla/rust/pull/12952
https://github.com/mozilla/rust/pull/12950
https://github.com/mozilla/rust/pull/12948
https://github.com/mozilla/rust/pull/12944
https://github.com/mozilla/rust/pull/12942


On 03/17/2014 09:22 AM, Lindsey Kuper wrote:

On Mon, Mar 17, 2014 at 8:04 AM, Cadence Marseille
 wrote:

That was fun!  I hope to see a few more of these sprints in the future.


Same!  Thanks for doing the work of organizing it.

Do we have any stats, like number of PRs as a result of the sprint,
number of modules documented, or some such thing?

Lindsey
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Shutting down rust-commits

[Brian Anderson]

I suspect this will not impact many, but I'm shutting down the 
rust-commits mailing list, which was just used to relay commits via the 
GitHub commit hook.


I haven't been subscribed to it for a long time and I know very few 
others that were using it. If it does impact you, I'm sorry for the 
inconvience.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust automation downtime

[Brian Anderson]

The entire Mountain View office is moving to a new building that has 
more space.


On 03/13/2014 06:21 AM, Thad Guidry wrote:

Curious, Whole Mozilla moving ? or just some teams ?  and why ?  making
room for others ?  kicked out by grumpy landlord or mayor ? :-)


On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson mailto:bander...@mozilla.com>> wrote:

This weekend Mozilla's Mountain View office is moving, and along
with it some of Rust's build infrastructure. There will be downtime.

Starting tonight bors is not gated on the mac or android builders
and those machines are turned off. Sometime this weekend other build
machines, including the build master and bors, will be moved and
things will stop working.

The Monday triage email will be delayed.

We'll sort everything out Monday. Sorry for the inconvenience.

Regards,
Brian
_
Rust-dev mailing list
Rust-dev@mozilla.org <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/__listinfo/rust-dev
<https://mail.mozilla.org/listinfo/rust-dev>




--
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Rust automation downtime

[Brian Anderson]

This weekend Mozilla's Mountain View office is moving, and along with it 
some of Rust's build infrastructure. There will be downtime.


Starting tonight bors is not gated on the mac or android builders and 
those machines are turned off. Sometime this weekend other build 
machines, including the build master and bors, will be moved and things 
will stop working.


The Monday triage email will be delayed.

We'll sort everything out Monday. Sorry for the inconvenience.

Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Brian Anderson]

On 03/12/2014 03:42 AM, Simon Sapin wrote:

On 12/03/2014 01:11, Brian Anderson wrote:

* Fork the RFC repohttp://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where
'my-feature' is descriptive. don't assign an RFC number yet).
* Fill in the RFC
* Submit a pull request. The pull request is the time to get review of
the design from the larger community.
* Build consensus and integrate feedback. RFCs that have broad support
are much more likely to make progress than those that don't receive any
comments.
* Eventually, somebody on the [core team] will either accept the RFC by
merging the pull request and assigning the RFC a number, at which point
the RFC is 'active', or reject it by closing the pull request.


Should the mailing list be involved in this process, as a way to get
more people discussing RFCs? (Maybe automatically with a bot sending
email for every PR in the RFC repo.)


Explicitly, no. rust-dev has a broad audience, few moderation options, 
and discussions tend to derail quickly.




On the other hand, we probably don’t want to fragment the discussion
between GitHub issues and email.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Brian Anderson]

On 03/12/2014 12:54 AM, Flaper87 wrote:




2014-03-12 2:11 GMT+01:00 Brian Anderson mailto:bander...@mozilla.com>>:

[snip]

-

Many changes, including bug fixes and documentation improvements can
be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put
through a bit of a design process and produce a consensus among the
Rust community and the [core team].

The "RFC" (request for comments process) is intended to provide a
consistent and controlled path for new features to enter the
language and standard libraries, so that all stakeholders can be
confident about the direction the language is evolving in.

## When you need to follow this process

You need to follow this process if you intend to make "substantial"
changes to the Rust distribution. What constitutes a "substantial"
change is evolving based on community norms, but may include the
following.

   - Any semantic or syntactic change to the language that is not a
bugfix.
   - Changes to the interface between the compiler and libraries,
including lang items and intrinsics.
   - Additions to `std`

Some changes do not require an RFC:

   - Rephrasing, reorganizing, refactoring, or otherwise "changing
shape does not change meaning".
   - Additions that strictly improve objective, numerical quality
criteria (warning removal, speedup, better platform coverage, more
parallelism, trap more errors, etc.)
   - Additions only likely to be _noticed by_ other
developers-of-rust, invisible to users-of-rust.

If you submit a pull request to implement a new feature without
going through the RFC process, it may be closed with a polite
request to submit an RFC first.

## What the process is

In short, to get a major feature added to Rust, one must first get
the RFC merged into the RFC repo as a markdown file. At that point
the RFC is 'active' and may be implemented with the goal of eventual
inclusion into Rust.

* Fork the RFC repo http://github.com/rust-lang/__rfcs
<http://github.com/rust-lang/rfcs>
* Copy `-template.md <http://-template.md>` to
`active/-my-feature.md <http://-my-feature.md>` (where
'my-feature' is descriptive. don't assign an RFC number yet).


What about using the PR's number? That means we'll end up with some gaps
between accepted RFCs but... just thinking aloud.


We've discussed this but decided against, though the argument doesn't 
seem to be that strong either way.





* Fill in the RFC
* Submit a pull request. The pull request is the time to get review
of the design from the larger community.
* Build consensus and integrate feedback. RFCs that have broad
support are much more likely to make progress than those that don't
receive any comments.
* Eventually, somebody on the [core team] will either accept the RFC
by merging the pull request and assigning the RFC a number, at which
point the RFC is 'active', or reject it by closing the pull request.


We should also use tags: `Rejected` / `Approved`


I'm specifically trying to avoid those words :) 'approved' is stronger 
than I want, because an approved RFC still may not get merged into the 
language, and being 'rejected' is unfun.





I'm wondering if we should keep rejected RFCs too and not just as closed
PRs. If for some reason, this repo is moved out of GH in the future,
we'd loose a bunch of RFC history. We could keep the first rejected RFC
for a type of change and reject future duplicated RFCs by linking them
to that RFC. Not sure about this, though.


I do think this is a good idea, particularly for good RFCs that we 
nonetheless don't want to implement. I haven't put any language in about 
doing this but I suspect it will happen anyway when the proper case arises.





Once an RFC becomes active then authors may implement it and submit
the feature as a pull request to the Rust repo. An 'active' is not a
rubber stamp, and in particular still does not mean the feature will
ultimately be merged; it does mean that in principle all the major
stakeholders have agreed to the feature and are amenable to merging it.

Modifications to active RFC's can be done in followup PR's. An RFC
that makes it through the entire process to implementation is
considered 'complete' and is moved to the 'complete' folder; an RFC
that fails after becoming active is 'inactive' and moves to the
'inactive' folder.


We also need a way to track who's working on that RFC. Should an RFC bug
be created in Rust's repo and be linked t

[rust-dev] RFC: Updated RFC process

[Brian Anderson]

Hey, Rusties.

The freewheeling way that we add new features to Rust has been good for 
early development, but for Rust to become a mature platform we need to 
develop some more self-discipline when it comes to changing the system. 
So this is a proposed modification to our current RFC process to make it 
a more integral part of the overall development process, and one that is 
followed consistently to introduce features to Rust.


Some improvements I would like this to bring over the current process 
include:


* Discourage unactionable or vague RFCs
* Ensure that all serious RFCs are considered equally
* Those with a stake in Rust's development should feel confident they 
understand why new features are being merged


Below is the proposed change to the RFC process. Please read and 
comment. Assuming the feedback is positive I'll update the wiki with 
this later.


-

Many changes, including bug fixes and documentation improvements can be 
implemented and reviewed via the normal GitHub pull request workflow.


Some changes though are "substantial", and we ask that these be put 
through a bit of a design process and produce a consensus among the Rust 
community and the [core team].


The "RFC" (request for comments process) is intended to provide a 
consistent and controlled path for new features to enter the language 
and standard libraries, so that all stakeholders can be confident about 
the direction the language is evolving in.


## When you need to follow this process

You need to follow this process if you intend to make "substantial" 
changes to the Rust distribution. What constitutes a "substantial" 
change is evolving based on community norms, but may include the following.


  - Any semantic or syntactic change to the language that is not a bugfix.
  - Changes to the interface between the compiler and libraries, 
including lang items and intrinsics.

  - Additions to `std`

Some changes do not require an RFC:

  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape 
does not change meaning".
  - Additions that strictly improve objective, numerical quality 
criteria (warning removal, speedup, better platform coverage, more 
parallelism, trap more errors, etc.)
  - Additions only likely to be _noticed by_ other developers-of-rust, 
invisible to users-of-rust.


If you submit a pull request to implement a new feature without going 
through the RFC process, it may be closed with a polite request to 
submit an RFC first.


## What the process is

In short, to get a major feature added to Rust, one must first get the 
RFC merged into the RFC repo as a markdown file. At that point the RFC 
is 'active' and may be implemented with the goal of eventual inclusion 
into Rust.


* Fork the RFC repo http://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where 
'my-feature' is descriptive. don't assign an RFC number yet).

* Fill in the RFC
* Submit a pull request. The pull request is the time to get review of 
the design from the larger community.
* Build consensus and integrate feedback. RFCs that have broad support 
are much more likely to make progress than those that don't receive any 
comments.
* Eventually, somebody on the [core team] will either accept the RFC by 
merging the pull request and assigning the RFC a number, at which point 
the RFC is 'active', or reject it by closing the pull request.


Once an RFC becomes active then authors may implement it and submit the 
feature as a pull request to the Rust repo. An 'active' is not a rubber 
stamp, and in particular still does not mean the feature will ultimately 
be merged; it does mean that in principle all the major stakeholders 
have agreed to the feature and are amenable to merging it.


Modifications to active RFC's can be done in followup PR's. An RFC that 
makes it through the entire process to implementation is considered 
'complete' and is moved to the 'complete' folder; an RFC that fails 
after becoming active is 'inactive' and moves to the 'inactive' folder.


### Help this is all too informal!

The process is intended to be as lightweight as reasonable for the 
present circumstances. As usual, we are trying to let the process be 
driven by consensus and community norms, not impose more structure than 
necessary.


[core team]: https://github.com/mozilla/rust/wiki/Note-core-team
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "Virtual fn" is a bad idea

[Brian Anderson]

The downsides you list are all more or less applicable to this design, 
indeed. We are seeing real requirements in real code that indicates that 
the current abstraction facilities provided by Rust are efficient enough 
for certain demanding use cases (the DOM in particular).


Here are the identified requirements:

tree of types (single inheritance)
downcasting
thin pointers
cheap field access
easy upcasting

The big problem that putting virtual methods on structs solves is 
removing the need for fat pointers to objects - with a lot of trait 
objects this can involve many duplicated words.


Fortunately, this feature is independent of others and we can feature 
gate it until it's right. So as with many aspects of Rust's design we 
are going to iterate on it using *real code* until it's right, and in 
the end Rust is going to be able to to provide the zero-cost 
abstractions necessary to write very high performance code.


Regards,
Brian


On 03/11/2014 12:09 PM, Bill Myers wrote:

I see a proposal to add "virtual struct" and "virtual fn" in the workweek 
meeting notes, which appears to add an exact copy of Java's OO system to Rust.

I think however that this should be carefully considered, and preferably not 
added at all (or failing that, feature gated and discouraged).

The core problem of "virtual functions" (shared by Java's classes, etc.) is 
that rather than exposing a single public API, they expose two: the API formed by public 
functions, and the API formed by virtual functions to be overridden by subclasses, and 
the second API is exposed in an inflexible and unclean way.

A much better way of allowing to override part of a struct's behavior is by 
defining a trait with the overridable functionality, and allowing to pass in an 
implementation of the trait to the base class, while also providing a default 
implementation if desired.

Another way is to have the "subclass" implement all the traits that the "base class" implements, 
include a field of the "base class" type, and then direct all non-overridden functionality to the "base 
class" (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all 
non-implemented trait functions by calling the same function on the base class field).

These approaches can be combined, as the first approach allows to change the "inside" 
behavior of the base class, while the second one allows to put extra behavior "around" 
the base class code.

The fact that OO using virtual functions (as opposed to traits) is a bad design 
is one of the crucial steps forward of the design of languages like Go and 
current Rust compared to earlier OO languages, and Rust should not go backwards 
on this.

Here is a list of issues with virtual functions:

1. Incentive for bad documentation

Usually there is no documentation for how virtual functions are supposed to be 
overridden, and it as awkward to add it since it needs to be mixed with the 
documentation on how to use the struct

2. Mishmashing multiple unrelated APIs

With traits, you could pass in multiple objects to implement separate sets of 
overridable functionality; with virtual structs you need to mishmash all those 
interfaces into a single set of virtual functions, all sharing data even when 
not appropriate.

3. No encapsulation

Private data for virtual function implementations is accessible to all other 
functions in the struct.

This means for instance that if you have a virtual function called "compute_foo()" that is 
implemented by default by reading a "foo" field in the base class, then all other parts of the base 
class can access "foo" too.

If anything else accesses mistakenly "foo" directly, which it can, then overriding 
"compute_foo()" will not work as expected.

If compute_foo() were provided by an external trait implementation, then "foo" 
would be private and inaccessible, eliminating the problem.

4. Data for overridden implementations left there in a "zombie" state.

In the above example, if you override "compute_foo()", the foo variable in the 
base class will no longer be used, yet it will still be present in the type and allocated 
in memory.

5. Inability to statically dispatch

With a trait implementation, you can pass the concrete type as a generic 
parameter, allowing static dispatch.

If you instead call an overridable virtual function, then you can't dispatch 
that statically at all (unless you add cumbersome syntax for that).

6. Adds a ton of unnecessary complexity to the language 

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Doc sprint planning

[Brian Anderson]

Hey,

As you may know, we've got our first doc sprint scheduled for Sunday, 
12-4 Pacific time. We'll to set up the commons area at the SF office 
with pizza and turn on video conferencing for remoties. Before that day 
comes though we need to come up with some kind of plan, something that 
is simple and fun.


Here's my strawman proposal for what we're going to do Sunday:

We'll focus on API docs since those are bitesize units of work and 
extremely parallelizable. Before the event we come up with a checklist 
for what API docs should include, as well as a list of high-value API's 
with missing docs.


Sunday we put that list on an etherpad, and let people claim individual 
functions, traits, etc. Additionally, we keep a 'scoreboard' to track 
who completes the most docs. Whoever has the most docs at the end wins 
(just pizza and accolades).


Does this sound reasonable? Does anybody want to volunteer to 'run' the 
sprint (make the list of needed docs, help people find tasks, collect 
and upstream the results, etc.)?


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Work week minutes and upcoming RFCs

[Brian Anderson]

Hi.

Last week a number of us got together to hash out designs for the 
remaining features in Rust 1.0, with the goal of producing RFC's for 
each in the upcoming weeks.


I'm very optimistic about how it's all going to come together, and that 
the quantity of work to be completed is reasonable.


I've put the minutes for the week up on the wiki[1] for the curious, but 
I warn you that they are sometimes inscrutable.


[1]: https://github.com/mozilla/rust/wiki/Meeting-workweek-2014-03-03

As I mentioned, folks will be writing RFC's on all the major topics to 
get feedback, and they are going to do so according to a tweaked RFC 
process aimed at introducing new features into Rust in a more controlled 
way than we have in the past. More about that later.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] history of rust?

[Brian Anderson]

There is not.

I am interested in this topic. There is a great deal of public 
information about Rust's development and I'd love it to be organized in 
an accessible way. With the right presentation it could be interesting, 
dramatic, and maybe even useful to other designers.


On 02/28/2014 11:13 AM, Martin Matusiak wrote:

Hi,

I'm wondering if there is a resource somewhere that chronicles the
history of Rust from its beginnings. My interest is not so much the
folklore, but more the heritage that would make it easier to
understand why the language is the way it is today.


Thanks,

Martin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Breaking change: new Hash framework has landed

[Brian Anderson]

On 02/24/2014 10:15 PM, Erick Tryzelaar wrote:

Brian: yes, at the moment `#[deriving(Hash)]` does support more than
SipHash. However this PR temporarily removes that feature to replace
`#[allow(default_type_param_usage)]` with `#[feature(default_type_params)]`:

https://github.com/mozilla/rust/pull/12525

If we land that change, we could try two things. First, we could just
turn on default_type_params permanently. Second, we could allow a syntax
extension to check if a feature has been enabled in a crate. Brian, I
know you were talking about this earlier on IRC, did you end up making a
decision on what to do?


I am hoping that somebody will prototype allocators before we turn 
default_type_params on permanently.




György: Yep, there is. I went through approximately 13 iterations to
converge on this design :) The reason why the `impl`'s need to know what
kind of state they are dealing with is to support custom hashers. In
most cases, people will want to compute a hash over the bytes of a
value, so that value's hash impl needs to know that it can pass the
value's bytes in with `state.write(...)`. Other values may actually have
a hash baked into them, or want to use an integer value as a hash. These
can just return the hash value by directly assigning the hash to the
`*state` as I did in the example. While not  cryptographically safe,
this can be dramatically faster than using something like SipHash. Yet
another value may want to use two completely different hashing
algorithms depending depending on some property. Letting the `Hash`ee
know about the state type allows for this level of flexibility. It also
adds some type safety, in that it'll prevent you from accidentally
passing a `Writer`-based hash state into a type that should only be used
with a specific hasher.



On Mon, Feb 24, 2014 at 9:35 PM, Niko Matsakis mailto:n...@alum.mit.edu>> wrote:

This looks very cool.


On Mon, Feb 24, 2014 at 11:31:19AM -0500, Erick Tryzelaar wrote:
 > I'm happy to announce that Rust's new hashing framework has
landed in:
 >
 > https://github.com/mozilla/rust/pull/11863
 > https://github.com/mozilla/rust/pull/12492
 >
 > This PR has has changed how to declare a type is hashable. Here's
a full
 > example on how to hash a value using either the new
`#[deriving(Hash)]` or
 > manual implementation.
 >
 > ```
 > use std::hash::{Hash, hash};
 > use std::hash::sip::SipState;
 >
 > #[deriving(Hash)]
 > struct Foo {
 > a: ~str,
 > b: uint,
 > c: bool,
 > }
 >
 > struct Bar {
 > a: ~str,
 > b: uint,
 > c: bool,
 > }
 >
 > impl Hash for Bar {
 > fn hash(&self, state: &mut SipState) {
 > self.a.hash(state);
 > self.b.hash(state);
 > self.c.hash(state);
 > }
 > }
 >
 > fn main() {
 > let foo = Foo { a: ~"hello world", b: 5, c: true };
 > println!("{}", hash(&foo));
 >
 > let bar = Bar { a: ~"hello world", b: 5, c: true };
 > println!("{}", hash(&bar));
 > }
 > ```
 >
 > We also have experimental support for hashers that compute a
value off a
 > stream of bytes:
 >
 > ```
 > use std::hash::{Hash, Hasher};
 > use std::io::IoResult;
 >
 > #[deriving(Hash)] // automatically provides hashing from a stream
of bytes
 > struct Foo {
 > a: ~str,
 > b: uint,
 > c: bool,
 > }
 >
 > struct Bar {
 > a: ~str,
 > b: uint,
 > c: bool,
 > }
 >
 > #[allow(default_type_param_usage)]
 > impl Hash for Bar {
 > fn hash(&self, state: &mut S) {
 > self.a.hash(state);
 > self.b.hash(state);
 > self.c.hash(state);
 > }
 > }
 >
 > struct SumState {
 > sum: u64,
 > }
 >
 > impl Writer for SumState {
 > fn write(&mut self, bytes: &[u8]) -> IoResult<()> {
 > for byte in bytes.iter() {
 > self.sum += *byte as u64;
 > }
 > Ok(())
 > }
 > }
 >
 > struct SumHasher;
 >
 > #[allow(default_type_param_usage)]
 > impl Hasher for SumHasher {
 > fn hash>(&self, value: &T) -> u64 {
 > let mut state = SumState { sum: 0 };
 > value.hash(&mut state);
 > state.sum
 > }
 > }
 >
 > fn main() {
 > let hasher = SumHasher;
 > let foo = Foo { a: ~"hello world", b: 5, c: true };
 > println!("{}", hasher.hash(&foo));
 > let bar = Bar { a: ~"hello world", b: 5, c: true };
 > println!("{}", hasher.hash(&bar));
 > }
 > ```
 >
 > Finally, we also support completely custom hash computation:
 >
 > ```
 > use std::hash::{Hash, Hasher};
 >
 > struct Foo {
 > hash: u64
 > }
 >
 > #[all

Re: [rust-dev] Breaking change: new Hash framework has landed

[Brian Anderson]

Thanks, Erick! This was an awesome effort that greatly improves the 
ergonomics of hashing.


On 02/24/2014 08:31 AM, Erick Tryzelaar wrote:

I'm happy to announce that Rust's new hashing framework has landed in:

https://github.com/mozilla/rust/pull/11863
https://github.com/mozilla/rust/pull/12492

This PR has has changed how to declare a type is hashable. Here's a full
example on how to hash a value using either the new `#[deriving(Hash)]`
or manual implementation.

```
use std::hash::{Hash, hash};
use std::hash::sip::SipState;

#[deriving(Hash)]
struct Foo {
 a: ~str,
 b: uint,
 c: bool,
}

struct Bar {
 a: ~str,
 b: uint,
 c: bool,
}

impl Hash for Bar {
 fn hash(&self, state: &mut SipState) {
 self.a.hash(state);
 self.b.hash(state);
 self.c.hash(state);
 }
}

fn main() {
 let foo = Foo { a: ~"hello world", b: 5, c: true };
 println!("{}", hash(&foo));

 let bar = Bar { a: ~"hello world", b: 5, c: true };
 println!("{}", hash(&bar));
}
```

We also have experimental support for hashers that compute a value off a
stream of bytes:

```
use std::hash::{Hash, Hasher};
use std::io::IoResult;

#[deriving(Hash)] // automatically provides hashing from a stream of bytes
struct Foo {
 a: ~str,
 b: uint,
 c: bool,
}



So `#[deriving(Hash)]` automatically gets you hashing for more than just 
SipHash?




struct Bar {
 a: ~str,
 b: uint,
 c: bool,
}

#[allow(default_type_param_usage)]
impl Hash for Bar {
 fn hash(&self, state: &mut S) {
 self.a.hash(state);
 self.b.hash(state);
 self.c.hash(state);
 }
}

struct SumState {
 sum: u64,
}

impl Writer for SumState {
 fn write(&mut self, bytes: &[u8]) -> IoResult<()> {
 for byte in bytes.iter() {
 self.sum += *byte as u64;
 }
 Ok(())
 }
}

struct SumHasher;

#[allow(default_type_param_usage)]
impl Hasher for SumHasher {
 fn hash>(&self, value: &T) -> u64 {
 let mut state = SumState { sum: 0 };
 value.hash(&mut state);
 state.sum
 }
}

fn main() {
 let hasher = SumHasher;
 let foo = Foo { a: ~"hello world", b: 5, c: true };
 println!("{}", hasher.hash(&foo));
 let bar = Bar { a: ~"hello world", b: 5, c: true };
 println!("{}", hasher.hash(&bar));
}
```

Finally, we also support completely custom hash computation:

```
use std::hash::{Hash, Hasher};

struct Foo {
 hash: u64
}

#[allow(default_type_param_usage)]
impl Hash for Foo {
 fn hash(&self, state: &mut u64) {
 *state = self.hash
 }
}

struct CustomHasher;

#[allow(default_type_param_usage)]
impl Hasher for CustomHasher {
 fn hash>(&self, value: &T) -> u64 {
 let mut state = 0;
 value.hash(&mut state);
 state
 }
}

fn main() {
 let hasher = CustomHasher;
 let foo = Foo { hash: 5 };
 println!("{}", hasher.hash(&foo));
}
```

This may break over the next couple days/weeks as we figure out the
right way to do this. Furthermore, HashMaps have not yet been updated to
take advantage of the custom hashers, but that should be coming later on
this week.

I hope they work well for all of you. If you run into any trouble,
please file bugs and cc @erickt on the ticket.

Thanks,
Erick


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: About the library stabilization process

[Brian Anderson]

On 02/19/2014 02:37 AM, György Andrasek wrote:

On Wed, Feb 19, 2014 at 1:40 AM, Brian Anderson  wrote:

Backwards-compatibility is guaranteed.

Does that include ABI compatibility?


Second, the AST is traversed and stability index is propagated downward to any 
indexable node that isn't explicitly tagged.

Should it be an error to use lower stability internally?


By default all nodes are *stable* - library authors have to opt-in to stability 
index tracking. This may end up being the wrong default and we'll want to 
revisit.

Oh dear god no. `stable` should be *earned* over time, otherwise it's
meaningless. The compiler should treat untagged code as `unstable`,
`experimental` or a special `untagged` stability and accept that level
by default.



OK, I agree let's start all code at `#[experimental]`. It's not too much 
burden for authors that don't want part of it to put an attribute on 
their crates.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] RFC: About the library stabilization process

[Brian Anderson]

Hey there.

I'd like to start the long process of stabilizing the libraries, and 
this is the opening salvo. This process and the tooling to support it 
has been percolating on the issue tracker for a while, but this is a 
summary of how I expect it to work. Assuming everybody feels good about 
it, we'll start trying to make some simple API's stable starting later 
this week or next.



# What is the stability index and stability attributes?

The stability index is a way of tracking, at the item level, which 
library features are safe to use backwards-compatibly. The intent is 
that the checks for stability catch all backwards-incompatible uses of 
library features. Between feature gates and stability


The stability index of any particular item can be manually applied with 
stability attributes, like `#[unstable]`.


These definitions are taken directly from the node.js documentation. 
node.js additionally defines the 'locked' and 'frozen' levels, but I 
don't think we need them yet.


* Stability: 0 - Deprecated

This feature is known to be problematic, and changes are
planned.  Do not rely on it.  Use of the feature may cause 
warnings.  Backwards

compatibility should not be expected.

* Stability: 1 - Experimental

This feature was introduced recently, and may change
or be removed in future versions.  Please try it out and provide 
feedback.
If it addresses a use-case that is important to you, tell the node 
core team.


* Stability: 2 - Unstable

The API is in the process of settling, but has not yet had
sufficient real-world testing to be considered stable. 
Backwards-compatibility

will be maintained if reasonable.

* Stability: 3 - Stable

The API has proven satisfactory, but cleanup in the underlying
code may cause minor changes.  Backwards-compatibility is guaranteed.

Crucially, once something becomes 'stable' its interface can no longer 
change outside of extenuating circumstances - reviewers will need to be 
vigilant about this.


All items may have a stability index: crates, modules, structs, enums, 
typedefs, fns, traits, impls, extern blocks;

extern statics and fns, methods (of inherent impls only).

Implementations of traits may have their own stability index, but their 
methods have the same stability as the trait's.



# How is the stability index determined and checked?

First, if the node has a stability attribute then it has that stability 
index.


Second, the AST is traversed and stability index is propagated downward 
to any indexable node that isn't explicitly tagged.


Reexported items maintain the stability they had in their original location.

By default all nodes are *stable* - library authors have to opt-in to 
stability index tracking. This may end up being the wrong default and 
we'll want to revisit.


During compilation the stabilization lint does at least the following 
checks:


* All components of all paths, in all syntactic positions are checked, 
including in

  * use statements
  * trait implementation and inheritance
  * type parameter bounds
* Casts to traits - checks the trait impl
* Method calls - checks the method stability

Note that not all of this is implemented, and we won't have complete 
tool support to start with.



# What's the process for promoting libraries to stable?

For 1.0 we're mostly concerned with promoting large portions of std to 
stable; most of the other libraries can be experimental or unstable. 
It's going to be a lengthy process, and it's going to require some 
iteration to figure out how it works best.


The process 'leader' for a particular module will post a stabilization 
RFC to the mailing list. Within, she will state the API's under 
discussion, offer an overview of their functionality, the patterns used, 
related API's and the patterns they use, and finally offer specific 
suggestions about how the API needs to be improved or not before it's 
final. If she can confidently recommend that some API's can be tagged 
stable as-is then that helps everybody.


After a week of discussion she will summarize the consensus, tag 
anything as stable that already has agreement, file and nominate issues 
for the remaining, and ensure that *somebody makes the changes*.


During this process we don't necessarily need to arrive at a plan to 
stabilize everything that comes up; we just need to get the most crucial 
features stable, and make continual progress.


We'll start by establishing a stability baseline, tagging most 
everything experimental or unstable, then proceed to the very simplest 
modules, like 'mem', 'ptr', 'cast', 'raw'.


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?

[Brian Anderson]

This may be the most canonical description of target triples (autoconf 
config names): https://sourceware.org/autobook/autobook/autobook_17.html


Triples are just a short way of identifying a compilation target, and 
their naming is mostly out of our hands, established by historical 
precedent. The individual components of the triple mean very little - 
it's generally the entire string used to identify a platform. "unknown" 
is a common vendor name where there's no obvious vendor, shows up a lot 
in linux triples, though `x86_64-pc-linux-gnu` is also common; "-gnu" 
probably means the target has a GNU userspace.


On 02/14/2014 05:16 PM, Liigo Zhuang wrote:

Hello Rusties:

I'm using Debian 7.4 Linux, not "unknown linux" obviously.
And I don't know the meaning of `-gnu`.

On Windows, that it `x86-pc-mingw32`, which is quite meaningful to 
understand.


Thank you.

--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] What form should the official Rust binary installers for Unixes take?

[Brian Anderson]

On 02/11/2014 01:01 AM, Tom Lee wrote:

Hey Brian,

Not sure I understand the last paragraph of your email (do you or do 
you not want to encourage distro-specific installation? :))


I'm still not sure. I want people to be able to install Rust easily and 
I want those sources to be reliable.

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] What form should the official Rust binary installers for Unixes take?

[Brian Anderson]

Thanks for the replies, everyone. Here are my current takeaways:

* Don't create Linux distro-specific packages, let the various 
communities deal with it

* Don't create a networked installer

So here's what I'm thinking we do now. These are the install methods we 
would be promoting on the home page:


* Mac: .pkg file
* Linux: standalone, cross-distro installer
* Windows: use the installer we've already got

I'm worried that, if we keep out of the packaging business, but those 
packages end up being peoples' preferred way to get Rust, then the web 
page would be advocating the worst ways to get Rust. It seems like we'll 
need to put a link to 'alternate installation methods' on the homepage 
to link people to homebrew, macports, ubuntu, arch, etc. packages, 
emphasizing that they are unsupported.




On 02/06/2014 04:35 PM, Brian Anderson wrote:

Hey.

One of my goals for 0.10 is to make the Rust installation and upgrade 
experience better. My personal ambitions are to make Rust installable 
with a single shell command, distribute binaries, not source, and to 
have both nightlies and point releases.


Since we're already able to create highly-compatible snapshot 
compilers, it should be relatively easy to extend our snapshot 
procedure to produce complete binaries, installable via a 
cross-platform shell script. This would require the least amount of 
effort and maintenance because we don't need to use any specific 
package managers or add new bots, and a single installer can work on 
all Linuxes.


We can also attempt to package Rust with various of the most common 
package managers: homebrew, macports, dpkg, rpm. There 
community-maintained packages for some of these already, so we don't 
necessarily need to redevelop from scratch if we just want to adopt 
one or all of them as official packages. We could also create a GUI 
installer for OS X, but I'm not sure how important that is.


What shall we do?


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] What form should the official Rust binary installers for Unixes take?

[Brian Anderson]

Hey.

One of my goals for 0.10 is to make the Rust installation and upgrade 
experience better. My personal ambitions are to make Rust installable 
with a single shell command, distribute binaries, not source, and to 
have both nightlies and point releases.


Since we're already able to create highly-compatible snapshot compilers, 
it should be relatively easy to extend our snapshot procedure to produce 
complete binaries, installable via a cross-platform shell script. This 
would require the least amount of effort and maintenance because we 
don't need to use any specific package managers or add new bots, and a 
single installer can work on all Linuxes.


We can also attempt to package Rust with various of the most common 
package managers: homebrew, macports, dpkg, rpm. There 
community-maintained packages for some of these already, so we don't 
necessarily need to redevelop from scratch if we just want to adopt one 
or all of them as official packages. We could also create a GUI 
installer for OS X, but I'm not sure how important that is.


What shall we do?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Faster communication between tasks

[Brian Anderson]

Thanks for the update! Once it's pushed a writeup about the design and 
performance might be well-receieved on r/rust.


On 01/28/2014 06:05 PM, Simon Ruggier wrote:
A small update: I've gotten a resizable version of my disruptor 
implementation working, and the performance looks pretty good so far. 
I still have a few loose ends to tie up before I push out the changes. 
I should have the updated code on GitHub hopefully within a couple of 
weeks, depending on how much time I find to work on it.



On Sat, Nov 9, 2013 at 2:13 PM, Simon Ruggier <mailto:simo...@gmail.com>> wrote:


Hi all, I've tentatively come up with a design that would allow
the sender to reallocate the buffer as necessary, with very little
added performance cost. The sending side would bear the cost of
reallocation, and there would be an extra test that receivers
would have to make every time they process an item (no extra
atomic operations needed). However, it may be a few weeks or more
before I have a working implementation to demonstrate, so I
figured it might be worthwhile to mention now that I'll be working
on this.

Also, I think it would be interesting to investigate doing
something like the Linux kernel's deadlock detection[1], but
generalized to apply to bounded queues, and implemented as a
static check. I know little about this, but even so, I can see how
it would be an enormous amount of work. On the other hand, I would
have thought the same thing about the memory safety rules that
Rust enforces. I'm hopeful that this will eventually be possible
as well.

[1] https://www.kernel.org/doc/Documentation/lockdep-design.txt


On Wed, Oct 30, 2013 at 12:55 AM, Simon Ruggier mailto:simo...@gmail.com>> wrote:

    On Tue, Oct 29, 2013 at 3:30 PM, Brian Anderson
mailto:bander...@mozilla.com>> wrote:

On 10/28/2013 10:02 PM, Simon Ruggier wrote:

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 way to communicate
between tasks in Rust, following the same approach as the
LMAX Disruptor.[1] I'm hoping to eventually offer a
superset of the functionality in the pipes API, and
replace them as the default communication mechanism
between tasks. Just as with concurrency in general, my
main motivation in implementing this is to improve
performance. For more information about the disruptor
approach, there's a lot of information linked from their
home page, in a variety of formats.


This is really exciting work. Thanks for pursuing it. I've
been interested in exploring something like Disruptor in
Rust. The current channel types in Rust are indeed slow,
and fixing them is the topic of
https://github.com/mozilla/rust/issues/8568.

I'll start paying attention to that. The Morrison & Afek 2013
paper looks like something I should read.




This is my first major contribution of new functionality
to an open-source project, so I didn't want to discuss it
in advance until I had a working system to demonstrate. I
currently have a very basic proof of concept that
achieves almost two orders of magnitude better
performance than the pipes API. On my hardware[2], I
currently see throughput of about 27 million items per
second when synchronizing with a double-checked wait
condition protocol between sender and receivers, 80+
million items with no blocking (i.e. busy waiting), and
anywhere from 240,000 to 600,000 when using pipes. The
LMAX Disruptor library gets up to 110 million items per
second on the same hardware (using busy waiting and
yielding), so there's definitely still room for
significant improvement.


Those are awesome results!


Thanks! When I first brought it up, it was getting about 14
million with the busy waiting. Minimizing the number of atomic
operations (even with relaxed memory ordering) makes a big
difference in performance. The 2/3 drop in performance with
the blocking wait strategy comes from merely doing a
read-modify-write operation on every send (it currently uses
atomic swap, I haven't experimented with others yet). To be
fair, the only result I can take credit for is t

[rust-dev] Nick Cameron joins the Rust team at Mozilla

[Brian Anderson]

Hi Rusties,

I'm just thrilled to announce today that Nick Cameron (nrc) has joined 
Mozilla's Rust team full-time. Nick has a PhD in programming language 
theory from Imperial College London and has been hacking on Gecko's 
graphics and layout for two years, but now that he's all ours you'll be 
seeing him eradicate critical Rust bugs by the dozens. Good luck, Nick, 
and welcome to the party.


Regards,
Brian
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

[Brian Anderson]

On 02/01/2014 02:59 PM, Benjamin Striegel wrote:

> Yes, and I don't have a solution for that.

Well, it's not like we don't already stumble here a bit, what with 
requiring ::<> instead of just <>. Not sure how much other people 
value the consistency here.


Yeah, the existing solution is bad, and also rare. If changing the 
declaration might happen then you might as well make another minor 
change for consistency, possibly for the better.





On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson > wrote:


On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
mailto:ben.strie...@gmail.com>> wrote:
> First of all, why a new keyword? Reusing `for` here would be totally
> unambiguous. :P And also save us from creating the precedent of
multi-word
> keywords.
>

I'd be equally happy with for instead of forall.

> Secondly, currently Rust has a philosophy of
use-follows-declaration (i.e.
> the syntax for using something mirrors the syntax for declaring
it). This
> would eliminate that.
>

Yes, and I don't have a solution for that.




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "let mut" <-> "var"

[Brian Anderson]

I'm convinced by this thread that this issue should be put to bed 
forever. I added a note to the design faq issue: 
https://github.com/mozilla/rust/issues/4047#issuecomment-33751021


On 01/30/2014 03:20 PM, Benjamin Striegel wrote:

> https://github.com/mozilla/rust/issues/2643

I came here to post that link, you beat me to it. :)

Highly, vehemently, frothing-at-the-mouthly against adding `var` as 
sugar for `let mut`. You can see from reading that issue that I too 
was once a fan of getting rid of `let mut`, but after using Rust in 
the years since I can see how lovely the current setup is. I was the 
one who initiated the widespread grepping recently that found that 
`let` was three times more common than `let mut`, and I admit I was 
surprised to find that immutability was so completely dominant. 
Immutability is crucial to Rust. Mutability *must* be explicit. Not 
having to ever worry about const-correctness is icing on the cake. 
Adding an alternative form for `let mut` would go completely against 
the spirit of the language.



On Thu, Jan 30, 2014 at 12:18 PM, Tim Chevalier 
mailto:catamorph...@gmail.com>> wrote:


I'm surprised that no one has mentioned so far that there was a
previous, exhaustive, discussion of this question on github:

https://github.com/mozilla/rust/issues/2643

As far as I can tell, this thread adds nothing new that wasn't already
discussed in the comments on #2643. So that strongly suggests to me
that nothing needs to be changed.

Cheers,
Tim


On Thu, Jan 30, 2014 at 8:49 AM, Steven Fackler
mailto:sfack...@gmail.com>> wrote:
> The Zen of Python also says "There should be one-- and
preferably only one
> --obvious way to do it."
>
> Steven Fackler
>
>
> On Thu, Jan 30, 2014 at 11:35 AM, Donaldo Fastoso
> mailto:donquest...@rocketmail.com>>
wrote:
>>
>> I like python's rational of "consenting adults": Give people
the tools
>> to do the right thing, if they still want to hurt themselves,
they may
>> have a good reason, or they are better of dead! ;-)
>>
>> I would argue, that people choosing Rust over C/C++ are choosing it
>> BECAUSE of safety measures like immutability and wouldn't need
>> overbearing lectures.
>>
>> In all honesty it's not the TYPING of three additional chars
"let mut",
>> but the READING. It interrupts the flow of reading, or better: it's
>> a bump in the flow of scanning. Source-Code is not prosa, you
have to
>> actively follow the train of thought and guess the intentions
of the
>> author. So improving READABILITY would really be nice, especially
>> for people coming from other languages. They would probably try to
>> learn by reading the source from experienced programmers.
>>
>> In this case i would also advice against the use of "var", instead
>> of "let mut", but omitting "let" and leave it to "mut" would be
much
>> easier to read and understand.
>>
>> so
>> "let mut x, y;"
>>
>> would become:
>>
>> "mut x;"
>> "let y;"
>>
>> which would take a possible interpretation-ambiguity away from the
>> single "let mut x, y", which can be read either as "let mut" for x
>> and y, or "let mut x" and "let y"!
>>
>> So imho "let mut" has at least two pitfalls:
>> 1) read-bump
>> 2) ambiguity.
>>
>> AFAIK you did a remarkable good job so far, and i have all the
faith
>> you are considering all arguments before coming to a decision.
>>
>> Even if some thoughts of the thoughts come form the bad smelling
>> "lurker"-fraction, which do nothing but making comments about
things they
>> possible can't understand! ;-)
>>
>> Regards,
>> Don
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org 
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org 
> https://mail.mozilla.org/listinfo/rust-dev
>



--
Tim Chevalier * http://catamorphism.org/ * Often in error, never
in doubt
"If you are silent about your pain, they'll kill you and say you
enjoyed it."
-- Zora Neale Hurston
___
Rust-dev mailing list
Rust-dev@mozilla.org 
https://mail.mozilla.org/listinfo/rust-dev




___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev