From ncm at cantrip.org Wed Jan 1 01:51:04 2014 From: ncm at cantrip.org (Nathan Myers) Date: Wed, 01 Jan 2014 01:51:04 -0800 Subject: [rust-dev] Unbounded channels: Good idea/bad idea? In-Reply-To: <52C33A07.3040002@mozilla.com> References: <52BCD80F.2000806@cantrip.org> <52BDF2AD.9070605@mozilla.com> <52BE411B.3040100@cantrip.org> <52BE5D16.40100@mozilla.com> <52BE7AF7.3050306@cantrip.org> <52C24EEF.2010104@mozilla.com> <52C33833.90203@cantrip.org> <52C33A07.3040002@mozilla.com> Message-ID: <52C3E508.7000303@cantrip.org> On 12/31/2013 01:41 PM, Patrick Walton wrote: > Bounded channels can be constructed from unbounded channels as well, > so I don't see how this is an argument for making bounded channels > the primitive. Sometimes we need an indefinite-precision integer, other times a fixed-size integer. Sometimes we need a variable-sized array, others a compile-time fixed-size array. A range-limited integer or array can be constructed using the unrestricted type, but would lack exactly those properties it needs in order to usable where you need one. It should be clear that in each case one type is more fundamental, implementation-wise, than the other, and can be used in circumstances where the other is entirely unaffordable. One is necessarily primitive, while the other can be constructed from primitives with no performance penalty or restrictions. There are many languages that offer indefinite-precision integers and variable-sized arrays as primitives. No one uses them for system coding. Nathan Myers From ncm at cantrip.org Wed Jan 1 02:06:42 2014 From: ncm at cantrip.org (Nathan Myers) Date: Wed, 01 Jan 2014 02:06:42 -0800 Subject: [rust-dev] Defined, precisely defined, and undefined In-Reply-To: <52C33A07.3040002@mozilla.com> References: <52BCD80F.2000806@cantrip.org> <52BDF2AD.9070605@mozilla.com> <52BE411B.3040100@cantrip.org> <52BE5D16.40100@mozilla.com> <52BE7AF7.3050306@cantrip.org> <52C24EEF.2010104@mozilla.com> <52C33833.90203@cantrip.org> <52C33A07.3040002@mozilla.com> Message-ID: <52C3E8B2.2030503@cantrip.org> On 12/31/2013 01:41 PM, Patrick Walton wrote: > On 12/31/13 1:33 PM, Nathan Myers wrote: >> >> The possibility of precisely defining the behavior of a bounded >> channel in all circumstances is what makes it suitable as a >> first-class primitive. > > Unbounded channels have defined behavior as well. Undefined behavior > has a precise definition and OOM is not undefined behavior. Undefined is not the opposite of precisely defined. OOM can not be part of precisely defined behavior, because it isn't. Nathan Myers From kevin at sb.org Wed Jan 1 09:46:10 2014 From: kevin at sb.org (Kevin Ballard) Date: Wed, 1 Jan 2014 12:46:10 -0500 Subject: [rust-dev] Unbounded channels: Good idea/bad idea? In-Reply-To: References: <52BCD80F.2000806@cantrip.org> <52BDF2AD.9070605@mozilla.com> <52BE411B.3040100@cantrip.org> <52BE5D16.40100@mozilla.com> <52BE7AF7.3050306@cantrip.org> <52C24EEF.2010104@mozilla.com> <52C33833.90203@cantrip.org> <52C33A07.3040002@mozilla.com> <52C3502B.9000207@gmail.com> <52C35097.5030105@mozilla.com> Message-ID: On Dec 31, 2013, at 7:40 PM, Jason Fager wrote: > If you're pushing to an unbounded vec in a tight loop you've got fundamental design issues. Or you?re processing user input. A rather trivial example here is parsing a file into lines. If I have 2GB of RAM and I throw a 4GB file at that parser, I?m going to have issues. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at minimum.se Wed Jan 1 15:49:29 2014 From: martin at minimum.se (Martin Olsson) Date: Thu, 02 Jan 2014 00:49:29 +0100 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? Message-ID: <52C4A989.5010201@minimum.se> Short version of my question: Why doesn't rust require "mut" param prefix at call sites? i.e. to avoid "non-const ref badness" that C++ has? Longer version of my question: Since this question was asked recently by vadim and not really answered clearly (imo), I'm also including this longer verbose version of my question. For example in C the call "f(a,&b);" might modify "b" but not "a" so the "&" token acts as a "call site heads-up flag" when reading the code. In C# the "out/ref" keywords are mandatory at the call site if the callee uses them in its param declaration so there you also get a little in hint when reading the code near the call site. C++ of course has non-const references so "f(a,&b);" might modify both "a" and "b" so the hint is missing and I really have to look up the code for "f()" to be sure. If some function foo() passes "a" to a bunch of functions then I have to find each such function and check if "a" can be modified or not, so potentially I have to open a bunch of files and read code there before I can fully understand the code near the call sites. Because of this many large C++ projects have coding styles that disallow non-const refs. See for example the google C++ coding style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Reference_Arguments#Reference_Arguments Right now, it seems that rust works similar to C++ in this regard, meaning that there is no hint at the call site that a parameter may or may not be modified by the function. In the snippet below, if I'm reading foo() in main.rs and I wonder which lines in foo() could possibly change the value of "i", then I have to open up 4 additional files and find the relevant source locations to double check which functions might mutate their arguments. Why isn't it a good idea to require some parameter prefix like "mut" at the call site so that when I read main.rs I immediately will know which lines among the calls to funcA()..funcD() that might change the value of "i" ? // ---[ funcA.rs ]----------------------- fn funcA(i: &int) -> int{ return 2**i; } // ---[ funcB.rs ]----------------------- fn funcB(i: &mut int) -> int { *i += 1; return 0; } // ---[ funcC.rs ]----------------------- fn funcC(i: &int) -> int { return 3**i; } // ---[ funcD.rs ]----------------------- fn funcD(i: &int) -> int{ return 2**i; } // ---[ main.rs ]----------------------- fn foo(i: &mut int) { *i += 1; funcA(i); funcB(i); // no mut! funcC(i); funcD(i); } fn main() { let mut i: int = 0; foo(&mut i); println!("{}", i); } Martin From pcwalton at mozilla.com Wed Jan 1 15:55:10 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 15:55:10 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C4A989.5010201@minimum.se> References: <52C4A989.5010201@minimum.se> Message-ID: <52C4AADE.3000602@mozilla.com> On 1/1/14 3:49 PM, Martin Olsson wrote: > For example in C the call "f(a,&b);" might modify "b" but not "a" so the > "&" token acts as a "call site heads-up flag" when reading the code. Same in Rust. > In > C# the "out/ref" keywords are mandatory at the call site if the callee > uses them in its param declaration so there you also get a little in > hint when reading the code near the call site. C# has neither first-class pointers nor first-class references, so it isn't really a comparison. > C++ of course has > non-const references so "f(a,&b);" might modify both "a" and "b" so the > hint is missing and I really have to look up the code for "f()" to be > sure. If some function foo() passes "a" to a bunch of functions then I > have to find each such function and check if "a" can be modified or not, > so potentially I have to open a bunch of files and read code there > before I can fully understand the code near the call sites. That's right, and that's why Rust doesn't do this. > Because of this many large C++ projects have coding styles that disallow > non-const refs. See for example the google C++ coding style guide: > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Reference_Arguments#Reference_Arguments Google's style guide allows mutable pointers, which are more like Rust references in this regard (except that pointers can be null in C++ and can't in Rust). > > Right now, it seems that rust works similar to C++ in this regard, > meaning that there is no hint at the call site that a parameter may or > may not be modified by the function. No, Rust works like *C*, where if you pass a mutable *pointer* that was already mutable down a call chain then the callee can mutate it. What C++ allows you to do that these style guides are trying to forbid is to pass an *lvalue* to a function and to have that function able to mutate that lvalue. That is not allowed in Rust. > In the snippet below, if I'm reading foo() in main.rs and I wonder which > lines in foo() could possibly change the value of "i", then I have to > open up 4 additional files and find the relevant source locations to > double check which functions might mutate their arguments. You already had a mutable pointer; you can pass that mutable pointer down the call chain. > Why isn't it a good idea to require some parameter prefix like "mut" at > the call site so that when I read main.rs I immediately will know which > lines among the calls to funcA()..funcD() that might change the value of > "i" ? Because that would work completely like any other language with pointers that I know of. Patrick From pcwalton at mozilla.com Wed Jan 1 15:55:50 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 15:55:50 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C4AADE.3000602@mozilla.com> References: <52C4A989.5010201@minimum.se> <52C4AADE.3000602@mozilla.com> Message-ID: <52C4AB06.9010106@mozilla.com> On 1/1/14 3:55 PM, Patrick Walton wrote: > Because that would work completely like any other language with pointers > that I know of. Err, I mean "unlike". Patrick From comexk at gmail.com Wed Jan 1 17:07:53 2014 From: comexk at gmail.com (comex) Date: Wed, 1 Jan 2014 20:07:53 -0500 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C4A989.5010201@minimum.se> References: <52C4A989.5010201@minimum.se> Message-ID: On Wed, Jan 1, 2014 at 6:49 PM, Martin Olsson wrote: > Short version of my question: > > Why doesn't rust require "mut" param prefix at call sites? i.e. to avoid > "non-const ref badness" that C++ has? Well, to be somewhat extreme, in a function like struct S { a: &mut int, b: &mut int } fn f(s: &mut &mut S) ... fn g(s: &mut &mut S) { f(s) } what sort of "mut"s does g need? From slabode at aim.com Wed Jan 1 20:26:42 2014 From: slabode at aim.com (SiegeLord) Date: Wed, 01 Jan 2014 23:26:42 -0500 Subject: [rust-dev] Using CMake with Rust Message-ID: <52C4EA82.1050706@aim.com> (Posting this here as I think it might be useful for some but I don't feel like getting a Reddit account and there's no rust-announce). I've been experimenting with building Rust crates using some established build systems, focusing on SCons and CMake due to their popularity. Neither turned out to be a perfect fit for Rust, but CMake was marginally less bad so I chose it in the end. To that end I created some CMake modules that make that integration be as painless as possible. Here's what a minimal CMakeLists.txt would look like for a single library crate project: ~~~ cmake_minimum_required(VERSION 2.8) project(testlib NONE) list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake") find_package(rustc) find_package(rustdoc) include(Rust) set(RUSTC_FLAGS "-L${CMAKE_BINARY_DIR}/lib") rust_crate_auto(src/lib.rs TARGET_NAME TESTLIB) add_custom_target(library_target ALL DEPENDS ${TESTLIB_FULL_TARGET}) install(FILES ${TESTLIB_ARTIFACTS} DESTINATION lib) ~~~ And then you'd do the usual out-of-source build. It will reconfigure the build system if any of the files referenced by src/lib.rs (as reported by rustc --dep-info) get changed. A more complete example that shows building several inter-dependent crates, documentation and tests can be seen here: https://github.com/SiegeLord/RustCMake . The modules for this to work are also found there. Caveats: CMake doesn't know what Rust is, so it has to reconfigure the entire build system whenever you change any of the source files needed for *ANY* crate in your project (it doesn't need to do that with C/C++ because it has an internal dependency scanner). This won't be a big deal in small projects, and I find the convenience of using CMake to be worth it, but it does suggest that CMake is not the ultimate solution to building Rust projects. -SL From pcwalton at mozilla.com Wed Jan 1 20:31:30 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 20:31:30 -0800 Subject: [rust-dev] Using CMake with Rust In-Reply-To: <52C4EA82.1050706@aim.com> References: <52C4EA82.1050706@aim.com> Message-ID: <52C4EBA2.6070506@mozilla.com> On 1/1/14 8:26 PM, SiegeLord wrote: > (Posting this here as I think it might be useful for some but I don't > feel like getting a Reddit account and there's no rust-announce). > > I've been experimenting with building Rust crates using some established > build systems, focusing on SCons and CMake due to their popularity. > Neither turned out to be a perfect fit for Rust, but CMake was > marginally less bad so I chose it in the end. To that end I created some > CMake modules that make that integration be as painless as possible. > Here's what a minimal CMakeLists.txt would look like for a single > library crate project: Cool! Experimentation with build systems for Rust is awesome. (To be honest?and these are just my own personal thoughts, and I do not speak for the entire team here?I'm beginning to wonder if we should just find which third-party build system works best, bless it, and build high-quality tooling around it rather than create another build system of our own.) Patrick From vadimcn at gmail.com Wed Jan 1 20:41:34 2014 From: vadimcn at gmail.com (Vadim) Date: Wed, 1 Jan 2014 20:41:34 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C4A989.5010201@minimum.se> References: <52C4A989.5010201@minimum.se> Message-ID: I think the real answer is "at this point nobody wants to tweak basic Rust syntax yet again". See the other thread about Rust roadmap, etc. Oh well... On Wed, Jan 1, 2014 at 3:49 PM, Martin Olsson wrote: > Short version of my question: > > Why doesn't rust require "mut" param prefix at call sites? i.e. to avoid > "non-const ref badness" that C++ has? > > > > Longer version of my question: > > Since this question was asked recently by vadim and not really answered > clearly (imo), I'm also including this longer verbose version of my > question. > > For example in C the call "f(a,&b);" might modify "b" but not "a" so the > "&" token acts as a "call site heads-up flag" when reading the code. In C# > the "out/ref" keywords are mandatory at the call site if the callee uses > them in its param declaration so there you also get a little in hint when > reading the code near the call site. C++ of course has non-const references > so "f(a,&b);" might modify both "a" and "b" so the hint is missing and I > really have to look up the code for "f()" to be sure. If some function > foo() passes "a" to a bunch of functions then I have to find each such > function and check if "a" can be modified or not, so potentially I have to > open a bunch of files and read code there before I can fully understand the > code near the call sites. > > Because of this many large C++ projects have coding styles that disallow > non-const refs. See for example the google C++ coding style guide: > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone= > Reference_Arguments#Reference_Arguments > > Right now, it seems that rust works similar to C++ in this regard, meaning > that there is no hint at the call site that a parameter may or may not be > modified by the function. > > In the snippet below, if I'm reading foo() in main.rs and I wonder which > lines in foo() could possibly change the value of "i", then I have to open > up 4 additional files and find the relevant source locations to double > check which functions might mutate their arguments. > > Why isn't it a good idea to require some parameter prefix like "mut" at > the call site so that when I read main.rs I immediately will know which > lines among the calls to funcA()..funcD() that might change the value of > "i" ? > > > // ---[ funcA.rs ]----------------------- > fn funcA(i: &int) -> int{ > return 2**i; > } > // ---[ funcB.rs ]----------------------- > fn funcB(i: &mut int) -> int { > *i += 1; > return 0; > } > // ---[ funcC.rs ]----------------------- > fn funcC(i: &int) -> int { > return 3**i; > } > // ---[ funcD.rs ]----------------------- > fn funcD(i: &int) -> int{ > return 2**i; > } > // ---[ main.rs ]----------------------- > fn foo(i: &mut int) { > *i += 1; > funcA(i); > funcB(i); // no mut! > funcC(i); > funcD(i); > } > fn main() { > let mut i: int = 0; > foo(&mut i); > println!("{}", i); > } > > > > Martin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jurily at gmail.com Wed Jan 1 21:05:27 2014 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Thu, 02 Jan 2014 06:05:27 +0100 Subject: [rust-dev] Using CMake with Rust In-Reply-To: <52C4EA82.1050706@aim.com> References: <52C4EA82.1050706@aim.com> Message-ID: <52C4F397.3070104@gmail.com> The proper way to support a language in CMake is outlined in `Modules/CMakeAddNewLanguage.txt`: > This file provides a few notes to CMake developers about how to add > support for a new language to CMake. It is also possible to place > these files in CMAKE_MODULE_PATH within an outside project to add > languages not supported by upstream CMake. However, this is not > a fully supported use case. > > The implementation behind the scenes of project/enable_language, > including the compiler/platform modules, is an *internal* API that > does not make any compatibility guarantees. It is not covered in the > official reference documentation that is versioned with the source code. > Maintainers of external language support are responsible for porting > it to each version of CMake as upstream changes are made. Since > the API is internal we will not necessarily include notice of any > changes in release notes. > > > CMakeDetermine(LANG)Compiler.cmake -> this should find the compiler for LANG and configure CMake(LANG)Compiler.cmake.in > > CMake(LANG)Compiler.cmake.in -> used by CMakeDetermine(LANG)Compiler.cmake > This file is used to store compiler information and is copied down into try > compile directories so that try compiles do not need to re-determine and test the LANG > > CMakeTest(LANG)Compiler.cmake -> test the compiler and set: > SET(CMAKE_(LANG)_COMPILER_WORKS 1 CACHE INTERNAL "") > > CMake(LANG)Information.cmake -> set up rule variables for LANG : > CMAKE_(LANG)_CREATE_SHARED_LIBRARY > CMAKE_(LANG)_CREATE_SHARED_MODULE > CMAKE_(LANG)_CREATE_STATIC_LIBRARY > CMAKE_(LANG)_COMPILE_OBJECT > CMAKE_(LANG)_LINK_EXECUTABLE I've been playing around with it, but so far I haven't been able to get a test case off the ground. I have no idea how to actually make this format string expand for example, or where to find documentation. > set(CMAKE_Java_COMPILE_OBJECT > " -d ") From pwalton at mozilla.com Wed Jan 1 21:12:30 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 21:12:30 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> Message-ID: <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> There is no "real answer" beyond the one I already gave: that we are already precisely as explicit as C, that Rust references do not actually have the hidden mutation hazard of C++ references, and that changing would place the language in a different space entirely. Please don't suggest that I am (or that anyone else on the list is) being dishonest. Patrick Vadim wrote: >I think the real answer is "at this point nobody wants to tweak basic >Rust >syntax yet again". See the other thread about Rust roadmap, etc. Oh >well... > > >On Wed, Jan 1, 2014 at 3:49 PM, Martin Olsson >wrote: > >> Short version of my question: >> >> Why doesn't rust require "mut" param prefix at call sites? i.e. to >avoid >> "non-const ref badness" that C++ has? >> >> >> >> Longer version of my question: >> >> Since this question was asked recently by vadim and not really >answered >> clearly (imo), I'm also including this longer verbose version of my >> question. >> >> For example in C the call "f(a,&b);" might modify "b" but not "a" so >the >> "&" token acts as a "call site heads-up flag" when reading the code. >In C# >> the "out/ref" keywords are mandatory at the call site if the callee >uses >> them in its param declaration so there you also get a little in hint >when >> reading the code near the call site. C++ of course has non-const >references >> so "f(a,&b);" might modify both "a" and "b" so the hint is missing >and I >> really have to look up the code for "f()" to be sure. If some >function >> foo() passes "a" to a bunch of functions then I have to find each >such >> function and check if "a" can be modified or not, so potentially I >have to >> open a bunch of files and read code there before I can fully >understand the >> code near the call sites. >> >> Because of this many large C++ projects have coding styles that >disallow >> non-const refs. See for example the google C++ coding style guide: >> >http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone= >> Reference_Arguments#Reference_Arguments >> >> Right now, it seems that rust works similar to C++ in this regard, >meaning >> that there is no hint at the call site that a parameter may or may >not be >> modified by the function. >> >> In the snippet below, if I'm reading foo() in main.rs and I wonder >which >> lines in foo() could possibly change the value of "i", then I have to >open >> up 4 additional files and find the relevant source locations to >double >> check which functions might mutate their arguments. >> >> Why isn't it a good idea to require some parameter prefix like "mut" >at >> the call site so that when I read main.rs I immediately will know >which >> lines among the calls to funcA()..funcD() that might change the value >of >> "i" ? >> >> >> // ---[ funcA.rs ]----------------------- >> fn funcA(i: &int) -> int{ >> return 2**i; >> } >> // ---[ funcB.rs ]----------------------- >> fn funcB(i: &mut int) -> int { >> *i += 1; >> return 0; >> } >> // ---[ funcC.rs ]----------------------- >> fn funcC(i: &int) -> int { >> return 3**i; >> } >> // ---[ funcD.rs ]----------------------- >> fn funcD(i: &int) -> int{ >> return 2**i; >> } >> // ---[ main.rs ]----------------------- >> fn foo(i: &mut int) { >> *i += 1; >> funcA(i); >> funcB(i); // no mut! >> funcC(i); >> funcD(i); >> } >> fn main() { >> let mut i: int = 0; >> foo(&mut i); >> println!("{}", i); >> } >> >> >> >> Martin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From palmercox at gmail.com Wed Jan 1 21:13:55 2014 From: palmercox at gmail.com (Palmer Cox) Date: Thu, 2 Jan 2014 00:13:55 -0500 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> Message-ID: I could be pretty wrong, so if I am, I apologize and please ignore. Anyway, I thought I once read somewhere that when you call a function defined like: fn foo(a: &mut int) { ... } with code that looks like fn bar(b: &mut int) { foo(b); } that despite what it looks like, you aren't really passing the value b into the function foo(). My understanding, is that when you pass a reference to foo(), that it takes ownership of that reference making it inaccessible to any following code. Since this is generally not what anyone wants, Rust silently re-borrows b and passes that re-borrowed version of the reference to foo() which takes ownership of it. Since b wasn't actually passed to foo(), code after the call to foo() can continue to use b since bar() still owns b. Anyway, if that is all correct, and I'm not sure how likely that is all to be correct, it feels like what this email thread really boils down to is a proposal to eliminate automatic re-borrowing of a &mut to &mut when invoking a function. I'm may be wrong, but, I'm also under the impression that manually re-borrowing would look something like: foo(&mut (*b)) which is extremely unpleasant, so, I'd imagine that the 2nd part of the proposal is to make some sort of nicer syntax for that. To me, this doesn't sound as much like a proposal for a change in syntax as a proposal to remove a bit of magic that Rust is currently doing. I don't know that I'm necessarily in favor or that though, since it would certainly make code more wordy. That wordiness might be nice, however, if it makes it clearer where variables might be mutated (eg: imagine that foo() is originally defined to take a & ,so bar() assumed that the variable won't be mutated. However foo() is later redefined to take a &mut which silently breaks bar()'s assumption about foo()). -Palmer Cox On Wed, Jan 1, 2014 at 11:41 PM, Vadim wrote: > I think the real answer is "at this point nobody wants to tweak basic Rust > syntax yet again". See the other thread about Rust roadmap, etc. Oh > well... > > > On Wed, Jan 1, 2014 at 3:49 PM, Martin Olsson wrote: > >> Short version of my question: >> >> Why doesn't rust require "mut" param prefix at call sites? i.e. to avoid >> "non-const ref badness" that C++ has? >> >> >> >> Longer version of my question: >> >> Since this question was asked recently by vadim and not really answered >> clearly (imo), I'm also including this longer verbose version of my >> question. >> >> For example in C the call "f(a,&b);" might modify "b" but not "a" so the >> "&" token acts as a "call site heads-up flag" when reading the code. In C# >> the "out/ref" keywords are mandatory at the call site if the callee uses >> them in its param declaration so there you also get a little in hint when >> reading the code near the call site. C++ of course has non-const references >> so "f(a,&b);" might modify both "a" and "b" so the hint is missing and I >> really have to look up the code for "f()" to be sure. If some function >> foo() passes "a" to a bunch of functions then I have to find each such >> function and check if "a" can be modified or not, so potentially I have to >> open a bunch of files and read code there before I can fully understand the >> code near the call sites. >> >> Because of this many large C++ projects have coding styles that disallow >> non-const refs. See for example the google C++ coding style guide: >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone= >> Reference_Arguments#Reference_Arguments >> >> Right now, it seems that rust works similar to C++ in this regard, >> meaning that there is no hint at the call site that a parameter may or may >> not be modified by the function. >> >> In the snippet below, if I'm reading foo() in main.rs and I wonder which >> lines in foo() could possibly change the value of "i", then I have to open >> up 4 additional files and find the relevant source locations to double >> check which functions might mutate their arguments. >> >> Why isn't it a good idea to require some parameter prefix like "mut" at >> the call site so that when I read main.rs I immediately will know which >> lines among the calls to funcA()..funcD() that might change the value of >> "i" ? >> >> >> // ---[ funcA.rs ]----------------------- >> fn funcA(i: &int) -> int{ >> return 2**i; >> } >> // ---[ funcB.rs ]----------------------- >> fn funcB(i: &mut int) -> int { >> *i += 1; >> return 0; >> } >> // ---[ funcC.rs ]----------------------- >> fn funcC(i: &int) -> int { >> return 3**i; >> } >> // ---[ funcD.rs ]----------------------- >> fn funcD(i: &int) -> int{ >> return 2**i; >> } >> // ---[ main.rs ]----------------------- >> fn foo(i: &mut int) { >> *i += 1; >> funcA(i); >> funcB(i); // no mut! >> funcC(i); >> funcD(i); >> } >> fn main() { >> let mut i: int = 0; >> foo(&mut i); >> println!("{}", i); >> } >> >> >> >> Martin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Jan 1 21:25:58 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 21:25:58 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> Message-ID: <52C4F866.1010007@mozilla.com> On 1/1/14 9:13 PM, Palmer Cox wrote: > To me, this doesn't sound as much like a proposal for a change in syntax > as a proposal to remove a bit of magic that Rust is currently doing. I > don't know that I'm necessarily in favor or that though, since it would > certainly make code more wordy. That wordiness might be nice, however, > if it makes it clearer where variables might be mutated (eg: imagine > that foo() is originally defined to take a & ,so bar() assumed that the > variable won't be mutated. However foo() is later redefined to take a > &mut which silently breaks bar()'s assumption about foo()). That's a much more interesting question. I do worry about the verbosity though, as you said. In general I feel like we should either have autoborrowing in as many places as reasonably possible or autoborrowing nowhere. Patrick From slabode at aim.com Wed Jan 1 21:32:18 2014 From: slabode at aim.com (SiegeLord) Date: Thu, 02 Jan 2014 00:32:18 -0500 Subject: [rust-dev] Using CMake with Rust In-Reply-To: <52C4F397.3070104@gmail.com> References: <52C4EA82.1050706@aim.com> <52C4F397.3070104@gmail.com> Message-ID: <52C4F9E2.1070702@aim.com> On 01/02/2014 12:05 AM, Gy?rgy Andrasek wrote: > The proper way to support a language in CMake is outlined in > `Modules/CMakeAddNewLanguage.txt`: I was guided away from that method by this email: http://www.cmake.org/pipermail/cmake/2011-March/043444.html . My approach is amenable to generating files for alternative build systems, like ninja. If you are aware that that email is incorrect, I'm glad to be corrected. Independently of that email, I have looked into doing it that way, but I found that it just did not mesh with the Rust compilation model, and I saw no clear way to using the information given by 'rustc --dep-info' to inform the build system. Additionally, my macros allow an easy way of doing documentation generation, which that method doesn't clearly allow. I'll be glad to be corrected on all those points though. -SL From sh4.seo at samsung.com Wed Jan 1 21:57:46 2014 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Thu, 02 Jan 2014 05:57:46 +0000 (GMT) Subject: [rust-dev] on quality & success Message-ID: <14244309.214971388642265762.JavaMail.weblogic@epml24> > Deciding to reuse wrong, but mainstream, design decisions in one's own language > is deciding to intentionally make it of lower quality. !!! Funny (read: mad), > isn't it? It is thus also intentionally deciding to make it not worth success. > This, apparently, to make its actual chances of success higher. (Isn't our > culture funny?) First, thank you for bringing up the important point. While I agree that many language designers do decide to intentionally make it of lower quality according to their subjective measure of quality, this is in no way new, mad, or funny. Your error seems to be thinking that such decisions make the language not worth success -- but in actuality such decisions make the language *less* worth success, and worth rarely reaches zero. Abstractly, if such decisions raise the chance of success higher, it can increases the expected worth of success. I consider creating a new programming language analogous to forming a new political party. (I pity you if you live in a two-party system.) For any given party, its platform is distinctly inferior to any of its supporter's ideal platform. In other words, party supporters are compromising in order to cooperate. People compromise in order to cooperate, because, even if compromising on your ideal is painful, cooperation is often much better way to change the world. Of course, one is free to conduct political activism alone, but such people usually do not consider political parties mad or funny. Thanks. From vadimcn at gmail.com Wed Jan 1 22:06:14 2014 From: vadimcn at gmail.com (Vadim) Date: Wed, 1 Jan 2014 22:06:14 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> Message-ID: On Wed, Jan 1, 2014 at 9:12 PM, Patrick Walton wrote: > There is no "real answer" beyond the one I already gave: that we are > already precisely as explicit as C, that Rust references do not actually > have the hidden mutation hazard of C++ references, and that changing would > place the language in a different space entirely. > Patrick, I disagree with this point. Rust references *do* have hidden mutation hazard, as do C's and C++'s pointers. In all three, mutation hazard is only obvious when you take an address of a stack variable. After that, when you already have a pointer, you pass it around, and never know who might mutate the underlying object. And let's not forget about the heap-allocated objects, which start out as pointers in the first place. Well, since requiring '&' at the original borrow site doesn't really prevent the "unexpected mutability" problem, why not drop it and eliminate a bunch of noise from Rust sources? And, again, if "unexpected mutability" is what concerns people, "mut" annotation is the better way to fix that, IMHO. > Please don't suggest that I am (or that anyone else on the list is) being > dishonest. > My apologies, I didn't mean to imply that. Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: From palmercox at gmail.com Wed Jan 1 22:13:58 2014 From: palmercox at gmail.com (Palmer Cox) Date: Thu, 2 Jan 2014 01:13:58 -0500 Subject: [rust-dev] on quality & success In-Reply-To: <52C2B0F7.2000103@gmail.com> References: <52C2B0F7.2000103@gmail.com> Message-ID: Everyone is entitled to their own opinions. However, those opinions should be expressed in a polite manner. Phrases such as "Choice he (since its mostly men)" and "mentally masturbate" do not seem to foster a welcoming, inclusive environment. Quoting from https://github.com/mozilla/rust/wiki/Note-development-policy#conduct: * We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, disability, ethnicity, religion, or similar personal characteristic Thanks, -Palmer Cox On Tue, Dec 31, 2013 at 6:56 AM, spir wrote: > Hol?! > > [This is a rather personal and involved post. Press del if you feel like > it...] > [also, it is long] > [copy to rust-dev mailing list: actually the post is inspired by a thread > there "Thoughts on the Rust Roadmap"] > > There is a point obvious to me; apparently most people including many > language designers don't share it, or act as if they did not: > > a language should be successful iff it is of high quality > > A kind of symmetric statement also holds; > > let us hope low quality languages have no success! > > There are various reasons to hope this, the most stupid beeing that > successful languages influence others, present & future. This is in my view > a symptom of our civilisation's funny spirit (read: madness), and related > to the actual points I intend to state (if, for once, I manage to express > my thought). > > Apparently, many language designers proceed more or less the following > way: there are a few key points (for them) they consider mis-designed or > missing or wrong in some way in existing languages (not all the same for > every language). Thus, they want to make a language that repairs these > points, all together. Then, certainly in fear that too many changes may > repel potential adopters of their language, in hope to maximise its chances > of success *despite* it breaking habits on the key points more important to > them, they won't change anything else, or only the bare minimum they can. > They want instead to remain as mainstream as possible on everything else. > [4] > > I consider this spirit bad; I mean, very bad. This is the way basic design > errors propagate from successful languages to others, for instance. [1] > Apparently, it takes a great dose of courage to break any existing practice > in a _new_ language: tell me why, I do not understand. > > Note that I am here talking of wrong design points in the opinion of a > given language designer. Choices he (since it's mostly men) would not do if > programming were a new field, open to all explorations. (There are indeed > loads of subjective or ideological design points; see also [1] & [3]) > However, while programming is not a new field anymore, it is indeed open to > all explorations, for you, for me, if you or me wants it. Nothing blocks us > but our own bloackages, our own fears, and, probably, wrong rationales, > perhaps non-fully-conscious ones. > > Deciding to reuse wrong, but mainstream, design decisions in one's own > language is deciding to intentionally make it of lower quality. !!! Funny > (read: mad), isn't it? It is thus also intentionally deciding to make it > not worth success. This, apparently, to make its actual chances of success > higher. (Isn't our culture funny?) > Then, why does one _actually_ make a new language? For the joy of making > something good? To contribute to a better world, since languages and > programming are a common good? [2] For the joy of offering something of as > high a quality as humanly possible? Else, why? For fame, honour, status, > money, power? To mentally masturbate on the idea of having made something > "sucessful" (sic!)? > > We are not in need of yet another language trying, or pretending, to > improve on a handful of disparate points, leaving all the rest as is, > meaning in bad state. And, as an example, we are not in need of yet another > failed trial for a successor to C as major low-level lang. > Differences, thought of by their designer as significant quality > improvements, are the *reasons* for programmers to adopt a new language. > There are the _only_ (good) reasons to do so. Thinking that programmers may > adopt a new language _despite_ its differences is thinking backwards; this, > in addition to preventing oneself from working for the common good; by > fear, probably; fear of truely thinking by oneself and/or of making one's > true thinking public truely. (I can understand that, however: I often do > not disclose my thinking by fear of the terrible level of violence, in my > view, present in the programming "community" [hum!], and among geeks in > general. This, rather than sharing and mutual help and cooperation, for the > common wealth. Our civilisation... again.) > > I have recently decided to adopt possible differences even if i am not > that convinced of their betterness; to give alternatives a try; to give > them at least a chance to show us (or just me) how good they actually are, > or not, in practice, maybe on the long term [3]. > This may go too far; it is a personal decision. > > However, deciding not to change what one sees wrong is weird for the > least. It means removing points of quality according to one's own views, > removing chances to contrbute to a better world, removing sources of > personal satisfaction, removing reasons for others to judge a language > better, thus removing motivation for programmers to adopt it. Maybe, > certainly, many programmers do not adopt a language on the base of its > quality, only; however, this counts; people I wish would adopt my lang, if > ever, are those people who judge first on quality, not hype followers or > otherwise conservatives. > What I mean is, apart from working against the common wealth, in addition > to preventing one's own enjoyment of doing what one does, such an attitude > may also work against a language's potential success. Is this (a factor) > why we have no successor to C yet, what do you think? because most > designers kept most of its design bugs unchanged? [4] just to have a > minimal chance, should a potential successor instead break as much as > possible? (And not have a builtin interface to C? ???) > > Also note that attitudes and spirits are psycho-sociologically contagious. > In particular, fear and lack of courage and angst are highly contagious (in > our world, with such a close to universal high level of anxiety...) What if > more (would-be) language designers boldly thought by themselves and boldly > assumed their thoughts? > > Final note: isn't it weird that such conformism is _that_ prevalent among > language designers? Precisely the ones who should be bearers of novelty? > the one "milieu" which could & should be a network of interacting > counter-cultures and individual iconoclasts (idol breakers)? > > I do not expect anyone shares (all of) this. I just hope it may open new > ways of thinking or questionning to a few. > > Denis > > [1] Including the funny usage of "=" for assignment and "==" for equality, > after at least 5 decades, lol! Still my favorite syntactic error after > dozens of thousands of hours of programming in languages which nearly all > use this amusing convention. Why not use "if" to mean 'try' or 'switch' or > 'foreach', and "ifif" to mean 'if'? What do you think? > > [2] Actually, they are both communal and social. Better quality languages > may contribute to a better world, at a communal level because we > programmers share code and read others' code all the time, and at a social > level because apps are a significant part of the world's state. > > [3] As you certainly know, it takes time to unlearn, especially to stop > judging something bad while it is just different. (Think at C programmers > and their beloved code block {} braces. I for one have better usage for > brace ;-.) > > [4] As an anecdote, somewhat complementary, in the course of my > explorations about programming languages, I often stepped on lists of C > design bugs, at least a dozen of them. Typically endless lists that take a > quarter of an hour to read in one go, without comments. There is space to > works for a language lover :-). If not enough, usually such critics seems > to agree on more than half of the points (and the remaining ones may not > figure on some lists just because the critic not think at it or did not > study this point) (but their solutions may diverge...). > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Jan 1 22:18:02 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 01 Jan 2014 22:18:02 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> Message-ID: <52C5049A.9080705@mozilla.com> On 1/1/14 10:06 PM, Vadim wrote: > Well, since requiring '&' at the original borrow site doesn't really > prevent the "unexpected mutability" problem, why not drop it and > eliminate a bunch of noise from Rust sources? But it does eliminate mutation of lvalues. > And, again, if > "unexpected mutability" is what concerns people, "mut" annotation is the > better way to fix that, IMHO. I don't know if it's a coherent proposal. Consider these four function signatures, each of which might mutate their arguments: fn f(x: &mut int) { ... } fn g(x: (&mut int, &mut int)) { ... } struct S<'a> { a: &'a mut int, b: &'a mut uint, } fn h(x: S) { ... } fn i(x: T, f: |T|) { f(x) } How might `i` mutate its argument? Consider function `j`: fn j() { let mut x = 3; i(&mut x, |ptr| *ptr = 5); } So `i` mutated its argument. So how should you be forced to notate that? Should you have to write: fn i(x: T, f: |T|) { f(mut x) } ... i(&mut x, |ptr| *ptr = 5); Or: fn i(x: T, f: |T|) { f(x) } ... i(mut &mut x, |ptr| *ptr = 5); Or: fn i(x: T, f: |T|) { f(mut x) } ... i(mut &mut x, |ptr| *ptr = 5); And that's just a simple example: start throwing in existential types like traits and it becomes clear that you really can't tell from the program where mutation could possibly happen, because the types are hiding mutability from you. And that's fine--existential types and generics deliberately permit that abstraction. But it does mean, I think, that we can't meaningfully talk about a sound and complete "mut" annotation at call sites. Patrick From danielmicay at gmail.com Wed Jan 1 22:21:07 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 2 Jan 2014 01:21:07 -0500 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> Message-ID: On Thu, Jan 2, 2014 at 1:06 AM, Vadim wrote: > > And let's not forget about the heap-allocated objects, which start out as pointers in the first place. Unique pointers have value semantics so this shouldn't be relevant to the visibility of mutation. The consensus is already to remove the auto-coercion of `~T` to `&mut T` because it doesn't make any sense. The auto-coercion to `&T` will probably either be removed or extended to `T` too, but that hasn't been decided (or discussed much). From martin at minimum.se Thu Jan 2 03:37:01 2014 From: martin at minimum.se (martin at minimum.se) Date: Thu, 02 Jan 2014 12:37:01 +0100 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C5049A.9080705@mozilla.com> Message-ID: <9a32a43bac33d83337bf0d8ce7db73e5192ff321@mail.glesys.se> Thanks, that explains it.Martin? ----- Original Message ----- From: "Patrick Walton" And that's just a simple example: start throwing in existential types like traits and it becomes clear that you really can't tell from the program where mutation could possibly happen, because the types are hiding mutability from you. And that's fine--existential types and generics deliberately permit that abstraction But it does mean, I think, that we can't meaningfully talk about a sound and complete "mut" annotation at call sites. Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Thu Jan 2 07:09:48 2014 From: gaetan at xeberon.net (Gaetan) Date: Thu, 2 Jan 2014 16:09:48 +0100 Subject: [rust-dev] on quality & success In-Reply-To: References: <52C2B0F7.2000103@gmail.com> Message-ID: I also agree this thread doesn't add grist to the mill. Let's cut it. ----- Gaetan 2014/1/2 Palmer Cox > Everyone is entitled to their own opinions. However, those opinions should > be expressed in a polite manner. Phrases such as "Choice he (since its > mostly men)" and "mentally masturbate" do not seem to foster a welcoming, > inclusive environment. Quoting from > https://github.com/mozilla/rust/wiki/Note-development-policy#conduct: > > * We are committed to providing a friendly, safe and welcoming > environment for all, regardless of gender, sexual orientation, disability, > ethnicity, religion, or similar personal characteristic > > Thanks, > -Palmer Cox > > > > > On Tue, Dec 31, 2013 at 6:56 AM, spir wrote: > >> Hol?! >> >> [This is a rather personal and involved post. Press del if you feel like >> it...] >> [also, it is long] >> [copy to rust-dev mailing list: actually the post is inspired by a thread >> there "Thoughts on the Rust Roadmap"] >> >> There is a point obvious to me; apparently most people including many >> language designers don't share it, or act as if they did not: >> >> a language should be successful iff it is of high quality >> >> A kind of symmetric statement also holds; >> >> let us hope low quality languages have no success! >> >> There are various reasons to hope this, the most stupid beeing that >> successful languages influence others, present & future. This is in my view >> a symptom of our civilisation's funny spirit (read: madness), and related >> to the actual points I intend to state (if, for once, I manage to express >> my thought). >> >> Apparently, many language designers proceed more or less the following >> way: there are a few key points (for them) they consider mis-designed or >> missing or wrong in some way in existing languages (not all the same for >> every language). Thus, they want to make a language that repairs these >> points, all together. Then, certainly in fear that too many changes may >> repel potential adopters of their language, in hope to maximise its chances >> of success *despite* it breaking habits on the key points more important to >> them, they won't change anything else, or only the bare minimum they can. >> They want instead to remain as mainstream as possible on everything else. >> [4] >> >> I consider this spirit bad; I mean, very bad. This is the way basic >> design errors propagate from successful languages to others, for instance. >> [1] Apparently, it takes a great dose of courage to break any existing >> practice in a _new_ language: tell me why, I do not understand. >> >> Note that I am here talking of wrong design points in the opinion of a >> given language designer. Choices he (since it's mostly men) would not do if >> programming were a new field, open to all explorations. (There are indeed >> loads of subjective or ideological design points; see also [1] & [3]) >> However, while programming is not a new field anymore, it is indeed open to >> all explorations, for you, for me, if you or me wants it. Nothing blocks us >> but our own bloackages, our own fears, and, probably, wrong rationales, >> perhaps non-fully-conscious ones. >> >> Deciding to reuse wrong, but mainstream, design decisions in one's own >> language is deciding to intentionally make it of lower quality. !!! Funny >> (read: mad), isn't it? It is thus also intentionally deciding to make it >> not worth success. This, apparently, to make its actual chances of success >> higher. (Isn't our culture funny?) >> Then, why does one _actually_ make a new language? For the joy of making >> something good? To contribute to a better world, since languages and >> programming are a common good? [2] For the joy of offering something of as >> high a quality as humanly possible? Else, why? For fame, honour, status, >> money, power? To mentally masturbate on the idea of having made something >> "sucessful" (sic!)? >> >> We are not in need of yet another language trying, or pretending, to >> improve on a handful of disparate points, leaving all the rest as is, >> meaning in bad state. And, as an example, we are not in need of yet another >> failed trial for a successor to C as major low-level lang. >> Differences, thought of by their designer as significant quality >> improvements, are the *reasons* for programmers to adopt a new language. >> There are the _only_ (good) reasons to do so. Thinking that programmers may >> adopt a new language _despite_ its differences is thinking backwards; this, >> in addition to preventing oneself from working for the common good; by >> fear, probably; fear of truely thinking by oneself and/or of making one's >> true thinking public truely. (I can understand that, however: I often do >> not disclose my thinking by fear of the terrible level of violence, in my >> view, present in the programming "community" [hum!], and among geeks in >> general. This, rather than sharing and mutual help and cooperation, for the >> common wealth. Our civilisation... again.) >> >> I have recently decided to adopt possible differences even if i am not >> that convinced of their betterness; to give alternatives a try; to give >> them at least a chance to show us (or just me) how good they actually are, >> or not, in practice, maybe on the long term [3]. >> This may go too far; it is a personal decision. >> >> However, deciding not to change what one sees wrong is weird for the >> least. It means removing points of quality according to one's own views, >> removing chances to contrbute to a better world, removing sources of >> personal satisfaction, removing reasons for others to judge a language >> better, thus removing motivation for programmers to adopt it. Maybe, >> certainly, many programmers do not adopt a language on the base of its >> quality, only; however, this counts; people I wish would adopt my lang, if >> ever, are those people who judge first on quality, not hype followers or >> otherwise conservatives. >> What I mean is, apart from working against the common wealth, in addition >> to preventing one's own enjoyment of doing what one does, such an attitude >> may also work against a language's potential success. Is this (a factor) >> why we have no successor to C yet, what do you think? because most >> designers kept most of its design bugs unchanged? [4] just to have a >> minimal chance, should a potential successor instead break as much as >> possible? (And not have a builtin interface to C? ???) >> >> Also note that attitudes and spirits are psycho-sociologically >> contagious. In particular, fear and lack of courage and angst are highly >> contagious (in our world, with such a close to universal high level of >> anxiety...) What if more (would-be) language designers boldly thought by >> themselves and boldly assumed their thoughts? >> >> Final note: isn't it weird that such conformism is _that_ prevalent among >> language designers? Precisely the ones who should be bearers of novelty? >> the one "milieu" which could & should be a network of interacting >> counter-cultures and individual iconoclasts (idol breakers)? >> >> I do not expect anyone shares (all of) this. I just hope it may open new >> ways of thinking or questionning to a few. >> >> Denis >> >> [1] Including the funny usage of "=" for assignment and "==" for >> equality, after at least 5 decades, lol! Still my favorite syntactic error >> after dozens of thousands of hours of programming in languages which nearly >> all use this amusing convention. Why not use "if" to mean 'try' or 'switch' >> or 'foreach', and "ifif" to mean 'if'? What do you think? >> >> [2] Actually, they are both communal and social. Better quality languages >> may contribute to a better world, at a communal level because we >> programmers share code and read others' code all the time, and at a social >> level because apps are a significant part of the world's state. >> >> [3] As you certainly know, it takes time to unlearn, especially to stop >> judging something bad while it is just different. (Think at C programmers >> and their beloved code block {} braces. I for one have better usage for >> brace ;-.) >> >> [4] As an anecdote, somewhat complementary, in the course of my >> explorations about programming languages, I often stepped on lists of C >> design bugs, at least a dozen of them. Typically endless lists that take a >> quarter of an hour to read in one go, without comments. There is space to >> works for a language lover :-). If not enough, usually such critics seems >> to agree on more than half of the points (and the remaining ones may not >> figure on some lists just because the critic not think at it or did not >> study this point) (but their solutions may diverge...). >> >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Thu Jan 2 07:22:17 2014 From: gaetan at xeberon.net (Gaetan) Date: Thu, 2 Jan 2014 16:22:17 +0100 Subject: [rust-dev] Using CMake with Rust In-Reply-To: <52C4F9E2.1070702@aim.com> References: <52C4EA82.1050706@aim.com> <52C4F397.3070104@gmail.com> <52C4F9E2.1070702@aim.com> Message-ID: I used cmake for years and was quite happy with it, so a support of cmake is welcomed. I recommend have it "officially" integrated into rust, along with some other popular toolsets (scon, bare makefiles, visual studio,...). Even if VS can derive from cmake. This is a strategic added value to have it provided by the language. I also would like to add I find this complementary to rust-pkg. For simple project, this latter might do the job, but for very complex projects, a full featured build system might be used, so let's have it seamlessly integrated into rust. ----- Gaetan 2014/1/2 SiegeLord > On 01/02/2014 12:05 AM, Gy?rgy Andrasek wrote: > >> The proper way to support a language in CMake is outlined in >> `Modules/CMakeAddNewLanguage.txt`: >> > > I was guided away from that method by this email: http://www.cmake.org/ > pipermail/cmake/2011-March/043444.html . My approach is amenable to > generating files for alternative build systems, like ninja. If you are > aware that that email is incorrect, I'm glad to be corrected. Independently > of that email, I have looked into doing it that way, but I found that it > just did not mesh with the Rust compilation model, and I saw no clear way > to using the information given by 'rustc --dep-info' to inform the build > system. Additionally, my macros allow an easy way of doing documentation > generation, which that method doesn't clearly allow. > > I'll be glad to be corrected on all those points though. > > -SL > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bytemr at gmail.com Thu Jan 2 12:42:59 2014 From: bytemr at gmail.com (Joshua Rodgers) Date: Thu, 2 Jan 2014 13:42:59 -0700 Subject: [rust-dev] Using CMake with Rust In-Reply-To: References: <52C4EA82.1050706@aim.com> <52C4F397.3070104@gmail.com> <52C4F9E2.1070702@aim.com> Message-ID: As an active user of CMake for several C++ projects that I maintain I would be fully on board with first class CMake support by rust. I know a lot of people want rustpkg to be the primary tool, but I feel like it is better fit for small projects and libraries. Rustpkg is definitely useful for smaller projects and for libraries. What I'd like to see is something for managing project dependencies that can be used with any build system like CMake or rustpkg. On Thu, Jan 2, 2014 at 8:22 AM, Gaetan wrote: > I used cmake for years and was quite happy with it, so a support of cmake > is welcomed. I recommend have it "officially" integrated into rust, along > with some other popular toolsets (scon, bare makefiles, visual studio,...). > Even if VS can derive from cmake. This is a strategic added value to have > it provided by the language. > > I also would like to add I find this complementary to rust-pkg. For simple > project, this latter might do the job, but for very complex projects, a > full featured build system might be used, so let's have it seamlessly > integrated into rust. > > ----- > Gaetan > > > > 2014/1/2 SiegeLord > >> On 01/02/2014 12:05 AM, Gy?rgy Andrasek wrote: >> >>> The proper way to support a language in CMake is outlined in >>> `Modules/CMakeAddNewLanguage.txt`: >>> >> >> I was guided away from that method by this email: http://www.cmake.org/ >> pipermail/cmake/2011-March/043444.html . My approach is amenable to >> generating files for alternative build systems, like ninja. If you are >> aware that that email is incorrect, I'm glad to be corrected. Independently >> of that email, I have looked into doing it that way, but I found that it >> just did not mesh with the Rust compilation model, and I saw no clear way >> to using the information given by 'rustc --dep-info' to inform the build >> system. Additionally, my macros allow an easy way of doing documentation >> generation, which that method doesn't clearly allow. >> >> I'll be glad to be corrected on all those points though. >> >> -SL >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Thu Jan 2 13:40:04 2014 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Thu, 02 Jan 2014 22:40:04 +0100 Subject: [rust-dev] error: can't find crate for `std` Message-ID: <52C5DCB4.50000@free.fr> I update with the master and now I have this error with a code that was compiling before. ... rs:1:1: 1:1 error: can't find crate for `std` The error is at the first line which ever was the first line. Not all crate have the problem. Philippe Delrieu From vadimcn at gmail.com Thu Jan 2 14:49:53 2014 From: vadimcn at gmail.com (Vadim) Date: Thu, 2 Jan 2014 14:49:53 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C5049A.9080705@mozilla.com> References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> <52C5049A.9080705@mozilla.com> Message-ID: I'd say it should be i(mut x, ...), though in this case inferring borrow is not possible because of the lambda. But if this were a standalone function, e.g. the f() above, one could write "i(mut x, f);" Regarding mutation-polymorphic generics, yes, it may not be possible to mut-annotate them. I would just let it slide for "pass-through" types like T, but require annotations in non-generic code. Not the best solution, but it just bothers me that we worry about the "mutability hazard" at the top level of the call chain, but then completely forget about it inside the callee. Vadim On Wed, Jan 1, 2014 at 10:18 PM, Patrick Walton wrote: > On 1/1/14 10:06 PM, Vadim wrote: > >> Well, since requiring '&' at the original borrow site doesn't really >> prevent the "unexpected mutability" problem, why not drop it and >> eliminate a bunch of noise from Rust sources? >> > > But it does eliminate mutation of lvalues. > > And, again, if >> "unexpected mutability" is what concerns people, "mut" annotation is the >> better way to fix that, IMHO. >> > > I don't know if it's a coherent proposal. Consider these four function > signatures, each of which might mutate their arguments: > > fn f(x: &mut int) { ... } > > fn g(x: (&mut int, &mut int)) { ... } > > struct S<'a> { > a: &'a mut int, > b: &'a mut uint, > } > fn h(x: S) { ... } > > fn i(x: T, f: |T|) { f(x) } > > How might `i` mutate its argument? Consider function `j`: > > fn j() { > let mut x = 3; > i(&mut x, |ptr| *ptr = 5); > } > > So `i` mutated its argument. So how should you be forced to notate that? > Should you have to write: > > fn i(x: T, f: |T|) { f(mut x) } > > ... i(&mut x, |ptr| *ptr = 5); > > Or: > > fn i(x: T, f: |T|) { f(x) } > > ... i(mut &mut x, |ptr| *ptr = 5); > > Or: > > fn i(x: T, f: |T|) { f(mut x) } > > ... i(mut &mut x, |ptr| *ptr = 5); > > And that's just a simple example: start throwing in existential types like > traits and it becomes clear that you really can't tell from the program > where mutation could possibly happen, because the types are hiding > mutability from you. And that's fine--existential types and generics > deliberately permit that abstraction. But it does mean, I think, that we > can't meaningfully talk about a sound and complete "mut" annotation at call > sites. > > Patrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Thu Jan 2 14:51:24 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 02 Jan 2014 14:51:24 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> <52C5049A.9080705@mozilla.com> Message-ID: <52C5ED6C.6090303@mozilla.com> On 1/2/14 2:49 PM, Vadim wrote: > I'd say it should be i(mut x, ...), though in this case inferring borrow > is not possible because of the lambda. But if this were a standalone > function, e.g. the f() above, one could write "i(mut x, f);" > > Regarding mutation-polymorphic generics, yes, it may not be possible to > mut-annotate them. I would just let it slide for "pass-through" types > like T, but require annotations in non-generic code. > Not the best solution, but it just bothers me that we worry about the > "mutability hazard" at the top level of the call chain, but then > completely forget about it inside the callee. I'd rather do something principled and easy to understand than to have ad-hoc rules that a user has to memorize. What current Rust does is easy to understand IMO: it's the same as C. Patrick From banderson at mozilla.com Thu Jan 2 15:04:22 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 02 Jan 2014 15:04:22 -0800 Subject: [rust-dev] RFC: Future-proof for unboxed closures In-Reply-To: <52C1E17F.2010809@mozilla.com> References: <52C1E17F.2010809@mozilla.com> Message-ID: <52C5F076.9000206@mozilla.com> On 12/30/2013 01:11 PM, Patrick Walton wrote: > I've been thinking that to future-proof unboxed closures in the future > we should maybe limit `|x| x+1` lambda syntax to either (a) require > `&` in front or (b) in function position. > > So today you would write: > > let f = |x| x+1; > > But tomorrow you would write: > > let f = &|x| x+1; > > But it would always work here: > > v.map(|&x| x+1); > > The reason is simply that we'd like `|x| x+1` to become an unboxed > closure in the future and it's easier in the language semantics to > future-proof for it this way: we simply special-case the function > argument position. Why special case it in argument position instead of just requiring & everywhere? Also, why couldn't you pass the closure by value to another function? > > Alternatively we can do it with assignability: say that `|x| x+1` is > an anonymous type (an error today) that is assignable to the type > `|int|->int`. That might be cleaner than special-casing the function > argument position. > > Patrick > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From carter.schonwald at gmail.com Thu Jan 2 15:44:40 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 2 Jan 2014 18:44:40 -0500 Subject: [rust-dev] Using CMake with Rust In-Reply-To: References: <52C4EA82.1050706@aim.com> <52C4F397.3070104@gmail.com> <52C4F9E2.1070702@aim.com> Message-ID: question: is there any reason why cmake integration / support couldn't be mediated via some improvements to rustpkg? I had a first look at the current rustpkg api yesterday, and i ran away screaming about the the many angled stringy typed ones that inhabit the gaps in configuration space. I emphatically agree that there should be some flexiblity in build tooling support, and any dogmatic approach "all in rust" or "use X" will fail for some use case. Is there any reason why that couldn't be via making it easy to use an external build system via some rustpkg api improvement? (seriously!) On Thu, Jan 2, 2014 at 3:42 PM, Joshua Rodgers wrote: > As an active user of CMake for several C++ projects that I maintain I > would be fully on board with first class CMake support by rust. I know a > lot of people want rustpkg to be the primary tool, but I feel like it is > better fit for small projects and libraries. Rustpkg is definitely useful > for smaller projects and for libraries. What I'd like to see is something > for managing project dependencies that can be used with any build system > like CMake or rustpkg. > > > On Thu, Jan 2, 2014 at 8:22 AM, Gaetan wrote: > >> I used cmake for years and was quite happy with it, so a support of cmake >> is welcomed. I recommend have it "officially" integrated into rust, along >> with some other popular toolsets (scon, bare makefiles, visual studio,...). >> Even if VS can derive from cmake. This is a strategic added value to have >> it provided by the language. >> >> I also would like to add I find this complementary to rust-pkg. For >> simple project, this latter might do the job, but for very complex >> projects, a full featured build system might be used, so let's have it >> seamlessly integrated into rust. >> >> ----- >> Gaetan >> >> >> >> 2014/1/2 SiegeLord >> >>> On 01/02/2014 12:05 AM, Gy?rgy Andrasek wrote: >>> >>>> The proper way to support a language in CMake is outlined in >>>> `Modules/CMakeAddNewLanguage.txt`: >>>> >>> >>> I was guided away from that method by this email: http://www.cmake.org/ >>> pipermail/cmake/2011-March/043444.html . My approach is amenable to >>> generating files for alternative build systems, like ninja. If you are >>> aware that that email is incorrect, I'm glad to be corrected. Independently >>> of that email, I have looked into doing it that way, but I found that it >>> just did not mesh with the Rust compilation model, and I saw no clear way >>> to using the information given by 'rustc --dep-info' to inform the build >>> system. Additionally, my macros allow an easy way of doing documentation >>> generation, which that method doesn't clearly allow. >>> >>> I'll be glad to be corrected on all those points though. >>> >>> -SL >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Fri Jan 3 02:07:54 2014 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Fri, 03 Jan 2014 11:07:54 +0100 Subject: [rust-dev] error: can't find crate for `std` In-Reply-To: <52C5DCB4.50000@free.fr> References: <52C5DCB4.50000@free.fr> Message-ID: <52C68BFA.3070708@free.fr> I found the problem. I had to rebuild all my external C binding that was compiled with the old version of rustc. Before rustc were crashing. Now I have this error. Philippe Le 02/01/2014 22:40, Philippe Delrieu a ?crit : > I update with the master and now I have this error with a code that > was compiling before. > ... rs:1:1: 1:1 error: can't find crate for `std` > > The error is at the first line which ever was the first line. Not all > crate have the problem. > > Philippe Delrieu > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > From stefan.plantikow at gmail.com Fri Jan 3 02:25:48 2014 From: stefan.plantikow at gmail.com (Stefan Plantikow) Date: Fri, 3 Jan 2014 11:25:48 +0100 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: <52C5049A.9080705@mozilla.com> References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> <52C5049A.9080705@mozilla.com> Message-ID: Hi, Am 02.01.2014 um 07:18 schrieb Patrick Walton : > > > And that's just a simple example: start throwing in existential types like traits and it becomes clear that you really can't tell from the program where mutation could possibly happen, because the types are hiding mutability from you. And that's fine--existential types and generics deliberately permit that abstraction. But it does mean, I think, that we can't meaningfully talk about a sound and complete "mut" annotation at call sites. > Maybe completely off here but why is mutability not tracked by the region system? Wouldn?t that help solve this issue? i.e. assignment to a mutable lvalue would only be allowed from an rvalue in a mutable region. Haven?t thought about how that relates to freezing/thawing. Cheers, Stefan From pcwalton at mozilla.com Fri Jan 3 09:02:45 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 03 Jan 2014 09:02:45 -0800 Subject: [rust-dev] Why doesn't rust require "mut" param prefix at call site? In-Reply-To: References: <52C4A989.5010201@minimum.se> <2e15dceb-ff7d-4350-8857-69d3c7b1b287@email.android.com> <52C5049A.9080705@mozilla.com> Message-ID: <52C6ED35.5020106@mozilla.com> On 1/3/14 2:25 AM, Stefan Plantikow wrote: > Maybe completely off here but why is mutability not tracked by the > region system? Wouldn?t that help solve this issue? i.e. assignment > to a mutable lvalue would only be allowed from an rvalue in a mutable > region. Haven?t thought about how that relates to > freezing/thawing. It kind of is, in that mutation generally requires a unique ownership path. See the comments in the borrow checker for more details. Patrick From palmercox at gmail.com Fri Jan 3 20:33:04 2014 From: palmercox at gmail.com (Palmer Cox) Date: Fri, 3 Jan 2014 23:33:04 -0500 Subject: [rust-dev] RFC: Iterator naming convention In-Reply-To: References: Message-ID: I said I was giving up on this in my last message. However, I decided to give it one more go. Details are at https://github.com/mozilla/rust/pull/11001. -Palmer Cox On Fri, Dec 27, 2013 at 1:50 AM, Palmer Cox wrote: > So, > > The rules that I tried to concoct don't really work. I don't know what to > do with something like BitvIterator. Rename it to BitvElements? Anyway, I'm > thinking of amending my pull request to just rename the *Iter structs to > *Iterator and leave the rest alone. > > Thoughts? > > I pulled together what I believe is the full list of iterators in Rust as > of f74b8f0d3a90fd3b64afa38b9470d9a45cd04ee9. If someone has a better > suggestion of how to unify their naming, I'm happy to do it. > > +------------------------------------------+---------------------------+ > | File | Name | > +------------------------------------------+---------------------------+ > | src/libextra/bitv.rs | BitvIterator | > +------------------------------------------+---------------------------+ > | src/libextra/bitv.rs | BitvSetIterator | > +------------------------------------------+---------------------------+ > | src/libextra/dlist.rs | DListIterator | > +------------------------------------------+---------------------------+ > | src/libextra/dlist.rs | MutDListIterator | > +------------------------------------------+---------------------------+ > | src/libextra/dlist.rs | MoveIterator | > +------------------------------------------+---------------------------+ > | src/libextra/enum_set.rs | EnumSetIterator | > +------------------------------------------+---------------------------+ > | src/libextra/glob.rs | GlobIterator | > +------------------------------------------+---------------------------+ > | src/libextra/priority_queue.rs | PriorityQueueIterator | > +------------------------------------------+---------------------------+ > | src/libextra/ringbuf.rs | RingBufIterator | > +------------------------------------------+---------------------------+ > | src/libextra/ringbuf.rs | RingBufMutIterator | > +------------------------------------------+---------------------------+ > | src/libextra/smallintmap.rs | SmallIntMapIterator | > +------------------------------------------+---------------------------+ > | src/libextra/smallintmap.rs | SmallIntMapMutIterator | > +------------------------------------------+---------------------------+ > | src/libextra/smallintmap.rs | SmallIntMapRevIterator | > +------------------------------------------+---------------------------+ > | src/libextra/smallintmap.rs | SmallIntMapMutRevIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | TreeMapIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | TreeMapRevIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | TreeMapMoveIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | TreeSetIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | TreeSetRevIterator | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | Difference | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | SymDifference | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | Intersection | > +------------------------------------------+---------------------------+ > | src/libextra/treemap.rs | Union | > +------------------------------------------+---------------------------+ > | src/librustc/middle/trans/basic_block.rs | PredIterator | > +------------------------------------------+---------------------------+ > | src/librustc/middle/trans/value.rs | UserIterator | > +------------------------------------------+---------------------------+ > | src/librustpkg/package_id.rs | Prefixes | > +------------------------------------------+---------------------------+ > | src/libstd/c_str.rs | CStringIterator | > +------------------------------------------+---------------------------+ > | src/libstd/comm/mod.rs | PortIterator | > +------------------------------------------+---------------------------+ > | src/libstd/comm/select.rs | PacketIterator | > +------------------------------------------+---------------------------+ > | src/libstd/either.rs | Lefts | > +------------------------------------------+---------------------------+ > | src/libstd/either.rs | Rights | > +------------------------------------------+---------------------------+ > | src/libstd/fmt/parse.rs | Parser | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | HashMapIterator | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | HashMapMutIterator | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | HashMapMoveIterator | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | HashSetIterator | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | HashSetMoveIterator | > +------------------------------------------+---------------------------+ > | src/libstd/hashmap.rs | SetAlgebraIter | > +------------------------------------------+---------------------------+ > | src/libstd/io/extensions.rs | ByteIterator | > +------------------------------------------+---------------------------+ > | src/libstd/io/fs.rs | WalkIterator | > +------------------------------------------+---------------------------+ > | src/libstd/io/mod.rs | LineIterator | > +------------------------------------------+---------------------------+ > | src/libstd/io/mod.rs | IncomingIterator | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Invert | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | ByRef | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Cycle | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Chain | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Zip | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Map | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Filter | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | FilterMap | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Enumerate | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Peekable | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | SkipWhile | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | TakeWhile | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Skip | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Take | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Scan | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | FlatMap | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Fuse | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Inspect | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Unfold | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Counter | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Range | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | RangeInclusive | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | RangeStep | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | RangeStepInclusive | > +------------------------------------------+---------------------------+ > | src/libstd/iter.rs | Repeat | > +------------------------------------------+---------------------------+ > | src/libstd/option.rs | OptionIterator | > +------------------------------------------+---------------------------+ > | src/libstd/path/posix.rs | ComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/posix.rs | RevComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/posix.rs | StrComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/posix.rs | RevStrComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/windows.rs | StrComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/windows.rs | RevStrComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/windows.rs | ComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/path/windows.rs | RevComponentIter | > +------------------------------------------+---------------------------+ > | src/libstd/rt/task.rs | BlockedTaskIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharOffsetIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharSplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharSplitNIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | MatchesIndexIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | StrSplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | NormalizationIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharRevIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharOffsetRevIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | ByteIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | ByteRevIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | CharRSplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | WordIterator | > +------------------------------------------+---------------------------+ > | src/libstd/str.rs | AnyLineIterator | > +------------------------------------------+---------------------------+ > | src/libstd/trie.rs | TrieMapIterator | > +------------------------------------------+---------------------------+ > | src/libstd/trie.rs | TrieSetIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | SplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | RSplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | ElementSwaps | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | Permutations | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | WindowIter | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | ChunkIter | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | VecIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | VecMutIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | MutSplitIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | MutChunkIter | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | MoveIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | RevIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | MutRevIterator | > +------------------------------------------+---------------------------+ > | src/libstd/vec.rs | MoveRevIterator | > +------------------------------------------+---------------------------+ > | src/libsyntax/opt_vec.rs | OptVecIterator | > +------------------------------------------+---------------------------+ > | src/libsyntax/util/small_vector.rs | SmallVectorMoveIterator | > +------------------------------------------+---------------------------+ > > Thanks, > -Palmer Cox > > > > On Sat, Dec 21, 2013 at 11:35 PM, Palmer Cox wrote: > >> Due to type inference, my assumption is that in many cases the only >> people that see the actual type names are the developers creating them and >> people reading the docs. I hadn't though about the Reader / Port cases, but >> those do seem like pretty reasonable places where you might want to have an >> object implement Iterator in addition to other traits. >> >> So, if the decision is no suffixes, what do we do with all of the >> existing Iterators that have suffixes? Strip them? Maybe the rule of thumb >> should look something like this: >> >> 1. If you are implementing a struct that only implements the Iterator >> trait, make the name plural, but don't use the Iterator suffix. eg: Chunks >> 2. If you are implementing a struct that implements traits in addition to >> Iterator, there is no need to make it plural. eg: Port / Reader >> >> If that's the general rule of thumb, then SplitIterator becomes Splits >> and MutChunkIter becomes MutChunks. I guess that means that >> DoubleEndedIterator also becomes just DoubledEnded. That seems reasonable >> to me, since it fits it better with the ExactSize trait also defined in the >> iter module. That doesn't really directly solve my issue with Map from the >> iter module being confusing. If its referenced as iter::Map, its >> not confusing of course, but at least some of the current code doesn't do >> that and there isn't any way to force future code to do so. Its probably >> not a huge deal, though. >> >> Does that sound like the general opinion? >> >> -Palmer Cox >> >> >> >> >> >> On Sat, Dec 21, 2013 at 8:43 PM, Eric Reed wrote: >> >>> I prefer the 'no suffix' option and generally agree with Alex. >>> Iterators aren't special and their iterator behavior is already denoted >>> by implementing the Iterator trait. >>> >>> Frankly, aside from documentation where it is clear that something is an >>> iterator, I'm not sure when a user would even see concrete iterator types. >>> I can't think of a reason why you'd ever want to restrict the type of a >>> variable to a specific kind of iterator (i.e. Map or Union). >>> >>> Acceptor and Port could implement Iterator directly, but currently they >>> create a struct containing only a mutable borrow of themselves to prevent >>> anything else from using the socket/channel in the meantime. >>> Reader could directly implement an Iterator that does one byte reads, >>> but currently it does the same trick as Acceptor and Port. >>> You only need a separate Iterator object if you actually require >>> additional state or if you want to prevent others from changing the >>> underlying source (mutable borrow of self). >>> >>> >>> >>> On Sat, Dec 21, 2013 at 4:35 PM, Kevin Cantu wrote: >>> >>>> Rust's standard libs are still pretty thin on their trait hierarchies, >>>> but I'm sure this will change. >>>> >>>> Kevin >>>> >>>> On Sat, Dec 21, 2013 at 1:30 PM, Palmer Cox >>>> wrote: >>>> > Are there examples of structs that implement Iterator that also >>>> implement >>>> > other non-Iterator related traits? Although its possible to do that, >>>> I can't >>>> > think of a use case for it off the top of my head. An Iterator >>>> basically >>>> > represents the state of an ongoing computation and once that >>>> computation is >>>> > completed, the object is mostly uselss. It seems like it would be >>>> awkward to >>>> > implement other traits for such an object. Maybe I'm not thinking of >>>> > something, however. >>>> > >>>> > -Palmer Cox >>>> > >>>> > >>>> > >>>> > On Sat, Dec 21, 2013 at 4:24 PM, Kevin Cantu >>>> wrote: >>>> >> >>>> >> Iterators are just structs which implement the "Iterator" or a >>>> related >>>> >> trait, right? >>>> >> >>>> >> These structs which do can also implement lots of other traits, too: >>>> >> no reason to make -Iter special. >>>> >> >>>> >> >>>> >> Kevin >>>> >> >>>> >> >>>> >> >>>> >> On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox >>>> wrote: >>>> >> > I'm not a big fan of Hungarian notation either. I'm not sure that >>>> having >>>> >> > a >>>> >> > naming convention for Iterators is Hungarian notation, however. For >>>> >> > example, >>>> >> > if you are doing Windows programming, you'll see stuff like: >>>> >> > >>>> >> > DWORD dwFoo = 0; >>>> >> > >>>> >> > In this case, the "dw" prefix on the variable indicates that we >>>> have a >>>> >> > DWORD >>>> >> > variable. However, the Iterator suffix that I'm proposing here is a >>>> >> > suffix >>>> >> > on the type names, not the actual variable names. So, if you are >>>> writing >>>> >> > Rust code, you'd write something like this: >>>> >> > >>>> >> > let chunks = some_vector.chunks(50); >>>> >> > >>>> >> > So, the actual variable name doesn't have the Hungarian notation >>>> and the >>>> >> > types aren't even generally visible since the compiler infers much >>>> of >>>> >> > that. >>>> >> > However, someone reading through the documentation and/or code >>>> will see >>>> >> > a >>>> >> > struct named ChunkIterator and instance know how the struct >>>> behaves - as >>>> >> > an >>>> >> > Iterator. So, I think the suffix serves less to describe the >>>> datatype >>>> >> > and >>>> >> > more to describe class of behavior that the struct implements. >>>> >> > >>>> >> > Anyway, as I said, I prefer #1. But, I also have done lots of Java >>>> >> > programming so I'm probably much more used to verbosity than >>>> others. I'm >>>> >> > not >>>> >> > horribly against some sort of other naming convention, either, of >>>> >> > course, >>>> >> > but I would like to see some consistency. >>>> >> > >>>> >> > My main motivation for opening the request was because I created >>>> >> > MutChunkIter and then realized that it was named differently than >>>> >> > majority >>>> >> > of other Iterators. I don't want to be responsible for someone >>>> reading >>>> >> > through the docs and seeing something thats inconsistent for no >>>> good >>>> >> > reason! >>>> >> > Also, I was reading through some code and happened upon a "Map" >>>> and was >>>> >> > exceptionally confused about it, until I realized it was iter::Map >>>> as >>>> >> > opposed to container::Map. I figured I probably wasn't the only >>>> person >>>> >> > that >>>> >> > was going to be confused by something like this. >>>> >> > >>>> >> > -Palmer Cox >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Sat, Dec 21, 2013 at 3:14 PM, Kevin Cantu >>>> wrote: >>>> >> >> >>>> >> >> IMHO Hungarian notation is for things the type system and tooling >>>> >> >> cannot deal with. I'm not sure this is one of them... >>>> >> >> >>>> >> >> >>>> >> >> Kevin >>>> >> > >>>> >> > >>>> > >>>> > >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flaper87 at gmail.com Sat Jan 4 06:01:28 2014 From: flaper87 at gmail.com (Flaper87) Date: Sat, 4 Jan 2014 15:01:28 +0100 Subject: [rust-dev] Configuration files library for Rust Message-ID: Hi Guys, I was looking around and I couldn't find a config file parser library for Rust. Getopt support seems to be pretty complete and stable, which would make the development of such library easier. Since I've some experience on this area, I thought about doing some work on it for Rust. My current plan is to do something along the lines of oslo.config[0] - which I've been contributing to - and take advantage of the existing getopt module, just as we do in oslo.config. The config file format parsed by oslo.config follows the INI[1] files format but with some changes to support list options and other types. One of the advantages of this library is that the config options registration is explicit and simple. However, before starting to work on this, I'd like to know what folks on this list think about the library, if there's been some work on this area that I'm not aware of, what the preferences are, etc. Cheers, FF [0] https://github.com/openstack/oslo.config [1] http://en.wikipedia.org/wiki/INI_file -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mneumann at ntecs.de Sat Jan 4 08:14:28 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Sat, 04 Jan 2014 17:14:28 +0100 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack Message-ID: <52C83364.7020500@ntecs.de> Hi all, rust-redis: A Redis client library written in pure Rust. Thanks to the new rust runtime it is pretty fast, despite being only 200 lines of code. rust-msgpack: Fully featured and high performance msgpack implementation for Rust. Both work with rust 0.9-pre. Regards, Michael From mneumann at ntecs.de Sat Jan 4 08:16:13 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Sat, 04 Jan 2014 17:16:13 +0100 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack In-Reply-To: <52C83364.7020500@ntecs.de> References: <52C83364.7020500@ntecs.de> Message-ID: <52C833CD.5030303@ntecs.de> Am 04.01.2014 17:14, schrieb Michael Neumann: > Hi all, > > rust-redis: A Redis client library written in pure Rust. Thanks to the > new rust runtime > it is pretty fast, despite being only 200 lines of code. > > rust-msgpack: Fully featured and high performance msgpack > implementation for Rust. > > Both work with rust 0.9-pre. Too stupid/sleepy that I forgot the links: http://github.com/mneumann/rust-redis http://github.com/mneumann/rust-msgpack Regards, Michael From corey at octayn.net Sat Jan 4 09:38:24 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 4 Jan 2014 12:38:24 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: Message-ID: oslo.config looks decent. On some projects I've worked on, we started out using INI files but found them severely lacking once we wanted to extend the options. We ended up using libconfig[0], which I think is an excellent library. In multibuilder[1], we use extra::serialize to load a config directly into the struct we'll be using. It's super convenient, but a bit unfortunate in that it's impossible to make a field truly optional (Option requires the field to be null, iirc). [0] http://www.hyperrealm.com/libconfig/ [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 wrote: > Hi Guys, > > I was looking around and I couldn't find a config file parser library for > Rust. Getopt support seems to be pretty complete and stable, which would > make the development of such library easier. > > Since I've some experience on this area, I thought about doing some work on > it for Rust. > > My current plan is to do something along the lines of oslo.config[0] - which > I've been contributing to - and take advantage of the existing getopt > module, just as we do in oslo.config. > > The config file format parsed by oslo.config follows the INI[1] files format > but with some changes to support list options and other types. One of the > advantages of this library is that the config options registration is > explicit and simple. > > However, before starting to work on this, I'd like to know what folks on > this list think about the library, if there's been some work on this area > that I'm not aware of, what the preferences are, etc. > > Cheers, > FF > > [0] https://github.com/openstack/oslo.config > [1] http://en.wikipedia.org/wiki/INI_file > > -- > Flavio (@flaper87) Percoco > http://www.flaper87.com > http://github.com/FlaPer87 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From corey at octayn.net Sat Jan 4 09:44:08 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 4 Jan 2014 12:44:08 -0500 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack In-Reply-To: <52C833CD.5030303@ntecs.de> References: <52C83364.7020500@ntecs.de> <52C833CD.5030303@ntecs.de> Message-ID: If you slap a #[no_uv]; on the benchmark, it will use libnative, which is threads On Sat, Jan 4, 2014 at 11:16 AM, Michael Neumann wrote: > > Am 04.01.2014 17:14, schrieb Michael Neumann: > >> Hi all, >> >> rust-redis: A Redis client library written in pure Rust. Thanks to the new >> rust runtime >> it is pretty fast, despite being only 200 lines of code. >> >> rust-msgpack: Fully featured and high performance msgpack implementation >> for Rust. >> >> Both work with rust 0.9-pre. > > > Too stupid/sleepy that I forgot the links: > > http://github.com/mneumann/rust-redis > http://github.com/mneumann/rust-msgpack > > > Regards, > > Michael > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From mneumann at ntecs.de Sat Jan 4 10:00:27 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Sat, 04 Jan 2014 19:00:27 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: Message-ID: <52C84C3B.2020304@ntecs.de> Am 04.01.2014 18:38, schrieb Corey Richardson: > oslo.config looks decent. On some projects I've worked on, we started > out using INI files but found them severely lacking once we wanted to > extend the options. We ended up using libconfig[0], which I think is > an excellent library. In multibuilder[1], we use extra::serialize to > load a config directly into the struct we'll be using. It's super > convenient, but a bit unfortunate in that it's impossible to make a > field truly optional (Option requires the field to be null, iirc). > > [0] http://www.hyperrealm.com/libconfig/ > [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 There is also TOML [1], an extended version of the INI config file format, which is used by a variety of languages. [1]: https://github.com/mojombo/toml Regards, Michael From flaper87 at gmail.com Sat Jan 4 10:00:18 2014 From: flaper87 at gmail.com (Flaper87) Date: Sat, 4 Jan 2014 19:00:18 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: Message-ID: 2014/1/4 Corey Richardson > oslo.config looks decent. On some projects I've worked on, we started > out using INI files but found them severely lacking once we wanted to > extend the options. We ended up using libconfig[0], which I think is > an excellent library. In multibuilder[1], we use extra::serialize to > load a config directly into the struct we'll be using. It's super > convenient, but a bit unfortunate in that it's impossible to make a > field truly optional (Option requires the field to be null, iirc). > > [0] http://www.hyperrealm.com/libconfig/ > [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 I'm also considering to have support for several parsers. It should be pretty simple / straightforward to do so. We could have a default parser based on INI files and then allow people to specify a different parser in case INI files are not what they want to use. I'll dive into libconfig and pick things from there as well. Also, I agree INI files could be a bit limited, which is why we ended up having our own INI parser in oslo.config. Thoughts? FF > > > On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 wrote: > > Hi Guys, > > > > I was looking around and I couldn't find a config file parser library for > > Rust. Getopt support seems to be pretty complete and stable, which would > > make the development of such library easier. > > > > Since I've some experience on this area, I thought about doing some work > on > > it for Rust. > > > > My current plan is to do something along the lines of oslo.config[0] - > which > > I've been contributing to - and take advantage of the existing getopt > > module, just as we do in oslo.config. > > > > The config file format parsed by oslo.config follows the INI[1] files > format > > but with some changes to support list options and other types. One of the > > advantages of this library is that the config options registration is > > explicit and simple. > > > > However, before starting to work on this, I'd like to know what folks on > > this list think about the library, if there's been some work on this area > > that I'm not aware of, what the preferences are, etc. > > > > Cheers, > > FF > > > > [0] https://github.com/openstack/oslo.config > > [1] http://en.wikipedia.org/wiki/INI_file > > > > -- > > Flavio (@flaper87) Percoco > > http://www.flaper87.com > > http://github.com/FlaPer87 > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sat Jan 4 10:11:25 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 04 Jan 2014 10:11:25 -0800 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack In-Reply-To: <52C833CD.5030303@ntecs.de> References: <52C83364.7020500@ntecs.de> <52C833CD.5030303@ntecs.de> Message-ID: <52C84ECD.1090709@mozilla.com> On 1/4/14 8:16 AM, Michael Neumann wrote: >> rust-msgpack: Fully featured and high performance msgpack >> implementation for Rust. >> >> Both work with rust 0.9-pre. > > Too stupid/sleepy that I forgot the links: > > http://github.com/mneumann/rust-redis > http://github.com/mneumann/rust-msgpack Sweet! msgpack might be a good IPC format for Servo. Patrick From gaetan at xeberon.net Sat Jan 4 10:17:54 2014 From: gaetan at xeberon.net (Gaetan) Date: Sat, 4 Jan 2014 19:17:54 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: Message-ID: I m also interessed in writing a YAML loader/dumper for rust but i m still learning the language... Le 4 janv. 2014 19:00, "Flaper87" a ?crit : > > > > 2014/1/4 Corey Richardson > >> oslo.config looks decent. On some projects I've worked on, we started >> out using INI files but found them severely lacking once we wanted to >> extend the options. We ended up using libconfig[0], which I think is >> an excellent library. In multibuilder[1], we use extra::serialize to >> load a config directly into the struct we'll be using. It's super >> convenient, but a bit unfortunate in that it's impossible to make a >> field truly optional (Option requires the field to be null, iirc). >> >> [0] http://www.hyperrealm.com/libconfig/ >> [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 > > > I'm also considering to have support for several parsers. It should be > pretty simple / straightforward to do so. > > We could have a default parser based on INI files and then allow people to > specify a different parser in case INI files are not what they want to use. > I'll dive into libconfig and pick things from there as well. > > Also, I agree INI files could be a bit limited, which is why we ended up > having our own INI parser in oslo.config. > > Thoughts? > FF > > >> >> >> On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 wrote: >> > Hi Guys, >> > >> > I was looking around and I couldn't find a config file parser library >> for >> > Rust. Getopt support seems to be pretty complete and stable, which would >> > make the development of such library easier. >> > >> > Since I've some experience on this area, I thought about doing some >> work on >> > it for Rust. >> > >> > My current plan is to do something along the lines of oslo.config[0] - >> which >> > I've been contributing to - and take advantage of the existing getopt >> > module, just as we do in oslo.config. >> > >> > The config file format parsed by oslo.config follows the INI[1] files >> format >> > but with some changes to support list options and other types. One of >> the >> > advantages of this library is that the config options registration is >> > explicit and simple. >> > >> > However, before starting to work on this, I'd like to know what folks on >> > this list think about the library, if there's been some work on this >> area >> > that I'm not aware of, what the preferences are, etc. >> > >> > Cheers, >> > FF >> > >> > [0] https://github.com/openstack/oslo.config >> > [1] http://en.wikipedia.org/wiki/INI_file >> > >> > -- >> > Flavio (@flaper87) Percoco >> > http://www.flaper87.com >> > http://github.com/FlaPer87 >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > Flavio (@flaper87) Percoco > http://www.flaper87.com > http://github.com/FlaPer87 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan at vandals.uidaho.edu Sat Jan 4 10:28:05 2014 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Sat, 4 Jan 2014 10:28:05 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: <52C84C3B.2020304@ntecs.de> References: <52C84C3B.2020304@ntecs.de> Message-ID: <52C852B5.1020803@vandals.uidaho.edu> On 1/4/14 10:00 AM, Michael Neumann wrote: > > Am 04.01.2014 18:38, schrieb Corey Richardson: >> oslo.config looks decent. On some projects I've worked on, we started >> out using INI files but found them severely lacking once we wanted to >> extend the options. We ended up using libconfig[0], which I think is >> an excellent library. In multibuilder[1], we use extra::serialize to >> load a config directly into the struct we'll be using. It's super >> convenient, but a bit unfortunate in that it's impossible to make a >> field truly optional (Option requires the field to be null, iirc). >> >> [0] http://www.hyperrealm.com/libconfig/ >> [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 > > There is also TOML [1], an extended version of the INI config file format, > which is used by a variety of languages. > > [1]: https://github.com/mojombo/toml > > Regards, > > Michael > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > . > I've used YAML, JSON, and INI extensively for configuration, and I confess that each have their problems. I agree that TOML is an excellent idea (I wrote the Common Lisp TOML parser). I just don't know off-hand how widely its been picked up in the past year. -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From gaetan at xeberon.net Sat Jan 4 12:26:23 2014 From: gaetan at xeberon.net (Gaetan) Date: Sat, 4 Jan 2014 21:26:23 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: <52C852B5.1020803@vandals.uidaho.edu> References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: I m interessed on having your feedback on json and yaml vs toml for instance. Le 4 janv. 2014 19:28, "Paul Nathan" a ?crit : > On 1/4/14 10:00 AM, Michael Neumann wrote: > > > > Am 04.01.2014 18:38, schrieb Corey Richardson: > >> oslo.config looks decent. On some projects I've worked on, we started > >> out using INI files but found them severely lacking once we wanted to > >> extend the options. We ended up using libconfig[0], which I think is > >> an excellent library. In multibuilder[1], we use extra::serialize to > >> load a config directly into the struct we'll be using. It's super > >> convenient, but a bit unfortunate in that it's impossible to make a > >> field truly optional (Option requires the field to be null, iirc). > >> > >> [0] http://www.hyperrealm.com/libconfig/ > >> [1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68 > > > > There is also TOML [1], an extended version of the INI config file > format, > > which is used by a variety of languages. > > > > [1]: https://github.com/mojombo/toml > > > > Regards, > > > > Michael > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > . > > > > I've used YAML, JSON, and INI extensively for configuration, and I > confess that each have their problems. > > I agree that TOML is an excellent idea (I wrote the Common Lisp TOML > parser). I just don't know off-hand how widely its been picked up in > the past year. > > -- > Regards, > Paul > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sat Jan 4 12:30:34 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sat, 4 Jan 2014 12:30:34 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 12:26 PM, Gaetan wrote: > I m interessed on having your feedback on json and yaml vs toml for > instance. > JSON is ugly and token-ridden for configuration files. Having worked with tools that use it for this purpose, I find the configuration hard to read. Then there's the issue of comments, which are particularly important for configuration files. Some things have adopted JS-style comments for this purpose, but that's technically not standard JSON. YAML's problem is indentation errors can turn into configuration errors, and they're incredibly tricky to spot. I've run into cases where we didn't spot problems until we deployed to production because the "production" section of a configuration file was misindented. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mneumann at ntecs.de Sat Jan 4 12:32:54 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Sat, 04 Jan 2014 21:32:54 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: <52C86FF6.8030106@ntecs.de> Am 04.01.2014 21:30, schrieb Tony Arcieri: > On Sat, Jan 4, 2014 at 12:26 PM, Gaetan > wrote: > > I m interessed on having your feedback on json and yaml vs toml > for instance. > > JSON is ugly and token-ridden for configuration files. Having worked > with tools that use it for this purpose, I find the configuration hard > to read. Then there's the issue of comments, which are particularly > important for configuration files. Some things have adopted JS-style > comments for this purpose, but that's technically not standard JSON. > > YAML's problem is indentation errors can turn into configuration > errors, and they're incredibly tricky to spot. I've run into cases > where we didn't spot problems until we deployed to production because > the "production" section of a configuration file was misindented. And, I think it's pretty hard to write a YAML parser. The spec is pretty extensive. Whereas a TOML or INI parser, you can hack within a few hours. Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 4 12:35:11 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 4 Jan 2014 15:35:11 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 3:30 PM, Tony Arcieri wrote: > > YAML's problem is indentation errors can turn into configuration errors, and > they're incredibly tricky to spot. I've run into cases where we didn't spot > problems until we deployed to production because the "production" section of > a configuration file was misindented. I don't buy that. A text editor should be more than capable enough to stop you from slipping in tabs. If there's a separate untested configuration for production then you have a problem. YAML is really complex though and I think the ability to extend it is overkill. From bascule at gmail.com Sat Jan 4 12:39:23 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sat, 4 Jan 2014 12:39:23 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay wrote: > I don't buy that. A text editor should be more than capable enough to > stop you from slipping in tabs. If there's a separate untested > configuration for production then you have a problem. This isn't just a single offhand incident. It's something I've seen a pattern of happening dozens of times over the course of my career. It's happened to me personally, and I've seen it happen to others. Having separate configuration sections for different environments is a rather common convention in the Rails world. Is it a bad idea? Offhand I can't say: what would you replace it with? -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.meiklejohn at gmail.com Sat Jan 4 12:41:50 2014 From: christopher.meiklejohn at gmail.com (Christopher Meiklejohn) Date: Sat, 4 Jan 2014 15:41:50 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Jan 4, 2014, at 3:39 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay wrote: > I don't buy that. A text editor should be more than capable enough to > stop you from slipping in tabs. If there's a separate untested > configuration for production then you have a problem. > > This isn't just a single offhand incident. It's something I've seen a pattern of happening dozens of times over the course of my career. It's happened to me personally, and I've seen it happen to others. > > Having separate configuration sections for different environments is a rather common convention in the Rails world. Is it a bad idea? Offhand I can't say: what would you replace it with? Why not something that looks like sysctl [1] syntax? http://www5.us.freebsd.org/doc/handbook/configtuning-sysctl.html - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sat Jan 4 12:45:12 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 04 Jan 2014 12:45:12 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: <52C86FF6.8030106@ntecs.de> References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> <52C86FF6.8030106@ntecs.de> Message-ID: <4e1a6e6c-737f-43a1-aa34-d71b9914b148@email.android.com> I would love to have a TOML parser. I've always had a bit of a fondness for the INI format, despite its limitations, and TOML looks like the best of both worlds (the expressivity of JSON and the simplicity and readability of INI). Benchmarks of TOML parsing would be fun too :) Patrick Michael Neumann wrote: > >Am 04.01.2014 21:30, schrieb Tony Arcieri: >> On Sat, Jan 4, 2014 at 12:26 PM, Gaetan > > wrote: >> >> I m interessed on having your feedback on json and yaml vs toml >> for instance. >> >> JSON is ugly and token-ridden for configuration files. Having worked >> with tools that use it for this purpose, I find the configuration >hard >> to read. Then there's the issue of comments, which are particularly >> important for configuration files. Some things have adopted JS-style >> comments for this purpose, but that's technically not standard JSON. >> >> YAML's problem is indentation errors can turn into configuration >> errors, and they're incredibly tricky to spot. I've run into cases >> where we didn't spot problems until we deployed to production because > >> the "production" section of a configuration file was misindented. > >And, I think it's pretty hard to write a YAML parser. The spec is >pretty >extensive. Whereas a TOML or INI parser, you can hack within a few >hours. > >Regards, > > Michael > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at cmoz.me Sat Jan 4 12:59:22 2014 From: chris at cmoz.me (Chris Molozian) Date: Sat, 4 Jan 2014 20:59:22 +0000 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: I second the sysctl syntax it?s very easy to grep through configuration files in this format. The ?key? prefix contains the context for the information which is useful. i.e. ?riak_kv.anti_entropy_leveldb_opts.write_buffer_size? Riak, a distributed KV dynamo store has recently been moving to the sysctl format from the traditional Erlang `app.config` ?format". Cheers. --? Chris Molozian Software Engineer On 4 January 2014 at 20:41:59, Christopher Meiklejohn (christopher.meiklejohn at gmail.com) wrote: On Jan 4, 2014, at 3:39 PM, Tony Arcieri wrote: On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay wrote: I don't buy that. A text editor should be more than capable enough to stop you from slipping in tabs. If there's a separate untested configuration for production then you have a problem. This isn't just a single offhand incident. It's something I've seen a pattern of happening dozens of times over the course of my career. It's happened to me personally, and I've seen it happen to others. Having separate configuration sections for different environments is a rather common convention in the Rails world. Is it a bad idea? Offhand I can't say: what would you replace it with?? Why not something that looks like sysctl [1] syntax? http://www5.us.freebsd.org/doc/handbook/configtuning-sysctl.html - Chris _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn at masklinn.net Sat Jan 4 12:59:30 2014 From: masklinn at masklinn.net (Masklinn) Date: Sat, 4 Jan 2014 21:59:30 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: <4e1a6e6c-737f-43a1-aa34-d71b9914b148@email.android.com> References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> <52C86FF6.8030106@ntecs.de> <4e1a6e6c-737f-43a1-aa34-d71b9914b148@email.android.com> Message-ID: <3AD65D18-E74A-43A8-95C8-098A07EA1E16@masklinn.net> On 2014-01-04, at 21:45 , Patrick Walton wrote: > I would love to have a TOML parser. I've always had a bit of a fondness for the INI format, despite its limitations, and TOML looks like the best of both worlds (the expressivity of JSON and the simplicity and readability of INI). Well IIRC "ini" is undefined and basically a wild west aside from having bracket-enclosed section names. So for all intents and purposes TOML is a strict and well-defined ini dialect (compared to most ini dialects anyway). In fact I believe its original tagline was "TOML is like INI, only better". > Benchmarks of TOML parsing would be fun too :) > > Patrick From danielmicay at gmail.com Sat Jan 4 13:25:43 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 4 Jan 2014 16:25:43 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 3:39 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay > > This isn't just a single offhand incident. It's something I've seen a > pattern of happening dozens of times over the course of my career. It's > happened to me personally, and I've seen it happen to others. I can believe that people are using poor tooling, as I can't understand how a tab character would sneak in otherwise. It can be easily prevented at both the text editor and version control layers. Git can be asked to prevent commits with whitespace problems by enabling the default pre-commit hook and setting either tabs or space (and the width) in gitattributes. > Having separate configuration sections for different environments is a > rather common convention in the Rails world. Is it a bad idea? Offhand I > can't say: what would you replace it with? Testing what you plan on deploying, instead of something else. From bascule at gmail.com Sat Jan 4 13:35:00 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sat, 4 Jan 2014 13:35:00 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 1:25 PM, Daniel Micay wrote: > I can believe that people are using poor tooling, as I can't > understand how a tab character would sneak in otherwise. It can be > easily prevented at both the text editor and version control layers. > Git can be asked to prevent commits with whitespace problems by > enabling the default pre-commit hook and setting either tabs or space > (and the width) in gitattributes. > Believe it or not, not all problems of this nature can be caught by automatic tools, and this is particularly problematic in YAML. Let's look at a particular one, which is a *semantic* error in the structure of YAML which I don't think any automated tools can catch, but please, correct me if I'm wrong. What if the programmer intended to write: stuff: one: foo: - a - b bar: - c - d two: foo: - e - f bar: - g - h But instead wrote: stuff: one: foo: - a - b bar: - c - d two: foo: - e - f bar: - g - h ? How exactly would an automated tool spot this error? > Testing what you plan on deploying, instead of something else. > So if we're talking to a payment gateway, our automated tests should run against the live payment gateway? Surely you see there are many cases where this simply doesn't work. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 4 13:44:13 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 4 Jan 2014 16:44:13 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 4:35 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 1:25 PM, Daniel Micay wrote: >> >> I can believe that people are using poor tooling, as I can't >> understand how a tab character would sneak in otherwise. It can be >> easily prevented at both the text editor and version control layers. >> Git can be asked to prevent commits with whitespace problems by >> enabling the default pre-commit hook and setting either tabs or space >> (and the width) in gitattributes. > > > Believe it or not, not all problems of this nature can be caught by > automatic tools, and this is particularly problematic in YAML. Let's look at > a particular one, which is a *semantic* error in the structure of YAML which > I don't think any automated tools can catch, but please, correct me if I'm > wrong. > > What if the programmer intended to write: > > stuff: > one: > foo: > - a > - b > bar: > - c > - d > two: > foo: > - e > - f > bar: > - g > - h > > But instead wrote: > > stuff: > one: > foo: > - a > - b > bar: > - c > - d > two: > foo: > - e > - f > bar: > - g > - h > > ? Not much of a problem with 8-space indents. This is not really any different than messing up brace nesting. If you go out of the way to obfuscate the code with 2-space indents then it's a problem. > So if we're talking to a payment gateway, our automated tests should run > against the live payment gateway? Surely you see there are many cases where > this simply doesn't work. I don't really. Wouldn't you want to test that it works with some dummy accounts after you've done testing against a mocked one? From bascule at gmail.com Sat Jan 4 13:47:57 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sat, 4 Jan 2014 13:47:57 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 1:44 PM, Daniel Micay wrote: > This is not really any different than messing up brace nesting. > Except brace nesting gives you more tokens from which someone reviewing your configuration can spot the error. A strict superset, at that, if you're indenting your code correctly anyway. Anyway, that's my two cents. I am not a fan of whitespace sensitivity. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan at vandals.uidaho.edu Sat Jan 4 13:52:52 2014 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Sat, 4 Jan 2014 13:52:52 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: <52C882B4.3050006@vandals.uidaho.edu> On 1/4/14 12:30 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 12:26 PM, Gaetan > wrote: > > I m interessed on having your feedback on json and yaml vs toml for > instance. > > JSON is ugly and token-ridden for configuration files. Having worked > with tools that use it for this purpose, I find the configuration hard > to read. Then there's the issue of comments, which are particularly > important for configuration files. Some things have adopted JS-style > comments for this purpose, but that's technically not standard JSON. > All of this is true. Further, JSON is very fiddly and sensitive to typos (e.g., spare " and ,) , which is something that does not play well with many users, who are not used to or comfortable with that level of syntax rigor. > YAML's problem is indentation errors can turn into configuration errors, > and they're incredibly tricky to spot. I've run into cases where we > didn't spot problems until we deployed to production because the > "production" section of a configuration file was misindented. This is also my experience: making or using a tool to do special-purpose editing of plaintext files sits ill with me. TOML is very like INI, but includes hierarchical capabilities, which is one of the cardinal problems with INI. TOML has a spec, unlike INI, which is nice. TOML is also similar in concept to YAML, but has certain variances - It is not whitespace-delimited (unlike YAML), which makes it simple to parse and visually edit by hand. YAML is reputed to be fairly insecure, something which would be good to avoid even the possibility of out of the gate[1]. TOML also specifies types out of the gate and covers certain gaps in JSON capabilities in this regards (I don't remember YAML here one way or another). And a final word - IMO it's better to have a system where it's harder to shoot yourself in the foot. TOML and INI are roughly at the same level here. JSON and YAML are a little easier to make mistakes with IME. [1] http://blogs.teamb.com/craigstuntz/2013/02/04/38738/ -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Sat Jan 4 13:53:45 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 4 Jan 2014 16:53:45 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 4:47 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 1:44 PM, Daniel Micay wrote: >> >> This is not really any different than messing up brace nesting. > > Except brace nesting gives you more tokens from which someone reviewing your > configuration can spot the error. A strict superset, at that, if you're > indenting your code correctly anyway. The problem being that only the braces matter, not the indentation. Perhaps a missing brace is easier to see than a missing 8 space indent or tab for some people, but not for me. From bascule at gmail.com Sat Jan 4 14:00:21 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sat, 4 Jan 2014 14:00:21 -0800 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 1:53 PM, Daniel Micay wrote: > The problem being that only the braces matter, not the indentation. > Perhaps a missing brace is easier to see than a missing 8 space indent > or tab for some people, but not for me. > And what do you do if you're editing another YAML file that someone started with 2-space tabs? Do you convert everything to 8? Use 8-space tabs just for your stuff and leave the rest of the file with 2-space tabs? I would venture to guess that 8-space YAML files are exceedingly uncommon. I'd also say 8-space tabs are ugly. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 4 14:04:38 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 4 Jan 2014 17:04:38 -0500 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: On Sat, Jan 4, 2014 at 5:00 PM, Tony Arcieri wrote: > On Sat, Jan 4, 2014 at 1:53 PM, Daniel Micay wrote: >> >> The problem being that only the braces matter, not the indentation. >> Perhaps a missing brace is easier to see than a missing 8 space indent >> or tab for some people, but not for me. > > > And what do you do if you're editing another YAML file that someone started > with 2-space tabs? Do you convert everything to 8? Use 8-space tabs just for > your stuff and leave the rest of the file with 2-space tabs? About as useful as saying non-YAML formats are less common, so all hope is lost because you don't like YAML. > I would venture to guess that 8-space YAML files are exceedingly uncommon. > > I'd also say 8-space tabs are ugly. I'd say that they're far nicer than braces and encourage splitting up the code/data sanely. Lots of nesting is hard to deal with, and 8-space indents discourage it. From gaetan at xeberon.net Sat Jan 4 16:39:45 2014 From: gaetan at xeberon.net (Gaetan) Date: Sun, 5 Jan 2014 01:39:45 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: <52C84C3B.2020304@ntecs.de> <52C852B5.1020803@vandals.uidaho.edu> Message-ID: Thanks for your answer. I think having reference parsers for majors format is a top feature for the rust standard lib. Json is pretty standard in web world, and yaml is pretty simple replacement for XML but lack schema standard. So if rust provides Json, yaml, ini, toml and why not other config storage/exchange standards, that will surely attack many developpers, but i recommend to have a certain homogeneity in the API. I ve used yaml for quite long time, and indeed indentation can be an issue, but that the same with Python code.... I am not fan with indentation meaning nesting, but yaml is much simpler for me to use than Json. Le 4 janv. 2014 21:59, "Chris Molozian" a ?crit : > I second the sysctl syntax it?s very easy to grep through configuration > files in this format. The ?key? prefix contains the context for the > information which is useful. > > i.e. ?riak_kv.anti_entropy_leveldb_opts.write_buffer_size? > > Riak, a distributed KV dynamo store has recently been moving to the sysctl > format from the traditional Erlang `app.config` ?format". > > Cheers. > > -- > Chris Molozian > Software Engineer > > On 4 January 2014 at 20:41:59, Christopher Meiklejohn ( > christopher.meiklejohn at gmail.com) wrote: > > On Jan 4, 2014, at 3:39 PM, Tony Arcieri wrote: > > On Sat, Jan 4, 2014 at 12:35 PM, Daniel Micay wrote: > >> I don't buy that. A text editor should be more than capable enough to >> stop you from slipping in tabs. If there's a separate untested >> configuration for production then you have a problem. > > > This isn't just a single offhand incident. It's something I've seen a > pattern of happening dozens of times over the course of my career. It's > happened to me personally, and I've seen it happen to others. > > Having separate configuration sections for different environments is a > rather common convention in the Rails world. Is it a bad idea? Offhand I > can't say: what would you replace it with? > > > Why not something that looks like sysctl [1] syntax? > > http://www5.us.freebsd.org/doc/handbook/configtuning-sysctl.html > > - Chris > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- ----- Gaetan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mneumann at ntecs.de Sun Jan 5 17:45:01 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Mon, 06 Jan 2014 02:45:01 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: References: Message-ID: <52CA0A9D.20404@ntecs.de> Am 04.01.2014 15:01, schrieb Flaper87: > Hi Guys, > > I was looking around and I couldn't find a config file parser library > for Rust. Getopt support seems to be pretty complete and stable, which > would make the development of such library easier. There is now a TOML parser for Rust [1] :) [1]: https://github.com/mneumann/rust-toml Regards, Michael From greg at kinostudios.com Sun Jan 5 18:11:16 2014 From: greg at kinostudios.com (Greg) Date: Sun, 5 Jan 2014 21:11:16 -0500 Subject: [rust-dev] Emscripten for Rust? Message-ID: I'd happy chip in for a Kickstarter-type project to automatically convert C/C++ to Rust. Anything like this exists or anyone planning on making this type of announcement? - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From corey at octayn.net Sun Jan 5 18:21:03 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 5 Jan 2014 21:21:03 -0500 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: Message-ID: Any such conversion is going to be lossy enough as to be worthless. It's only acceptable for emscripten because the web platform can't run native code. But any use of Rust is already going to be targetting something that can run C. On Sun, Jan 5, 2014 at 9:11 PM, Greg wrote: > I'd happy chip in for a Kickstarter-type project to automatically convert > C/C++ to Rust. > > Anything like this exists or anyone planning on making this type of > announcement? > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing > with the NSA. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From ben.striegel at gmail.com Sun Jan 5 18:21:09 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Sun, 5 Jan 2014 21:21:09 -0500 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: Message-ID: I'm not sure if this is generally feasible! If memory-unsafe C/C++ code could be automatically and mechanically converted to memory-safe Rust code, then that would imply the existence of static analysis tools for C/C++ code that could themselves guarantee memory safety without requiring Rust at all. On Sun, Jan 5, 2014 at 9:11 PM, Greg wrote: > I'd happy chip in for a Kickstarter-type project to automatically convert > C/C++ to Rust. > > Anything like this exists or anyone planning on making this type of > announcement? > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sun Jan 5 18:25:41 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Mon, 06 Jan 2014 13:25:41 +1100 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: Message-ID: <52CA1425.4080009@gmail.com> On first glance it seems like C -> Rust would be very feasible via a lot of `unsafe`, * and *mut. On 06/01/14 13:21, Corey Richardson wrote: > Any such conversion is going to be lossy enough as to be worthless. > It's only acceptable for emscripten because the web platform can't run > native code. But any use of Rust is already going to be targetting > something that can run C. > > On Sun, Jan 5, 2014 at 9:11 PM, Greg wrote: >> I'd happy chip in for a Kickstarter-type project to automatically convert >> C/C++ to Rust. >> >> Anything like this exists or anyone planning on making this type of >> announcement? >> >> - Greg >> >> -- >> Please do not email me anything that you are not comfortable also sharing >> with the NSA. >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Sun Jan 5 18:28:47 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 5 Jan 2014 21:28:47 -0500 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: <52CA1425.4080009@gmail.com> References: <52CA1425.4080009@gmail.com> Message-ID: Much of it would be. But why? On Sun, Jan 5, 2014 at 9:25 PM, Huon Wilson wrote: > On first glance it seems like C -> Rust would be very feasible via a lot of > `unsafe`, * and *mut. > > > > On 06/01/14 13:21, Corey Richardson wrote: >> >> Any such conversion is going to be lossy enough as to be worthless. >> It's only acceptable for emscripten because the web platform can't run >> native code. But any use of Rust is already going to be targetting >> something that can run C. >> >> On Sun, Jan 5, 2014 at 9:11 PM, Greg wrote: >>> >>> I'd happy chip in for a Kickstarter-type project to automatically convert >>> C/C++ to Rust. >>> >>> Anything like this exists or anyone planning on making this type of >>> announcement? >>> >>> - Greg >>> >>> -- >>> Please do not email me anything that you are not comfortable also sharing >>> with the NSA. >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From me at kevincantu.org Sun Jan 5 19:47:09 2014 From: me at kevincantu.org (Kevin Cantu) Date: Sun, 5 Jan 2014 19:47:09 -0800 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: <52CA1425.4080009@gmail.com> Message-ID: It would provide a nice migration path. And a way to guarantee that your nice Rust program had some terrible unsupported legacy C for the next decade or two. ;D Kevin On Sun, Jan 5, 2014 at 6:28 PM, Corey Richardson wrote: > Much of it would be. But why? > > On Sun, Jan 5, 2014 at 9:25 PM, Huon Wilson wrote: >> On first glance it seems like C -> Rust would be very feasible via a lot of >> `unsafe`, * and *mut. >> >> >> >> On 06/01/14 13:21, Corey Richardson wrote: >>> >>> Any such conversion is going to be lossy enough as to be worthless. >>> It's only acceptable for emscripten because the web platform can't run >>> native code. But any use of Rust is already going to be targetting >>> something that can run C. >>> >>> On Sun, Jan 5, 2014 at 9:11 PM, Greg wrote: >>>> >>>> I'd happy chip in for a Kickstarter-type project to automatically convert >>>> C/C++ to Rust. >>>> >>>> Anything like this exists or anyone planning on making this type of >>>> announcement? >>>> >>>> - Greg >>>> >>>> -- >>>> Please do not email me anything that you are not comfortable also sharing >>>> with the NSA. >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From bascule at gmail.com Sun Jan 5 20:07:11 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 5 Jan 2014 20:07:11 -0800 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: Message-ID: Just wait until they write RustMonkey for Servo, then you can run your Emscriptened C++ inside of that On Sun, Jan 5, 2014 at 6:11 PM, Greg wrote: > I'd happy chip in for a Kickstarter-type project to automatically convert > C/C++ to Rust. > > Anything like this exists or anyone planning on making this type of > announcement? > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.boggiano at seld.be Sun Jan 5 23:49:58 2014 From: j.boggiano at seld.be (Jordi Boggiano) Date: Mon, 06 Jan 2014 08:49:58 +0100 Subject: [rust-dev] Configuration files library for Rust In-Reply-To: <52CA0A9D.20404@ntecs.de> References: <52CA0A9D.20404@ntecs.de> Message-ID: <52CA6026.60402@seld.be> On 06/01/2014 02:45, Michael Neumann wrote: >> I was looking around and I couldn't find a config file parser library >> for Rust. Getopt support seems to be pretty complete and stable, which >> would make the development of such library easier. > > There is now a TOML parser for Rust [1] :) Thanks! /me crosses item off the todo list Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From mneumann at ntecs.de Mon Jan 6 06:57:50 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Mon, 06 Jan 2014 15:57:50 +0100 Subject: [rust-dev] [ANN] rust-toml - TOML configuration file parser Message-ID: <52CAC46E.3030004@ntecs.de> Hi all, rust-toml [1] is TOML [2] configuration file parser :) Regards, Michael [1]: https://github.com/mneumann/rust-toml [2]: https://github.com/mojombo/toml From chris at cmoz.me Mon Jan 6 07:29:04 2014 From: chris at cmoz.me (Chris Molozian) Date: Mon, 6 Jan 2014 08:29:04 -0700 Subject: [rust-dev] [ANN] rust-toml - TOML configuration file parser In-Reply-To: <52CAC46E.3030004@ntecs.de> References: <52CAC46E.3030004@ntecs.de> Message-ID: Nice work! :) FWIW, the license text in the README talks about a different project: ??" rust-redis is under the MIT license, see LICENSE-MIT for details. Copyright (c) 2014 by Michael Neumann. ??? Also, it?d be nice to get this on Rust CI:?http://www.rust-ci.org/ Cheers, Chris --? Chris Molozian Software Engineer On 6 January 2014 at 07:58:01, Michael Neumann (mneumann at ntecs.de) wrote: Hi all, rust-toml [1] is TOML [2] configuration file parser :) Regards, Michael [1]: https://github.com/mneumann/rust-toml [2]: https://github.com/mojombo/toml _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.ronacher at active-4.com Mon Jan 6 07:56:34 2014 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Mon, 06 Jan 2014 15:56:34 +0000 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack In-Reply-To: <52C833CD.5030303@ntecs.de> References: <52C83364.7020500@ntecs.de> <52C833CD.5030303@ntecs.de> Message-ID: <52CAD232.7070908@active-4.com> Hi, On 04/01/2014 16:16, Michael Neumann wrote: >> rust-redis: A Redis client library written in pure Rust. Thanks to the new >> rust runtime >> it is pretty fast, despite being only 200 lines of code. Just compared that with the one I'm working on (https://github.com/mitsuhiko/redis-rs/) and maybe we can unify those two into one. I plan on continue maintaining mine for a long time to come as I'm using redis very frequently. My biggest issue currently with continue working on it, is that I want to replicate the pipeline functionality from the Python and JavaScript implementation but I can't see a way of doing that in Rust without having to manually generate code. Macros are not going to be particularly useful. Primarily the issue is that on the client you want this: fn get(&mut self, key: ~str) -> ~str { value_as_string(self.execute("GET", [StrArg(key)])) } but on the pipeline you want this behavior: let rv = client.pipeline() .get("my_key") .tap(|s| println!("I got a string: {}", s) .get("another_key") .execute(); for result in rv { println!("I got result: {}", result); } I am not sure yet how to do this nicely without repeating a lot of code (also I have no idea how to make .tap() work). Regards, Armin From mneumann at ntecs.de Mon Jan 6 09:00:29 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Mon, 06 Jan 2014 18:00:29 +0100 Subject: [rust-dev] [ANN] rust-redis and rust-msgpack In-Reply-To: <52C84ECD.1090709@mozilla.com> References: <52C83364.7020500@ntecs.de> <52C833CD.5030303@ntecs.de> <52C84ECD.1090709@mozilla.com> Message-ID: <52CAE12D.1090003@ntecs.de> Am 04.01.2014 19:11, schrieb Patrick Walton: > On 1/4/14 8:16 AM, Michael Neumann wrote: >>> rust-msgpack: Fully featured and high performance msgpack >>> implementation for Rust. >>> >>> Both work with rust 0.9-pre. >> >> Too stupid/sleepy that I forgot the links: >> >> http://github.com/mneumann/rust-redis >> http://github.com/mneumann/rust-msgpack > > Sweet! msgpack might be a good IPC format for Servo. Give it a try :) It's very efficient, both in storage and speed. Regards, Michael From greg at kinostudios.com Mon Jan 6 09:21:23 2014 From: greg at kinostudios.com (Greg) Date: Mon, 6 Jan 2014 12:21:23 -0500 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: References: Message-ID: <1C24BF95-E8AB-4D03-A676-59A3C3F6DCFC@kinostudios.com> Hmm. I don't think that's quite what I'm looking for. I'm not interested in converting C++ to JS, but C++ to Rust. I think the skepticism expressed in other replies is unwarranted. Between the sort of static analysis that LLVM & Xcode do, along with feedback from a human developer, something could definitely be done to greatly speed up the porting of C++ programs to Rust, and I think many people would love to have that, including the wonderful folks at Mozilla. :-) -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jan 5, 2014, at 11:07 PM, Tony Arcieri wrote: > Just wait until they write RustMonkey for Servo, then you can run your Emscriptened C++ inside of that > > > On Sun, Jan 5, 2014 at 6:11 PM, Greg wrote: > I'd happy chip in for a Kickstarter-type project to automatically convert C/C++ to Rust. > > Anything like this exists or anyone planning on making this type of announcement? > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing with the NSA. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From douglas.linder at gmail.com Sat Jan 4 22:13:28 2014 From: douglas.linder at gmail.com (Doug) Date: Sun, 5 Jan 2014 14:13:28 +0800 Subject: [rust-dev] Using CMake with Rust In-Reply-To: <52C4F9E2.1070702@aim.com> References: <52C4EA82.1050706@aim.com> <52C4F397.3070104@gmail.com> <52C4F9E2.1070702@aim.com> Message-ID: For what it's worth, your rust cmake example currently seems to work with ninja, which is brilliant. My vote definitely goes for your current approach; I tried to implement a C# module for cmake some time ago using the other method, and ran into similar sorts of issues (specifically with various variables only being supported by Makefile builds in cmake). ~ Doug. On Thu, Jan 2, 2014 at 1:32 PM, SiegeLord wrote: > On 01/02/2014 12:05 AM, Gy?rgy Andrasek wrote: > >> The proper way to support a language in CMake is outlined in >> `Modules/CMakeAddNewLanguage.txt`: >> > > I was guided away from that method by this email: http://www.cmake.org/ > pipermail/cmake/2011-March/043444.html . My approach is amenable to > generating files for alternative build systems, like ninja. If you are > aware that that email is incorrect, I'm glad to be corrected. Independently > of that email, I have looked into doing it that way, but I found that it > just did not mesh with the Rust compilation model, and I saw no clear way > to using the information given by 'rustc --dep-info' to inform the build > system. Additionally, my macros allow an easy way of doing documentation > generation, which that method doesn't clearly allow. > > I'll be glad to be corrected on all those points though. > > -SL > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at kinostudios.com Mon Jan 6 11:45:43 2014 From: greg at kinostudios.com (Greg) Date: Mon, 6 Jan 2014 14:45:43 -0500 Subject: [rust-dev] C/C++ to Rust cross-compiler [Re: Emscripten for Rust?] In-Reply-To: <1C24BF95-E8AB-4D03-A676-59A3C3F6DCFC@kinostudios.com> References: <1C24BF95-E8AB-4D03-A676-59A3C3F6DCFC@kinostudios.com> Message-ID: <42CDE7DB-446E-4285-AE0B-4E48873A90FF@kinostudios.com> Someone very helpfully pointed out the following to me offlist, and so I've changed the subject of the thread: The word you're looking for is a 'cross compiler' or 'transpiler.' Saying "emscripten" calls forth an image of a transpiler _to_ JavaScript. I think this would be super neat, but as was previously said, possibly too lossy to be useful. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jan 6, 2014, at 12:21 PM, Greg wrote: > Hmm. I don't think that's quite what I'm looking for. I'm not interested in converting C++ to JS, but C++ to Rust. > > I think the skepticism expressed in other replies is unwarranted. Between the sort of static analysis that LLVM & Xcode do, along with feedback from a human developer, something could definitely be done to greatly speed up the porting of C++ programs to Rust, and I think many people would love to have that, including the wonderful folks at Mozilla. :-) > > -- > Please do not email me anything that you are not comfortable also sharing with the NSA. > > On Jan 5, 2014, at 11:07 PM, Tony Arcieri wrote: > >> Just wait until they write RustMonkey for Servo, then you can run your Emscriptened C++ inside of that >> >> >> On Sun, Jan 5, 2014 at 6:11 PM, Greg wrote: >> I'd happy chip in for a Kickstarter-type project to automatically convert C/C++ to Rust. >> >> Anything like this exists or anyone planning on making this type of announcement? >> >> - Greg >> >> -- >> Please do not email me anything that you are not comfortable also sharing with the NSA. >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> >> -- >> Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From martindemello at gmail.com Mon Jan 6 11:46:59 2014 From: martindemello at gmail.com (Martin DeMello) Date: Mon, 6 Jan 2014 11:46:59 -0800 Subject: [rust-dev] Emscripten for Rust? In-Reply-To: <1C24BF95-E8AB-4D03-A676-59A3C3F6DCFC@kinostudios.com> References: <1C24BF95-E8AB-4D03-A676-59A3C3F6DCFC@kinostudios.com> Message-ID: I think it would be more useful to extend rust-bindgen to support c++, and work from there. dobkeratops has done some work on this already: https://github.com/dobkeratops/rust-bindgen/tree/cpptemplate martin On Mon, Jan 6, 2014 at 9:21 AM, Greg wrote: > Hmm. I don't think that's quite what I'm looking for. I'm not interested in > converting C++ to JS, but C++ to Rust. > > I think the skepticism expressed in other replies is unwarranted. Between > the sort of static analysis that LLVM & Xcode do, along with feedback from a > human developer, something could definitely be done to greatly speed up the > porting of C++ programs to Rust, and I think many people would love to have > that, including the wonderful folks at Mozilla. :-) > > -- > Please do not email me anything that you are not comfortable also sharing > with the NSA. > > On Jan 5, 2014, at 11:07 PM, Tony Arcieri wrote: > > Just wait until they write RustMonkey for Servo, then you can run your > Emscriptened C++ inside of that > > > On Sun, Jan 5, 2014 at 6:11 PM, Greg wrote: >> >> I'd happy chip in for a Kickstarter-type project to automatically convert >> C/C++ to Rust. >> >> Anything like this exists or anyone planning on making this type of >> announcement? >> >> - Greg >> >> -- >> Please do not email me anything that you are not comfortable also sharing >> with the NSA. >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > Tony Arcieri > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From mneumann at ntecs.de Tue Jan 7 07:37:36 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Tue, 07 Jan 2014 16:37:36 +0100 Subject: [rust-dev] Porting rust to DragonFlyBSD Message-ID: <52CC1F40.4010602@ntecs.de> Hi there, At the moment rust "only" supports Linux/FreeBSD/Windows/MacOSX. I'd like to be able to compile it on DragonFlyBSD [1]. I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet with no success. Is it possible to generate a static rustc binary somehow? Or what in general is the procedure to "port" rustc to a different platform? Regards, Michael [1]: http://www.dragonflybsd.org/ From alex at crichton.co Tue Jan 7 08:10:22 2014 From: alex at crichton.co (Alex Crichton) Date: Tue, 7 Jan 2014 08:10:22 -0800 Subject: [rust-dev] Porting rust to DragonFlyBSD In-Reply-To: <52CC1F40.4010602@ntecs.de> References: <52CC1F40.4010602@ntecs.de> Message-ID: The snapshots themselves are all "static binaries" in the sense that they have no dynamic rust dependencies and only the "necessary" system dependencies. Rustc does not generate 0-dependency static binaries right now that depend on libstd (as that would involve rewriting libc and writing a syscall interface for all platforms). When porting to a new architecture, the general idea is to add support in the compiler and standard libraries, then use cross compilation from a supported platform to generate a snapshot for the target platform, then take the snapshot and bootstrap on the target platform. A new platform hasn't shown up in awhile, but this sounds pretty cool! On Tue, Jan 7, 2014 at 7:37 AM, Michael Neumann wrote: > Hi there, > > At the moment rust "only" supports Linux/FreeBSD/Windows/MacOSX. I'd like to > be > able to compile it on DragonFlyBSD [1]. > > I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet > with no success. > Is it possible to generate a static rustc binary somehow? Or what in general > is the procedure > to "port" rustc to a different platform? > > Regards, > > Michael > > [1]: http://www.dragonflybsd.org/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From lists at ncameron.org Tue Jan 7 11:30:44 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 8 Jan 2014 08:30:44 +1300 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A23660.5040500@exyr.org> References: <52A23660.5040500@exyr.org> Message-ID: I agree with Simon that doubling the API is inelegant. I think the solution is adding sugar to make working with Option/Result easier - (semi-)independent of the foo/foo_opt issue, I find working with Option pretty painful. I prefer the Haskell do sugar to refutable patterns in let. Similar in spirit is the ? operator from Groovy, which I think is elegant and simple, it is an alternative to the . operator for field access/method call. In Rust it would have the following type and semantics: \Gamma e : Option fType(T', f) = T ------------------------------------ \Gamma e?f : Option e?f ~~> match e { Some => Some, None => None } and similarly for method call. The ? operator has the same advantages and disadvantages as Haskell's do, but is more concise. Just another alternative to consider. On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: > We have some functions and methods such as [std::str::from_utf8](http:// > static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may > succeed and give a result, or fail when the input is invalid. > > 1. Sometimes we assume the input is valid and don?t want to deal with the > error case. Task failure works nicely. > > 2. Sometimes we do want to do something different on invalid input, so > returning an `Option` works best. > > And so we end up with both `from_utf8` and `from_utf8`. This particular > case is worse because we also have `from_utf8_owned` and > `from_utf8_owned_opt`, to cover everything. > > Multiplying names like this is just not good design. I?d like to reduce > this pattern. > > Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the > Option. I think we should rename every `foo_opt()` function or method to > just `foo`, remove the old `foo()` behavior, and tell people (through > documentation) to use `foo().unwrap()` if they want it back? > > The downsides are that unwrap is more verbose and gives less helpful error > messages on task failure. But I think it?s worth it. > > What do you think? > > (PS: I?m guilty of making this worse in #10828, but I?d like to discuss > this before sending pull requests with invasive API changes.) > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Tue Jan 7 11:35:30 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 7 Jan 2014 13:35:30 -0600 Subject: [rust-dev] Porting rust to DragonFlyBSD In-Reply-To: References: <52CC1F40.4010602@ntecs.de> Message-ID: I am VERY interested in the support of this platform, DragonFlyBSD. Which is a great "Systems OS" in and of itself. Thanks for your future efforts on it, Michael ! (BTW, in particular, I am interested in access to the HAMMER File System on DragonFlyBSD to begin my experiments) On Tue, Jan 7, 2014 at 10:10 AM, Alex Crichton wrote: > The snapshots themselves are all "static binaries" in the sense that > they have no dynamic rust dependencies and only the "necessary" system > dependencies. Rustc does not generate 0-dependency static binaries > right now that depend on libstd (as that would involve rewriting libc > and writing a syscall interface for all platforms). > > When porting to a new architecture, the general idea is to add support > in the compiler and standard libraries, then use cross compilation > from a supported platform to generate a snapshot for the target > platform, then take the snapshot and bootstrap on the target platform. > > A new platform hasn't shown up in awhile, but this sounds pretty cool! > > On Tue, Jan 7, 2014 at 7:37 AM, Michael Neumann wrote: > > Hi there, > > > > At the moment rust "only" supports Linux/FreeBSD/Windows/MacOSX. I'd > like to > > be > > able to compile it on DragonFlyBSD [1]. > > > > I am trying to get the FreeBSD stage0/bin/rustc to run on DragonFly, yet > > with no success. > > Is it possible to generate a static rustc binary somehow? Or what in > general > > is the procedure > > to "port" rustc to a different platform? > > > > Regards, > > > > Michael > > > > [1]: http://www.dragonflybsd.org/ > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Tue Jan 7 16:42:49 2014 From: vadimcn at gmail.com (Vadim) Date: Tue, 7 Jan 2014 16:42:49 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: I can see how '?.' would work when foo() returns a struct, but what about non-struct types, e.g. Option ? Also, you'd still have to deal with 'None' at the end of the chain. I think in most cases I'd rather have it fail. I also don't really like refutable let-patterns proposal, because stuff like "let Some(x) = foo();" does not work with chaining when foo() returns a struct (and is still pretty wordy). Maybe we need an operator for "getting wrapped value"? This would be similar to "deref" for [smart]pointers, except I think it should be a postfix operator to allow for easy chaining. Let's say we chose '^' for this purpose, and implemented its' trait for Option, Result, etc. Then one could write: let x = foo()^; or let y = foo()^.field; Vadim On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron wrote: > I agree with Simon that doubling the API is inelegant. I think the > solution is adding sugar to make working with Option/Result easier - > (semi-)independent of the foo/foo_opt issue, I find working with Option > pretty painful. > > I prefer the Haskell do sugar to refutable patterns in let. Similar in > spirit is the ? operator from Groovy, which I think is elegant and simple, > it is an alternative to the . operator for field access/method call. In > Rust it would have the following type and semantics: > > \Gamma e : Option > fType(T', f) = T > ------------------------------------ > \Gamma e?f : Option > > e?f ~~> match e { Some => Some, None => None } > > and similarly for method call. > > The ? operator has the same advantages and disadvantages as Haskell's do, > but is more concise. > > Just another alternative to consider. > > > On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: > >> We have some functions and methods such as [std::str::from_utf8](http:// >> static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may >> succeed and give a result, or fail when the input is invalid. >> >> 1. Sometimes we assume the input is valid and don?t want to deal with the >> error case. Task failure works nicely. >> >> 2. Sometimes we do want to do something different on invalid input, so >> returning an `Option` works best. >> >> And so we end up with both `from_utf8` and `from_utf8`. This particular >> case is worse because we also have `from_utf8_owned` and >> `from_utf8_owned_opt`, to cover everything. >> >> Multiplying names like this is just not good design. I?d like to reduce >> this pattern. >> >> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on >> the Option. I think we should rename every `foo_opt()` function or method >> to just `foo`, remove the old `foo()` behavior, and tell people (through >> documentation) to use `foo().unwrap()` if they want it back? >> >> The downsides are that unwrap is more verbose and gives less helpful >> error messages on task failure. But I think it?s worth it. >> >> What do you think? >> >> (PS: I?m guilty of making this worse in #10828, but I?d like to discuss >> this before sending pull requests with invasive API changes.) >> >> -- >> Simon Sapin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Tue Jan 7 18:39:24 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 8 Jan 2014 15:39:24 +1300 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: I think that you eventually have to deal with the Some or None-ness of an expression is an advantage of the ? operator, it means you can't ignore failure, but you don't have to deal with it at every step of a compound expression. Using an operator for unwrap has the same disadvantage as plain unwrap - it lets you ignore the failure case. On Wed, Jan 8, 2014 at 1:42 PM, Vadim wrote: > I can see how '?.' would work when foo() returns a struct, but what about > non-struct types, e.g. Option ? Also, you'd still have to deal with > 'None' at the end of the chain. I think in most cases I'd rather have it > fail. > > I also don't really like refutable let-patterns proposal, because stuff > like "let Some(x) = foo();" does not work with chaining when foo() returns > a struct (and is still pretty wordy). > > Maybe we need an operator for "getting wrapped value"? This would be > similar to "deref" for [smart]pointers, except I think it should be a > postfix operator to allow for easy chaining. Let's say we chose '^' for > this purpose, and implemented its' trait for Option, Result, etc. Then one > could write: > let x = foo()^; > or > let y = foo()^.field; > > Vadim > > > > On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron wrote: > >> I agree with Simon that doubling the API is inelegant. I think the >> solution is adding sugar to make working with Option/Result easier - >> (semi-)independent of the foo/foo_opt issue, I find working with Option >> pretty painful. >> >> I prefer the Haskell do sugar to refutable patterns in let. Similar in >> spirit is the ? operator from Groovy, which I think is elegant and simple, >> it is an alternative to the . operator for field access/method call. In >> Rust it would have the following type and semantics: >> >> \Gamma e : Option >> fType(T', f) = T >> ------------------------------------ >> \Gamma e?f : Option >> >> e?f ~~> match e { Some => Some, None => None } >> >> and similarly for method call. >> >> The ? operator has the same advantages and disadvantages as Haskell's do, >> but is more concise. >> >> Just another alternative to consider. >> >> >> On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: >> >>> We have some functions and methods such as [std::str::from_utf8](http:// >>> static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may >>> succeed and give a result, or fail when the input is invalid. >>> >>> 1. Sometimes we assume the input is valid and don?t want to deal with >>> the error case. Task failure works nicely. >>> >>> 2. Sometimes we do want to do something different on invalid input, so >>> returning an `Option` works best. >>> >>> And so we end up with both `from_utf8` and `from_utf8`. This particular >>> case is worse because we also have `from_utf8_owned` and >>> `from_utf8_owned_opt`, to cover everything. >>> >>> Multiplying names like this is just not good design. I?d like to reduce >>> this pattern. >>> >>> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on >>> the Option. I think we should rename every `foo_opt()` function or method >>> to just `foo`, remove the old `foo()` behavior, and tell people (through >>> documentation) to use `foo().unwrap()` if they want it back? >>> >>> The downsides are that unwrap is more verbose and gives less helpful >>> error messages on task failure. But I think it?s worth it. >>> >>> What do you think? >>> >>> (PS: I?m guilty of making this worse in #10828, but I?d like to discuss >>> this before sending pull requests with invasive API changes.) >>> >>> -- >>> Simon Sapin >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Tue Jan 7 19:31:16 2014 From: vadimcn at gmail.com (Vadim) Date: Tue, 7 Jan 2014 19:31:16 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: On Tue, Jan 7, 2014 at 6:39 PM, Nick Cameron wrote: > I think that you eventually have to deal with the Some or None-ness of an > expression is an advantage of the ? operator, it means you can't ignore > failure, but you don't have to deal with it at every step of a compound > expression. Using an operator for unwrap has the same disadvantage as plain > unwrap - it lets you ignore the failure case. > First of all, it does not let me ignore errors - if I try to unwrap() a None, it will kill my program (or at least the current task). Whether this is what I want, depends on the use case. In my experience, more often than not, an error returned by an API represents a bug in the program. So what am I gonna do when I see that something has error'ed out? I will probably just call fail!(). Anyways, I think this thread was about how to avoid having both foo() and foo_opt() versions of every API, and many people (including myself), consider unwrap() too noisy. So... Vadim > > On Wed, Jan 8, 2014 at 1:42 PM, Vadim wrote: > >> I can see how '?.' would work when foo() returns a struct, but what about >> non-struct types, e.g. Option ? Also, you'd still have to deal with >> 'None' at the end of the chain. I think in most cases I'd rather have it >> fail. >> >> I also don't really like refutable let-patterns proposal, because stuff >> like "let Some(x) = foo();" does not work with chaining when foo() returns >> a struct (and is still pretty wordy). >> >> Maybe we need an operator for "getting wrapped value"? This would be >> similar to "deref" for [smart]pointers, except I think it should be a >> postfix operator to allow for easy chaining. Let's say we chose '^' for >> this purpose, and implemented its' trait for Option, Result, etc. Then one >> could write: >> let x = foo()^; >> or >> let y = foo()^.field; >> >> Vadim >> >> >> >> On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron wrote: >> >>> I agree with Simon that doubling the API is inelegant. I think the >>> solution is adding sugar to make working with Option/Result easier - >>> (semi-)independent of the foo/foo_opt issue, I find working with Option >>> pretty painful. >>> >>> I prefer the Haskell do sugar to refutable patterns in let. Similar in >>> spirit is the ? operator from Groovy, which I think is elegant and simple, >>> it is an alternative to the . operator for field access/method call. In >>> Rust it would have the following type and semantics: >>> >>> \Gamma e : Option >>> fType(T', f) = T >>> ------------------------------------ >>> \Gamma e?f : Option >>> >>> e?f ~~> match e { Some => Some, None => None } >>> >>> and similarly for method call. >>> >>> The ? operator has the same advantages and disadvantages as Haskell's >>> do, but is more concise. >>> >>> Just another alternative to consider. >>> >>> >>> On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: >>> >>>> We have some functions and methods such as [std::str::from_utf8]( >>>> http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that >>>> may succeed and give a result, or fail when the input is invalid. >>>> >>>> 1. Sometimes we assume the input is valid and don?t want to deal with >>>> the error case. Task failure works nicely. >>>> >>>> 2. Sometimes we do want to do something different on invalid input, so >>>> returning an `Option` works best. >>>> >>>> And so we end up with both `from_utf8` and `from_utf8`. This particular >>>> case is worse because we also have `from_utf8_owned` and >>>> `from_utf8_owned_opt`, to cover everything. >>>> >>>> Multiplying names like this is just not good design. I?d like to reduce >>>> this pattern. >>>> >>>> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on >>>> the Option. I think we should rename every `foo_opt()` function or method >>>> to just `foo`, remove the old `foo()` behavior, and tell people (through >>>> documentation) to use `foo().unwrap()` if they want it back? >>>> >>>> The downsides are that unwrap is more verbose and gives less helpful >>>> error messages on task failure. But I think it?s worth it. >>>> >>>> What do you think? >>>> >>>> (PS: I?m guilty of making this worse in #10828, but I?d like to discuss >>>> this before sending pull requests with invasive API changes.) >>>> >>>> -- >>>> Simon Sapin >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From git at zimothy.com Tue Jan 7 21:46:30 2014 From: git at zimothy.com (Timothy Jones) Date: Wed, 8 Jan 2014 18:46:30 +1300 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: On 8/01/2014, at 3:39 pm, Nick Cameron wrote: > I think that you eventually have to deal with the Some or None-ness of an expression is an advantage of the ? operator, it means you can't ignore failure, but you don't have to deal with it at every step of a compound expression. Using an operator for unwrap has the same disadvantage as plain unwrap - it lets you ignore the failure case. It's also worth pointing out that ? and do-notation solve different problems. ? is addressing that there's no partial application of the dot operator, so you can't write `maybe.and_then(.next)`. In do-notation, you'd still have to name the value inside the option. You can produce a limited form of the refutable do-notation with a macro: macro_rules! refute ( (let $bind:pat = $val:expr; $(let $rbind:pat = $rval:expr);+; $result:expr) => (match $val { $bind => refute!($(let $rbind = $rval);+; $result), fail => fail }); (let $bind:pat = $val:expr; $result:expr) => (match $val { $bind => $result, fail => fail }); ) fn add_opts(x: Option, y: Option) -> Option { refute!( let Some(a) = x; let Some(b) = y; Some(a + b) ) } Chaining the ? operator can't really be done in a tidy manner without having it be part of the language. `?.` has been really useful in CoffeeScript, and Rust has the advantage of being able to tie it into a trait and allow any relevant type to use it. -- Tim From carter.schonwald at gmail.com Tue Jan 7 22:12:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 8 Jan 2014 01:12:37 -0500 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: I realized something. A good near term working solution could make use of the pending procedural macros to make a nicer syntax for the and_then procedures! (or could the current syntax rules style macros work with that even?). Not sure If i'll have the time to do that experiment, but throwing the idea out there. On Tuesday, January 7, 2014, Vadim wrote: > I can see how '?.' would work when foo() returns a struct, but what > about non-struct types, e.g. Option ? Also, you'd still have to deal > with 'None' at the end of the chain. I think in most cases I'd rather > have it fail. > > I also don't really like refutable let-patterns proposal, because stuff > like "let Some(x) = foo();" does not work with chaining when foo() returns > a struct (and is still pretty wordy). > > Maybe we need an operator for "getting wrapped value"? This would be > similar to "deref" for [smart]pointers, except I think it should be a > postfix operator to allow for easy chaining. Let's say we chose '^' for > this purpose, and implemented its' trait for Option, Result, etc. Then one > could write: > let x = foo()^; > or > let y = foo()^.field; > > Vadim > > > > On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron wrote: > >> I agree with Simon that doubling the API is inelegant. I think the >> solution is adding sugar to make working with Option/Result easier - >> (semi-)independent of the foo/foo_opt issue, I find working with Option >> pretty painful. >> >> I prefer the Haskell do sugar to refutable patterns in let. Similar in >> spirit is the ? operator from Groovy, which I think is elegant and simple, >> it is an alternative to the . operator for field access/method call. In >> Rust it would have the following type and semantics: >> >> \Gamma e : Option >> fType(T', f) = T >> ------------------------------------ >> \Gamma e?f : Option >> >> e?f ~~> match e { Some => Some, None => None } >> >> and similarly for method call. >> >> The ? operator has the same advantages and disadvantages as Haskell's do, >> but is more concise. >> >> Just another alternative to consider. >> >> >> On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: >> >>> We have some functions and methods such as [std::str::from_utf8](http:// >>> static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may >>> succeed and give a result, or fail when the input is invalid. >>> >>> 1. Sometimes we assume the input is valid and don?t want to deal with >>> the error case. Task failure works nicely. >>> >>> 2. Sometimes we do want to do something different on invalid input, so >>> returning an `Option` works best. >>> >>> And so we end up with both `from_utf8` and `from_utf8`. This particular >>> case is worse because we also have `from_utf8_owned` and >>> `from_utf8_owned_opt`, to cover everything. >>> >>> Multiplying names like this is just not good design. I?d like to reduce >>> this pattern. >>> >>> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on >>> the Option. I think we should rename every `foo_opt()` function or method >>> to just `foo`, remove the old `foo()` behavior, and tell people (through >>> documentation) to use `foo().unwrap()` if they want it back? >>> >>> The downsides are that unwrap is more verbose and gives less helpful >>> error messages on task failure. But I think it?s worth it. >>> >>> What do you think? >>> >>> (PS: I?m guilty of making this worse in #10828, but I?d like to discuss >>> this before sending pull requests with invasive API changes.) >>> >>> -- >>> Simon Sapin >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Tue Jan 7 22:37:33 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 8 Jan 2014 19:37:33 +1300 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: Sorry, I didn't mean ignore errors as in unsafe, I meant that it allows the programmer to write code without having the error case be explicit. This is the (well, one of the) problems with null pointers in C and Java. You make a good point about errors from the API, and I guess this highlights a worthwhile difference between expected None (e.g., a fn which returns the age of a user, but the user could leave the field unspecified) and an exceptional None (the same method fails to connect to the database). It is perhaps worth having different mechanisms to deal with the two cases. Cheers, Nick On Wed, Jan 8, 2014 at 4:31 PM, Vadim wrote: > On Tue, Jan 7, 2014 at 6:39 PM, Nick Cameron wrote: > >> I think that you eventually have to deal with the Some or None-ness of an >> expression is an advantage of the ? operator, it means you can't ignore >> failure, but you don't have to deal with it at every step of a compound >> expression. Using an operator for unwrap has the same disadvantage as plain >> unwrap - it lets you ignore the failure case. >> > > First of all, it does not let me ignore errors - if I try to unwrap() a > None, it will kill my program (or at least the current task). Whether > this is what I want, depends on the use case. In my experience, more > often than not, an error returned by an API represents a bug in the > program. So what am I gonna do when I see that something has error'ed > out? I will probably just call fail!(). > > Anyways, I think this thread was about how to avoid having both foo() and > foo_opt() versions of every API, and many people (including myself), > consider unwrap() too noisy. So... > > Vadim > > > >> >> On Wed, Jan 8, 2014 at 1:42 PM, Vadim wrote: >> >>> I can see how '?.' would work when foo() returns a struct, but what >>> about non-struct types, e.g. Option ? Also, you'd still have to deal >>> with 'None' at the end of the chain. I think in most cases I'd rather >>> have it fail. >>> >>> I also don't really like refutable let-patterns proposal, because stuff >>> like "let Some(x) = foo();" does not work with chaining when foo() returns >>> a struct (and is still pretty wordy). >>> >>> Maybe we need an operator for "getting wrapped value"? This would be >>> similar to "deref" for [smart]pointers, except I think it should be a >>> postfix operator to allow for easy chaining. Let's say we chose '^' for >>> this purpose, and implemented its' trait for Option, Result, etc. Then one >>> could write: >>> let x = foo()^; >>> or >>> let y = foo()^.field; >>> >>> Vadim >>> >>> >>> >>> On Tue, Jan 7, 2014 at 11:30 AM, Nick Cameron wrote: >>> >>>> I agree with Simon that doubling the API is inelegant. I think the >>>> solution is adding sugar to make working with Option/Result easier - >>>> (semi-)independent of the foo/foo_opt issue, I find working with Option >>>> pretty painful. >>>> >>>> I prefer the Haskell do sugar to refutable patterns in let. Similar in >>>> spirit is the ? operator from Groovy, which I think is elegant and simple, >>>> it is an alternative to the . operator for field access/method call. In >>>> Rust it would have the following type and semantics: >>>> >>>> \Gamma e : Option >>>> fType(T', f) = T >>>> ------------------------------------ >>>> \Gamma e?f : Option >>>> >>>> e?f ~~> match e { Some => Some, None => None } >>>> >>>> and similarly for method call. >>>> >>>> The ? operator has the same advantages and disadvantages as Haskell's >>>> do, but is more concise. >>>> >>>> Just another alternative to consider. >>>> >>>> >>>> On Sat, Dec 7, 2013 at 9:41 AM, Simon Sapin wrote: >>>> >>>>> We have some functions and methods such as [std::str::from_utf8]( >>>>> http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) >>>>> that may succeed and give a result, or fail when the input is invalid. >>>>> >>>>> 1. Sometimes we assume the input is valid and don?t want to deal with >>>>> the error case. Task failure works nicely. >>>>> >>>>> 2. Sometimes we do want to do something different on invalid input, so >>>>> returning an `Option` works best. >>>>> >>>>> And so we end up with both `from_utf8` and `from_utf8`. This >>>>> particular case is worse because we also have `from_utf8_owned` and >>>>> `from_utf8_owned_opt`, to cover everything. >>>>> >>>>> Multiplying names like this is just not good design. I?d like to >>>>> reduce this pattern. >>>>> >>>>> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on >>>>> the Option. I think we should rename every `foo_opt()` function or method >>>>> to just `foo`, remove the old `foo()` behavior, and tell people (through >>>>> documentation) to use `foo().unwrap()` if they want it back? >>>>> >>>>> The downsides are that unwrap is more verbose and gives less helpful >>>>> error messages on task failure. But I think it?s worth it. >>>>> >>>>> What do you think? >>>>> >>>>> (PS: I?m guilty of making this worse in #10828, but I?d like to >>>>> discuss this before sending pull requests with invasive API changes.) >>>>> >>>>> -- >>>>> Simon Sapin >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Jan 8 07:58:42 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 8 Jan 2014 07:58:42 -0800 Subject: [rust-dev] 1/28 Bay Area Rust meetup: Rust 0.9 and DST Message-ID: Hello Rusticians! I'm happy to announce the next Bay Area Rust meetup on 1/28! You can sign up for it here: http://www.meetup.com/Rust-Bay-Area/events/153909222/ On January 28 at 7:00pm at Mozilla SF, we have 4 great presenters lined up: Presenters: ? Brian Anderson: Will present about the soon-to-be-released Rust 0.9. ? Niko Matsakis: Will present his current plans for the long awaited Dynamically Sized Types, or DST. ? Kevin Ballard: Will present his safe Lua bindings: https://github.com/kballard/rust-lua ? Corey Richardson: Will present remotely on something yet-to-be-determined. This event will be catered and filmed by Air Mozilla if you cannot attend. *Location* This event will be held at the Mozilla San Francisco headquarters, at 2 Harrison St, San Francisco, CA 94105. Look for the building with the big "Hills Coffee" sign on the roof. Please sign in to the visitor log at the first floor reception desk when you arrive. I hope you can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcianx at gmail.com Wed Jan 8 19:08:02 2014 From: marcianx at gmail.com (Ashish Myles) Date: Wed, 8 Jan 2014 22:08:02 -0500 Subject: [rust-dev] What type to put for index when impl-ing Index? Message-ID: The following implementation of Index for Foo works fine. struct Foo([f64, ..3]); impl Index for Foo { fn index(&self, index: &uint) -> f64 { match self { &Foo(ref v) => v[*index].clone() } } } fn main() { let tmp : uint = 0; let foo = Foo([1.0, 2.0, 3.0]); println!("{:?}", foo[tmp]); } But if tmp is of type int, then I get an int-uint type mismatch failure. So I tried the following. use std::num::Int; ... impl Index for Foo { fn index(&self, index: &Idx) -> f64 { match self { &Foo(ref v) => v[*index].clone() } } } But I get error: mismatched types: expected integral type but found `Idx` with the error pointing at *index above. What's the right way to go about implementing generic operator indexing? Or does one always require conversion to uint (in the first case above) on the caller's side? Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Wed Jan 8 20:21:40 2014 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Thu, 9 Jan 2014 15:21:40 +1100 Subject: [rust-dev] What type to put for index when impl-ing Index? In-Reply-To: References: Message-ID: <5684E882-6D8F-485D-A660-30DDBADB0B13@yahoo.com.au> struct Foo([f64, ..3]); impl Index for Foo { fn index(&self, index: &I) -> f64 { let index = index.to_uint().unwrap(); match self { &Foo(ref v) => v[index].clone() } } } fn main() { let tmp : uint = 0; let foo = Foo([1.0, 2.0, 3.0]); println!("{:?}", foo[tmp]); } On 9 Jan 2014, at 2:08 pm, Ashish Myles wrote: > The following implementation of Index for Foo works fine. > > struct Foo([f64, ..3]); > impl Index for Foo { > fn index(&self, index: &uint) -> f64 { > match self { > &Foo(ref v) => v[*index].clone() > } > } > } > fn main() { > let tmp : uint = 0; > let foo = Foo([1.0, 2.0, 3.0]); > println!("{:?}", foo[tmp]); > } > > But if tmp is of type int, then I get an int-uint type mismatch failure. So I tried the following. > > use std::num::Int; > ... > impl Index for Foo { > fn index(&self, index: &Idx) -> f64 { > match self { > &Foo(ref v) => v[*index].clone() > } > } > } > > But I get > error: mismatched types: expected integral type but found `Idx` > with the error pointing at *index above. What's the right way to go about implementing generic operator indexing? Or does one always require conversion to uint (in the first case above) on the caller's side? > > Ashish > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From marcianx at gmail.com Wed Jan 8 20:43:42 2014 From: marcianx at gmail.com (Ashish Myles) Date: Wed, 8 Jan 2014 23:43:42 -0500 Subject: [rust-dev] What type to put for index when impl-ing Index? In-Reply-To: <5684E882-6D8F-485D-A660-30DDBADB0B13@yahoo.com.au> References: <5684E882-6D8F-485D-A660-30DDBADB0B13@yahoo.com.au> Message-ID: That'll do it, thanks! :) Here's to hoping that the compiler is smart enough to remove the bounds-checks and the None pathway for when I is one of the unsigned integer primitives. Ashish On Wed, Jan 8, 2014 at 11:21 PM, Brendan Zabarauskas wrote: > struct Foo([f64, ..3]); > > impl Index for Foo { > fn index(&self, index: &I) -> f64 { > let index = index.to_uint().unwrap(); > match self { > &Foo(ref v) => v[index].clone() > } > } > } > > fn main() { > let tmp : uint = 0; > let foo = Foo([1.0, 2.0, 3.0]); > println!("{:?}", foo[tmp]); > } > > On 9 Jan 2014, at 2:08 pm, Ashish Myles wrote: > > > The following implementation of Index for Foo works fine. > > > > struct Foo([f64, ..3]); > > impl Index for Foo { > > fn index(&self, index: &uint) -> f64 { > > match self { > > &Foo(ref v) => v[*index].clone() > > } > > } > > } > > fn main() { > > let tmp : uint = 0; > > let foo = Foo([1.0, 2.0, 3.0]); > > println!("{:?}", foo[tmp]); > > } > > > > But if tmp is of type int, then I get an int-uint type mismatch failure. > So I tried the following. > > > > use std::num::Int; > > ... > > impl Index for Foo { > > fn index(&self, index: &Idx) -> f64 { > > match self { > > &Foo(ref v) => v[*index].clone() > > } > > } > > } > > > > But I get > > error: mismatched types: expected integral type but found `Idx` > > with the error pointing at *index above. What's the right way to go > about implementing generic operator indexing? Or does one always require > conversion to uint (in the first case above) on the caller's side? > > > > Ashish > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Wed Jan 8 22:39:26 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 08 Jan 2014 22:39:26 -0800 Subject: [rust-dev] 0.9 prerelease testing Message-ID: <52CE441E.7040208@mozilla.com> Hey there, Rusticians! We've got a little 0.9 release candidate here. I've given it the most cursory test, but if you have the inclination go ahead and install these on your system of choice and see how it fares. These days we generally claim to support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes, and Android, but the intrepid may have luck on other platforms as well. If things go reasonably well with this RC then we'll sign and tag and release it to the world tomorrow. commit: 7613b15fdbbb9bf770a2c731f4135886b0ff3cf0 http://static.rust-lang.org/dist/rust-0.9.tar.gz c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 rust-0.9.tar.gz http://static.rust-lang.org/dist/rust-0.9-install.exe 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 rust-0.9-install.exe This is going to be the best release yet! Regards, Brian From jack at metajack.im Wed Jan 8 22:53:30 2014 From: jack at metajack.im (Jack Moffitt) Date: Wed, 8 Jan 2014 23:53:30 -0700 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: <52CE441E.7040208@mozilla.com> References: <52CE441E.7040208@mozilla.com> Message-ID: > We've got a little 0.9 release candidate here. I've given it the most > cursory test, but if you have the inclination go ahead and install these on > your system of choice and see how it fares. These days we generally claim to > support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes, and > Android, but the intrepid may have luck on other platforms as well. If > things go reasonably well with this RC then we'll sign and tag and release > it to the world tomorrow. Servo is moving almost to this version and it's been working pretty well even with lightly mixed native and green tasks. Debugging in particular seems much improved (except on OS X 10.9 where Apple has removed gdb). Some of my favorite things from 0.9 are the dead code warnings and the almost total removal of the option dance. Servo's code gets a little cleaner every time we move Rust forward. Happy testing! jack. From j.boggiano at seld.be Thu Jan 9 03:06:45 2014 From: j.boggiano at seld.be (Jordi Boggiano) Date: Thu, 09 Jan 2014 12:06:45 +0100 Subject: [rust-dev] 1/28 Bay Area Rust meetup: Rust 0.9 and DST In-Reply-To: References: Message-ID: <52CE82C5.8030509@seld.be> On 08/01/2014 16:58, Erick Tryzelaar wrote: > Hello Rusticians! > > I'm happy to announce the next Bay Area Rust meetup on 1/28! You can > sign up for it here: > > http://www.meetup.com/Rust-Bay-Area/events/153909222/ If possible it'd be awesome to post recordings here after the meetup, for those that can't physically make it. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From a.stavonin at gmail.com Thu Jan 9 04:04:12 2014 From: a.stavonin at gmail.com (Alexander Stavonin) Date: Thu, 9 Jan 2014 16:04:12 +0400 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: References: <52CE441E.7040208@mozilla.com> Message-ID: FYI. Apple doesn't remove GDB in 10.9. They has removed symlink for it So, you can find GDB in /Applications/Xcode.app/Contents/Developer/usr/libexec/gdb/gdb-i386-apple-darwin and create symlink manually. Best, Alex 2014/1/9 Jack Moffitt > > We've got a little 0.9 release candidate here. I've given it the most > > cursory test, but if you have the inclination go ahead and install these > on > > your system of choice and see how it fares. These days we generally > claim to > > support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes, and > > Android, but the intrepid may have luck on other platforms as well. If > > things go reasonably well with this RC then we'll sign and tag and > release > > it to the world tomorrow. > > Servo is moving almost to this version and it's been working pretty > well even with lightly mixed native and green tasks. Debugging in > particular seems much improved (except on OS X 10.9 where Apple has > removed gdb). > > Some of my favorite things from 0.9 are the dead code warnings and the > almost total removal of the option dance. Servo's code gets a little > cleaner every time we move Rust forward. > > Happy testing! > jack. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Thu Jan 9 06:37:55 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 9 Jan 2014 06:37:55 -0800 Subject: [rust-dev] 1/28 Bay Area Rust meetup: Rust 0.9 and DST In-Reply-To: <52CE82C5.8030509@seld.be> References: <52CE82C5.8030509@seld.be> Message-ID: You are in luck. They all are posted on air.mozilla.org. You can find all the other meetup presentations here: https://air.mozilla.org/search/?q=Rust On Thursday, January 9, 2014, Jordi Boggiano wrote: > On 08/01/2014 16:58, Erick Tryzelaar wrote: > >> Hello Rusticians! >> >> I'm happy to announce the next Bay Area Rust meetup on 1/28! You can >> sign up for it here: >> >> http://www.meetup.com/Rust-Bay-Area/events/153909222/ >> > > If possible it'd be awesome to post recordings here after the meetup, for > those that can't physically make it. > > Cheers > > -- > Jordi Boggiano > @seldaek - http://nelm.io/jordi > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Thu Jan 9 09:58:10 2014 From: kevin at sb.org (Kevin Ballard) Date: Thu, 9 Jan 2014 09:58:10 -0800 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: References: <52CE441E.7040208@mozilla.com> Message-ID: <72F3941D-6691-4A17-BF74-2DCCB0491947@sb.org> That path does not exist in Xcode 5.0 or Xcode 5.1 DP3. Are you sure you aren't looking at an older Xcode (say, Xcode 4.6)? -Kevin On Jan 9, 2014, at 4:04 AM, Alexander Stavonin wrote: > FYI. Apple doesn't remove GDB in 10.9. They has removed symlink for it So, you can find GDB in /Applications/Xcode.app/Contents/Developer/usr/libexec/gdb/gdb-i386-apple-darwin and create symlink manually. > > Best, > Alex > > > 2014/1/9 Jack Moffitt > > We've got a little 0.9 release candidate here. I've given it the most > > cursory test, but if you have the inclination go ahead and install these on > > your system of choice and see how it fares. These days we generally claim to > > support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes, and > > Android, but the intrepid may have luck on other platforms as well. If > > things go reasonably well with this RC then we'll sign and tag and release > > it to the world tomorrow. > > Servo is moving almost to this version and it's been working pretty > well even with lightly mixed native and green tasks. Debugging in > particular seems much improved (except on OS X 10.9 where Apple has > removed gdb). > > Some of my favorite things from 0.9 are the dead code warnings and the > almost total removal of the option dance. Servo's code gets a little > cleaner every time we move Rust forward. > > Happy testing! > jack. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From a.stavonin at gmail.com Thu Jan 9 11:00:48 2014 From: a.stavonin at gmail.com (Alexander Stavonin) Date: Thu, 9 Jan 2014 23:00:48 +0400 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: <72F3941D-6691-4A17-BF74-2DCCB0491947@sb.org> References: <52CE441E.7040208@mozilla.com> <72F3941D-6691-4A17-BF74-2DCCB0491947@sb.org> Message-ID: Very strange. I?ve checked the folder on my personal notebook and yes, there is not gdb. Looks like I was wrong. Best regards, Alexander On 09 Jan 2014, at 21:58, Kevin Ballard wrote: > That path does not exist in Xcode 5.0 or Xcode 5.1 DP3. Are you sure you aren't looking at an older Xcode (say, Xcode 4.6)? > > -Kevin > > On Jan 9, 2014, at 4:04 AM, Alexander Stavonin wrote: > >> FYI. Apple doesn't remove GDB in 10.9. They has removed symlink for it So, you can find GDB in /Applications/Xcode.app/Contents/Developer/usr/libexec/gdb/gdb-i386-apple-darwin and create symlink manually. >> >> Best, >> Alex >> >> >> 2014/1/9 Jack Moffitt >> > We've got a little 0.9 release candidate here. I've given it the most >> > cursory test, but if you have the inclination go ahead and install these on >> > your system of choice and see how it fares. These days we generally claim to >> > support Mac OS X 10.6+, Windows 7 and 2008 RC2, a variety of Linuxes, and >> > Android, but the intrepid may have luck on other platforms as well. If >> > things go reasonably well with this RC then we'll sign and tag and release >> > it to the world tomorrow. >> >> Servo is moving almost to this version and it's been working pretty >> well even with lightly mixed native and green tasks. Debugging in >> particular seems much improved (except on OS X 10.9 where Apple has >> removed gdb). >> >> Some of my favorite things from 0.9 are the dead code warnings and the >> almost total removal of the option dance. Servo's code gets a little >> cleaner every time we move Rust forward. >> >> Happy testing! >> jack. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Jan 9 12:59:21 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 12:59:21 -0800 Subject: [rust-dev] Rust 0.8 released Message-ID: <52CF0DA9.70309@mozilla.com> Mozilla and the Rust community are pleased to announce version 0.9 of the Rust compiler and tools. Rust is a systems programming language with a focus on safety, performance and concurrency. This was another eventful release in which we made extensive improvements to the runtime and I/O subsystem, introduced static linking and link-time optimization, and reduced the variety of closures in the language. 0.9 also begins a final series of planned changes to how pointers are treated in Rust, starting with the deprecation of the built-in "managed pointer" type and its accompanying `@` sigil, and the introduction of smart pointer types to the standard library. The brief release notes are included in this announcement, and there is further explanation in the detailed release [notes] on the wiki. Documentation and all the links in this email are available on the [website]. As usual, version 0.9 should be considered an alpha release, suitable for early adopters and language enthusiasts. Please file [bugs] and join the [fun]. [website]: http://www.rust-lang.org [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes [bugs]: https://github.com/mozilla/rust/issues [fun]: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors This release is available as both a tarball and a Windows installer: * http://static.rust-lang.org/dist/rust-0.9.tar.gz http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc SHA256 (of .tar.gz): c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 * http://static.rust-lang.org/dist/rust-0.9-install.exe http://static.rust-lang.org/dist/rust-0.9-install.exe.asc SHA256 (of .exe): 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 Thanks to everyone who contributed! Regards, The Rust Team Version 0.9 (January 2014) -------------------------- * Language * The `float` type has been removed. Use `f32` or `f64` instead. * A new facility for enabling experimental features (feature gating) has been added, using the crate-level `#[feature(foo)]` attribute. * Managed boxes (@) are now behind a feature gate (`#[feature(managed_boxes)]`) in preperation for future removal. Use the standard library's `Gc` or `Rc` types instead. * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. * Jumping back to the top of a loop is now done with `continue` instead of `loop`. * Strings can no longer be mutated through index assignment. * Raw strings can be created via the basic `r"foo"` syntax or with matched hash delimiters, as in `r###"foo"###`. * `~fn` is now written `proc (args) -> retval { ... }` and may only be called once. * The `&fn` type is now written `|args| -> ret` to match the literal form. * `@fn`s have been removed. * `do` only works with procs in order to make it obvious what the cost of `do` is. * Single-element tuple-like structs can no longer be dereferenced to obtain the inner value. A more comprehensive solution for overloading the dereference operator will be provided in the future. * The `#[link(...)]` attribute has been replaced with `#[crate_id = "name#vers"]`. * Empty `impl`s must be terminated with empty braces and may not be terminated with a semicolon. * Keywords are no longer allowed as lifetime names; the `self` lifetime no longer has any special meaning. * The old `fmt!` string formatting macro has been removed. * `printf!` and `printfln!` (old-style formatting) removed in favor of `print!` and `println!`. * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. * The `extern mod foo (name = "bar")` syntax has been removed. Use `extern mod foo = "bar"` instead. * New reserved keywords: `alignof`, `offsetof`, `sizeof`. * Macros can have attributes. * Macros can expand to items with attributes. * Macros can expand to multiple items. * The `asm!` macro is feature-gated (`#[feature(asm)]`). * Comments may be nested. * Values automatically coerce to trait objects they implement, without an explicit `as`. * Enum discriminants are no longer an entire word but as small as needed to contain all the variants. The `repr` attribute can be used to override the discriminant size, as in `#[repr(int)]` for integer-sized, and `#[repr(C)]` to match C enums. * Non-string literals are not allowed in attributes (they never worked). * The FFI now supports variadic functions. * Octal numeric literals, as in `0o7777`. * The `concat!` syntax extension performs compile-time string concatenation. * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been removed as Rust no longer uses segmented stacks. * Non-ascii identifiers are feature-gated (`#[feature(non_ascii_idents)]`). * Ignoring all fields of an enum variant or tuple-struct is done with `..`, not `*`; ignoring remaining fields of a struct is also done with `..`, not `_`; ignoring a slice of a vector is done with `..`, not `.._`. * `rustc` supports the "win64" calling convention via `extern "win64"`. * `rustc` supports the "system" calling convention, which defaults to the preferred convention for the target platform, "stdcall" on 32-bit Windows, "C" elsewhere. * The `type_overflow` lint (default: warn) checks literals for overflow. * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. * The `attribute_usage` lint (default: warn) warns about unknown attributes. * The `unknown_features` lint (default: warn) warns about unknown feature gates. * The `dead_code` lint (default: warn) checks for dead code. * Rust libraries can be linked statically to one another * `#[link_args]` is behind the `link_args` feature gate. * Native libraries are now linked with `#[link(name = "foo")]` * Native libraries can be statically linked to a rust crate (`#[link(name = "foo", kind = "static")]`). * Native OS X frameworks are now officially supported (`#[link(name = "foo", kind = "framework")]`). * The `#[thread_local]` attribute creates thread-local (not task-local) variables. Currently behind the `thread_local` feature gate. * The `return` keyword may be used in closures. * Types that can be copied via a memcpy implement the `Pod` kind. * The `cfg` attribute can now be used on struct fields and enum variants. * Libraries * std: The `option` and `result` API's have been overhauled to make them simpler, more consistent, and more composable. * std: The entire `std::io` module has been replaced with one that is more comprehensive and that properly interfaces with the underlying scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all implemented. * std: `io::util` contains a number of useful implementations of `Reader` and `Writer`, including `NullReader`, `NullWriter`, `ZeroReader`, `TeeReader`. * std: The reference counted pointer type `extra::rc` moved into std. * std: The `Gc` type in the `gc` module will replace `@` (it is currently just a wrapper around it). * std: The `Either` type has been removed. * std: `fmt::Default` can be implemented for any type to provide default formatting to the `format!` macro, as in `format!("{}", myfoo)`. * std: The `rand` API continues to be tweaked. * std: The `rust_begin_unwind` function, useful for inserting breakpoints on failure in gdb, is now named `rust_fail`. * std: The `each_key` and `each_value` methods on `HashMap` have been replaced by the `keys` and `values` iterators. * std: Functions dealing with type size and alignment have moved from the `sys` module to the `mem` module. * std: The `path` module was written and API changed. * std: `str::from_utf8` has been changed to cast instead of allocate. * std: `starts_with` and `ends_with` methods added to vectors via the `ImmutableEqVector` trait, which is in the prelude. * std: Vectors can be indexed with the `get_opt` method, which returns `None` if the index is out of bounds. * std: Task failure no longer propagates between tasks, as the model was complex, expensive, and incompatible with thread-based tasks. * std: The `Any` type can be used for dynamic typing. * std: `~Any` can be passed to the `fail!` macro and retrieved via `task::try`. * std: Methods that produce iterators generally do not have an `_iter` suffix now. * std: `cell::Cell` and `cell::RefCell` can be used to introduc mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. * std: `util::ignore` renamed to `prelude::drop`. * std: Slices have `sort` and `sort_by` methods via the `MutableVector` trait. * std: `vec::raw` has seen a lot of cleanup and API changes. * std: The standard library no longer includes any C++ code, and very minimal C, eliminating the dependency on libstdc++. * std: Runtime scheduling and I/O functionality has been factored out into extensible interfaces and is now implemented by two different crates: libnative, for native threading and I/O; and libgreen, for green threading and I/O. This paves the way for using the standard library in more limited embeded environments. * std: The `comm` module has been rewritten to be much faster, have a simpler, more consistent API, and to work for both native and green threading. * std: All libuv dependencies have been moved into the rustuv crate. * native: New implementations of runtime scheduling on top of OS threads. * native: New native implementations of TCP, UDP, file I/O, process spawning, and other I/O. * green: The green thread scheduler and message passing types are almost entirely lock-free. * extra: The `flatpipes` module had bitrotted and was removed. * extra: All crypto functions have been removed and Rust now has a policy of not reimplementing crypto in the standard library. In the future crypto will be provided by external crates with bindings to established libraries. * extra: `c_vec` has been modernized. * extra: The `sort` module has been removed. Use the `sort` method on mutable slices. * Tooling * The `rust` and `rusti` commands have been removed, due to lack of maintenance. * `rustdoc` was completely rewritten. * `rustdoc` can test code examples in documentation. * `rustpkg` can test packages with the argument, 'test'. * `rustpkg` supports arbitrary dependencies, including C libraries. * `rustc`'s support for generating debug info is improved again. * `rustc` has better error reporting for unbalanced delimiters. * `rustc`'s JIT support was removed due to bitrot. * Executables and static libraries can be built with LTO (-Z lto) * `rustc` adds a `--dep-info` flag for communicating dependencies to build tools. Contributors to Rust 0.9 ------------------------ Adrien T?tar Alan Andrade Alexandros Tasos Alex Crichton a_m0d Andreas Neuhaus Andreas Ots Andrei Formiga Benjamin Herr Benjamin Peterson Birunthan Mohanathas blake2-ppc Branimir Brendan Zabarauskas Brian Anderson Brian Cadence Marseille Carl-Anton Ingmarsson Carol Willing Carter Tazio Schonwald chitra Chris Morgan Chris Sainty Corey Richardson Dan Connolly Daniel Micay Dan Luu Dave Hodder David Creswick David Renshaw Diego Ongaro Dirkjan Bussink Dmitry Ermolov Do Nhat Minh Eduard Burtescu Edward Z. Yang eliovir Eric Biggers Eric Holk Erick Tryzelaar Erik Lyon Erik Price Fabrice Desr? Felix S. Klock II Flavio Percoco flo-l Florian Gilcher Florian Hahn Florian Zeitz g3xzh Gareth Smith Geoff Hill Geoffroy Couprie Georges Dubus gifnksm Guillaume Pinot Gyorgy Andrasek Harry Marr Heather Huon Wilson Ian Daniher Igor Bukanov Isaac Dupree Jack Moffitt Jaemin Moon Jan Niklas Hasse Jannis Harder Jason Orendorff Jason Toffaletti Jay Anderson Jed Davis Jeff Olson Joe Schafer John Louis Walker Jordi Boggiano Joshua Yanovski Julia Evans Jyun-Yan You Keegan McAllister Kevin Ballard Kiet Tran klutzy kud1ing Leah Hanson LEE Wondong Le?o Testard Lindsey Kuper Luca Bruno Luis de Bethencourt Luqman Aden lyuts Mark Rowe Marvin L?bel Matt Carberry Matthew Auld Matthew Iselin Micah Chalmer Michael 'devbug' Williams Michael Letterle Michael Woerister niftynif Niko Matsakis Noufal Ibrahim Olivier Saut osa1 Palmer Cox

Patrick Walton Peter Zotov Philipp Br?schweiler Raphael Speyer reedlepee Richard Diamond Robert Irelan Scott Lawrence S?bastien Chauvel S?bastien Crozet S?bastien Paolacci Seo Sanghyeon sh8281.kim SiegeLord sp3d S Pradeep Kumar Steve Klabnik Steven Fackler Strahinja Val Markovic Tim Chevalier Tomas Sedovic Vadim Chugunov Vijay Korapaty Volker Mische Young-il Choi Zach Kamsler Zack Corr Ziad Hatahet From banderson at mozilla.com Thu Jan 9 12:59:48 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 12:59:48 -0800 Subject: [rust-dev] Rust 0.8 released In-Reply-To: <52CF0DA9.70309@mozilla.com> References: <52CF0DA9.70309@mozilla.com> Message-ID: <52CF0DC4.1000707@mozilla.com> 0.9.... On 01/09/2014 12:59 PM, Brian Anderson wrote: > Mozilla and the Rust community are pleased to announce version 0.9 of the > Rust compiler and tools. Rust is a systems programming language with a > focus on safety, performance and concurrency. > > This was another eventful release in which we made extensive improvements > to the runtime and I/O subsystem, introduced static linking and link-time > optimization, and reduced the variety of closures in the language. 0.9 > also > begins a final series of planned changes to how pointers are treated in > Rust, starting with the deprecation of the built-in "managed pointer" > type > and its accompanying `@` sigil, and the introduction of smart pointer > types > to the standard library. > > The brief release notes are included in this announcement, and there is > further explanation in the detailed release [notes] on the wiki. > Documentation and all the links in this email are available on the > [website]. As usual, version 0.9 should be considered an alpha release, > suitable for early adopters and language enthusiasts. Please file [bugs] > and join the [fun]. > > [website]: http://www.rust-lang.org > [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes > [bugs]: https://github.com/mozilla/rust/issues > [fun]: > https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors > > This release is available as both a tarball and a Windows installer: > > * http://static.rust-lang.org/dist/rust-0.9.tar.gz > http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc > SHA256 (of .tar.gz): > c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 > > * http://static.rust-lang.org/dist/rust-0.9-install.exe > http://static.rust-lang.org/dist/rust-0.9-install.exe.asc > SHA256 (of .exe): > 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 > > Thanks to everyone who contributed! > > Regards, > The Rust Team > > > Version 0.9 (January 2014) > -------------------------- > > * Language > * The `float` type has been removed. Use `f32` or `f64` instead. > * A new facility for enabling experimental features (feature gating) > has been added, using the crate-level `#[feature(foo)]` attribute. > * Managed boxes (@) are now behind a feature gate > (`#[feature(managed_boxes)]`) in preperation for future removal. Use > the standard library's `Gc` or `Rc` types instead. > * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. > * Jumping back to the top of a loop is now done with `continue` instead > of `loop`. > * Strings can no longer be mutated through index assignment. > * Raw strings can be created via the basic `r"foo"` syntax or with > matched hash delimiters, as in `r###"foo"###`. > * `~fn` is now written `proc (args) -> retval { ... }` and may only be > called once. > * The `&fn` type is now written `|args| -> ret` to match the literal > form. > * `@fn`s have been removed. > * `do` only works with procs in order to make it obvious what the cost > of `do` is. > * Single-element tuple-like structs can no longer be dereferenced to > obtain the inner value. A more comprehensive solution for overloading > the dereference operator will be provided in the future. > * The `#[link(...)]` attribute has been replaced with > `#[crate_id = "name#vers"]`. > * Empty `impl`s must be terminated with empty braces and may not be > terminated with a semicolon. > * Keywords are no longer allowed as lifetime names; the `self` lifetime > no longer has any special meaning. > * The old `fmt!` string formatting macro has been removed. > * `printf!` and `printfln!` (old-style formatting) removed in favor of > `print!` and `println!`. > * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. > * The `extern mod foo (name = "bar")` syntax has been removed. Use > `extern mod foo = "bar"` instead. > * New reserved keywords: `alignof`, `offsetof`, `sizeof`. > * Macros can have attributes. > * Macros can expand to items with attributes. > * Macros can expand to multiple items. > * The `asm!` macro is feature-gated (`#[feature(asm)]`). > * Comments may be nested. > * Values automatically coerce to trait objects they implement, without > an explicit `as`. > * Enum discriminants are no longer an entire word but as small as needed > to contain all the variants. The `repr` attribute can be used to > override the discriminant size, as in `#[repr(int)]` for integer-sized, > and `#[repr(C)]` to match C enums. > * Non-string literals are not allowed in attributes (they never worked). > * The FFI now supports variadic functions. > * Octal numeric literals, as in `0o7777`. > * The `concat!` syntax extension performs compile-time string > concatenation. > * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been > removed as Rust no longer uses segmented stacks. > * Non-ascii identifiers are feature-gated > (`#[feature(non_ascii_idents)]`). > * Ignoring all fields of an enum variant or tuple-struct is done with > `..`, not `*`; ignoring remaining fields of a struct is also done > with `..`, not `_`; ignoring a slice of a vector is done with `..`, > not `.._`. > * `rustc` supports the "win64" calling convention via `extern "win64"`. > * `rustc` supports the "system" calling convention, which defaults to > the preferred convention for the target platform, "stdcall" on 32-bit > Windows, "C" elsewhere. > * The `type_overflow` lint (default: warn) checks literals for overflow. > * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. > * The `attribute_usage` lint (default: warn) warns about unknown > attributes. > * The `unknown_features` lint (default: warn) warns about unknown > feature gates. > * The `dead_code` lint (default: warn) checks for dead code. > * Rust libraries can be linked statically to one another > * `#[link_args]` is behind the `link_args` feature gate. > * Native libraries are now linked with `#[link(name = "foo")]` > * Native libraries can be statically linked to a rust crate > (`#[link(name = "foo", kind = "static")]`). > * Native OS X frameworks are now officially supported > (`#[link(name = "foo", kind = "framework")]`). > * The `#[thread_local]` attribute creates thread-local (not task-local) > variables. Currently behind the `thread_local` feature gate. > * The `return` keyword may be used in closures. > * Types that can be copied via a memcpy implement the `Pod` kind. > * The `cfg` attribute can now be used on struct fields and enum variants. > > * Libraries > * std: The `option` and `result` API's have been overhauled to make them > simpler, more consistent, and more composable. > * std: The entire `std::io` module has been replaced with one that is > more comprehensive and that properly interfaces with the underlying > scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all > implemented. > * std: `io::util` contains a number of useful implementations of > `Reader` and `Writer`, including `NullReader`, `NullWriter`, > `ZeroReader`, `TeeReader`. > * std: The reference counted pointer type `extra::rc` moved into std. > * std: The `Gc` type in the `gc` module will replace `@` (it is currently > just a wrapper around it). > * std: The `Either` type has been removed. > * std: `fmt::Default` can be implemented for any type to provide default > formatting to the `format!` macro, as in `format!("{}", myfoo)`. > * std: The `rand` API continues to be tweaked. > * std: The `rust_begin_unwind` function, useful for inserting > breakpoints on failure in gdb, is now named `rust_fail`. > * std: The `each_key` and `each_value` methods on `HashMap` have been > replaced by the `keys` and `values` iterators. > * std: Functions dealing with type size and alignment have moved from > the `sys` module to the `mem` module. > * std: The `path` module was written and API changed. > * std: `str::from_utf8` has been changed to cast instead of allocate. > * std: `starts_with` and `ends_with` methods added to vectors via the > `ImmutableEqVector` trait, which is in the prelude. > * std: Vectors can be indexed with the `get_opt` method, which returns > `None` if the index is out of bounds. > * std: Task failure no longer propagates between tasks, as the model > was complex, expensive, and incompatible with thread-based tasks. > * std: The `Any` type can be used for dynamic typing. > * std: `~Any` can be passed to the `fail!` macro and retrieved via > `task::try`. > * std: Methods that produce iterators generally do not have an `_iter` > suffix now. > * std: `cell::Cell` and `cell::RefCell` can be used to introduc > mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. > * std: `util::ignore` renamed to `prelude::drop`. > * std: Slices have `sort` and `sort_by` methods via the `MutableVector` > trait. > * std: `vec::raw` has seen a lot of cleanup and API changes. > * std: The standard library no longer includes any C++ code, and very > minimal C, eliminating the dependency on libstdc++. > * std: Runtime scheduling and I/O functionality has been factored out > into extensible interfaces and is now implemented by two different > crates: libnative, for native threading and I/O; and libgreen, for > green threading and I/O. This paves the way for using the standard > library in more limited embeded environments. > * std: The `comm` module has been rewritten to be much faster, have a > simpler, more consistent API, and to work for both native and green > threading. > * std: All libuv dependencies have been moved into the rustuv crate. > * native: New implementations of runtime scheduling on top of OS > threads. > * native: New native implementations of TCP, UDP, file I/O, process > spawning, and other I/O. > * green: The green thread scheduler and message passing types are > almost entirely lock-free. > * extra: The `flatpipes` module had bitrotted and was removed. > * extra: All crypto functions have been removed and Rust now has a > policy of not reimplementing crypto in the standard library. In the > future crypto will be provided by external crates with bindings to > established libraries. > * extra: `c_vec` has been modernized. > * extra: The `sort` module has been removed. Use the `sort` method on > mutable slices. > > * Tooling > * The `rust` and `rusti` commands have been removed, due to lack of > maintenance. > * `rustdoc` was completely rewritten. > * `rustdoc` can test code examples in documentation. > * `rustpkg` can test packages with the argument, 'test'. > * `rustpkg` supports arbitrary dependencies, including C libraries. > * `rustc`'s support for generating debug info is improved again. > * `rustc` has better error reporting for unbalanced delimiters. > * `rustc`'s JIT support was removed due to bitrot. > * Executables and static libraries can be built with LTO (-Z lto) > * `rustc` adds a `--dep-info` flag for communicating dependencies to > build tools. > > > Contributors to Rust 0.9 > ------------------------ > > Adrien T?tar > Alan Andrade > Alexandros Tasos > Alex Crichton > a_m0d > Andreas Neuhaus > Andreas Ots > Andrei Formiga > Benjamin Herr > Benjamin Peterson > Birunthan Mohanathas > blake2-ppc > Branimir > Brendan Zabarauskas > Brian Anderson > Brian > Cadence Marseille > Carl-Anton Ingmarsson > Carol Willing > Carter Tazio Schonwald > chitra > Chris Morgan > Chris Sainty > Corey Richardson > Dan Connolly > Daniel Micay > Dan Luu > Dave Hodder > David Creswick > David Renshaw > Diego Ongaro > Dirkjan Bussink > Dmitry Ermolov > Do Nhat Minh > Eduard Burtescu > Edward Z. Yang > eliovir > Eric Biggers > Eric Holk > Erick Tryzelaar > Erik Lyon > Erik Price > Fabrice Desr? > Felix S. Klock II > Flavio Percoco > flo-l > Florian Gilcher > Florian Hahn > Florian Zeitz > g3xzh > Gareth Smith > Geoff Hill > Geoffroy Couprie > Georges Dubus > gifnksm > Guillaume Pinot > Gyorgy Andrasek > Harry Marr > Heather > Huon Wilson > Ian Daniher > Igor Bukanov > Isaac Dupree > Jack Moffitt > Jaemin Moon > Jan Niklas Hasse > Jannis Harder > Jason Orendorff > Jason Toffaletti > Jay Anderson > Jed Davis > Jeff Olson > Joe Schafer > John Louis Walker > Jordi Boggiano > Joshua Yanovski > Julia Evans > Jyun-Yan You > Keegan McAllister > Kevin Ballard > Kiet Tran > klutzy > kud1ing > Leah Hanson > LEE Wondong > Le?o Testard > Lindsey Kuper > Luca Bruno > Luis de Bethencourt > Luqman Aden > lyuts > Mark Rowe > Marvin L?bel > Matt Carberry > Matthew Auld > Matthew Iselin > Micah Chalmer > Michael 'devbug' Williams > Michael Letterle > Michael Woerister > niftynif > Niko Matsakis > Noufal Ibrahim > Olivier Saut > osa1 > Palmer Cox

> Patrick Walton > Peter Zotov > Philipp Br?schweiler > Raphael Speyer > reedlepee > Richard Diamond > Robert Irelan > Scott Lawrence > S?bastien Chauvel > S?bastien Crozet > S?bastien Paolacci > Seo Sanghyeon > sh8281.kim > SiegeLord > sp3d > S Pradeep Kumar > Steve Klabnik > Steven Fackler > Strahinja Val Markovic > Tim Chevalier > Tomas Sedovic > Vadim Chugunov > Vijay Korapaty > Volker Mische > Young-il Choi > Zach Kamsler > Zack Corr > Ziad Hatahet > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From banderson at mozilla.com Thu Jan 9 13:04:13 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 13:04:13 -0800 Subject: [rust-dev] Rust 0.9 released Message-ID: <52CF0ECD.5050405@mozilla.com> Mozilla and the Rust community are pleased to announce version 0.9 of the Rust compiler and tools. Rust is a systems programming language with a focus on safety, performance and concurrency. This was another eventful release in which we made extensive improvements to the runtime and I/O subsystem, introduced static linking and link-time optimization, and reduced the variety of closures in the language. 0.9 also begins a final series of planned changes to how pointers are treated in Rust, starting with the deprecation of the built-in "managed pointer" type and its accompanying `@` sigil, and the introduction of smart pointer types to the standard library. The brief release notes are included in this announcement, and there is further explanation in the detailed release [notes] on the wiki. Documentation and all the links in this email are available on the [website]. As usual, version 0.9 should be considered an alpha release, suitable for early adopters and language enthusiasts. Please file [bugs] and join the [fun]. [website]: http://www.rust-lang.org [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes [bugs]: https://github.com/mozilla/rust/issues [fun]: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors This release is available as both a tarball and a Windows installer: * http://static.rust-lang.org/dist/rust-0.9.tar.gz http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc SHA256 (of .tar.gz): c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 * http://static.rust-lang.org/dist/rust-0.9-install.exe http://static.rust-lang.org/dist/rust-0.9-install.exe.asc SHA256 (of .exe): 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 Thanks to everyone who contributed! Regards, The Rust Team Version 0.9 (January 2014) -------------------------- * Language * The `float` type has been removed. Use `f32` or `f64` instead. * A new facility for enabling experimental features (feature gating) has been added, using the crate-level `#[feature(foo)]` attribute. * Managed boxes (@) are now behind a feature gate (`#[feature(managed_boxes)]`) in preperation for future removal. Use the standard library's `Gc` or `Rc` types instead. * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. * Jumping back to the top of a loop is now done with `continue` instead of `loop`. * Strings can no longer be mutated through index assignment. * Raw strings can be created via the basic `r"foo"` syntax or with matched hash delimiters, as in `r###"foo"###`. * `~fn` is now written `proc (args) -> retval { ... }` and may only be called once. * The `&fn` type is now written `|args| -> ret` to match the literal form. * `@fn`s have been removed. * `do` only works with procs in order to make it obvious what the cost of `do` is. * Single-element tuple-like structs can no longer be dereferenced to obtain the inner value. A more comprehensive solution for overloading the dereference operator will be provided in the future. * The `#[link(...)]` attribute has been replaced with `#[crate_id = "name#vers"]`. * Empty `impl`s must be terminated with empty braces and may not be terminated with a semicolon. * Keywords are no longer allowed as lifetime names; the `self` lifetime no longer has any special meaning. * The old `fmt!` string formatting macro has been removed. * `printf!` and `printfln!` (old-style formatting) removed in favor of `print!` and `println!`. * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. * The `extern mod foo (name = "bar")` syntax has been removed. Use `extern mod foo = "bar"` instead. * New reserved keywords: `alignof`, `offsetof`, `sizeof`. * Macros can have attributes. * Macros can expand to items with attributes. * Macros can expand to multiple items. * The `asm!` macro is feature-gated (`#[feature(asm)]`). * Comments may be nested. * Values automatically coerce to trait objects they implement, without an explicit `as`. * Enum discriminants are no longer an entire word but as small as needed to contain all the variants. The `repr` attribute can be used to override the discriminant size, as in `#[repr(int)]` for integer-sized, and `#[repr(C)]` to match C enums. * Non-string literals are not allowed in attributes (they never worked). * The FFI now supports variadic functions. * Octal numeric literals, as in `0o7777`. * The `concat!` syntax extension performs compile-time string concatenation. * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been removed as Rust no longer uses segmented stacks. * Non-ascii identifiers are feature-gated (`#[feature(non_ascii_idents)]`). * Ignoring all fields of an enum variant or tuple-struct is done with `..`, not `*`; ignoring remaining fields of a struct is also done with `..`, not `_`; ignoring a slice of a vector is done with `..`, not `.._`. * `rustc` supports the "win64" calling convention via `extern "win64"`. * `rustc` supports the "system" calling convention, which defaults to the preferred convention for the target platform, "stdcall" on 32-bit Windows, "C" elsewhere. * The `type_overflow` lint (default: warn) checks literals for overflow. * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. * The `attribute_usage` lint (default: warn) warns about unknown attributes. * The `unknown_features` lint (default: warn) warns about unknown feature gates. * The `dead_code` lint (default: warn) checks for dead code. * Rust libraries can be linked statically to one another * `#[link_args]` is behind the `link_args` feature gate. * Native libraries are now linked with `#[link(name = "foo")]` * Native libraries can be statically linked to a rust crate (`#[link(name = "foo", kind = "static")]`). * Native OS X frameworks are now officially supported (`#[link(name = "foo", kind = "framework")]`). * The `#[thread_local]` attribute creates thread-local (not task-local) variables. Currently behind the `thread_local` feature gate. * The `return` keyword may be used in closures. * Types that can be copied via a memcpy implement the `Pod` kind. * The `cfg` attribute can now be used on struct fields and enum variants. * Libraries * std: The `option` and `result` API's have been overhauled to make them simpler, more consistent, and more composable. * std: The entire `std::io` module has been replaced with one that is more comprehensive and that properly interfaces with the underlying scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all implemented. * std: `io::util` contains a number of useful implementations of `Reader` and `Writer`, including `NullReader`, `NullWriter`, `ZeroReader`, `TeeReader`. * std: The reference counted pointer type `extra::rc` moved into std. * std: The `Gc` type in the `gc` module will replace `@` (it is currently just a wrapper around it). * std: The `Either` type has been removed. * std: `fmt::Default` can be implemented for any type to provide default formatting to the `format!` macro, as in `format!("{}", myfoo)`. * std: The `rand` API continues to be tweaked. * std: The `rust_begin_unwind` function, useful for inserting breakpoints on failure in gdb, is now named `rust_fail`. * std: The `each_key` and `each_value` methods on `HashMap` have been replaced by the `keys` and `values` iterators. * std: Functions dealing with type size and alignment have moved from the `sys` module to the `mem` module. * std: The `path` module was written and API changed. * std: `str::from_utf8` has been changed to cast instead of allocate. * std: `starts_with` and `ends_with` methods added to vectors via the `ImmutableEqVector` trait, which is in the prelude. * std: Vectors can be indexed with the `get_opt` method, which returns `None` if the index is out of bounds. * std: Task failure no longer propagates between tasks, as the model was complex, expensive, and incompatible with thread-based tasks. * std: The `Any` type can be used for dynamic typing. * std: `~Any` can be passed to the `fail!` macro and retrieved via `task::try`. * std: Methods that produce iterators generally do not have an `_iter` suffix now. * std: `cell::Cell` and `cell::RefCell` can be used to introduc mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. * std: `util::ignore` renamed to `prelude::drop`. * std: Slices have `sort` and `sort_by` methods via the `MutableVector` trait. * std: `vec::raw` has seen a lot of cleanup and API changes. * std: The standard library no longer includes any C++ code, and very minimal C, eliminating the dependency on libstdc++. * std: Runtime scheduling and I/O functionality has been factored out into extensible interfaces and is now implemented by two different crates: libnative, for native threading and I/O; and libgreen, for green threading and I/O. This paves the way for using the standard library in more limited embeded environments. * std: The `comm` module has been rewritten to be much faster, have a simpler, more consistent API, and to work for both native and green threading. * std: All libuv dependencies have been moved into the rustuv crate. * native: New implementations of runtime scheduling on top of OS threads. * native: New native implementations of TCP, UDP, file I/O, process spawning, and other I/O. * green: The green thread scheduler and message passing types are almost entirely lock-free. * extra: The `flatpipes` module had bitrotted and was removed. * extra: All crypto functions have been removed and Rust now has a policy of not reimplementing crypto in the standard library. In the future crypto will be provided by external crates with bindings to established libraries. * extra: `c_vec` has been modernized. * extra: The `sort` module has been removed. Use the `sort` method on mutable slices. * Tooling * The `rust` and `rusti` commands have been removed, due to lack of maintenance. * `rustdoc` was completely rewritten. * `rustdoc` can test code examples in documentation. * `rustpkg` can test packages with the argument, 'test'. * `rustpkg` supports arbitrary dependencies, including C libraries. * `rustc`'s support for generating debug info is improved again. * `rustc` has better error reporting for unbalanced delimiters. * `rustc`'s JIT support was removed due to bitrot. * Executables and static libraries can be built with LTO (-Z lto) * `rustc` adds a `--dep-info` flag for communicating dependencies to build tools. Contributors to Rust 0.9 ------------------------ Adrien T?tar Alan Andrade Alexandros Tasos Alex Crichton a_m0d Andreas Neuhaus Andreas Ots Andrei Formiga Benjamin Herr Benjamin Peterson Birunthan Mohanathas blake2-ppc Branimir Brendan Zabarauskas Brian Anderson Brian Cadence Marseille Carl-Anton Ingmarsson Carol Willing Carter Tazio Schonwald chitra Chris Morgan Chris Sainty Corey Richardson Dan Connolly Daniel Micay Dan Luu Dave Hodder David Creswick David Renshaw Diego Ongaro Dirkjan Bussink Dmitry Ermolov Do Nhat Minh Eduard Burtescu Edward Z. Yang eliovir Eric Biggers Eric Holk Erick Tryzelaar Erik Lyon Erik Price Fabrice Desr? Felix S. Klock II Flavio Percoco flo-l Florian Gilcher Florian Hahn Florian Zeitz g3xzh Gareth Smith Geoff Hill Geoffroy Couprie Georges Dubus gifnksm Guillaume Pinot Gyorgy Andrasek Harry Marr Heather Huon Wilson Ian Daniher Igor Bukanov Isaac Dupree Jack Moffitt Jaemin Moon Jan Niklas Hasse Jannis Harder Jason Orendorff Jason Toffaletti Jay Anderson Jed Davis Jeff Olson Joe Schafer John Louis Walker Jordi Boggiano Joshua Yanovski Julia Evans Jyun-Yan You Keegan McAllister Kevin Ballard Kiet Tran klutzy kud1ing Leah Hanson LEE Wondong Le?o Testard Lindsey Kuper Luca Bruno Luis de Bethencourt Luqman Aden lyuts Mark Rowe Marvin L?bel Matt Carberry Matthew Auld Matthew Iselin Micah Chalmer Michael 'devbug' Williams Michael Letterle Michael Woerister niftynif Niko Matsakis Noufal Ibrahim Olivier Saut osa1 Palmer Cox

Patrick Walton Peter Zotov Philipp Br?schweiler Raphael Speyer reedlepee Richard Diamond Robert Irelan Scott Lawrence S?bastien Chauvel S?bastien Crozet S?bastien Paolacci Seo Sanghyeon sh8281.kim SiegeLord sp3d S Pradeep Kumar Steve Klabnik Steven Fackler Strahinja Val Markovic Tim Chevalier Tomas Sedovic Vadim Chugunov Vijay Korapaty Volker Mische Young-il Choi Zach Kamsler Zack Corr Ziad Hatahet _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Jan 9 13:04:35 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 13:04:35 -0800 Subject: [rust-dev] Rust 0.9 released In-Reply-To: <52CF0ECD.5050405@mozilla.com> References: <52CF0ECD.5050405@mozilla.com> Message-ID: <52CF0EE3.20404@mozilla.com> Just in case somebody wants one with the correct title. So sad. On 01/09/2014 01:04 PM, Brian Anderson wrote: > Mozilla and the Rust community are pleased to announce version 0.9 of the > Rust compiler and tools. Rust is a systems programming language with a > focus on safety, performance and concurrency. > > This was another eventful release in which we made extensive improvements > to the runtime and I/O subsystem, introduced static linking and link-time > optimization, and reduced the variety of closures in the language. 0.9 > also > begins a final series of planned changes to how pointers are treated in > Rust, starting with the deprecation of the built-in "managed pointer" > type > and its accompanying `@` sigil, and the introduction of smart pointer > types > to the standard library. > > The brief release notes are included in this announcement, and there is > further explanation in the detailed release [notes] on the wiki. > Documentation and all the links in this email are available on the > [website]. As usual, version 0.9 should be considered an alpha release, > suitable for early adopters and language enthusiasts. Please file [bugs] > and join the [fun]. > > [website]: http://www.rust-lang.org > [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes > [bugs]: https://github.com/mozilla/rust/issues > [fun]: > https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors > > This release is available as both a tarball and a Windows installer: > > * http://static.rust-lang.org/dist/rust-0.9.tar.gz > http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc > SHA256 (of .tar.gz): > c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 > > * http://static.rust-lang.org/dist/rust-0.9-install.exe > http://static.rust-lang.org/dist/rust-0.9-install.exe.asc > SHA256 (of .exe): > 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 > > Thanks to everyone who contributed! > > Regards, > The Rust Team > > > Version 0.9 (January 2014) > -------------------------- > > * Language > * The `float` type has been removed. Use `f32` or `f64` instead. > * A new facility for enabling experimental features (feature gating) > has been added, using the crate-level `#[feature(foo)]` attribute. > * Managed boxes (@) are now behind a feature gate > (`#[feature(managed_boxes)]`) in preperation for future removal. Use > the standard library's `Gc` or `Rc` types instead. > * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. > * Jumping back to the top of a loop is now done with `continue` instead > of `loop`. > * Strings can no longer be mutated through index assignment. > * Raw strings can be created via the basic `r"foo"` syntax or with > matched hash delimiters, as in `r###"foo"###`. > * `~fn` is now written `proc (args) -> retval { ... }` and may only be > called once. > * The `&fn` type is now written `|args| -> ret` to match the literal > form. > * `@fn`s have been removed. > * `do` only works with procs in order to make it obvious what the cost > of `do` is. > * Single-element tuple-like structs can no longer be dereferenced to > obtain the inner value. A more comprehensive solution for overloading > the dereference operator will be provided in the future. > * The `#[link(...)]` attribute has been replaced with > `#[crate_id = "name#vers"]`. > * Empty `impl`s must be terminated with empty braces and may not be > terminated with a semicolon. > * Keywords are no longer allowed as lifetime names; the `self` lifetime > no longer has any special meaning. > * The old `fmt!` string formatting macro has been removed. > * `printf!` and `printfln!` (old-style formatting) removed in favor of > `print!` and `println!`. > * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. > * The `extern mod foo (name = "bar")` syntax has been removed. Use > `extern mod foo = "bar"` instead. > * New reserved keywords: `alignof`, `offsetof`, `sizeof`. > * Macros can have attributes. > * Macros can expand to items with attributes. > * Macros can expand to multiple items. > * The `asm!` macro is feature-gated (`#[feature(asm)]`). > * Comments may be nested. > * Values automatically coerce to trait objects they implement, without > an explicit `as`. > * Enum discriminants are no longer an entire word but as small as needed > to contain all the variants. The `repr` attribute can be used to > override the discriminant size, as in `#[repr(int)]` for integer-sized, > and `#[repr(C)]` to match C enums. > * Non-string literals are not allowed in attributes (they never worked). > * The FFI now supports variadic functions. > * Octal numeric literals, as in `0o7777`. > * The `concat!` syntax extension performs compile-time string > concatenation. > * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been > removed as Rust no longer uses segmented stacks. > * Non-ascii identifiers are feature-gated > (`#[feature(non_ascii_idents)]`). > * Ignoring all fields of an enum variant or tuple-struct is done with > `..`, not `*`; ignoring remaining fields of a struct is also done > with `..`, not `_`; ignoring a slice of a vector is done with `..`, > not `.._`. > * `rustc` supports the "win64" calling convention via `extern "win64"`. > * `rustc` supports the "system" calling convention, which defaults to > the preferred convention for the target platform, "stdcall" on 32-bit > Windows, "C" elsewhere. > * The `type_overflow` lint (default: warn) checks literals for overflow. > * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. > * The `attribute_usage` lint (default: warn) warns about unknown > attributes. > * The `unknown_features` lint (default: warn) warns about unknown > feature gates. > * The `dead_code` lint (default: warn) checks for dead code. > * Rust libraries can be linked statically to one another > * `#[link_args]` is behind the `link_args` feature gate. > * Native libraries are now linked with `#[link(name = "foo")]` > * Native libraries can be statically linked to a rust crate > (`#[link(name = "foo", kind = "static")]`). > * Native OS X frameworks are now officially supported > (`#[link(name = "foo", kind = "framework")]`). > * The `#[thread_local]` attribute creates thread-local (not task-local) > variables. Currently behind the `thread_local` feature gate. > * The `return` keyword may be used in closures. > * Types that can be copied via a memcpy implement the `Pod` kind. > * The `cfg` attribute can now be used on struct fields and enum variants. > > * Libraries > * std: The `option` and `result` API's have been overhauled to make them > simpler, more consistent, and more composable. > * std: The entire `std::io` module has been replaced with one that is > more comprehensive and that properly interfaces with the underlying > scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all > implemented. > * std: `io::util` contains a number of useful implementations of > `Reader` and `Writer`, including `NullReader`, `NullWriter`, > `ZeroReader`, `TeeReader`. > * std: The reference counted pointer type `extra::rc` moved into std. > * std: The `Gc` type in the `gc` module will replace `@` (it is currently > just a wrapper around it). > * std: The `Either` type has been removed. > * std: `fmt::Default` can be implemented for any type to provide default > formatting to the `format!` macro, as in `format!("{}", myfoo)`. > * std: The `rand` API continues to be tweaked. > * std: The `rust_begin_unwind` function, useful for inserting > breakpoints on failure in gdb, is now named `rust_fail`. > * std: The `each_key` and `each_value` methods on `HashMap` have been > replaced by the `keys` and `values` iterators. > * std: Functions dealing with type size and alignment have moved from > the `sys` module to the `mem` module. > * std: The `path` module was written and API changed. > * std: `str::from_utf8` has been changed to cast instead of allocate. > * std: `starts_with` and `ends_with` methods added to vectors via the > `ImmutableEqVector` trait, which is in the prelude. > * std: Vectors can be indexed with the `get_opt` method, which returns > `None` if the index is out of bounds. > * std: Task failure no longer propagates between tasks, as the model > was complex, expensive, and incompatible with thread-based tasks. > * std: The `Any` type can be used for dynamic typing. > * std: `~Any` can be passed to the `fail!` macro and retrieved via > `task::try`. > * std: Methods that produce iterators generally do not have an `_iter` > suffix now. > * std: `cell::Cell` and `cell::RefCell` can be used to introduc > mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. > * std: `util::ignore` renamed to `prelude::drop`. > * std: Slices have `sort` and `sort_by` methods via the `MutableVector` > trait. > * std: `vec::raw` has seen a lot of cleanup and API changes. > * std: The standard library no longer includes any C++ code, and very > minimal C, eliminating the dependency on libstdc++. > * std: Runtime scheduling and I/O functionality has been factored out > into extensible interfaces and is now implemented by two different > crates: libnative, for native threading and I/O; and libgreen, for > green threading and I/O. This paves the way for using the standard > library in more limited embeded environments. > * std: The `comm` module has been rewritten to be much faster, have a > simpler, more consistent API, and to work for both native and green > threading. > * std: All libuv dependencies have been moved into the rustuv crate. > * native: New implementations of runtime scheduling on top of OS > threads. > * native: New native implementations of TCP, UDP, file I/O, process > spawning, and other I/O. > * green: The green thread scheduler and message passing types are > almost entirely lock-free. > * extra: The `flatpipes` module had bitrotted and was removed. > * extra: All crypto functions have been removed and Rust now has a > policy of not reimplementing crypto in the standard library. In the > future crypto will be provided by external crates with bindings to > established libraries. > * extra: `c_vec` has been modernized. > * extra: The `sort` module has been removed. Use the `sort` method on > mutable slices. > > * Tooling > * The `rust` and `rusti` commands have been removed, due to lack of > maintenance. > * `rustdoc` was completely rewritten. > * `rustdoc` can test code examples in documentation. > * `rustpkg` can test packages with the argument, 'test'. > * `rustpkg` supports arbitrary dependencies, including C libraries. > * `rustc`'s support for generating debug info is improved again. > * `rustc` has better error reporting for unbalanced delimiters. > * `rustc`'s JIT support was removed due to bitrot. > * Executables and static libraries can be built with LTO (-Z lto) > * `rustc` adds a `--dep-info` flag for communicating dependencies to > build tools. > > > Contributors to Rust 0.9 > ------------------------ > > Adrien T?tar > Alan Andrade > Alexandros Tasos > Alex Crichton > a_m0d > Andreas Neuhaus > Andreas Ots > Andrei Formiga > Benjamin Herr > Benjamin Peterson > Birunthan Mohanathas > blake2-ppc > Branimir > Brendan Zabarauskas > Brian Anderson > Brian > Cadence Marseille > Carl-Anton Ingmarsson > Carol Willing > Carter Tazio Schonwald > chitra > Chris Morgan > Chris Sainty > Corey Richardson > Dan Connolly > Daniel Micay > Dan Luu > Dave Hodder > David Creswick > David Renshaw > Diego Ongaro > Dirkjan Bussink > Dmitry Ermolov > Do Nhat Minh > Eduard Burtescu > Edward Z. Yang > eliovir > Eric Biggers > Eric Holk > Erick Tryzelaar > Erik Lyon > Erik Price > Fabrice Desr? > Felix S. Klock II > Flavio Percoco > flo-l > Florian Gilcher > Florian Hahn > Florian Zeitz > g3xzh > Gareth Smith > Geoff Hill > Geoffroy Couprie > Georges Dubus > gifnksm > Guillaume Pinot > Gyorgy Andrasek > Harry Marr > Heather > Huon Wilson > Ian Daniher > Igor Bukanov > Isaac Dupree > Jack Moffitt > Jaemin Moon > Jan Niklas Hasse > Jannis Harder > Jason Orendorff > Jason Toffaletti > Jay Anderson > Jed Davis > Jeff Olson > Joe Schafer > John Louis Walker > Jordi Boggiano > Joshua Yanovski > Julia Evans > Jyun-Yan You > Keegan McAllister > Kevin Ballard > Kiet Tran > klutzy > kud1ing > Leah Hanson > LEE Wondong > Le?o Testard > Lindsey Kuper > Luca Bruno > Luis de Bethencourt > Luqman Aden > lyuts > Mark Rowe > Marvin L?bel > Matt Carberry > Matthew Auld > Matthew Iselin > Micah Chalmer > Michael 'devbug' Williams > Michael Letterle > Michael Woerister > niftynif > Niko Matsakis > Noufal Ibrahim > Olivier Saut > osa1 > Palmer Cox

> Patrick Walton > Peter Zotov > Philipp Br?schweiler > Raphael Speyer > reedlepee > Richard Diamond > Robert Irelan > Scott Lawrence > S?bastien Chauvel > S?bastien Crozet > S?bastien Paolacci > Seo Sanghyeon > sh8281.kim > SiegeLord > sp3d > S Pradeep Kumar > Steve Klabnik > Steven Fackler > Strahinja Val Markovic > Tim Chevalier > Tomas Sedovic > Vadim Chugunov > Vijay Korapaty > Volker Mische > Young-il Choi > Zach Kamsler > Zack Corr > Ziad Hatahet > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Thu Jan 9 13:10:37 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Thu, 9 Jan 2014 16:10:37 -0500 Subject: [rust-dev] Rust 0.9 released In-Reply-To: <52CF0ECD.5050405@mozilla.com> References: <52CF0ECD.5050405@mozilla.com> Message-ID: Congrats everyone! Here's to 0.10. :) On Thu, Jan 9, 2014 at 4:04 PM, Brian Anderson wrote: > Mozilla and the Rust community are pleased to announce version 0.9 of the > Rust compiler and tools. Rust is a systems programming language with a > focus on safety, performance and concurrency. > > This was another eventful release in which we made extensive improvements > to the runtime and I/O subsystem, introduced static linking and link-time > optimization, and reduced the variety of closures in the language. 0.9 > also > begins a final series of planned changes to how pointers are treated in > Rust, starting with the deprecation of the built-in "managed pointer" type > and its accompanying `@` sigil, and the introduction of smart pointer > types > to the standard library. > > The brief release notes are included in this announcement, and there is > further explanation in the detailed release [notes] on the wiki. > Documentation and all the links in this email are available on the > [website]. As usual, version 0.9 should be considered an alpha release, > suitable for early adopters and language enthusiasts. Please file [bugs] > and join the [fun]. > > [website]: http://www.rust-lang.org > [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes > [bugs]: https://github.com/mozilla/rust/issues > [fun]: > https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors > > This release is available as both a tarball and a Windows installer: > > * http://static.rust-lang.org/dist/rust-0.9.tar.gz > http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc > SHA256 (of .tar.gz): > c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 > > * http://static.rust-lang.org/dist/rust-0.9-install.exe > http://static.rust-lang.org/dist/rust-0.9-install.exe.asc > SHA256 (of .exe): > 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 > > Thanks to everyone who contributed! > > Regards, > The Rust Team > > > Version 0.9 (January 2014) > -------------------------- > > * Language > * The `float` type has been removed. Use `f32` or `f64` instead. > * A new facility for enabling experimental features (feature gating) > has been added, using the crate-level `#[feature(foo)]` attribute. > * Managed boxes (@) are now behind a feature gate > (`#[feature(managed_boxes)]`) in preperation for future removal. Use > the standard library's `Gc` or `Rc` types instead. > * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. > * Jumping back to the top of a loop is now done with `continue` instead > of `loop`. > * Strings can no longer be mutated through index assignment. > * Raw strings can be created via the basic `r"foo"` syntax or with > matched hash delimiters, as in `r###"foo"###`. > * `~fn` is now written `proc (args) -> retval { ... }` and may only be > called once. > * The `&fn` type is now written `|args| -> ret` to match the literal > form. > * `@fn`s have been removed. > * `do` only works with procs in order to make it obvious what the cost > of `do` is. > * Single-element tuple-like structs can no longer be dereferenced to > obtain the inner value. A more comprehensive solution for overloading > the dereference operator will be provided in the future. > * The `#[link(...)]` attribute has been replaced with > `#[crate_id = "name#vers"]`. > * Empty `impl`s must be terminated with empty braces and may not be > terminated with a semicolon. > * Keywords are no longer allowed as lifetime names; the `self` lifetime > no longer has any special meaning. > * The old `fmt!` string formatting macro has been removed. > * `printf!` and `printfln!` (old-style formatting) removed in favor of > `print!` and `println!`. > * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. > * The `extern mod foo (name = "bar")` syntax has been removed. Use > `extern mod foo = "bar"` instead. > * New reserved keywords: `alignof`, `offsetof`, `sizeof`. > * Macros can have attributes. > * Macros can expand to items with attributes. > * Macros can expand to multiple items. > * The `asm!` macro is feature-gated (`#[feature(asm)]`). > * Comments may be nested. > * Values automatically coerce to trait objects they implement, without > an explicit `as`. > * Enum discriminants are no longer an entire word but as small as needed > to contain all the variants. The `repr` attribute can be used to > override the discriminant size, as in `#[repr(int)]` for integer-sized, > and `#[repr(C)]` to match C enums. > * Non-string literals are not allowed in attributes (they never worked). > * The FFI now supports variadic functions. > * Octal numeric literals, as in `0o7777`. > * The `concat!` syntax extension performs compile-time string > concatenation. > * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been > removed as Rust no longer uses segmented stacks. > * Non-ascii identifiers are feature-gated > (`#[feature(non_ascii_idents)]`). > * Ignoring all fields of an enum variant or tuple-struct is done with > `..`, not `*`; ignoring remaining fields of a struct is also done > with `..`, not `_`; ignoring a slice of a vector is done with `..`, > not `.._`. > * `rustc` supports the "win64" calling convention via `extern "win64"`. > * `rustc` supports the "system" calling convention, which defaults to > the preferred convention for the target platform, "stdcall" on 32-bit > Windows, "C" elsewhere. > * The `type_overflow` lint (default: warn) checks literals for overflow. > * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. > * The `attribute_usage` lint (default: warn) warns about unknown > attributes. > * The `unknown_features` lint (default: warn) warns about unknown > feature gates. > * The `dead_code` lint (default: warn) checks for dead code. > * Rust libraries can be linked statically to one another > * `#[link_args]` is behind the `link_args` feature gate. > * Native libraries are now linked with `#[link(name = "foo")]` > * Native libraries can be statically linked to a rust crate > (`#[link(name = "foo", kind = "static")]`). > * Native OS X frameworks are now officially supported > (`#[link(name = "foo", kind = "framework")]`). > * The `#[thread_local]` attribute creates thread-local (not task-local) > variables. Currently behind the `thread_local` feature gate. > * The `return` keyword may be used in closures. > * Types that can be copied via a memcpy implement the `Pod` kind. > * The `cfg` attribute can now be used on struct fields and enum variants. > > * Libraries > * std: The `option` and `result` API's have been overhauled to make them > simpler, more consistent, and more composable. > * std: The entire `std::io` module has been replaced with one that is > more comprehensive and that properly interfaces with the underlying > scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all > implemented. > * std: `io::util` contains a number of useful implementations of > `Reader` and `Writer`, including `NullReader`, `NullWriter`, > `ZeroReader`, `TeeReader`. > * std: The reference counted pointer type `extra::rc` moved into std. > * std: The `Gc` type in the `gc` module will replace `@` (it is currently > just a wrapper around it). > * std: The `Either` type has been removed. > * std: `fmt::Default` can be implemented for any type to provide default > formatting to the `format!` macro, as in `format!("{}", myfoo)`. > * std: The `rand` API continues to be tweaked. > * std: The `rust_begin_unwind` function, useful for inserting > breakpoints on failure in gdb, is now named `rust_fail`. > * std: The `each_key` and `each_value` methods on `HashMap` have been > replaced by the `keys` and `values` iterators. > * std: Functions dealing with type size and alignment have moved from > the `sys` module to the `mem` module. > * std: The `path` module was written and API changed. > * std: `str::from_utf8` has been changed to cast instead of allocate. > * std: `starts_with` and `ends_with` methods added to vectors via the > `ImmutableEqVector` trait, which is in the prelude. > * std: Vectors can be indexed with the `get_opt` method, which returns > `None` if the index is out of bounds. > * std: Task failure no longer propagates between tasks, as the model > was complex, expensive, and incompatible with thread-based tasks. > * std: The `Any` type can be used for dynamic typing. > * std: `~Any` can be passed to the `fail!` macro and retrieved via > `task::try`. > * std: Methods that produce iterators generally do not have an `_iter` > suffix now. > * std: `cell::Cell` and `cell::RefCell` can be used to introduc > mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. > * std: `util::ignore` renamed to `prelude::drop`. > * std: Slices have `sort` and `sort_by` methods via the `MutableVector` > trait. > * std: `vec::raw` has seen a lot of cleanup and API changes. > * std: The standard library no longer includes any C++ code, and very > minimal C, eliminating the dependency on libstdc++. > * std: Runtime scheduling and I/O functionality has been factored out > into extensible interfaces and is now implemented by two different > crates: libnative, for native threading and I/O; and libgreen, for > green threading and I/O. This paves the way for using the standard > library in more limited embeded environments. > * std: The `comm` module has been rewritten to be much faster, have a > simpler, more consistent API, and to work for both native and green > threading. > * std: All libuv dependencies have been moved into the rustuv crate. > * native: New implementations of runtime scheduling on top of OS > threads. > * native: New native implementations of TCP, UDP, file I/O, process > spawning, and other I/O. > * green: The green thread scheduler and message passing types are > almost entirely lock-free. > * extra: The `flatpipes` module had bitrotted and was removed. > * extra: All crypto functions have been removed and Rust now has a > policy of not reimplementing crypto in the standard library. In the > future crypto will be provided by external crates with bindings to > established libraries. > * extra: `c_vec` has been modernized. > * extra: The `sort` module has been removed. Use the `sort` method on > mutable slices. > > * Tooling > * The `rust` and `rusti` commands have been removed, due to lack of > maintenance. > * `rustdoc` was completely rewritten. > * `rustdoc` can test code examples in documentation. > * `rustpkg` can test packages with the argument, 'test'. > * `rustpkg` supports arbitrary dependencies, including C libraries. > * `rustc`'s support for generating debug info is improved again. > * `rustc` has better error reporting for unbalanced delimiters. > * `rustc`'s JIT support was removed due to bitrot. > * Executables and static libraries can be built with LTO (-Z lto) > * `rustc` adds a `--dep-info` flag for communicating dependencies to > build tools. > > > Contributors to Rust 0.9 > ------------------------ > > Adrien T?tar > Alan Andrade > Alexandros Tasos > Alex Crichton > a_m0d > Andreas Neuhaus > Andreas Ots > Andrei Formiga > Benjamin Herr > Benjamin Peterson > Birunthan Mohanathas > blake2-ppc > Branimir > Brendan Zabarauskas > Brian Anderson > Brian > Cadence Marseille > Carl-Anton Ingmarsson > Carol Willing > Carter Tazio Schonwald > chitra > Chris Morgan > Chris Sainty > Corey Richardson > Dan Connolly > Daniel Micay > Dan Luu > Dave Hodder > David Creswick > David Renshaw > Diego Ongaro > Dirkjan Bussink > Dmitry Ermolov > Do Nhat Minh > Eduard Burtescu > Edward Z. Yang > eliovir > Eric Biggers > Eric Holk > Erick Tryzelaar > Erik Lyon > Erik Price > Fabrice Desr? > Felix S. Klock II > Flavio Percoco > flo-l > Florian Gilcher > Florian Hahn > Florian Zeitz > g3xzh > Gareth Smith > Geoff Hill > Geoffroy Couprie > Georges Dubus > gifnksm > Guillaume Pinot > Gyorgy Andrasek > Harry Marr > Heather > Huon Wilson > Ian Daniher > Igor Bukanov > Isaac Dupree > Jack Moffitt > Jaemin Moon > Jan Niklas Hasse > Jannis Harder > Jason Orendorff > Jason Toffaletti > Jay Anderson > Jed Davis > Jeff Olson > Joe Schafer > John Louis Walker > Jordi Boggiano > Joshua Yanovski > Julia Evans > Jyun-Yan You > Keegan McAllister > Kevin Ballard > Kiet Tran > klutzy > kud1ing > Leah Hanson > LEE Wondong > Le?o Testard > Lindsey Kuper > Luca Bruno > Luis de Bethencourt > Luqman Aden > lyuts > Mark Rowe > Marvin L?bel > Matt Carberry > Matthew Auld > Matthew Iselin > Micah Chalmer > Michael 'devbug' Williams > Michael Letterle > Michael Woerister > niftynif > Niko Matsakis > Noufal Ibrahim > Olivier Saut > osa1 > Palmer Cox

> Patrick Walton > Peter Zotov > Philipp Br?schweiler > Raphael Speyer > reedlepee > Richard Diamond > Robert Irelan > Scott Lawrence > S?bastien Chauvel > S?bastien Crozet > S?bastien Paolacci > Seo Sanghyeon > sh8281.kim > SiegeLord > sp3d > S Pradeep Kumar > Steve Klabnik > Steven Fackler > Strahinja Val Markovic > Tim Chevalier > Tomas Sedovic > Vadim Chugunov > Vijay Korapaty > Volker Mische > Young-il Choi > Zach Kamsler > Zack Corr > Ziad Hatahet > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mozilla at mcpherrin.ca Thu Jan 9 13:35:36 2014 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Thu, 9 Jan 2014 13:35:36 -0800 Subject: [rust-dev] Rust 0.9 released In-Reply-To: References: <52CF0ECD.5050405@mozilla.com> Message-ID: Fantastic release! I think Rust is really becoming a usable language for "real" projects. Great work from everyone involved! I look forward to future releases, and to building some great products in Rust! On Thu, Jan 9, 2014 at 1:10 PM, Benjamin Striegel wrote: > Congrats everyone! Here's to 0.10. :) > > > On Thu, Jan 9, 2014 at 4:04 PM, Brian Anderson > wrote: >> >> Mozilla and the Rust community are pleased to announce version 0.9 of the >> Rust compiler and tools. Rust is a systems programming language with a >> focus on safety, performance and concurrency. >> >> This was another eventful release in which we made extensive improvements >> to the runtime and I/O subsystem, introduced static linking and link-time >> optimization, and reduced the variety of closures in the language. 0.9 >> also >> begins a final series of planned changes to how pointers are treated in >> Rust, starting with the deprecation of the built-in "managed pointer" type >> and its accompanying `@` sigil, and the introduction of smart pointer >> types >> to the standard library. >> >> The brief release notes are included in this announcement, and there is >> further explanation in the detailed release [notes] on the wiki. >> Documentation and all the links in this email are available on the >> [website]. As usual, version 0.9 should be considered an alpha release, >> suitable for early adopters and language enthusiasts. Please file [bugs] >> and join the [fun]. >> >> [website]: http://www.rust-lang.org >> [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes >> [bugs]: https://github.com/mozilla/rust/issues >> [fun]: >> https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors >> >> This release is available as both a tarball and a Windows installer: >> >> * http://static.rust-lang.org/dist/rust-0.9.tar.gz >> http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc >> SHA256 (of .tar.gz): >> c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 >> >> * http://static.rust-lang.org/dist/rust-0.9-install.exe >> http://static.rust-lang.org/dist/rust-0.9-install.exe.asc >> SHA256 (of .exe): >> 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 >> >> Thanks to everyone who contributed! >> >> Regards, >> The Rust Team >> >> >> Version 0.9 (January 2014) >> -------------------------- >> >> * Language >> * The `float` type has been removed. Use `f32` or `f64` instead. >> * A new facility for enabling experimental features (feature gating) >> has been added, using the crate-level `#[feature(foo)]` attribute. >> * Managed boxes (@) are now behind a feature gate >> (`#[feature(managed_boxes)]`) in preperation for future removal. Use >> the standard library's `Gc` or `Rc` types instead. >> * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. >> * Jumping back to the top of a loop is now done with `continue` instead >> of `loop`. >> * Strings can no longer be mutated through index assignment. >> * Raw strings can be created via the basic `r"foo"` syntax or with >> matched hash delimiters, as in `r###"foo"###`. >> * `~fn` is now written `proc (args) -> retval { ... }` and may only be >> called once. >> * The `&fn` type is now written `|args| -> ret` to match the literal >> form. >> * `@fn`s have been removed. >> * `do` only works with procs in order to make it obvious what the cost >> of `do` is. >> * Single-element tuple-like structs can no longer be dereferenced to >> obtain the inner value. A more comprehensive solution for overloading >> the dereference operator will be provided in the future. >> * The `#[link(...)]` attribute has been replaced with >> `#[crate_id = "name#vers"]`. >> * Empty `impl`s must be terminated with empty braces and may not be >> terminated with a semicolon. >> * Keywords are no longer allowed as lifetime names; the `self` lifetime >> no longer has any special meaning. >> * The old `fmt!` string formatting macro has been removed. >> * `printf!` and `printfln!` (old-style formatting) removed in favor of >> `print!` and `println!`. >> * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. >> * The `extern mod foo (name = "bar")` syntax has been removed. Use >> `extern mod foo = "bar"` instead. >> * New reserved keywords: `alignof`, `offsetof`, `sizeof`. >> * Macros can have attributes. >> * Macros can expand to items with attributes. >> * Macros can expand to multiple items. >> * The `asm!` macro is feature-gated (`#[feature(asm)]`). >> * Comments may be nested. >> * Values automatically coerce to trait objects they implement, without >> an explicit `as`. >> * Enum discriminants are no longer an entire word but as small as needed >> to contain all the variants. The `repr` attribute can be used to >> override the discriminant size, as in `#[repr(int)]` for integer-sized, >> and `#[repr(C)]` to match C enums. >> * Non-string literals are not allowed in attributes (they never worked). >> * The FFI now supports variadic functions. >> * Octal numeric literals, as in `0o7777`. >> * The `concat!` syntax extension performs compile-time string >> concatenation. >> * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been >> removed as Rust no longer uses segmented stacks. >> * Non-ascii identifiers are feature-gated >> (`#[feature(non_ascii_idents)]`). >> * Ignoring all fields of an enum variant or tuple-struct is done with >> `..`, not `*`; ignoring remaining fields of a struct is also done >> with `..`, not `_`; ignoring a slice of a vector is done with `..`, >> not `.._`. >> * `rustc` supports the "win64" calling convention via `extern "win64"`. >> * `rustc` supports the "system" calling convention, which defaults to >> the preferred convention for the target platform, "stdcall" on 32-bit >> Windows, "C" elsewhere. >> * The `type_overflow` lint (default: warn) checks literals for overflow. >> * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. >> * The `attribute_usage` lint (default: warn) warns about unknown >> attributes. >> * The `unknown_features` lint (default: warn) warns about unknown >> feature gates. >> * The `dead_code` lint (default: warn) checks for dead code. >> * Rust libraries can be linked statically to one another >> * `#[link_args]` is behind the `link_args` feature gate. >> * Native libraries are now linked with `#[link(name = "foo")]` >> * Native libraries can be statically linked to a rust crate >> (`#[link(name = "foo", kind = "static")]`). >> * Native OS X frameworks are now officially supported >> (`#[link(name = "foo", kind = "framework")]`). >> * The `#[thread_local]` attribute creates thread-local (not task-local) >> variables. Currently behind the `thread_local` feature gate. >> * The `return` keyword may be used in closures. >> * Types that can be copied via a memcpy implement the `Pod` kind. >> * The `cfg` attribute can now be used on struct fields and enum variants. >> >> * Libraries >> * std: The `option` and `result` API's have been overhauled to make them >> simpler, more consistent, and more composable. >> * std: The entire `std::io` module has been replaced with one that is >> more comprehensive and that properly interfaces with the underlying >> scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all >> implemented. >> * std: `io::util` contains a number of useful implementations of >> `Reader` and `Writer`, including `NullReader`, `NullWriter`, >> `ZeroReader`, `TeeReader`. >> * std: The reference counted pointer type `extra::rc` moved into std. >> * std: The `Gc` type in the `gc` module will replace `@` (it is currently >> just a wrapper around it). >> * std: The `Either` type has been removed. >> * std: `fmt::Default` can be implemented for any type to provide default >> formatting to the `format!` macro, as in `format!("{}", myfoo)`. >> * std: The `rand` API continues to be tweaked. >> * std: The `rust_begin_unwind` function, useful for inserting >> breakpoints on failure in gdb, is now named `rust_fail`. >> * std: The `each_key` and `each_value` methods on `HashMap` have been >> replaced by the `keys` and `values` iterators. >> * std: Functions dealing with type size and alignment have moved from >> the `sys` module to the `mem` module. >> * std: The `path` module was written and API changed. >> * std: `str::from_utf8` has been changed to cast instead of allocate. >> * std: `starts_with` and `ends_with` methods added to vectors via the >> `ImmutableEqVector` trait, which is in the prelude. >> * std: Vectors can be indexed with the `get_opt` method, which returns >> `None` if the index is out of bounds. >> * std: Task failure no longer propagates between tasks, as the model >> was complex, expensive, and incompatible with thread-based tasks. >> * std: The `Any` type can be used for dynamic typing. >> * std: `~Any` can be passed to the `fail!` macro and retrieved via >> `task::try`. >> * std: Methods that produce iterators generally do not have an `_iter` >> suffix now. >> * std: `cell::Cell` and `cell::RefCell` can be used to introduc >> mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. >> * std: `util::ignore` renamed to `prelude::drop`. >> * std: Slices have `sort` and `sort_by` methods via the `MutableVector` >> trait. >> * std: `vec::raw` has seen a lot of cleanup and API changes. >> * std: The standard library no longer includes any C++ code, and very >> minimal C, eliminating the dependency on libstdc++. >> * std: Runtime scheduling and I/O functionality has been factored out >> into extensible interfaces and is now implemented by two different >> crates: libnative, for native threading and I/O; and libgreen, for >> green threading and I/O. This paves the way for using the standard >> library in more limited embeded environments. >> * std: The `comm` module has been rewritten to be much faster, have a >> simpler, more consistent API, and to work for both native and green >> threading. >> * std: All libuv dependencies have been moved into the rustuv crate. >> * native: New implementations of runtime scheduling on top of OS >> threads. >> * native: New native implementations of TCP, UDP, file I/O, process >> spawning, and other I/O. >> * green: The green thread scheduler and message passing types are >> almost entirely lock-free. >> * extra: The `flatpipes` module had bitrotted and was removed. >> * extra: All crypto functions have been removed and Rust now has a >> policy of not reimplementing crypto in the standard library. In the >> future crypto will be provided by external crates with bindings to >> established libraries. >> * extra: `c_vec` has been modernized. >> * extra: The `sort` module has been removed. Use the `sort` method on >> mutable slices. >> >> * Tooling >> * The `rust` and `rusti` commands have been removed, due to lack of >> maintenance. >> * `rustdoc` was completely rewritten. >> * `rustdoc` can test code examples in documentation. >> * `rustpkg` can test packages with the argument, 'test'. >> * `rustpkg` supports arbitrary dependencies, including C libraries. >> * `rustc`'s support for generating debug info is improved again. >> * `rustc` has better error reporting for unbalanced delimiters. >> * `rustc`'s JIT support was removed due to bitrot. >> * Executables and static libraries can be built with LTO (-Z lto) >> * `rustc` adds a `--dep-info` flag for communicating dependencies to >> build tools. >> >> >> Contributors to Rust 0.9 >> ------------------------ >> >> Adrien T?tar >> Alan Andrade >> Alexandros Tasos >> Alex Crichton >> a_m0d >> Andreas Neuhaus >> Andreas Ots >> Andrei Formiga >> Benjamin Herr >> Benjamin Peterson >> Birunthan Mohanathas >> blake2-ppc >> Branimir >> Brendan Zabarauskas >> Brian Anderson >> Brian >> Cadence Marseille >> Carl-Anton Ingmarsson >> Carol Willing >> Carter Tazio Schonwald >> chitra >> Chris Morgan >> Chris Sainty >> Corey Richardson >> Dan Connolly >> Daniel Micay >> Dan Luu >> Dave Hodder >> David Creswick >> David Renshaw >> Diego Ongaro >> Dirkjan Bussink >> Dmitry Ermolov >> Do Nhat Minh >> Eduard Burtescu >> Edward Z. Yang >> eliovir >> Eric Biggers >> Eric Holk >> Erick Tryzelaar >> Erik Lyon >> Erik Price >> Fabrice Desr? >> Felix S. Klock II >> Flavio Percoco >> flo-l >> Florian Gilcher >> Florian Hahn >> Florian Zeitz >> g3xzh >> Gareth Smith >> Geoff Hill >> Geoffroy Couprie >> Georges Dubus >> gifnksm >> Guillaume Pinot >> Gyorgy Andrasek >> Harry Marr >> Heather >> Huon Wilson >> Ian Daniher >> Igor Bukanov >> Isaac Dupree >> Jack Moffitt >> Jaemin Moon >> Jan Niklas Hasse >> Jannis Harder >> Jason Orendorff >> Jason Toffaletti >> Jay Anderson >> Jed Davis >> Jeff Olson >> Joe Schafer >> John Louis Walker >> Jordi Boggiano >> Joshua Yanovski >> Julia Evans >> Jyun-Yan You >> Keegan McAllister >> Kevin Ballard >> Kiet Tran >> klutzy >> kud1ing >> Leah Hanson >> LEE Wondong >> Le?o Testard >> Lindsey Kuper >> Luca Bruno >> Luis de Bethencourt >> Luqman Aden >> lyuts >> Mark Rowe >> Marvin L?bel >> Matt Carberry >> Matthew Auld >> Matthew Iselin >> Micah Chalmer >> Michael 'devbug' Williams >> Michael Letterle >> Michael Woerister >> niftynif >> Niko Matsakis >> Noufal Ibrahim >> Olivier Saut >> osa1 >> Palmer Cox

>> Patrick Walton >> Peter Zotov >> Philipp Br?schweiler >> Raphael Speyer >> reedlepee >> Richard Diamond >> Robert Irelan >> Scott Lawrence >> S?bastien Chauvel >> S?bastien Crozet >> S?bastien Paolacci >> Seo Sanghyeon >> sh8281.kim >> SiegeLord >> sp3d >> S Pradeep Kumar >> Steve Klabnik >> Steven Fackler >> Strahinja Val Markovic >> Tim Chevalier >> Tomas Sedovic >> Vadim Chugunov >> Vijay Korapaty >> Volker Mische >> Young-il Choi >> Zach Kamsler >> Zack Corr >> Ziad Hatahet >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From hatahet at gmail.com Thu Jan 9 13:35:56 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 9 Jan 2014 13:35:56 -0800 Subject: [rust-dev] Rust 0.9 released In-Reply-To: References: <52CF0ECD.5050405@mozilla.com> Message-ID: Awesome job! Keep up the good work. -- Ziad On Thu, Jan 9, 2014 at 1:10 PM, Benjamin Striegel wrote: > Congrats everyone! Here's to 0.10. :) > > > On Thu, Jan 9, 2014 at 4:04 PM, Brian Anderson wrote: > >> Mozilla and the Rust community are pleased to announce version 0.9 of >> the >> Rust compiler and tools. Rust is a systems programming language with a >> focus on safety, performance and concurrency. >> >> This was another eventful release in which we made extensive improvements >> to the runtime and I/O subsystem, introduced static linking and link-time >> optimization, and reduced the variety of closures in the language. 0.9 >> also >> begins a final series of planned changes to how pointers are treated in >> Rust, starting with the deprecation of the built-in "managed pointer" >> type >> and its accompanying `@` sigil, and the introduction of smart pointer >> types >> to the standard library. >> >> The brief release notes are included in this announcement, and there is >> further explanation in the detailed release [notes] on the wiki. >> Documentation and all the links in this email are available on the >> [website]. As usual, version 0.9 should be considered an alpha release, >> suitable for early adopters and language enthusiasts. Please file [bugs] >> and join the [fun]. >> >> [website]: http://www.rust-lang.org >> [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes >> [bugs]: https://github.com/mozilla/rust/issues >> [fun]: >> https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors >> >> This release is available as both a tarball and a Windows installer: >> >> * http://static.rust-lang.org/dist/rust-0.9.tar.gz >> http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc >> SHA256 (of .tar.gz): >> c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 >> >> * http://static.rust-lang.org/dist/rust-0.9-install.exe >> http://static.rust-lang.org/dist/rust-0.9-install.exe.asc >> SHA256 (of .exe): >> 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 >> >> Thanks to everyone who contributed! >> >> Regards, >> The Rust Team >> >> >> Version 0.9 (January 2014) >> -------------------------- >> >> * Language >> * The `float` type has been removed. Use `f32` or `f64` instead. >> * A new facility for enabling experimental features (feature gating) >> has been added, using the crate-level `#[feature(foo)]` attribute. >> * Managed boxes (@) are now behind a feature gate >> (`#[feature(managed_boxes)]`) in preperation for future removal. Use >> the standard library's `Gc` or `Rc` types instead. >> * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. >> * Jumping back to the top of a loop is now done with `continue` instead >> of `loop`. >> * Strings can no longer be mutated through index assignment. >> * Raw strings can be created via the basic `r"foo"` syntax or with >> matched hash delimiters, as in `r###"foo"###`. >> * `~fn` is now written `proc (args) -> retval { ... }` and may only be >> called once. >> * The `&fn` type is now written `|args| -> ret` to match the literal >> form. >> * `@fn`s have been removed. >> * `do` only works with procs in order to make it obvious what the cost >> of `do` is. >> * Single-element tuple-like structs can no longer be dereferenced to >> obtain the inner value. A more comprehensive solution for overloading >> the dereference operator will be provided in the future. >> * The `#[link(...)]` attribute has been replaced with >> `#[crate_id = "name#vers"]`. >> * Empty `impl`s must be terminated with empty braces and may not be >> terminated with a semicolon. >> * Keywords are no longer allowed as lifetime names; the `self` lifetime >> no longer has any special meaning. >> * The old `fmt!` string formatting macro has been removed. >> * `printf!` and `printfln!` (old-style formatting) removed in favor of >> `print!` and `println!`. >> * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. >> * The `extern mod foo (name = "bar")` syntax has been removed. Use >> `extern mod foo = "bar"` instead. >> * New reserved keywords: `alignof`, `offsetof`, `sizeof`. >> * Macros can have attributes. >> * Macros can expand to items with attributes. >> * Macros can expand to multiple items. >> * The `asm!` macro is feature-gated (`#[feature(asm)]`). >> * Comments may be nested. >> * Values automatically coerce to trait objects they implement, without >> an explicit `as`. >> * Enum discriminants are no longer an entire word but as small as needed >> to contain all the variants. The `repr` attribute can be used to >> override the discriminant size, as in `#[repr(int)]` for integer-sized, >> and `#[repr(C)]` to match C enums. >> * Non-string literals are not allowed in attributes (they never worked). >> * The FFI now supports variadic functions. >> * Octal numeric literals, as in `0o7777`. >> * The `concat!` syntax extension performs compile-time string >> concatenation. >> * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been >> removed as Rust no longer uses segmented stacks. >> * Non-ascii identifiers are feature-gated >> (`#[feature(non_ascii_idents)]`). >> * Ignoring all fields of an enum variant or tuple-struct is done with >> `..`, not `*`; ignoring remaining fields of a struct is also done >> with `..`, not `_`; ignoring a slice of a vector is done with `..`, >> not `.._`. >> * `rustc` supports the "win64" calling convention via `extern "win64"`. >> * `rustc` supports the "system" calling convention, which defaults to >> the preferred convention for the target platform, "stdcall" on 32-bit >> Windows, "C" elsewhere. >> * The `type_overflow` lint (default: warn) checks literals for overflow. >> * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. >> * The `attribute_usage` lint (default: warn) warns about unknown >> attributes. >> * The `unknown_features` lint (default: warn) warns about unknown >> feature gates. >> * The `dead_code` lint (default: warn) checks for dead code. >> * Rust libraries can be linked statically to one another >> * `#[link_args]` is behind the `link_args` feature gate. >> * Native libraries are now linked with `#[link(name = "foo")]` >> * Native libraries can be statically linked to a rust crate >> (`#[link(name = "foo", kind = "static")]`). >> * Native OS X frameworks are now officially supported >> (`#[link(name = "foo", kind = "framework")]`). >> * The `#[thread_local]` attribute creates thread-local (not task-local) >> variables. Currently behind the `thread_local` feature gate. >> * The `return` keyword may be used in closures. >> * Types that can be copied via a memcpy implement the `Pod` kind. >> * The `cfg` attribute can now be used on struct fields and enum variants. >> >> * Libraries >> * std: The `option` and `result` API's have been overhauled to make them >> simpler, more consistent, and more composable. >> * std: The entire `std::io` module has been replaced with one that is >> more comprehensive and that properly interfaces with the underlying >> scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all >> implemented. >> * std: `io::util` contains a number of useful implementations of >> `Reader` and `Writer`, including `NullReader`, `NullWriter`, >> `ZeroReader`, `TeeReader`. >> * std: The reference counted pointer type `extra::rc` moved into std. >> * std: The `Gc` type in the `gc` module will replace `@` (it is currently >> just a wrapper around it). >> * std: The `Either` type has been removed. >> * std: `fmt::Default` can be implemented for any type to provide default >> formatting to the `format!` macro, as in `format!("{}", myfoo)`. >> * std: The `rand` API continues to be tweaked. >> * std: The `rust_begin_unwind` function, useful for inserting >> breakpoints on failure in gdb, is now named `rust_fail`. >> * std: The `each_key` and `each_value` methods on `HashMap` have been >> replaced by the `keys` and `values` iterators. >> * std: Functions dealing with type size and alignment have moved from >> the `sys` module to the `mem` module. >> * std: The `path` module was written and API changed. >> * std: `str::from_utf8` has been changed to cast instead of allocate. >> * std: `starts_with` and `ends_with` methods added to vectors via the >> `ImmutableEqVector` trait, which is in the prelude. >> * std: Vectors can be indexed with the `get_opt` method, which returns >> `None` if the index is out of bounds. >> * std: Task failure no longer propagates between tasks, as the model >> was complex, expensive, and incompatible with thread-based tasks. >> * std: The `Any` type can be used for dynamic typing. >> * std: `~Any` can be passed to the `fail!` macro and retrieved via >> `task::try`. >> * std: Methods that produce iterators generally do not have an `_iter` >> suffix now. >> * std: `cell::Cell` and `cell::RefCell` can be used to introduc >> mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. >> * std: `util::ignore` renamed to `prelude::drop`. >> * std: Slices have `sort` and `sort_by` methods via the `MutableVector` >> trait. >> * std: `vec::raw` has seen a lot of cleanup and API changes. >> * std: The standard library no longer includes any C++ code, and very >> minimal C, eliminating the dependency on libstdc++. >> * std: Runtime scheduling and I/O functionality has been factored out >> into extensible interfaces and is now implemented by two different >> crates: libnative, for native threading and I/O; and libgreen, for >> green threading and I/O. This paves the way for using the standard >> library in more limited embeded environments. >> * std: The `comm` module has been rewritten to be much faster, have a >> simpler, more consistent API, and to work for both native and green >> threading. >> * std: All libuv dependencies have been moved into the rustuv crate. >> * native: New implementations of runtime scheduling on top of OS >> threads. >> * native: New native implementations of TCP, UDP, file I/O, process >> spawning, and other I/O. >> * green: The green thread scheduler and message passing types are >> almost entirely lock-free. >> * extra: The `flatpipes` module had bitrotted and was removed. >> * extra: All crypto functions have been removed and Rust now has a >> policy of not reimplementing crypto in the standard library. In the >> future crypto will be provided by external crates with bindings to >> established libraries. >> * extra: `c_vec` has been modernized. >> * extra: The `sort` module has been removed. Use the `sort` method on >> mutable slices. >> >> * Tooling >> * The `rust` and `rusti` commands have been removed, due to lack of >> maintenance. >> * `rustdoc` was completely rewritten. >> * `rustdoc` can test code examples in documentation. >> * `rustpkg` can test packages with the argument, 'test'. >> * `rustpkg` supports arbitrary dependencies, including C libraries. >> * `rustc`'s support for generating debug info is improved again. >> * `rustc` has better error reporting for unbalanced delimiters. >> * `rustc`'s JIT support was removed due to bitrot. >> * Executables and static libraries can be built with LTO (-Z lto) >> * `rustc` adds a `--dep-info` flag for communicating dependencies to >> build tools. >> >> >> Contributors to Rust 0.9 >> ------------------------ >> >> Adrien T?tar >> Alan Andrade >> Alexandros Tasos >> Alex Crichton >> a_m0d >> Andreas Neuhaus >> Andreas Ots >> Andrei Formiga >> Benjamin Herr >> Benjamin Peterson >> Birunthan Mohanathas >> blake2-ppc >> Branimir >> Brendan Zabarauskas >> Brian Anderson >> Brian >> Cadence Marseille >> Carl-Anton Ingmarsson >> Carol Willing >> Carter Tazio Schonwald >> chitra >> Chris Morgan >> Chris Sainty >> Corey Richardson >> Dan Connolly >> Daniel Micay >> Dan Luu >> Dave Hodder >> David Creswick >> David Renshaw >> Diego Ongaro >> Dirkjan Bussink >> Dmitry Ermolov >> Do Nhat Minh >> Eduard Burtescu >> Edward Z. Yang >> eliovir >> Eric Biggers >> Eric Holk >> Erick Tryzelaar >> Erik Lyon >> Erik Price >> Fabrice Desr? >> Felix S. Klock II >> Flavio Percoco >> flo-l >> Florian Gilcher >> Florian Hahn >> Florian Zeitz >> g3xzh >> Gareth Smith >> Geoff Hill >> Geoffroy Couprie >> Georges Dubus >> gifnksm >> Guillaume Pinot >> Gyorgy Andrasek >> Harry Marr >> Heather >> Huon Wilson >> Ian Daniher >> Igor Bukanov >> Isaac Dupree >> Jack Moffitt >> Jaemin Moon >> Jan Niklas Hasse >> Jannis Harder >> Jason Orendorff >> Jason Toffaletti >> Jay Anderson >> Jed Davis >> Jeff Olson >> Joe Schafer >> John Louis Walker >> Jordi Boggiano >> Joshua Yanovski >> Julia Evans >> Jyun-Yan You >> Keegan McAllister >> Kevin Ballard >> Kiet Tran >> klutzy >> kud1ing >> Leah Hanson >> LEE Wondong >> Le?o Testard >> Lindsey Kuper >> Luca Bruno >> Luis de Bethencourt >> Luqman Aden >> lyuts >> Mark Rowe >> Marvin L?bel >> Matt Carberry >> Matthew Auld >> Matthew Iselin >> Micah Chalmer >> Michael 'devbug' Williams >> Michael Letterle >> Michael Woerister >> niftynif >> Niko Matsakis >> Noufal Ibrahim >> Olivier Saut >> osa1 >> Palmer Cox

>> Patrick Walton >> Peter Zotov >> Philipp Br?schweiler >> Raphael Speyer >> reedlepee >> Richard Diamond >> Robert Irelan >> Scott Lawrence >> S?bastien Chauvel >> S?bastien Crozet >> S?bastien Paolacci >> Seo Sanghyeon >> sh8281.kim >> SiegeLord >> sp3d >> S Pradeep Kumar >> Steve Klabnik >> Steven Fackler >> Strahinja Val Markovic >> Tim Chevalier >> Tomas Sedovic >> Vadim Chugunov >> Vijay Korapaty >> Volker Mische >> Young-il Choi >> Zach Kamsler >> Zack Corr >> Ziad Hatahet >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Thu Jan 9 16:47:35 2014 From: ncm at cantrip.org (Nathan Myers) Date: Thu, 09 Jan 2014 16:47:35 -0800 Subject: [rust-dev] Rust 0.9 released In-Reply-To: <52CF0EE3.20404@mozilla.com> References: <52CF0ECD.5050405@mozilla.com> <52CF0EE3.20404@mozilla.com> Message-ID: <52CF4327.7080605@cantrip.org> Much blush Congratulations, this looks like a big step in a right direction, and in a very short time. When I build on Debian amd64 with g++-4.8.2, I get internal C++ compiler failures in stage 0. I run "make" again, and it builds OK for a while, and then dies on another file. It does finish stage 0 after a few cycles of this. Should I be using the "other" C++ compiler? Also, running "make -j4", I get failures like: /bin/mv: cannot stat `/tmp/rust-0.9/x86_64-unknown-linux-gnu/llvm/utils/TableGen/Release+Asserts/AsmMatcherEmitter.d.tmp': No such file or directory I haven't seen these when building with just "make". (0.8 built without hiccups on g++-4.7 and "make -j3".) Nathan Myers On 01/09/2014 01:04 PM, Brian Anderson wrote: > Just in case somebody wants one with the correct title. So sad. > > On 01/09/2014 01:04 PM, Brian Anderson wrote: >> Mozilla and the Rust community are pleased to announce version 0.9 of the >> Rust compiler and tools. Rust is a systems programming language with a >> focus on safety, performance and concurrency. >> >> This was another eventful release in which we made extensive improvements >> to the runtime and I/O subsystem, introduced static linking and link-time >> optimization, and reduced the variety of closures in the language. 0.9 >> also >> begins a final series of planned changes to how pointers are treated in >> Rust, starting with the deprecation of the built-in "managed pointer" >> type >> and its accompanying `@` sigil, and the introduction of smart pointer >> types >> to the standard library. >> >> The brief release notes are included in this announcement, and there is >> further explanation in the detailed release [notes] on the wiki. >> Documentation and all the links in this email are available on the >> [website]. As usual, version 0.9 should be considered an alpha release, >> suitable for early adopters and language enthusiasts. Please file [bugs] >> and join the [fun]. >> >> [website]: http://www.rust-lang.org >> [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes >> [bugs]: https://github.com/mozilla/rust/issues >> [fun]: >> https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors >> >> This release is available as both a tarball and a Windows installer: >> >> * http://static.rust-lang.org/dist/rust-0.9.tar.gz >> http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc >> SHA256 (of .tar.gz): >> c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 >> >> * http://static.rust-lang.org/dist/rust-0.9-install.exe >> http://static.rust-lang.org/dist/rust-0.9-install.exe.asc >> SHA256 (of .exe): >> 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 >> >> Thanks to everyone who contributed! >> >> Regards, >> The Rust Team >> >> >> Version 0.9 (January 2014) >> -------------------------- >> >> * Language >> * The `float` type has been removed. Use `f32` or `f64` instead. >> * A new facility for enabling experimental features (feature gating) >> has been added, using the crate-level `#[feature(foo)]` attribute. >> * Managed boxes (@) are now behind a feature gate >> (`#[feature(managed_boxes)]`) in preperation for future removal. Use >> the standard library's `Gc` or `Rc` types instead. >> * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. >> * Jumping back to the top of a loop is now done with `continue` instead >> of `loop`. >> * Strings can no longer be mutated through index assignment. >> * Raw strings can be created via the basic `r"foo"` syntax or with >> matched hash delimiters, as in `r###"foo"###`. >> * `~fn` is now written `proc (args) -> retval { ... }` and may only be >> called once. >> * The `&fn` type is now written `|args| -> ret` to match the literal >> form. >> * `@fn`s have been removed. >> * `do` only works with procs in order to make it obvious what the cost >> of `do` is. >> * Single-element tuple-like structs can no longer be dereferenced to >> obtain the inner value. A more comprehensive solution for overloading >> the dereference operator will be provided in the future. >> * The `#[link(...)]` attribute has been replaced with >> `#[crate_id = "name#vers"]`. >> * Empty `impl`s must be terminated with empty braces and may not be >> terminated with a semicolon. >> * Keywords are no longer allowed as lifetime names; the `self` lifetime >> no longer has any special meaning. >> * The old `fmt!` string formatting macro has been removed. >> * `printf!` and `printfln!` (old-style formatting) removed in favor of >> `print!` and `println!`. >> * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. >> * The `extern mod foo (name = "bar")` syntax has been removed. Use >> `extern mod foo = "bar"` instead. >> * New reserved keywords: `alignof`, `offsetof`, `sizeof`. >> * Macros can have attributes. >> * Macros can expand to items with attributes. >> * Macros can expand to multiple items. >> * The `asm!` macro is feature-gated (`#[feature(asm)]`). >> * Comments may be nested. >> * Values automatically coerce to trait objects they implement, without >> an explicit `as`. >> * Enum discriminants are no longer an entire word but as small as needed >> to contain all the variants. The `repr` attribute can be used to >> override the discriminant size, as in `#[repr(int)]` for integer-sized, >> and `#[repr(C)]` to match C enums. >> * Non-string literals are not allowed in attributes (they never worked). >> * The FFI now supports variadic functions. >> * Octal numeric literals, as in `0o7777`. >> * The `concat!` syntax extension performs compile-time string >> concatenation. >> * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been >> removed as Rust no longer uses segmented stacks. >> * Non-ascii identifiers are feature-gated >> (`#[feature(non_ascii_idents)]`). >> * Ignoring all fields of an enum variant or tuple-struct is done with >> `..`, not `*`; ignoring remaining fields of a struct is also done >> with `..`, not `_`; ignoring a slice of a vector is done with `..`, >> not `.._`. >> * `rustc` supports the "win64" calling convention via `extern "win64"`. >> * `rustc` supports the "system" calling convention, which defaults to >> the preferred convention for the target platform, "stdcall" on 32-bit >> Windows, "C" elsewhere. >> * The `type_overflow` lint (default: warn) checks literals for overflow. >> * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. >> * The `attribute_usage` lint (default: warn) warns about unknown >> attributes. >> * The `unknown_features` lint (default: warn) warns about unknown >> feature gates. >> * The `dead_code` lint (default: warn) checks for dead code. >> * Rust libraries can be linked statically to one another >> * `#[link_args]` is behind the `link_args` feature gate. >> * Native libraries are now linked with `#[link(name = "foo")]` >> * Native libraries can be statically linked to a rust crate >> (`#[link(name = "foo", kind = "static")]`). >> * Native OS X frameworks are now officially supported >> (`#[link(name = "foo", kind = "framework")]`). >> * The `#[thread_local]` attribute creates thread-local (not task-local) >> variables. Currently behind the `thread_local` feature gate. >> * The `return` keyword may be used in closures. >> * Types that can be copied via a memcpy implement the `Pod` kind. >> * The `cfg` attribute can now be used on struct fields and enum variants. >> >> * Libraries >> * std: The `option` and `result` API's have been overhauled to make them >> simpler, more consistent, and more composable. >> * std: The entire `std::io` module has been replaced with one that is >> more comprehensive and that properly interfaces with the underlying >> scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all >> implemented. >> * std: `io::util` contains a number of useful implementations of >> `Reader` and `Writer`, including `NullReader`, `NullWriter`, >> `ZeroReader`, `TeeReader`. >> * std: The reference counted pointer type `extra::rc` moved into std. >> * std: The `Gc` type in the `gc` module will replace `@` (it is currently >> just a wrapper around it). >> * std: The `Either` type has been removed. >> * std: `fmt::Default` can be implemented for any type to provide default >> formatting to the `format!` macro, as in `format!("{}", myfoo)`. >> * std: The `rand` API continues to be tweaked. >> * std: The `rust_begin_unwind` function, useful for inserting >> breakpoints on failure in gdb, is now named `rust_fail`. >> * std: The `each_key` and `each_value` methods on `HashMap` have been >> replaced by the `keys` and `values` iterators. >> * std: Functions dealing with type size and alignment have moved from >> the `sys` module to the `mem` module. >> * std: The `path` module was written and API changed. >> * std: `str::from_utf8` has been changed to cast instead of allocate. >> * std: `starts_with` and `ends_with` methods added to vectors via the >> `ImmutableEqVector` trait, which is in the prelude. >> * std: Vectors can be indexed with the `get_opt` method, which returns >> `None` if the index is out of bounds. >> * std: Task failure no longer propagates between tasks, as the model >> was complex, expensive, and incompatible with thread-based tasks. >> * std: The `Any` type can be used for dynamic typing. >> * std: `~Any` can be passed to the `fail!` macro and retrieved via >> `task::try`. >> * std: Methods that produce iterators generally do not have an `_iter` >> suffix now. >> * std: `cell::Cell` and `cell::RefCell` can be used to introduc >> mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. >> * std: `util::ignore` renamed to `prelude::drop`. >> * std: Slices have `sort` and `sort_by` methods via the `MutableVector` >> trait. >> * std: `vec::raw` has seen a lot of cleanup and API changes. >> * std: The standard library no longer includes any C++ code, and very >> minimal C, eliminating the dependency on libstdc++. >> * std: Runtime scheduling and I/O functionality has been factored out >> into extensible interfaces and is now implemented by two different >> crates: libnative, for native threading and I/O; and libgreen, for >> green threading and I/O. This paves the way for using the standard >> library in more limited embeded environments. >> * std: The `comm` module has been rewritten to be much faster, have a >> simpler, more consistent API, and to work for both native and green >> threading. >> * std: All libuv dependencies have been moved into the rustuv crate. >> * native: New implementations of runtime scheduling on top of OS >> threads. >> * native: New native implementations of TCP, UDP, file I/O, process >> spawning, and other I/O. >> * green: The green thread scheduler and message passing types are >> almost entirely lock-free. >> * extra: The `flatpipes` module had bitrotted and was removed. >> * extra: All crypto functions have been removed and Rust now has a >> policy of not reimplementing crypto in the standard library. In the >> future crypto will be provided by external crates with bindings to >> established libraries. >> * extra: `c_vec` has been modernized. >> * extra: The `sort` module has been removed. Use the `sort` method on >> mutable slices. >> >> * Tooling >> * The `rust` and `rusti` commands have been removed, due to lack of >> maintenance. >> * `rustdoc` was completely rewritten. >> * `rustdoc` can test code examples in documentation. >> * `rustpkg` can test packages with the argument, 'test'. >> * `rustpkg` supports arbitrary dependencies, including C libraries. >> * `rustc`'s support for generating debug info is improved again. >> * `rustc` has better error reporting for unbalanced delimiters. >> * `rustc`'s JIT support was removed due to bitrot. >> * Executables and static libraries can be built with LTO (-Z lto) >> * `rustc` adds a `--dep-info` flag for communicating dependencies to >> build tools. >> >> >> Contributors to Rust 0.9 >> ------------------------ >> >> Adrien T?tar >> Alan Andrade >> Alexandros Tasos >> Alex Crichton >> a_m0d >> Andreas Neuhaus >> Andreas Ots >> Andrei Formiga >> Benjamin Herr >> Benjamin Peterson >> Birunthan Mohanathas >> blake2-ppc >> Branimir >> Brendan Zabarauskas >> Brian Anderson >> Brian >> Cadence Marseille >> Carl-Anton Ingmarsson >> Carol Willing >> Carter Tazio Schonwald >> chitra >> Chris Morgan >> Chris Sainty >> Corey Richardson >> Dan Connolly >> Daniel Micay >> Dan Luu >> Dave Hodder >> David Creswick >> David Renshaw >> Diego Ongaro >> Dirkjan Bussink >> Dmitry Ermolov >> Do Nhat Minh >> Eduard Burtescu >> Edward Z. Yang >> eliovir >> Eric Biggers >> Eric Holk >> Erick Tryzelaar >> Erik Lyon >> Erik Price >> Fabrice Desr? >> Felix S. Klock II >> Flavio Percoco >> flo-l >> Florian Gilcher >> Florian Hahn >> Florian Zeitz >> g3xzh >> Gareth Smith >> Geoff Hill >> Geoffroy Couprie >> Georges Dubus >> gifnksm >> Guillaume Pinot >> Gyorgy Andrasek >> Harry Marr >> Heather >> Huon Wilson >> Ian Daniher >> Igor Bukanov >> Isaac Dupree >> Jack Moffitt >> Jaemin Moon >> Jan Niklas Hasse >> Jannis Harder >> Jason Orendorff >> Jason Toffaletti >> Jay Anderson >> Jed Davis >> Jeff Olson >> Joe Schafer >> John Louis Walker >> Jordi Boggiano >> Joshua Yanovski >> Julia Evans >> Jyun-Yan You >> Keegan McAllister >> Kevin Ballard >> Kiet Tran >> klutzy >> kud1ing >> Leah Hanson >> LEE Wondong >> Le?o Testard >> Lindsey Kuper >> Luca Bruno >> Luis de Bethencourt >> Luqman Aden >> lyuts >> Mark Rowe >> Marvin L?bel >> Matt Carberry >> Matthew Auld >> Matthew Iselin >> Micah Chalmer >> Michael 'devbug' Williams >> Michael Letterle >> Michael Woerister >> niftynif >> Niko Matsakis >> Noufal Ibrahim >> Olivier Saut >> osa1 >> Palmer Cox

>> Patrick Walton >> Peter Zotov >> Philipp Br?schweiler >> Raphael Speyer >> reedlepee >> Richard Diamond >> Robert Irelan >> Scott Lawrence >> S?bastien Chauvel >> S?bastien Crozet >> S?bastien Paolacci >> Seo Sanghyeon >> sh8281.kim >> SiegeLord >> sp3d >> S Pradeep Kumar >> Steve Klabnik >> Steven Fackler >> Strahinja Val Markovic >> Tim Chevalier >> Tomas Sedovic >> Vadim Chugunov >> Vijay Korapaty >> Volker Mische >> Young-il Choi >> Zach Kamsler >> Zack Corr >> Ziad Hatahet From lindsey at composition.al Thu Jan 9 18:21:36 2014 From: lindsey at composition.al (Lindsey Kuper) Date: Thu, 9 Jan 2014 21:21:36 -0500 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: <52CE441E.7040208@mozilla.com> References: <52CE441E.7040208@mozilla.com> Message-ID: On Thu, Jan 9, 2014 at 1:39 AM, Brian Anderson wrote: > These days we generally claim to > support Mac OS X 10.6+ Do we still claim to support 10.6? It's broken right now for me and others (https://github.com/mozilla/rust/issues/10842). Lindsey From banderson at mozilla.com Thu Jan 9 19:18:26 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 19:18:26 -0800 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: References: <52CE441E.7040208@mozilla.com> Message-ID: <52CF6682.5040702@mozilla.com> Then no :) On 01/09/2014 06:21 PM, Lindsey Kuper wrote: > On Thu, Jan 9, 2014 at 1:39 AM, Brian Anderson wrote: >> These days we generally claim to >> support Mac OS X 10.6+ > Do we still claim to support 10.6? It's broken right now for me and > others (https://github.com/mozilla/rust/issues/10842). > > Lindsey From banderson at mozilla.com Thu Jan 9 19:21:02 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Jan 2014 19:21:02 -0800 Subject: [rust-dev] 0.9 prerelease testing In-Reply-To: <52CF6682.5040702@mozilla.com> References: <52CE441E.7040208@mozilla.com> <52CF6682.5040702@mozilla.com> Message-ID: <52CF671E.9010804@mozilla.com> I guess I should expand. It would be nice if we fixed this, since I don't think the TLS problem is a good reason to abandon 10.6, but neither are we too concerned with supporting very old Mac releases. My macbook is running 10.6 and I would like to continue using it, so I have some interest in seeing this fixed. On 01/09/2014 07:18 PM, Brian Anderson wrote: > Then no :) > > On 01/09/2014 06:21 PM, Lindsey Kuper wrote: >> On Thu, Jan 9, 2014 at 1:39 AM, Brian Anderson >> wrote: >>> These days we generally claim to >>> support Mac OS X 10.6+ >> Do we still claim to support 10.6? It's broken right now for me and >> others (https://github.com/mozilla/rust/issues/10842). >> >> Lindsey > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Thu Jan 9 21:46:43 2014 From: corey at octayn.net (Corey Richardson) Date: Fri, 10 Jan 2014 00:46:43 -0500 Subject: [rust-dev] RFC: Future of the Build System Message-ID: Hey all, The build system has grown a fair bit of complexity, and is getting hard to understand. I've been thinking about what could replace it moving forward. Most of the complexity stems from having to self-host (ie, staging) and cross compilation (which target are we compiling for, and with which host?) Our build system must: 1. Work on all the platforms we support 2. Be able to track dependencies. Our ideal build system should: 1. Require minimal build-time dependencies 2. Allow ease of staging and cross compilation 3. Be easy to extend as we grow 4. Have readable build scripts 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc should all be retained) There are a few options: 1. Rework the current makefiles to be nicer. I'm not sure if this is feasible. Some stuff certainly could be easier, but the inherent problems of make (nested evals + calls, no named parameters (what does $(1) mean here, etc), general ugliness) make this unlikely to be a worthwhile effort, besides factoring out some of the current boilerplate. 2. Use a different build system. The major option here seems to be cmake[1], although I've heard murmurings of tup[2] and some other obscure things. I'm unsure tup is going to be of much help here. With our compilation model, fine-grained file-based dependencies are not very useful. However, it's awesome bottom-up dependency model could be neat. It's possible that we could use it with a combination of: 3. Write a build system in Rust. This would take care of everything for us, using ourselves. We'd have a small script fetch the snapshot and build the build system, and then hand off the rest of the build to it. This has the advantage of one less build-time dependency, but the disadvantage that it's going to be a lot of work. This could also potentially output tup, ninja[3], or another form of build script after taking configuration options and so-forth. It could also integrate with librustc for smart handling of comments-or-test-only changes, an issue near to my heart[4]. This build system could potentially be rustpkg, but as I understand it the current idea is to *remove* rustpkg's ability as a build system and keep it as a package manager. (At least, that is what I've understood of recent discussion; this could be wrong.) 4. Write a build system in $LANG. Python seems to be a good choice here, since we already depend on it for fetching the snapshot etc. This still has the disadvantage of being a lot of work, but would perhaps be easier than writing a build system in Rust. We would definitely lose hacker points for doing so. There are undoubtedly other options as well. Does anyone have good ideas or opinions on what we should do? Personally I think that 3 is going to be the best option, unless there's some super amazing build system I haven't heard of it. Which is totally possible! [1]: http://www.cmake.org/ [2]: http://gittup.org/tup/ [3]: http://martine.github.io/ninja/ [4]: https://github.com/mozilla/rust/issues/6522 From com.liigo at gmail.com Thu Jan 9 22:20:00 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Fri, 10 Jan 2014 14:20:00 +0800 Subject: [rust-dev] Rust 0.9 released In-Reply-To: <52CF0ECD.5050405@mozilla.com> References: <52CF0ECD.5050405@mozilla.com> Message-ID: Great work, thanks. ? 2014?1?10? ??5:04?"Brian Anderson" ??? > Mozilla and the Rust community are pleased to announce version 0.9 of the > Rust compiler and tools. Rust is a systems programming language with a > focus on safety, performance and concurrency. > > This was another eventful release in which we made extensive improvements > to the runtime and I/O subsystem, introduced static linking and link-time > optimization, and reduced the variety of closures in the language. 0.9 > also > begins a final series of planned changes to how pointers are treated in > Rust, starting with the deprecation of the built-in "managed pointer" type > and its accompanying `@` sigil, and the introduction of smart pointer > types > to the standard library. > > The brief release notes are included in this announcement, and there is > further explanation in the detailed release [notes] on the wiki. > Documentation and all the links in this email are available on the > [website]. As usual, version 0.9 should be considered an alpha release, > suitable for early adopters and language enthusiasts. Please file [bugs] > and join the [fun]. > > [website]: http://www.rust-lang.org > [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes > [bugs]: https://github.com/mozilla/rust/issues > [fun]: > https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors > > This release is available as both a tarball and a Windows installer: > > * http://static.rust-lang.org/dist/rust-0.9.tar.gz > http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc > SHA256 (of .tar.gz): > c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1 > > * http://static.rust-lang.org/dist/rust-0.9-install.exe > http://static.rust-lang.org/dist/rust-0.9-install.exe.asc > SHA256 (of .exe): > 6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90 > > Thanks to everyone who contributed! > > Regards, > The Rust Team > > > Version 0.9 (January 2014) > -------------------------- > > * Language > * The `float` type has been removed. Use `f32` or `f64` instead. > * A new facility for enabling experimental features (feature gating) > has been added, using the crate-level `#[feature(foo)]` attribute. > * Managed boxes (@) are now behind a feature gate > (`#[feature(managed_boxes)]`) in preperation for future removal. Use > the standard library's `Gc` or `Rc` types instead. > * `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead. > * Jumping back to the top of a loop is now done with `continue` instead > of `loop`. > * Strings can no longer be mutated through index assignment. > * Raw strings can be created via the basic `r"foo"` syntax or with > matched hash delimiters, as in `r###"foo"###`. > * `~fn` is now written `proc (args) -> retval { ... }` and may only be > called once. > * The `&fn` type is now written `|args| -> ret` to match the literal > form. > * `@fn`s have been removed. > * `do` only works with procs in order to make it obvious what the cost > of `do` is. > * Single-element tuple-like structs can no longer be dereferenced to > obtain the inner value. A more comprehensive solution for overloading > the dereference operator will be provided in the future. > * The `#[link(...)]` attribute has been replaced with > `#[crate_id = "name#vers"]`. > * Empty `impl`s must be terminated with empty braces and may not be > terminated with a semicolon. > * Keywords are no longer allowed as lifetime names; the `self` lifetime > no longer has any special meaning. > * The old `fmt!` string formatting macro has been removed. > * `printf!` and `printfln!` (old-style formatting) removed in favor of > `print!` and `println!`. > * `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`. > * The `extern mod foo (name = "bar")` syntax has been removed. Use > `extern mod foo = "bar"` instead. > * New reserved keywords: `alignof`, `offsetof`, `sizeof`. > * Macros can have attributes. > * Macros can expand to items with attributes. > * Macros can expand to multiple items. > * The `asm!` macro is feature-gated (`#[feature(asm)]`). > * Comments may be nested. > * Values automatically coerce to trait objects they implement, without > an explicit `as`. > * Enum discriminants are no longer an entire word but as small as needed > to contain all the variants. The `repr` attribute can be used to > override the discriminant size, as in `#[repr(int)]` for integer-sized, > and `#[repr(C)]` to match C enums. > * Non-string literals are not allowed in attributes (they never worked). > * The FFI now supports variadic functions. > * Octal numeric literals, as in `0o7777`. > * The `concat!` syntax extension performs compile-time string > concatenation. > * The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been > removed as Rust no longer uses segmented stacks. > * Non-ascii identifiers are feature-gated > (`#[feature(non_ascii_idents)]`). > * Ignoring all fields of an enum variant or tuple-struct is done with > `..`, not `*`; ignoring remaining fields of a struct is also done > with `..`, not `_`; ignoring a slice of a vector is done with `..`, > not `.._`. > * `rustc` supports the "win64" calling convention via `extern "win64"`. > * `rustc` supports the "system" calling convention, which defaults to > the preferred convention for the target platform, "stdcall" on 32-bit > Windows, "C" elsewhere. > * The `type_overflow` lint (default: warn) checks literals for overflow. > * The `unsafe_block` lint (default: allow) checks for usage of `unsafe`. > * The `attribute_usage` lint (default: warn) warns about unknown > attributes. > * The `unknown_features` lint (default: warn) warns about unknown > feature gates. > * The `dead_code` lint (default: warn) checks for dead code. > * Rust libraries can be linked statically to one another > * `#[link_args]` is behind the `link_args` feature gate. > * Native libraries are now linked with `#[link(name = "foo")]` > * Native libraries can be statically linked to a rust crate > (`#[link(name = "foo", kind = "static")]`). > * Native OS X frameworks are now officially supported > (`#[link(name = "foo", kind = "framework")]`). > * The `#[thread_local]` attribute creates thread-local (not task-local) > variables. Currently behind the `thread_local` feature gate. > * The `return` keyword may be used in closures. > * Types that can be copied via a memcpy implement the `Pod` kind. > * The `cfg` attribute can now be used on struct fields and enum variants. > > * Libraries > * std: The `option` and `result` API's have been overhauled to make them > simpler, more consistent, and more composable. > * std: The entire `std::io` module has been replaced with one that is > more comprehensive and that properly interfaces with the underlying > scheduler. File, TCP, UDP, Unix sockets, pipes, and timers are all > implemented. > * std: `io::util` contains a number of useful implementations of > `Reader` and `Writer`, including `NullReader`, `NullWriter`, > `ZeroReader`, `TeeReader`. > * std: The reference counted pointer type `extra::rc` moved into std. > * std: The `Gc` type in the `gc` module will replace `@` (it is currently > just a wrapper around it). > * std: The `Either` type has been removed. > * std: `fmt::Default` can be implemented for any type to provide default > formatting to the `format!` macro, as in `format!("{}", myfoo)`. > * std: The `rand` API continues to be tweaked. > * std: The `rust_begin_unwind` function, useful for inserting > breakpoints on failure in gdb, is now named `rust_fail`. > * std: The `each_key` and `each_value` methods on `HashMap` have been > replaced by the `keys` and `values` iterators. > * std: Functions dealing with type size and alignment have moved from > the `sys` module to the `mem` module. > * std: The `path` module was written and API changed. > * std: `str::from_utf8` has been changed to cast instead of allocate. > * std: `starts_with` and `ends_with` methods added to vectors via the > `ImmutableEqVector` trait, which is in the prelude. > * std: Vectors can be indexed with the `get_opt` method, which returns > `None` if the index is out of bounds. > * std: Task failure no longer propagates between tasks, as the model > was complex, expensive, and incompatible with thread-based tasks. > * std: The `Any` type can be used for dynamic typing. > * std: `~Any` can be passed to the `fail!` macro and retrieved via > `task::try`. > * std: Methods that produce iterators generally do not have an `_iter` > suffix now. > * std: `cell::Cell` and `cell::RefCell` can be used to introduc > mutability roots (mutable fields, etc.). Use instead of e.g. `@mut`. > * std: `util::ignore` renamed to `prelude::drop`. > * std: Slices have `sort` and `sort_by` methods via the `MutableVector` > trait. > * std: `vec::raw` has seen a lot of cleanup and API changes. > * std: The standard library no longer includes any C++ code, and very > minimal C, eliminating the dependency on libstdc++. > * std: Runtime scheduling and I/O functionality has been factored out > into extensible interfaces and is now implemented by two different > crates: libnative, for native threading and I/O; and libgreen, for > green threading and I/O. This paves the way for using the standard > library in more limited embeded environments. > * std: The `comm` module has been rewritten to be much faster, have a > simpler, more consistent API, and to work for both native and green > threading. > * std: All libuv dependencies have been moved into the rustuv crate. > * native: New implementations of runtime scheduling on top of OS > threads. > * native: New native implementations of TCP, UDP, file I/O, process > spawning, and other I/O. > * green: The green thread scheduler and message passing types are > almost entirely lock-free. > * extra: The `flatpipes` module had bitrotted and was removed. > * extra: All crypto functions have been removed and Rust now has a > policy of not reimplementing crypto in the standard library. In the > future crypto will be provided by external crates with bindings to > established libraries. > * extra: `c_vec` has been modernized. > * extra: The `sort` module has been removed. Use the `sort` method on > mutable slices. > > * Tooling > * The `rust` and `rusti` commands have been removed, due to lack of > maintenance. > * `rustdoc` was completely rewritten. > * `rustdoc` can test code examples in documentation. > * `rustpkg` can test packages with the argument, 'test'. > * `rustpkg` supports arbitrary dependencies, including C libraries. > * `rustc`'s support for generating debug info is improved again. > * `rustc` has better error reporting for unbalanced delimiters. > * `rustc`'s JIT support was removed due to bitrot. > * Executables and static libraries can be built with LTO (-Z lto) > * `rustc` adds a `--dep-info` flag for communicating dependencies to > build tools. > > > Contributors to Rust 0.9 > ------------------------ > > Adrien T?tar > Alan Andrade > Alexandros Tasos > Alex Crichton > a_m0d > Andreas Neuhaus > Andreas Ots > Andrei Formiga > Benjamin Herr > Benjamin Peterson > Birunthan Mohanathas > blake2-ppc > Branimir > Brendan Zabarauskas > Brian Anderson > Brian > Cadence Marseille > Carl-Anton Ingmarsson > Carol Willing > Carter Tazio Schonwald > chitra > Chris Morgan > Chris Sainty > Corey Richardson > Dan Connolly > Daniel Micay > Dan Luu > Dave Hodder > David Creswick > David Renshaw > Diego Ongaro > Dirkjan Bussink > Dmitry Ermolov > Do Nhat Minh > Eduard Burtescu > Edward Z. Yang > eliovir > Eric Biggers > Eric Holk > Erick Tryzelaar > Erik Lyon > Erik Price > Fabrice Desr? > Felix S. Klock II > Flavio Percoco > flo-l > Florian Gilcher > Florian Hahn > Florian Zeitz > g3xzh > Gareth Smith > Geoff Hill > Geoffroy Couprie > Georges Dubus > gifnksm > Guillaume Pinot > Gyorgy Andrasek > Harry Marr > Heather > Huon Wilson > Ian Daniher > Igor Bukanov > Isaac Dupree > Jack Moffitt > Jaemin Moon > Jan Niklas Hasse > Jannis Harder > Jason Orendorff > Jason Toffaletti > Jay Anderson > Jed Davis > Jeff Olson > Joe Schafer > John Louis Walker > Jordi Boggiano > Joshua Yanovski > Julia Evans > Jyun-Yan You > Keegan McAllister > Kevin Ballard > Kiet Tran > klutzy > kud1ing > Leah Hanson > LEE Wondong > Le?o Testard > Lindsey Kuper > Luca Bruno > Luis de Bethencourt > Luqman Aden > lyuts > Mark Rowe > Marvin L?bel > Matt Carberry > Matthew Auld > Matthew Iselin > Micah Chalmer > Michael 'devbug' Williams > Michael Letterle > Michael Woerister > niftynif > Niko Matsakis > Noufal Ibrahim > Olivier Saut > osa1 > Palmer Cox

> Patrick Walton > Peter Zotov > Philipp Br?schweiler > Raphael Speyer > reedlepee > Richard Diamond > Robert Irelan > Scott Lawrence > S?bastien Chauvel > S?bastien Crozet > S?bastien Paolacci > Seo Sanghyeon > sh8281.kim > SiegeLord > sp3d > S Pradeep Kumar > Steve Klabnik > Steven Fackler > Strahinja Val Markovic > Tim Chevalier > Tomas Sedovic > Vadim Chugunov > Vijay Korapaty > Volker Mische > Young-il Choi > Zach Kamsler > Zack Corr > Ziad Hatahet > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Thu Jan 9 22:46:07 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Fri, 10 Jan 2014 08:46:07 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: Hello, Having a build system entirely dependent of Rust alone, would make the entire experience in deploying the language extremely cohere. The only counter - argument is indeed that it would require some work to get this to fruition. I would like to know if this has any chance of getting priority soon enough. G. Corey Richardson wrote: >Hey all, > >The build system has grown a fair bit of complexity, and is getting >hard to understand. I've been thinking about what could replace it >moving forward. Most of the complexity stems from having to self-host >(ie, staging) and cross compilation (which target are we compiling >for, and with which host?) [...] >3. Write a build system in Rust. > >This would take care of everything for us, using ourselves. We'd have >a small script fetch the snapshot and build the build system, and then >hand off the rest of the build to it. This has the advantage of one >less build-time dependency, but the disadvantage that it's going to be >a lot of work. This could also potentially output tup, ninja[3], or >another form of build script after taking configuration options and >so-forth. It could also integrate with librustc for smart handling of >comments-or-test-only changes, an issue near to my heart[4]. This >build system could potentially be rustpkg, but as I understand it the >current idea is to *remove* rustpkg's ability as a build system and >keep it as a package manager. (At least, that is what I've understood >of recent discussion; this could be wrong.) [...] From carter.schonwald at gmail.com Thu Jan 9 23:43:17 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 10 Jan 2014 02:43:17 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: If the in rust approach is chosen, I warmly recommend checking out some of the design ideas in Shake. Shake has a pretty nice design that allows for dynamic build deps (in make systems the way around that is to use make to make your make files), and a few other neat ideas, including but not limited to playing nice with ninja files (which I believe cmake can generate too). http://community.haskell.org/~ndm/shake/ http://hackage.haskell.org/package/shake On Friday, January 10, 2014, George Makrydakis wrote: > > Hello, > > Having a build system entirely dependent of Rust alone, would make the > entire experience in deploying the language extremely cohere. The only > counter - argument is indeed that it would require some work to get this to > fruition. I would like to know if this has any chance of getting priority > soon enough. > > G. > > Corey Richardson wrote: > >Hey all, > > > >The build system has grown a fair bit of complexity, and is getting > >hard to understand. I've been thinking about what could replace it > >moving forward. Most of the complexity stems from having to self-host > >(ie, staging) and cross compilation (which target are we compiling > >for, and with which host?) > > [...] > > >3. Write a build system in Rust. > > > >This would take care of everything for us, using ourselves. We'd have > >a small script fetch the snapshot and build the build system, and then > >hand off the rest of the build to it. This has the advantage of one > >less build-time dependency, but the disadvantage that it's going to be > >a lot of work. This could also potentially output tup, ninja[3], or > >another form of build script after taking configuration options and > >so-forth. It could also integrate with librustc for smart handling of > >comments-or-test-only changes, an issue near to my heart[4]. This > >build system could potentially be rustpkg, but as I understand it the > >current idea is to *remove* rustpkg's ability as a build system and > >keep it as a package manager. (At least, that is what I've understood > >of recent discussion; this could be wrong.) > > [...] > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Fri Jan 10 00:16:49 2014 From: gaetan at xeberon.net (Gaetan) Date: Fri, 10 Jan 2014 09:16:49 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: I am not in favor of a customized build system. For instance boost library use their jam build system, and i never figured how to use it in my projects. I push to use standard and well proved build system like cmake or scons, at least for major components. This would give a nice example of how to use it in any projects. Le 10 janv. 2014 08:43, "Carter Schonwald" a ?crit : > If the in rust approach is chosen, I warmly recommend checking out some of > the design ideas in Shake. Shake has a pretty nice design that allows for > dynamic build deps (in make systems the way around that is to use make to > make your make files), and a few other neat ideas, including but not > limited to playing nice with ninja files (which I believe cmake can > generate too). > > http://community.haskell.org/~ndm/shake/ > http://hackage.haskell.org/package/shake > > On Friday, January 10, 2014, George Makrydakis wrote: > >> >> Hello, >> >> Having a build system entirely dependent of Rust alone, would make the >> entire experience in deploying the language extremely cohere. The only >> counter - argument is indeed that it would require some work to get this to >> fruition. I would like to know if this has any chance of getting priority >> soon enough. >> >> G. >> >> Corey Richardson wrote: >> >Hey all, >> > >> >The build system has grown a fair bit of complexity, and is getting >> >hard to understand. I've been thinking about what could replace it >> >moving forward. Most of the complexity stems from having to self-host >> >(ie, staging) and cross compilation (which target are we compiling >> >for, and with which host?) >> >> [...] >> >> >3. Write a build system in Rust. >> > >> >This would take care of everything for us, using ourselves. We'd have >> >a small script fetch the snapshot and build the build system, and then >> >hand off the rest of the build to it. This has the advantage of one >> >less build-time dependency, but the disadvantage that it's going to be >> >a lot of work. This could also potentially output tup, ninja[3], or >> >another form of build script after taking configuration options and >> >so-forth. It could also integrate with librustc for smart handling of >> >comments-or-test-only changes, an issue near to my heart[4]. This >> >build system could potentially be rustpkg, but as I understand it the >> >current idea is to *remove* rustpkg's ability as a build system and >> >keep it as a package manager. (At least, that is what I've understood >> >of recent discussion; this could be wrong.) >> >> [...] >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Fri Jan 10 00:34:32 2014 From: leebraid at gmail.com (Lee Braiden) Date: Fri, 10 Jan 2014 08:34:32 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: <52CFB098.8010100@gmail.com> On 10/01/14 08:16, Gaetan wrote: > > I am not in favor of a customized build system. For instance boost > library use their jam build system, and i never figured how to use it > in my projects. > > I push to use standard and well proved build system like cmake or > scons, at least for major components. This would give a nice example > of how to use it in any projects. > I'd agree with that on both counts: the principle of using something standard, and the two recommendations. CMake would probably get my vote, because it's not so much a build tool, as a meta tool for whichever system you prefer, so it would fit in well with various platform-specific IDEs, unusual platforms (android, embedded, ...), etc. That said, scons is also a strong contender, and which of the two is more open to integrating patches and working with new languages is very much worth considering. I think Rust will be contributing to the wider community by lending its support (and patches) to a common, modern build system, AND it will get something back in terms of users who already know the build system. > On Friday, January 10, 2014, George Makrydakis wrote: > > > Hello, > > Having a build system entirely dependent of Rust alone, would > make the entire experience in deploying the language extremely > cohere. The only counter - argument is indeed that it would > require some work to get this to fruition. I would like to > know if this has any chance of getting priority soon enough. > Bear in mind that Debian are having a lot of issues packaging Rust already, because it self-compiles. If the build tool also had a Rust pre-dependency, that would be a big step backwards. -- Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhasse at gmail.com Fri Jan 10 00:54:21 2014 From: jhasse at gmail.com (Jan Niklas Hasse) Date: Fri, 10 Jan 2014 09:54:21 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: Have you heart about waf? http://code.google.com/p/waf/ It only depends on Python so this would not result in another dependency. The python script (< 200 kB) can be included in the repository. I am all for using rustpkg though. And I'm strongly against cmake, because I don't know its language and don't like a build system which doesn't use an already existing one (like scons is using Python). Also cmake still depends on make (or even worse Visual Studio / Xcode). 2014/1/10 Corey Richardson > Hey all, > > The build system has grown a fair bit of complexity, and is getting > hard to understand. I've been thinking about what could replace it > moving forward. Most of the complexity stems from having to self-host > (ie, staging) and cross compilation (which target are we compiling > for, and with which host?) > > Our build system must: > > 1. Work on all the platforms we support > 2. Be able to track dependencies. > > Our ideal build system should: > > 1. Require minimal build-time dependencies > 2. Allow ease of staging and cross compilation > 3. Be easy to extend as we grow > 4. Have readable build scripts > 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc > should all be retained) > > There are a few options: > > 1. Rework the current makefiles to be nicer. > > I'm not sure if this is feasible. Some stuff certainly could be > easier, but the inherent problems of make (nested evals + calls, no > named parameters (what does $(1) mean here, etc), general ugliness) > make this unlikely to be a worthwhile effort, besides factoring out > some of the current boilerplate. > > 2. Use a different build system. > > The major option here seems to be cmake[1], although I've heard > murmurings of tup[2] and some other obscure things. I'm unsure tup is > going to be of much help here. With our compilation model, > fine-grained file-based dependencies are not very useful. However, > it's awesome bottom-up dependency model could be neat. It's possible > that we could use it with a combination of: > > 3. Write a build system in Rust. > > This would take care of everything for us, using ourselves. We'd have > a small script fetch the snapshot and build the build system, and then > hand off the rest of the build to it. This has the advantage of one > less build-time dependency, but the disadvantage that it's going to be > a lot of work. This could also potentially output tup, ninja[3], or > another form of build script after taking configuration options and > so-forth. It could also integrate with librustc for smart handling of > comments-or-test-only changes, an issue near to my heart[4]. This > build system could potentially be rustpkg, but as I understand it the > current idea is to *remove* rustpkg's ability as a build system and > keep it as a package manager. (At least, that is what I've understood > of recent discussion; this could be wrong.) > > 4. Write a build system in $LANG. > > Python seems to be a good choice here, since we already depend on it > for fetching the snapshot etc. This still has the disadvantage of > being a lot of work, but would perhaps be easier than writing a build > system in Rust. We would definitely lose hacker points for doing so. > > There are undoubtedly other options as well. Does anyone have good > ideas or opinions on what we should do? Personally I think that 3 is > going to be the best option, unless there's some super amazing build > system I haven't heard of it. Which is totally possible! > > [1]: http://www.cmake.org/ > [2]: http://gittup.org/tup/ > [3]: http://martine.github.io/ninja/ > [4]: https://github.com/mozilla/rust/issues/6522 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Fri Jan 10 02:06:46 2014 From: gaetan at xeberon.net (Gaetan) Date: Fri, 10 Jan 2014 11:06:46 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: See this page that compares scons to other build system: http://www.scons.org/wiki/SconsVsOtherBuildTools I still personally recommend CMake. One of the major feature is that it is NOT a build system, it a script factory that generates system dependant build file: Makefile for GNU, Visual Studio for Windows, Eclipse projects,... It actually replaces all bash scripts we usually write on large projects to trigger the builds. ----- Gaetan 2014/1/10 Jan Niklas Hasse > > Have you heart about waf? http://code.google.com/p/waf/ > > It only depends on Python so this would not result in another dependency. > The python script (< 200 kB) can be included in the repository. > > I am all for using rustpkg though. And I'm strongly against cmake, because > I don't know its language and don't like a build system which doesn't use > an already existing one (like scons is using Python). Also cmake still > depends on make (or even worse Visual Studio / Xcode). > > > 2014/1/10 Corey Richardson > >> Hey all, >> >> The build system has grown a fair bit of complexity, and is getting >> hard to understand. I've been thinking about what could replace it >> moving forward. Most of the complexity stems from having to self-host >> (ie, staging) and cross compilation (which target are we compiling >> for, and with which host?) >> >> Our build system must: >> >> 1. Work on all the platforms we support >> 2. Be able to track dependencies. >> >> Our ideal build system should: >> >> 1. Require minimal build-time dependencies >> 2. Allow ease of staging and cross compilation >> 3. Be easy to extend as we grow >> 4. Have readable build scripts >> 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc >> should all be retained) >> >> There are a few options: >> >> 1. Rework the current makefiles to be nicer. >> >> I'm not sure if this is feasible. Some stuff certainly could be >> easier, but the inherent problems of make (nested evals + calls, no >> named parameters (what does $(1) mean here, etc), general ugliness) >> make this unlikely to be a worthwhile effort, besides factoring out >> some of the current boilerplate. >> >> 2. Use a different build system. >> >> The major option here seems to be cmake[1], although I've heard >> murmurings of tup[2] and some other obscure things. I'm unsure tup is >> going to be of much help here. With our compilation model, >> fine-grained file-based dependencies are not very useful. However, >> it's awesome bottom-up dependency model could be neat. It's possible >> that we could use it with a combination of: >> >> 3. Write a build system in Rust. >> >> This would take care of everything for us, using ourselves. We'd have >> a small script fetch the snapshot and build the build system, and then >> hand off the rest of the build to it. This has the advantage of one >> less build-time dependency, but the disadvantage that it's going to be >> a lot of work. This could also potentially output tup, ninja[3], or >> another form of build script after taking configuration options and >> so-forth. It could also integrate with librustc for smart handling of >> comments-or-test-only changes, an issue near to my heart[4]. This >> build system could potentially be rustpkg, but as I understand it the >> current idea is to *remove* rustpkg's ability as a build system and >> keep it as a package manager. (At least, that is what I've understood >> of recent discussion; this could be wrong.) >> >> 4. Write a build system in $LANG. >> >> Python seems to be a good choice here, since we already depend on it >> for fetching the snapshot etc. This still has the disadvantage of >> being a lot of work, but would perhaps be easier than writing a build >> system in Rust. We would definitely lose hacker points for doing so. >> >> There are undoubtedly other options as well. Does anyone have good >> ideas or opinions on what we should do? Personally I think that 3 is >> going to be the best option, unless there's some super amazing build >> system I haven't heard of it. Which is totally possible! >> >> [1]: http://www.cmake.org/ >> [2]: http://gittup.org/tup/ >> [3]: http://martine.github.io/ninja/ >> [4]: https://github.com/mozilla/rust/issues/6522 >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertknight at gmail.com Fri Jan 10 03:19:26 2014 From: robertknight at gmail.com (Robert Knight) Date: Fri, 10 Jan 2014 11:19:26 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: Hello, CMake does have a few things going for it: - It is a popular choice for C++ projects, including LLVM, WebKit and others, so this would provide familiarity from developers coming from C++ - As mentioned, it is a meta-build system which can generate project files for Xcode, Visual Studio, Ninja and others. This is very useful for cross-platform development - It has a good and sizable ecosystem (full time active maintainers, documentation, user questions on StackOverflow etc.) - It has a large collection of modules to find packages, detect compiler versions etc. Downsides for CMake include: - The built script language is primitive and not a familiar language like Python. It is easy enough to use for writing a build project file but for more complex logic, I've found it easier to write separate commands in Python/Ruby which CMake then invokes. - CMakeLists.txt files are not declarative documents that can be easily parsed by other tools for eg. IDE integration. Having said that, the CMake developers are aware of the benefits of more declarative ways of specifying things and there is a general trend in that direction. - Adds a non-rusty dependency to rust. Regards, Rob. On 10 January 2014 10:06, Gaetan wrote: > See this page that compares scons to other build system: > http://www.scons.org/wiki/SconsVsOtherBuildTools > > I still personally recommend CMake. One of the major feature is that it is > NOT a build system, it a script factory that generates system dependant > build file: Makefile for GNU, Visual Studio for Windows, Eclipse > projects,... > It actually replaces all bash scripts we usually write on large projects to > trigger the builds. > > ----- > Gaetan > > > > 2014/1/10 Jan Niklas Hasse >> >> >> Have you heart about waf? http://code.google.com/p/waf/ >> >> It only depends on Python so this would not result in another dependency. >> The python script (< 200 kB) can be included in the repository. >> >> I am all for using rustpkg though. And I'm strongly against cmake, because >> I don't know its language and don't like a build system which doesn't use an >> already existing one (like scons is using Python). Also cmake still depends >> on make (or even worse Visual Studio / Xcode). >> >> >> 2014/1/10 Corey Richardson >>> >>> Hey all, >>> >>> The build system has grown a fair bit of complexity, and is getting >>> hard to understand. I've been thinking about what could replace it >>> moving forward. Most of the complexity stems from having to self-host >>> (ie, staging) and cross compilation (which target are we compiling >>> for, and with which host?) >>> >>> Our build system must: >>> >>> 1. Work on all the platforms we support >>> 2. Be able to track dependencies. >>> >>> Our ideal build system should: >>> >>> 1. Require minimal build-time dependencies >>> 2. Allow ease of staging and cross compilation >>> 3. Be easy to extend as we grow >>> 4. Have readable build scripts >>> 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc >>> should all be retained) >>> >>> There are a few options: >>> >>> 1. Rework the current makefiles to be nicer. >>> >>> I'm not sure if this is feasible. Some stuff certainly could be >>> easier, but the inherent problems of make (nested evals + calls, no >>> named parameters (what does $(1) mean here, etc), general ugliness) >>> make this unlikely to be a worthwhile effort, besides factoring out >>> some of the current boilerplate. >>> >>> 2. Use a different build system. >>> >>> The major option here seems to be cmake[1], although I've heard >>> murmurings of tup[2] and some other obscure things. I'm unsure tup is >>> going to be of much help here. With our compilation model, >>> fine-grained file-based dependencies are not very useful. However, >>> it's awesome bottom-up dependency model could be neat. It's possible >>> that we could use it with a combination of: >>> >>> 3. Write a build system in Rust. >>> >>> This would take care of everything for us, using ourselves. We'd have >>> a small script fetch the snapshot and build the build system, and then >>> hand off the rest of the build to it. This has the advantage of one >>> less build-time dependency, but the disadvantage that it's going to be >>> a lot of work. This could also potentially output tup, ninja[3], or >>> another form of build script after taking configuration options and >>> so-forth. It could also integrate with librustc for smart handling of >>> comments-or-test-only changes, an issue near to my heart[4]. This >>> build system could potentially be rustpkg, but as I understand it the >>> current idea is to *remove* rustpkg's ability as a build system and >>> keep it as a package manager. (At least, that is what I've understood >>> of recent discussion; this could be wrong.) >>> >>> 4. Write a build system in $LANG. >>> >>> Python seems to be a good choice here, since we already depend on it >>> for fetching the snapshot etc. This still has the disadvantage of >>> being a lot of work, but would perhaps be easier than writing a build >>> system in Rust. We would definitely lose hacker points for doing so. >>> >>> There are undoubtedly other options as well. Does anyone have good >>> ideas or opinions on what we should do? Personally I think that 3 is >>> going to be the best option, unless there's some super amazing build >>> system I haven't heard of it. Which is totally possible! >>> >>> [1]: http://www.cmake.org/ >>> [2]: http://gittup.org/tup/ >>> [3]: http://martine.github.io/ninja/ >>> [4]: https://github.com/mozilla/rust/issues/6522 >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From lists at dhardy.name Fri Jan 10 07:06:01 2014 From: lists at dhardy.name (Diggory Hardy) Date: Fri, 10 Jan 2014 16:06:01 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52CFB098.8010100@gmail.com> References: <52CFB098.8010100@gmail.com> Message-ID: <1949520.i7MrgNSkXU@yoga.dhardy> A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a "C-family" project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: > On 10/01/14 08:16, Gaetan wrote: > > I am not in favor of a customized build system. For instance boost > > library use their jam build system, and i never figured how to use it > > in my projects. > > > > I push to use standard and well proved build system like cmake or > > scons, at least for major components. This would give a nice example > > of how to use it in any projects. > > I'd agree with that on both counts: the principle of using something > standard, and the two recommendations. > > CMake would probably get my vote, because it's not so much a build tool, > as a meta tool for whichever system you prefer, so it would fit in well > with various platform-specific IDEs, unusual platforms (android, > embedded, ...), etc. That said, scons is also a strong contender, and > which of the two is more open to integrating patches and working with > new languages is very much worth considering. > > I think Rust will be contributing to the wider community by lending its > support (and patches) to a common, modern build system, AND it will get > something back in terms of users who already know the build system. > > > On Friday, January 10, 2014, George Makrydakis wrote: > > Hello, > > > > Having a build system entirely dependent of Rust alone, would > > make the entire experience in deploying the language extremely > > cohere. The only counter - argument is indeed that it would > > require some work to get this to fruition. I would like to > > know if this has any chance of getting priority soon enough. > > Bear in mind that Debian are having a lot of issues packaging Rust > already, because it self-compiles. If the build tool also had a Rust > pre-dependency, that would be a big step backwards. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From corey at octayn.net Fri Jan 10 07:08:09 2014 From: corey at octayn.net (Corey Richardson) Date: Fri, 10 Jan 2014 10:08:09 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <1949520.i7MrgNSkXU@yoga.dhardy> References: <52CFB098.8010100@gmail.com> <1949520.i7MrgNSkXU@yoga.dhardy> Message-ID: This RFC isn't about using a single build system for everything, it's the build system we use to build Rust itself. On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy wrote: > A further point in favour of CMake is that it would make multi-language > projects easier to manage, in particular transitioning a "C-family" project to > Rust. > > On Friday 10 January 2014 08:34:32 Lee Braiden wrote: >> On 10/01/14 08:16, Gaetan wrote: >> > I am not in favor of a customized build system. For instance boost >> > library use their jam build system, and i never figured how to use it >> > in my projects. >> > >> > I push to use standard and well proved build system like cmake or >> > scons, at least for major components. This would give a nice example >> > of how to use it in any projects. >> >> I'd agree with that on both counts: the principle of using something >> standard, and the two recommendations. >> >> CMake would probably get my vote, because it's not so much a build tool, >> as a meta tool for whichever system you prefer, so it would fit in well >> with various platform-specific IDEs, unusual platforms (android, >> embedded, ...), etc. That said, scons is also a strong contender, and >> which of the two is more open to integrating patches and working with >> new languages is very much worth considering. >> >> I think Rust will be contributing to the wider community by lending its >> support (and patches) to a common, modern build system, AND it will get >> something back in terms of users who already know the build system. >> >> > On Friday, January 10, 2014, George Makrydakis wrote: >> > Hello, >> > >> > Having a build system entirely dependent of Rust alone, would >> > make the entire experience in deploying the language extremely >> > cohere. The only counter - argument is indeed that it would >> > require some work to get this to fruition. I would like to >> > know if this has any chance of getting priority soon enough. >> >> Bear in mind that Debian are having a lot of issues packaging Rust >> already, because it self-compiles. If the build tool also had a Rust >> pre-dependency, that would be a big step backwards. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From slabode at aim.com Fri Jan 10 07:17:00 2014 From: slabode at aim.com (SiegeLord) Date: Fri, 10 Jan 2014 10:17:00 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: <52D00EEC.6090306@aim.com> On 01/10/2014 06:19 AM, Robert Knight wrote: > Hello, > > CMake does have a few things going for it: One more consideration is that LLVM can be built with CMake afaik, so if we switch to CMake we may be able to drop the autotools dependency, which is a more annoying dependency to fulfill (on Windows) than CMake (I don't know if Rust has other components that require autotools though). Along the same lines, we also require Python for whatever reason, so SCons would be a natural option too (it can't build LLVM though). I'd only use SCons conditional on it accepting a Rust dependency scanner into its source: using its current custom scanner infrastructure is not practical as I found out. As for waf... they and Debian have been having a tiff (e.g. see http://waf-devel.blogspot.com/2012/01/debian.html , https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would not suggest it based on that. -SL From nnythm at gmail.com Fri Jan 10 07:20:42 2014 From: nnythm at gmail.com (Nakamura) Date: Fri, 10 Jan 2014 10:20:42 -0500 Subject: [rust-dev] returning functions in rust Message-ID: I'm new to rust, and tried going through some of the examples from the OS class[0] that was taught in rust. However, I got tripped up by the exercise, "make a function that takes an integer n and another function |x| -> x, and returns a function that is n applications of the original function." I've been trying to see what the limits of rust are if you are using it without the runtime/managed pointers etc, and it seems like I stumble against one of the limits when trying to return functions. The big question is where to allocate the new function I want to return. Like other people who are new to rust, I made the mistake of thinking that lifetime parameters actually affecting lifetimes[1]. If this were the case, it would be sensible to write this as a recursive function which has the same lifetime as the function that you pass in. Is there a safe way other than using managed pointers to return functions? It looks like you can use externs and call it a day (or you can maybe use unsafe? I haven't explored it yet), but that doesn't seem satisfactory. I saw a thread that mentioned unboxed closures, but couldn't find any other details about them. Maybe that's what I'm looking for? If I do end up having to use managed pointers to return functions, will the runtime infect everything I do, or could I just designate certain threads (green or otherwise) gc-threads and go about my day on threads which don't need to worry about gc? [0]: http://rust-class.org/ [1]: http://stackoverflow.com/questions/19213494/lifetime-of-a-lambda-expression-in-rust/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Fri Jan 10 07:53:14 2014 From: gaetan at xeberon.net (Gaetan) Date: Fri, 10 Jan 2014 16:53:14 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D00EEC.6090306@aim.com> References: <52D00EEC.6090306@aim.com> Message-ID: I also agree that the way waf works is quite weird to use, but this is actually how most of the installers works under windows or some on MacOS: the code of the installers is embedded into the distributed package. This violates the debian packaging rules, and I think this will be the same with rust. I however really like this approach. You don't have a huge among of dependencies to setup in order to build your package. This is not a problem on debian where apt does to marveillous job, but on Windows/Mac/generic linux/arm, .. this is a nightmare. One more point in favor of CMake to build rust: you can build android/arm/misc (thanks to Makefile) with the same CMakeList.txt files, or with external module inclusion. I also agree that its syntax used to be quite ugly (the famous if() / else() / endif()), but not so much in the lastest versions... But if you require python for building, scons is the perfect, natural candidate. ----- Gaetan 2014/1/10 SiegeLord > On 01/10/2014 06:19 AM, Robert Knight wrote: > >> Hello, >> >> CMake does have a few things going for it: >> > > One more consideration is that LLVM can be built with CMake afaik, so if > we switch to CMake we may be able to drop the autotools dependency, which > is a more annoying dependency to fulfill (on Windows) than CMake (I don't > know if Rust has other components that require autotools though). > > Along the same lines, we also require Python for whatever reason, so SCons > would be a natural option too (it can't build LLVM though). I'd only use > SCons conditional on it accepting a Rust dependency scanner into its > source: using its current custom scanner infrastructure is not practical as > I found out. > > As for waf... they and Debian have been having a tiff (e.g. see > http://waf-devel.blogspot.com/2012/01/debian.html , > https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would > not suggest it based on that. > > -SL > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhasse at gmail.com Fri Jan 10 08:53:56 2014 From: jhasse at gmail.com (Jan Niklas Hasse) Date: Fri, 10 Jan 2014 17:53:56 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: 2014/1/10 Robert Knight > > Hello, > > CMake does have a few things going for it: > > - It is a popular choice for C++ projects, including LLVM, WebKit and > others, so this would provide familiarity from developers coming from > C++ Same for scons (Blender, MongoDB) and waf (Samba, node.js). > > - As mentioned, it is a meta-build system which can generate project > files for Xcode, Visual Studio, Ninja and others. This is very useful > for cross-platform development I don't think this is useful for Rust itself as these IDEs don't support Rust anyway and some things won't work (like copying files around which is currently done in the Makefiles and seems to be hard if not impossible to do in VC++/Xcode to me). Some counter arguments for cmake (I haven't worked with many cmake projects though, so these points are just my personal opinion, sorry if I'm spreading FUD): - Some projects [1] include handcrafted VC++ and Xcode project files anyway, even if using cmake. Looks to me like cmake's generator isn't worth it. - To create Makefiles for MinGW you have to use `cmake -G "MinGW Makefiles"` which I find rather ugly looking (I always have to look it up). - CMakeLists.txt often look ugly [2] and don't follow any particular style (lower case vs. upper case, etc.). - Using cmake on Windows wasn't as pleasant as scons or autotools (when working with msys or cmd.exe and not Visual Studio). I have to admit ccmake is nice though! [1] https://github.com/slembcke/Chipmunk2D [2] https://github.com/rougier/freetype-gl/blob/master/CMakeLists.txt From thadguidry at gmail.com Fri Jan 10 09:38:56 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Fri, 10 Jan 2014 11:38:56 -0600 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: Best Reason ever for a Rust Build System = You Prove Rust Itself. So get hacking on a Rust Build System. -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertknight at gmail.com Fri Jan 10 09:57:32 2014 From: robertknight at gmail.com (Robert Knight) Date: Fri, 10 Jan 2014 17:57:32 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: > - CMakeLists.txt often look ugly [2] and don't follow any particular > style (lower case vs. upper case, etc.). A fair point, though a number of projects do have coding conventions for CMakeLists.txt files, one of which could be adopted - eg. http://techbase.kde.org/Policies/CMake_Coding_Style Regards, Rob. On 10 January 2014 17:38, Thad Guidry wrote: > Best Reason ever for a Rust Build System = You Prove Rust Itself. > > So get hacking on a Rust Build System. > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Fri Jan 10 10:18:36 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 10 Jan 2014 10:18:36 -0800 Subject: [rust-dev] returning functions in rust In-Reply-To: References: Message-ID: <52D0397C.3010305@mozilla.com> On 1/10/14 7:20 AM, Nakamura wrote: > I'm new to rust, and tried going through some of the examples from the > OS class[0] that was taught in rust. However, I got tripped up by the > exercise, "make a function that takes an integer n and another function > |x| -> x, and returns a function that is n applications of the original > function." > > I've been trying to see what the limits of rust are if you are using it > without the runtime/managed pointers etc, and it seems like I stumble > against one of the limits when trying to return functions. The big > question is where to allocate the new function I want to return. Rust won't automatically allocate closed-over variables on the heap. This limits the ability to write code like this naturally, but you get the benefit that all allocations are immediately visible and under the control of the programmer. I would not suggest trying to use managed pointers for this. Instead I would suggest `proc`, which is allocated on the exchange heap and can close over variables. This should be sufficient for the question as posed, as long as the "another function" has a `'static` bound (`'static |x| -> x`). Patrick From danielmicay at gmail.com Fri Jan 10 10:27:11 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 10 Jan 2014 13:27:11 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52CFB098.8010100@gmail.com> References: <52CFB098.8010100@gmail.com> Message-ID: On Fri, Jan 10, 2014 at 3:34 AM, Lee Braiden wrote: > On 10/01/14 08:16, Gaetan wrote: > > Bear in mind that Debian are having a lot of issues packaging Rust already, > because it self-compiles. If the build tool also had a Rust pre-dependency, > that would be a big step backwards. What kind of issues? I've had close to zero issues maintaining a package in the Arch repositories along with a nightly build. The only difficulty has been the occasionally Makefile race with `-j8`. It would be nice if it wasn't necessary to strip rpaths with chrpath too... From kevin at sb.org Fri Jan 10 10:28:04 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 10 Jan 2014 10:28:04 -0800 Subject: [rust-dev] returning functions in rust In-Reply-To: <52D0397C.3010305@mozilla.com> References: <52D0397C.3010305@mozilla.com> Message-ID: On Jan 10, 2014, at 10:18 AM, Patrick Walton wrote: > On 1/10/14 7:20 AM, Nakamura wrote: >> I'm new to rust, and tried going through some of the examples from the >> OS class[0] that was taught in rust. However, I got tripped up by the >> exercise, "make a function that takes an integer n and another function >> |x| -> x, and returns a function that is n applications of the original >> function." >> >> I've been trying to see what the limits of rust are if you are using it >> without the runtime/managed pointers etc, and it seems like I stumble >> against one of the limits when trying to return functions. The big >> question is where to allocate the new function I want to return. > > Rust won't automatically allocate closed-over variables on the heap. This limits the ability to write code like this naturally, but you get the benefit that all allocations are immediately visible and under the control of the programmer. > > I would not suggest trying to use managed pointers for this. Instead I would suggest `proc`, which is allocated on the exchange heap and can close over variables. This should be sufficient for the question as posed, as long as the "another function" has a `'static` bound (`'static |x| -> x`). Procs can only be called once, though, which is a bit of a limitation. Does ~|| -> T no longer exist? -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Fri Jan 10 10:38:38 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Fri, 10 Jan 2014 10:38:38 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52D00EEC.6090306@aim.com> Message-ID: I'm personally in favor of us making our own build system, but I am completely biased as I've already written one multistage cross-compiling build system in Python: https://github.com/felix-lang/fbuild The reason why went crazy and built one was for a couple reasons. Before Rust I worked on the Felix language, which had some complex needs for the build system. First off, we wanted to support using MSVC without Cygwin. Second, Building Felix used three languages as part of it's build. The compiler was written in O'Caml, the runtime in C++, and the standard library was in Felix. We also used a couple parser generators. Third, Felix was a cross compiler, so we would configure and build 3 compilers. The first generated a compiler for architecture A that could make a compiler for architecture B who's output targeted architecture C. As you can see, it was a complex problem. Before I started working on FBuild, I evaluated a ton of other build systems, but they all had a bunch of issues trying to support something like this. The biggest one was due to the very nature of a declarative build system. There really are two phases to these systems. First is a phase to gather up all the dependencies and build a tree of work to do. Second is the evaluation of that tree. Things get rather messy when you need to run a command and use it's output to declare more dependencies. A simple example of this is using `gcc -M` to get all the C file dependencies. This is typically supported by all build systems. A more complex one is something like `doxygen`, which requires manual inspection of the file system to determine dependencies. When you combine the two phases with multiple stages it gets really complicated. Code generators like Autoconf and CMake use macro substitutions which can be very difficult to decipher. Systems like SCons can be a little better because you can run arbitrary code at a given step in the dependency tree, but there's some impedance mismatches with how you define the build and run code. You can't do something like this: print 'before' Program('foo.c') print 'after And have the prints bracket the building of 'foo.c'. Futhermore, you need to work with a shared environment to declare command options, and I found that to be difficult to work with when doing a multistage build. Finally, it still seems to be suffering from some poor performance issues: http://blog.melski.net/2013/12/11/update-scons-is-still-really-slow/ Waf and Tup were still pretty new at the time I started FBuild, and if I recall correctly, I think they still had trouble doing a simple multistage build. What I ended up doing with FBuild was to make a build system that was centered around the idea of caching function calls. I made it in Python, and it had a similar style to SCons, where you would write: def build(ctx): c = fbuild.builders.c.guess_static(ctx) print 'before' lib = c.build_lib('static', ['lib.c']) exe = c.build_exe('exe', ['exe.c'], libs=[lib]) print 'after' But each function call actually built the output (or loaded the results from the cache), and the printouts actually happen when they look to happen. Doing multiple stages in this way was really simple. You just use functions: def my_c_compiler(ctx, c): exe = c.build_exec('my-gcc', ['my_gcc.c']) return fbuild.builders.c.gcc.static(ctx, exe) def build(ctx): c = fbuild.builders.c.guess_static(ctx) new_c = my_c_compiler(ctx, c) new_new_c = my_c_compiler(ctx, new_c) It worked well, and was able to run on all our platforms and support some nifty auto configuration support too for many c libraries. It could also build in parallel, but there were some limitations to it because Python did not play well with exceptions, threads, and signals. I've been planning on reimplementing FBuild in rust for quite some time, but I haven't had the time yet to do it beyond a couple experiments. We already have some pieces of this approach in libextra though. Graydon took my caching-of-functions idea and turned it into `extra::workcache`. It wouldn't be *that* hard to port my ideas over from python though. When I get home tonight I'll try to upload my work in progress somewhere. On Fri, Jan 10, 2014 at 7:53 AM, Gaetan wrote: > I also agree that the way waf works is quite weird to use, but this is > actually how most of the installers works under windows or some on MacOS: > the code of the installers is embedded into the distributed package. This > violates the debian packaging rules, and I think this will be the same with > rust. > > I however really like this approach. You don't have a huge among of > dependencies to setup in order to build your package. This is not a problem > on debian where apt does to marveillous job, but on Windows/Mac/generic > linux/arm, .. this is a nightmare. > > One more point in favor of CMake to build rust: you can build > android/arm/misc (thanks to Makefile) with the same CMakeList.txt files, or > with external module inclusion. I also agree that its syntax used to be > quite ugly (the famous if() / else() / endif()), but not so much in the > lastest versions... > But if you require python for building, scons is the perfect, natural > candidate. > > ----- > Gaetan > > > > 2014/1/10 SiegeLord > >> On 01/10/2014 06:19 AM, Robert Knight wrote: >> >>> Hello, >>> >>> CMake does have a few things going for it: >>> >> >> One more consideration is that LLVM can be built with CMake afaik, so if >> we switch to CMake we may be able to drop the autotools dependency, which >> is a more annoying dependency to fulfill (on Windows) than CMake (I don't >> know if Rust has other components that require autotools though). >> >> Along the same lines, we also require Python for whatever reason, so >> SCons would be a natural option too (it can't build LLVM though). I'd only >> use SCons conditional on it accepting a Rust dependency scanner into its >> source: using its current custom scanner infrastructure is not practical as >> I found out. >> >> As for waf... they and Debian have been having a tiff (e.g. see >> http://waf-devel.blogspot.com/2012/01/debian.html , >> https://lists.debian.org/debian-devel/2012/02/msg00207.html ). I would >> not suggest it based on that. >> >> -SL >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Fri Jan 10 10:43:43 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Fri, 10 Jan 2014 10:43:43 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52CFB098.8010100@gmail.com> References: <52CFB098.8010100@gmail.com> Message-ID: Lee, Can you go into more detail on the problems that Debian is having packaging Rust? This sounds like a classic bootstrapping problem, and I'm sure other languages are running into it. How does Debian handle that first build of `make` or `bash` that I assume gcc depends on? On Fri, Jan 10, 2014 at 12:34 AM, Lee Braiden wrote: > On 10/01/14 08:16, Gaetan wrote: > > I am not in favor of a customized build system. For instance boost library > use their jam build system, and i never figured how to use it in my > projects. > > I push to use standard and well proved build system like cmake or scons, > at least for major components. This would give a nice example of how to use > it in any projects. > > > I'd agree with that on both counts: the principle of using something > standard, and the two recommendations. > > CMake would probably get my vote, because it's not so much a build tool, > as a meta tool for whichever system you prefer, so it would fit in well > with various platform-specific IDEs, unusual platforms (android, embedded, > ...), etc. That said, scons is also a strong contender, and which of the > two is more open to integrating patches and working with new languages is > very much worth considering. > > I think Rust will be contributing to the wider community by lending its > support (and patches) to a common, modern build system, AND it will get > something back in terms of users who already know the build system. > > > > On Friday, January 10, 2014, George Makrydakis wrote: >> >>> >>> Hello, >>> >>> Having a build system entirely dependent of Rust alone, would make the >>> entire experience in deploying the language extremely cohere. The only >>> counter - argument is indeed that it would require some work to get this to >>> fruition. I would like to know if this has any chance of getting priority >>> soon enough. >>> >> > Bear in mind that Debian are having a lot of issues packaging Rust > already, because it self-compiles. If the build tool also had a Rust > pre-dependency, that would be a big step backwards. > > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Fri Jan 10 10:57:43 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 10 Jan 2014 10:57:43 -0800 Subject: [rust-dev] returning functions in rust In-Reply-To: References: <52D0397C.3010305@mozilla.com> Message-ID: <4e49b135-fa55-49a6-96b5-d3c6270a8115@email.android.com> It doesn't exist, outside of traits. Unboxed closures will probably make it possible to express once again though. Patrick Kevin Ballard wrote: >On Jan 10, 2014, at 10:18 AM, Patrick Walton >wrote: > >> On 1/10/14 7:20 AM, Nakamura wrote: >>> I'm new to rust, and tried going through some of the examples from >the >>> OS class[0] that was taught in rust. However, I got tripped up by >the >>> exercise, "make a function that takes an integer n and another >function >>> |x| -> x, and returns a function that is n applications of the >original >>> function." >>> >>> I've been trying to see what the limits of rust are if you are using >it >>> without the runtime/managed pointers etc, and it seems like I >stumble >>> against one of the limits when trying to return functions. The big >>> question is where to allocate the new function I want to return. >> >> Rust won't automatically allocate closed-over variables on the heap. >This limits the ability to write code like this naturally, but you get >the benefit that all allocations are immediately visible and under the >control of the programmer. >> >> I would not suggest trying to use managed pointers for this. Instead >I would suggest `proc`, which is allocated on the exchange heap and can >close over variables. This should be sufficient for the question as >posed, as long as the "another function" has a `'static` bound >(`'static |x| -> x`). > >Procs can only be called once, though, which is a bit of a limitation. > >Does ~|| -> T no longer exist? > >-Kevin -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Fri Jan 10 10:56:03 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 10 Jan 2014 10:56:03 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: I definitely encourage any sort of experimentation with build systems in Rust. But the most important criterion for Rust to adopt a build system in practice is going to be whether someone is available and willing to maintain it at a production quality level. That trumps all technical and language evangelism issues, in my mind. Not saying we don't have the resources in the community, mind you, just establishing what is in my mind an important criterion. Patrick Thad Guidry wrote: >Best Reason ever for a Rust Build System = You Prove Rust Itself. > >So get hacking on a Rust Build System. > >-- >-Thad >+ThadGuidry >Thad on LinkedIn > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Jan 10 11:01:15 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 10 Jan 2014 14:01:15 -0500 Subject: [rust-dev] returning functions in rust In-Reply-To: <4e49b135-fa55-49a6-96b5-d3c6270a8115@email.android.com> References: <52D0397C.3010305@mozilla.com> <4e49b135-fa55-49a6-96b5-d3c6270a8115@email.android.com> Message-ID: On Fri, Jan 10, 2014 at 1:57 PM, Patrick Walton wrote: > It doesn't exist, outside of traits. Unboxed closures will probably make it > possible to express once again though. > > Patrick The tricky part is the need to infer the return type if it's defined inside the function since it's different per-closure. From banderson at mozilla.com Fri Jan 10 11:13:32 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 10 Jan 2014 11:13:32 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: <52D0465C.5040509@mozilla.com> I think we are going to end up doing a total rewrite. Here are my current concerns: * We need to make a big change to the way bootstrapping works in order to cross-compile correctly: https://github.com/mozilla/rust/issues/11145 * Adding new crates to the current build system is very error-prone. We need all the logic for building them to be encapsulated into something simple. * The build system that Rust uses should be the build system we are promoting as the defacto community build system, and as such it also needs to integrate with rustpkg. My personal preference is to create a tool that can eventually integrate into rustpkg that generates ninja scripts, and package and distribute ninja ourselves (as rust-ninja or something). On 01/09/2014 09:46 PM, Corey Richardson wrote: > Hey all, > > The build system has grown a fair bit of complexity, and is getting > hard to understand. I've been thinking about what could replace it > moving forward. Most of the complexity stems from having to self-host > (ie, staging) and cross compilation (which target are we compiling > for, and with which host?) > > Our build system must: > > 1. Work on all the platforms we support > 2. Be able to track dependencies. > > Our ideal build system should: > > 1. Require minimal build-time dependencies > 2. Allow ease of staging and cross compilation > 3. Be easy to extend as we grow > 4. Have readable build scripts > 5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc > should all be retained) > > There are a few options: > > 1. Rework the current makefiles to be nicer. > > I'm not sure if this is feasible. Some stuff certainly could be > easier, but the inherent problems of make (nested evals + calls, no > named parameters (what does $(1) mean here, etc), general ugliness) > make this unlikely to be a worthwhile effort, besides factoring out > some of the current boilerplate. > > 2. Use a different build system. > > The major option here seems to be cmake[1], although I've heard > murmurings of tup[2] and some other obscure things. I'm unsure tup is > going to be of much help here. With our compilation model, > fine-grained file-based dependencies are not very useful. However, > it's awesome bottom-up dependency model could be neat. It's possible > that we could use it with a combination of: > > 3. Write a build system in Rust. > > This would take care of everything for us, using ourselves. We'd have > a small script fetch the snapshot and build the build system, and then > hand off the rest of the build to it. This has the advantage of one > less build-time dependency, but the disadvantage that it's going to be > a lot of work. This could also potentially output tup, ninja[3], or > another form of build script after taking configuration options and > so-forth. It could also integrate with librustc for smart handling of > comments-or-test-only changes, an issue near to my heart[4]. This > build system could potentially be rustpkg, but as I understand it the > current idea is to *remove* rustpkg's ability as a build system and > keep it as a package manager. (At least, that is what I've understood > of recent discussion; this could be wrong.) > > 4. Write a build system in $LANG. > > Python seems to be a good choice here, since we already depend on it > for fetching the snapshot etc. This still has the disadvantage of > being a lot of work, but would perhaps be easier than writing a build > system in Rust. We would definitely lose hacker points for doing so. > > There are undoubtedly other options as well. Does anyone have good > ideas or opinions on what we should do? Personally I think that 3 is > going to be the best option, unless there's some super amazing build > system I haven't heard of it. Which is totally possible! > > [1]: http://www.cmake.org/ > [2]: http://gittup.org/tup/ > [3]: http://martine.github.io/ninja/ > [4]: https://github.com/mozilla/rust/issues/6522 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From leebraid at gmail.com Fri Jan 10 11:18:32 2014 From: leebraid at gmail.com (Lee Braiden) Date: Fri, 10 Jan 2014 19:18:32 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> Message-ID: <52D04788.5070203@gmail.com> Hmm, after further reading, I think I've they're making more progress on it than I thought, from first impressions of the discussion. They've had a lot of different issues to deal with, not just the self-dependency, but they got 0.7 packaged, at least. More detail here, particularly in the last comment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689207 You can see there that the debian packagers also referenced a list of issues that the fedora wrote up: https://github.com/mozilla/rust/wiki/Note-packaging -- Lee On 10/01/14 18:43, Erick Tryzelaar wrote: > Lee, > > Can you go into more detail on the problems that Debian is having > packaging Rust? This sounds like a classic bootstrapping problem, and > I'm sure other languages are running into it. How does Debian handle > that first build of `make` or `bash` that I assume gcc depends on? > > > > On Fri, Jan 10, 2014 at 12:34 AM, Lee Braiden > wrote: > > On 10/01/14 08:16, Gaetan wrote: >> >> I am not in favor of a customized build system. For instance >> boost library use their jam build system, and i never figured how >> to use it in my projects. >> >> I push to use standard and well proved build system like cmake or >> scons, at least for major components. This would give a nice >> example of how to use it in any projects. >> > > I'd agree with that on both counts: the principle of using > something standard, and the two recommendations. > > CMake would probably get my vote, because it's not so much a build > tool, as a meta tool for whichever system you prefer, so it would > fit in well with various platform-specific IDEs, unusual platforms > (android, embedded, ...), etc. That said, scons is also a strong > contender, and which of the two is more open to integrating > patches and working with new languages is very much worth considering. > > I think Rust will be contributing to the wider community by > lending its support (and patches) to a common, modern build > system, AND it will get something back in terms of users who > already know the build system. > > > >> On Friday, January 10, 2014, George Makrydakis wrote: >> >> >> Hello, >> >> Having a build system entirely dependent of Rust alone, >> would make the entire experience in deploying the >> language extremely cohere. The only counter - argument is >> indeed that it would require some work to get this to >> fruition. I would like to know if this has any chance of >> getting priority soon enough. >> > > Bear in mind that Debian are having a lot of issues packaging Rust > already, because it self-compiles. If the build tool also had a > Rust pre-dependency, that would be a big step backwards. > > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Fri Jan 10 11:29:51 2014 From: bascule at gmail.com (Tony Arcieri) Date: Fri, 10 Jan 2014 11:29:51 -0800 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts Message-ID: Hi there Rustafarians, There's a particular type I'd love to see in core Rust: a bytebuffer for crypto purposes which automatically provides what I'd call "good crypto hygiene". It'd do the following things: - Avoid being paged out to swap by use of mlock/VirtualLock - Ensure it's zeroed out (and munlocked) after use (via RAII-style conventions?) - Be able to interact directly with the I/O layer so it's easy to get data in/out of these buffers without having to thunk it through a bunch of intermediate types that won't have these properties, i.e. it should be possible for me to read an encryption key from a file without going through a [u8] that wouldn't get locked/zeroed automatically. Why is it important to have a type like this in the Rust standard library? IMO, so all the cryptographic libraries in Rust can use the same type for this purpose and in doing so interoperate easily (i.e. I should be able to get a cryptographic key read from TLS and decrypted into one of these buffers and use it with another library while still ensuring everything will get locked/zeroed) It would also mean that anyone using Rust would have a lot easier time writing code with good crypto hygiene, at least if all the crypto libraries used it, because this type would take care of doing all of this sort of thing for you automatically. Most other languages completely punt on this problem. Can Rust do better? Is this the sort of thing that belongs in the Rust standard library? -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Fri Jan 10 12:27:31 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 10 Jan 2014 12:27:31 -0800 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts In-Reply-To: References: Message-ID: <0FBE528E-4261-4653-B242-B3D7EA01F4AF@sb.org> Given that the crypto philosophy of the core Rust libraries is "don't put crypto in the core Rust libraries", I don't think a type like this needs to be in the core libraries. But I do think this is a good opportunity for a third-party library to create this type and promote itself as the set of building blocks for doing crypto in Rust. Furthermore, I could also imagine there being official Rust documentation that recommends this third-party library to anyone who wants to do crypto. -Kevin On Jan 10, 2014, at 11:29 AM, Tony Arcieri wrote: > Hi there Rustafarians, > > There's a particular type I'd love to see in core Rust: a bytebuffer for crypto purposes which automatically provides what I'd call "good crypto hygiene". It'd do the following things: > > - Avoid being paged out to swap by use of mlock/VirtualLock > - Ensure it's zeroed out (and munlocked) after use (via RAII-style conventions?) > - Be able to interact directly with the I/O layer so it's easy to get data in/out of these buffers without having to thunk it through a bunch of intermediate types that won't have these properties, i.e. it should be possible for me to read an encryption key from a file without going through a [u8] that wouldn't get locked/zeroed automatically. > > Why is it important to have a type like this in the Rust standard library? IMO, so all the cryptographic libraries in Rust can use the same type for this purpose and in doing so interoperate easily (i.e. I should be able to get a cryptographic key read from TLS and decrypted into one of these buffers and use it with another library while still ensuring everything will get locked/zeroed) > > It would also mean that anyone using Rust would have a lot easier time writing code with good crypto hygiene, at least if all the crypto libraries used it, because this type would take care of doing all of this sort of thing for you automatically. > > Most other languages completely punt on this problem. Can Rust do better? Is this the sort of thing that belongs in the Rust standard library? > > -- > Tony Arcieri > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From jurily at gmail.com Fri Jan 10 12:39:47 2014 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Fri, 10 Jan 2014 21:39:47 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <1949520.i7MrgNSkXU@yoga.dhardy> Message-ID: <52D05A93.50304@gmail.com> On 01/10/2014 04:08 PM, Corey Richardson wrote: > This RFC isn't about using a single build system for everything, it's > the build system we use to build Rust itself. > > On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy wrote: >> A further point in favour of CMake is that it would make multi-language >> projects easier to manage, in particular transitioning a "C-family" project to >> Rust. >> >> On Friday 10 January 2014 08:34:32 Lee Braiden wrote: > Both Rust and Servo are multi-language projects, and LLVM already uses CMake. Wouldn't it be a plus to bootstrap Rust with the Standard Rust Build System(tm)? Also, CMake can use the Visual Studio toolchain on Windows. From leebraid at gmail.com Fri Jan 10 12:50:16 2014 From: leebraid at gmail.com (Lee Braiden) Date: Fri, 10 Jan 2014 20:50:16 +0000 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts In-Reply-To: References: Message-ID: <52D05D08.1030000@gmail.com> On 10/01/14 19:29, Tony Arcieri wrote: > There's a particular type I'd love to see in core Rust: a bytebuffer > for crypto purposes which automatically provides what I'd call "good > crypto hygiene". It'd do the following things: > > - Avoid being paged out to swap by use of mlock/VirtualLock This is a general memory setting, which is required for all sorts of use-cases: disk io buffers, device driver buffers, off-screen rendering, caching, important interactive elements (mouse pointers and application menus, for instance), which would hamper the user experience if they were paged in/out, etc. I'd go as far as to say that any system with swapping needs an easy way to lock memory like this. It's not even really a crypto problem, since swap can (and probably should be) encrypted too, if you encrypt your filesystem(s). I would like to see a platform-independent implementation in std::mem -- std::mem::lock(buf, len) and it's unlock() opposite, perhaps. > - Ensure it's zeroed out (and munlocked) after use (via RAII-style > conventions?) Isn't this just a dtor thing? > - Be able to interact directly with the I/O layer so it's easy to get > data in/out of these buffers without having to thunk it through a > bunch of intermediate types that won't have these properties, i.e. it > should be possible for me to read an encryption key from a file > without going through a [u8] that wouldn't get locked/zeroed > automatically. This sounds like a general IO optimisation, which virtually any block-based io use-case could benefit from. -- Lee From jurily at gmail.com Fri Jan 10 13:26:09 2014 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Fri, 10 Jan 2014 22:26:09 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: <52D06571.50109@gmail.com> I'm all for CMake. Not so much for the technical merits, but the amount of infrastructure already built up around it. KDE has adopted it wholesale, meaning all the dependencies of the entire KDE project are supported out of the box, and also IDE support in KDevelop, Qt Creator, emacs/vi etc. Bootstrapping comes to mind as a potential problem, but LLVM and Clang use it too. From bill_myers at outlook.com Fri Jan 10 14:15:38 2014 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 10 Jan 2014 22:15:38 +0000 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts In-Reply-To: References: Message-ID: This can be easily implemented in Rust as a struct doing exactly that. There's no need to modify the I/O layer, since you'd simply borrow an &[u8] from the type and pass it, resulting in the I/O layer directly writing into the locked zeroed-on-destruction memory. As for crypto, it seems the plan is to not implement it in Rust, but to bind to libraries such as OpenSSL, libgcrypt, Windows CryptoAPI, etc. I guess patches would be welcome to implement this. From bill_myers at outlook.com Fri Jan 10 14:25:30 2014 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 10 Jan 2014 22:25:30 +0000 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts In-Reply-To: References: , Message-ID: At any rate, note that what you are trying to do only provides some mitigation and is far from a complete solution, because in practice you can't prevent leakage of all confidential data in this way (what about hibernation while the key is in memory? what about plaintext decrypted with the key?) The only effective solution is to encrypt all storage including swap using full-disk encryption, as well as all internal network links using IPsec or similar, so that it doesn't matter if sensitive data is swapped, accidentally written to files or communicated between servers. From donquestion at rocketmail.com Fri Jan 10 14:38:49 2014 From: donquestion at rocketmail.com (Don Question) Date: Fri, 10 Jan 2014 23:38:49 +0100 Subject: [rust-dev] general onlookers questions on rust development In-Reply-To: References: Message-ID: <52D07679.8040607@rocketmail.com> Congrats to 0.9! I'm coming from a C/C++/Python background and was loosely following the progress of Rust for quite a while now, but never tried it until yesterday. I must admit i'm quite pleased so far, but i have some question, which i hope you could help to clarify. 1. I miss a search functionality on the mailing list. Am i just blind, or do i have to use google with the "site:" option? 2. I'm used to curly braces, but every time i have to code in C or JavaScript i miss the better readability of python's curly-free syntax. What was the reason to keep the (imho: annoying) curly braces? I must confess i was a little bit taken aback by the first sentence on rust-lang.org: "Rust is a curly-brace, ..." 3. If i wanted to use Rust instead of C for external Python-Modules, what would be my options to achieve that? Could i use ctypes and Rust's "extern"? 4. Why is the BSD implementation almost 3 times faster then the linux and mac-versions ? http://huonw.github.io/isrustfastyet/buildbot/ 5. When will we see a Rust version of the Linux kernel? Just joking! ;-) Keep up the good work! Thx and regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Fri Jan 10 14:44:35 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 10 Jan 2014 14:44:35 -0800 Subject: [rust-dev] general onlookers questions on rust development In-Reply-To: <52D07679.8040607@rocketmail.com> References: <52D07679.8040607@rocketmail.com> Message-ID: > 1. I miss a search functionality on the mailing list. Am i just blind, or do > i have to > use google with the "site:" option? The mailing list we use is pretty standard, and it's archived/searchable on other mirrors (gmane I think mirrors our mailing list) > 2. I'm used to curly braces, but every time i have to code in C or > JavaScript i miss the > better readability of python's curly-free syntax. What was the reason to > keep the (imho: > annoying) curly braces? I must confess i was a little bit taken aback by the > first > sentence on rust-lang.org: "Rust is a curly-brace, ..." This is certainly a subjective topic rather than an objective one, and we have long since made this decision. There are many reasons as to why we chose this, along with many other things that then fell out because of this decision. At this point it would be a little difficult to go back to the core reason, but it's not too interesting any more because this is pretty much set in stone at this point. > 3. If i wanted to use Rust instead of C for external Python-Modules, what > would be my > options to achieve that? Could i use ctypes and Rust's "extern"? You certainly can! You can build dynamic or static rust libraries with functions tagged with `#[no_mangle]` so python can see the symbols. There's at least one (and I think a few more) ruby extension which is using rust to power it. > 4. Why is the BSD implementation almost 3 times faster then the linux and > mac-versions ? > http://huonw.github.io/isrustfastyet/buildbot/ This is just an artifact of BSD running a vastly stripped down version of the test suite (it's running on a very slow AWS bot). The BSD implementation is not actually 3x faster than everything else. > 5. When will we see a Rust version of the Linux kernel? Just joking! ;-) > Keep up the good > work! In all seriousness, there are actually a fairly large and growing number of kernels written in rust! Most of them are "demo quality" in the sense that they're not production kernels, but Rust is turning out to be a good language to write kernels in. From corey at octayn.net Fri Jan 10 14:44:58 2014 From: corey at octayn.net (Corey Richardson) Date: Fri, 10 Jan 2014 17:44:58 -0500 Subject: [rust-dev] general onlookers questions on rust development In-Reply-To: <52D07679.8040607@rocketmail.com> References: <52D07679.8040607@rocketmail.com> Message-ID: On Fri, Jan 10, 2014 at 5:38 PM, Don Question wrote: > Congrats to 0.9! > > I'm coming from a C/C++/Python background and was loosely following the > progress of Rust > for quite a while now, but never tried it until yesterday. > > I must admit i'm quite pleased so far, but i have some question, which i > hope you could > help to clarify. > > 1. I miss a search functionality on the mailing list. Am i just blind, or do > i have to > use google with the "site:" option? > You're not blind. But, there's also a searchable gmane mirror: http://blog.gmane.org/gmane.comp.lang.rust.devel > 2. I'm used to curly braces, but every time i have to code in C or > JavaScript i miss the > better readability of python's curly-free syntax. What was the reason to > keep the (imho: > annoying) curly braces? I must confess i was a little bit taken aback by the > first > sentence on rust-lang.org: "Rust is a curly-brace, ..." > I'm not 100% sure but afaik it's to keep syntactical familiarity. > 3. If i wanted to use Rust instead of C for external Python-Modules, what > would be my > options to achieve that? Could i use ctypes and Rust's "extern"? > Devin Jeanpierre (aka ssbr) has Python bindings: https://bitbucket.org/devin.jeanpierre/pyrite. They might need updating. But yes, you'd want to use `extern "C"` and then use it the same way you'd use a C module. > 4. Why is the BSD implementation almost 3 times faster then the linux and > mac-versions ? > http://huonw.github.io/isrustfastyet/buildbot/ > It isn't. It's running a stripped down version of the test suite (make check-fast). From dpx.infinity at gmail.com Fri Jan 10 14:46:54 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sat, 11 Jan 2014 02:46:54 +0400 Subject: [rust-dev] Exporting macros: #[macro_escape] usage Message-ID: Hi, As far as I understand, the current way to export macros is to annotate the module with macro_rules definition with #[macro_escape] annotation. But I just can't get it right, and my macro is not visible in other module :( Here is what I have: ----- START ----- /lib.rs: #[feature(macro_rules)]; pub mod m1; -- /m1/mod.rs: #[macro_escape]; pub mod submod; macro_rules! example_rule( () => (mod test;) ) -- /m1/submod.rs: use m1; example_rule!() ----- END ----- I have assumed that putting #[macro_escape] annotation to a module makes all macros from that module available in all modules which import this module, but apparently I'm wrong because the code above does not work with 'macro undefined' error. Could please someone explain how #[macro_escape] works in detail? I couldn't find any documentation on it, and looking through standard libs was not helpful. Thanks, Vladimir. From me at chrismorgan.info Fri Jan 10 15:44:51 2014 From: me at chrismorgan.info (Chris Morgan) Date: Sat, 11 Jan 2014 10:44:51 +1100 Subject: [rust-dev] Exporting macros: #[macro_escape] usage In-Reply-To: References: Message-ID: The macro is being defined after the module is defined. You need to move the macro definition before the "pub mod submod;" line. Also due to the scoping rules of macros, you don't need #[macro_escape] there---it's a child, so it gets the macro. Only siblings, parents, uncles, aunts, cousins, &c. would need it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Fri Jan 10 16:02:51 2014 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Sat, 11 Jan 2014 11:02:51 +1100 Subject: [rust-dev] general onlookers questions on rust development In-Reply-To: References: <52D07679.8040607@rocketmail.com> <18367033-4628-4312-9E3F-42075246C2D2@yahoo.com.au> Message-ID: <288CEE8A-FF50-4241-9058-45230490A7AA@yahoo.com.au> On 11 Jan 2014, at 9:38 am, Don Question wrote: > 2. I'm used to curly braces, but every time i have to code in C or JavaScript i miss the > better readability of python's curly-free syntax. What was the reason to keep the (imho: > annoying) curly braces? I must confess i was a little bit taken aback by the first > sentence on rust-lang.org: "Rust is a curly-brace, ..." I?m pretty sure it was for familiarity?s sake. I?m not the biggest fan of curly bracket syntax, but it?s a) too far down the road to change it easily, and b) far less important to me than the semantics that Rust brings to the table. ~Brendan From bascule at gmail.com Fri Jan 10 16:23:11 2014 From: bascule at gmail.com (Tony Arcieri) Date: Fri, 10 Jan 2014 16:23:11 -0800 Subject: [rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts In-Reply-To: References: Message-ID: Okay, first, I'm glad to hear that people are interested in general solutions to the problems that I posed which are orthogonal to crypto but could still benefit crypto applications. On Fri, Jan 10, 2014 at 2:25 PM, Bill Myers wrote: > At any rate, note that what you are trying to do only provides some > mitigation and is far from a complete solution Hence "best crypto hygiene" not "crypto-safe memory type for Rust!" > in practice you can't prevent leakage of all confidential data in this way You mean attackers could potentially reach /dev/kmem? Yes, at that point, all bets are off ;) > what about hibernation while the key is in memory? Seems useful actually! But clearly the way memory is being saved (encrypted or not) is important. > what about plaintext decrypted with the key? I guess you're vicariously attempting to ask what the threat model is here, and spelling out some potential compromises. I'd say what about: 1) hardware-attached DMA devices, i.e. firewire memory inspection via tools like Inception: http://www.breaknenter.org/projects/inception/ 2) Cold-boot attacks: https://en.wikipedia.org/wiki/Cold_boot_attack We really need to back up here and get back to what I was really talking about, which is best crypto hygiene. This isn't about building a virtual safe with 4" thick steel walls for cryptographic applications. This is about using the language to enforce cryptographic best practices, which do NOT provide any guarantees about securing cryptosystems, they merely make the attacker's job harder. But we should back up even further yet: On Fri, Jan 10, 2014 at 12:50 PM, Lee Braiden wrote: > This is a general memory setting, which is required for all sorts of > use-cases: disk io buffers, device driver buffers, off-screen rendering, > caching, important interactive elements (mouse pointers and application > menus, for instance), which would hamper the user experience if they were > paged in/out, etc. I'd go as far as to say that any system with swapping > needs an easy way to lock memory like this. It's not even really a crypto > problem, since swap can (and probably should be) encrypted too, if you > encrypt your filesystem(s). > Yes, this isn't just a crypto problem. I want to solve my crypto-problems, but if there are bigger fish to fry here, then cool ;) Isn't this just a dtor thing? > YES! This sounds like a general IO optimisation, which virtually any block-based > io use-case could benefit from. > Yup! Can we solve it? ;) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.morganiser at gmail.com Fri Jan 10 15:39:24 2014 From: chris.morganiser at gmail.com (Chris Morgan) Date: Sat, 11 Jan 2014 10:39:24 +1100 Subject: [rust-dev] Exporting macros: #[macro_escape] usage In-Reply-To: References: Message-ID: The macro is being defined after the module is defined. You need to move the macro definition before the "pub mod submod;" line. Also due to the scoping rules of macros, you don't need #[macro_escape] there---it's a child, so it gets the macro. Only siblings, parents, uncles, aunts, cousins, &c. would need it. On Jan 11, 2014 9:46 AM, "Vladimir Matveev" wrote: > Hi, > > As far as I understand, the current way to export macros is to > annotate the module with macro_rules definition with #[macro_escape] > annotation. But I just can't get it right, and my macro is not visible > in other module :( > > Here is what I have: > > ----- START ----- > /lib.rs: > #[feature(macro_rules)]; > > pub mod m1; > > -- > /m1/mod.rs: > #[macro_escape]; > > pub mod submod; > > macro_rules! example_rule( > () => (mod test;) > ) > > -- > /m1/submod.rs: > use m1; > > example_rule!() > ----- END ----- > > I have assumed that putting #[macro_escape] annotation to a module > makes all macros from that module available in all modules which > import this module, but apparently I'm wrong because the code above > does not work with 'macro undefined' error. > > Could please someone explain how #[macro_escape] works in detail? I > couldn't find any documentation on it, and looking through standard > libs was not helpful. > > Thanks, > Vladimir. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Fri Jan 10 19:44:24 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 10 Jan 2014 19:44:24 -0800 Subject: [rust-dev] Properly licensing Rust documentation and wiki Message-ID: <52D0BE18.2070106@mozilla.com> Hey. Time for more legal stuff. Per https://github.com/mozilla/rust/issues/5831 the licensing of our documentation is not clear. Like all things Rust we want to make our doc license as permissive as possible, so after getting some legal advice here is what I intend to do: * Rust documentation will be MIT/ASL2 licensed like everything else. * Add the license as a *footer* to existing in-tree documentation, under the argument that it is already licensed according to the same terms as the rest of the repo. * Gather new statements from wiki contributors asserting that they contrtibuted under the MIT/ASL2, as we did when we relicensed Rust. * Put the license as footers on all pages of the wiki. For the most part this should not affect anybody, though if you've ever touched the wiki you may recieve an email from me about this in the future. Regards, Brian From leebraid at gmail.com Fri Jan 10 21:15:49 2014 From: leebraid at gmail.com (Lee Braiden) Date: Sat, 11 Jan 2014 05:15:49 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 Message-ID: <52D0D385.1080200@gmail.com> This may be go nowhere, especially so late in Rust's development, but I feel like this is an important, relatively small change (though a high-profile one). I believe it could have a large, positive impact in terms of targeting new developer communities, gaining more libraries and applications, giving a better impression of the language, AND on performance and futureproofing. However, a lot of people who are interested in performance will probably baulk at this, on first sight. If you're in that group, let me encourage you to keep reading, at least until the points on performance /improvements/. Then baulk, if you like ;) Also, I said it in the post as well, but it's late here, so apologies for any readability / editing issues. I tried, but sleep beckons ;) http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ -- Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jan 10 21:41:07 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 11 Jan 2014 00:41:07 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0D385.1080200@gmail.com> References: <52D0D385.1080200@gmail.com> Message-ID: The current consensus on this subject, afaik, is the rename int/uint to intptr/uintptr. They're awful names, but it frees up int for a *fast* bigint type. Fast here is key. We can't have a suboptimal numeric type be the recommended default. We need to perform at least as well as GMP for me to even consider it. Additionally we'd have generic numeric literals. I don't think anyone wants what we current have for *numerics*. Fixed-size integers are necessary for some tasks, but numerics is not one of them. As long as we rename int/uint to intptr/uintptr and leave int etc reserved, I think we can defer the language issues to post-1.0. It should be entirely backwards compatible. Development of robust numerics can happen outside the standard library. Talk to bjz about this, he has some ideas :) As an aside, you mention a "real" in your blog post like it's something that exists. Rust does not have any such type. On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I feel > like this is an important, relatively small change (though a high-profile > one). I believe it could have a large, positive impact in terms of > targeting new developer communities, gaining more libraries and > applications, giving a better impression of the language, AND on performance > and futureproofing. > > However, a lot of people who are interested in performance will probably > baulk at this, on first sight. If you're in that group, let me encourage > you to keep reading, at least until the points on performance improvements. > Then baulk, if you like ;) > > Also, I said it in the post as well, but it's late here, so apologies for > any readability / editing issues. I tried, but sleep beckons ;) > > > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Fri Jan 10 21:48:40 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 10 Jan 2014 21:48:40 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: <52D0DB38.4030001@mozilla.com> On 1/10/14 9:41 PM, Corey Richardson wrote: > The current consensus on this subject, afaik, is the rename int/uint > to intptr/uintptr. They're awful names, but it frees up int for a > *fast* bigint type. Fast here is key. We can't have a suboptimal > numeric type be the recommended default. We need to perform at least > as well as GMP for me to even consider it. Additionally we'd have > generic numeric literals. I don't think anyone wants what we current > have for *numerics*. Fixed-size integers are necessary for some tasks, > but numerics is not one of them. I wasn't aware of this consensus. I'm not sure what I think; int and uint as they are is pretty nice for array indexing. Patrick From bob at redivi.com Fri Jan 10 21:50:02 2014 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Jan 2014 21:50:02 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0D385.1080200@gmail.com> References: <52D0D385.1080200@gmail.com> Message-ID: On Friday, January 10, 2014, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I > feel like this is an important, relatively small change (though a > high-profile one). I believe it could have a large, positive impact in > terms of targeting new developer communities, gaining more libraries and > applications, giving a better impression of the language, AND on > performance and futureproofing. > > However, a lot of people who are interested in performance will probably > baulk at this, on first sight. If you're in that group, let me encourage > you to keep reading, at least until the points on performance > *improvements*. Then baulk, if you like ;) > > Also, I said it in the post as well, but it's late here, so apologies for > any readability / editing issues. I tried, but sleep beckons ;) > > > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > I think a pragmatic approach is to do what Haskell does and allow number literals to be used for any type that implements the right typeclasses. You can implement what you need to as a library, and if it solves problems then people will use it. (rant below, feel free to ignore) Floats aren't horrible, you just have to know a little bit of numerical analysis in order to use them properly (regardless of what base they are in!). Most of the science and finance computations that I know of fit just fine into the domain of fixed size floating point. The numbers have finite precision to begin with, and there's often a ton of them so performance matters. Having some arbitrary precision type where adding a really small number to a really big one can take up an arbitrarily large amount of memory and/or time probably isn't going to help much. Also, good luck actually supporting real numbers unless you intend for this type to work symbolically, and then you are building a computer algebra system. That's not likely the right course for a systems programming language. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Fri Jan 10 21:50:43 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 11 Jan 2014 16:50:43 +1100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0DB38.4030001@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DB38.4030001@mozilla.com> Message-ID: <52D0DBB3.2040005@gmail.com> On 11/01/14 16:48, Patrick Walton wrote: > On 1/10/14 9:41 PM, Corey Richardson wrote: >> The current consensus on this subject, afaik, is the rename int/uint >> to intptr/uintptr. They're awful names, but it frees up int for a >> *fast* bigint type. Fast here is key. We can't have a suboptimal >> numeric type be the recommended default. We need to perform at least >> as well as GMP for me to even consider it. Additionally we'd have >> generic numeric literals. I don't think anyone wants what we current >> have for *numerics*. Fixed-size integers are necessary for some tasks, >> but numerics is not one of them. > > I wasn't aware of this consensus. I'm not sure what I think; int and > uint as they are is pretty nice for array indexing. The RFC/issue is https://github.com/mozilla/rust/issues/9940 Huon > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From ml at isaac.cedarswampstudios.org Fri Jan 10 21:58:59 2014 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat, 11 Jan 2014 00:58:59 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0D385.1080200@gmail.com> References: <52D0D385.1080200@gmail.com> Message-ID: <52D0DDA3.8040501@isaac.cedarswampstudios.org> Scheme's numeric tower is one of the best in extant languages. Take a look at it. Of course, its dynamic typing is poorly suited for Rust. Arbitrary-precision arithmetic can get you mathematically perfect integers and rational numbers, but not real numbers. There are an uncountably infinite number of real numbers and sophisticated computer algebra systems are devoted the problem (or estimates are used, or you become unable to compare two real numbers for equality). The MPFR C library implements arbitrarily high precision floating point, but that still has all the pitfalls of floating-point that you complain about. For starters, try representing sqrt(2) and testing its equality with e^(0.5 ln 2). In general, Rust is a systems language, so fixed-size integral types are important to have. They are better-behaved than in C and C++ in that signed types are modulo, not undefined behaviour, on overflow. It could be nice to have integral types that are task-failure on overflow as an option too. As you note, bignum integers are important too; it's good they're available. I think bignum rationals would be a fine additional choice to have (Haskell and GMP offer them, for example). -Isaac On 01/11/2014 12:15 AM, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I > feel like this is an important, relatively small change (though a > high-profile one). I believe it could have a large, positive impact in > terms of targeting new developer communities, gaining more libraries and > applications, giving a better impression of the language, AND on > performance and futureproofing. > > However, a lot of people who are interested in performance will probably > baulk at this, on first sight. If you're in that group, let me > encourage you to keep reading, at least until the points on performance > /improvements/. Then baulk, if you like ;) > > Also, I said it in the post as well, but it's late here, so apologies > for any readability / editing issues. I tried, but sleep beckons ;) > > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > > > -- > Lee > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From danielmicay at gmail.com Fri Jan 10 22:01:29 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:01:29 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0D385.1080200@gmail.com> References: <52D0D385.1080200@gmail.com> Message-ID: On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I feel > like this is an important, relatively small change (though a high-profile > one). I believe it could have a large, positive impact in terms of > targeting new developer communities, gaining more libraries and > applications, giving a better impression of the language, AND on performance > and futureproofing. > > However, a lot of people who are interested in performance will probably > baulk at this, on first sight. If you're in that group, let me encourage > you to keep reading, at least until the points on performance improvements. > Then baulk, if you like ;) > > Also, I said it in the post as well, but it's late here, so apologies for > any readability / editing issues. I tried, but sleep beckons ;) > > > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > > > -- > Lee > The wrongness of float There is no lossless implementation of real numbers on a computer. You assume arbitrary precision floating point can cover every real number, but there's no such thing. Arbitrary precision means you can choose the precision used by the numbers. It's certainly no replacement for hardware floating point because it's many orders of magnitude slower. You may not understand IEEE754 floating point arithmetic, but it's certainly not *wrong*. > The wrongness of machine ints Big integers are many orders of magnitude slower than hardware integer arithmetic. It's not a replacement for it, but rather an alternative when you need a larger range. You still need to validate inputs because it's very easy to go out-of-memory, and that's going to bring down the whole process or even other processes on the system. > For those looking to reject this idea on the basis of optimisation: consider that abstracting away from 32-bit integers or 64-bit floats, or 256-bit ints, can potentially lead to better optimisation, if the compiler can then figure out that it?s on a 256-bit machine (or indeed, is targeting a 256-bit GPU) and is free to optimise accordingly. This isn't how hardware works. Smaller floating point numbers are faster than higher precision, because they're smaller. An array of 32-bit floating point numbers will always be half the size as the same array of 64-bit floating point numbers. Double the amount of data can fit into the layers of caches, and you can fit twice as many into SIMD registers so there's double the amount of theoretical throughput. > real becomes, not a 32-bit float (as I understand it currently is), but what it sounds like: a real number, covering all numbers in the real number range, using an arbitrary precision type. Rust doesn't have a `real` type. It has `f32` and `f64`, which are an explicit opt-in to IEEE754 binary floating point. If you don't want this, you don't have to use them. Anyway, covering all numbers in the real number range isn't possible. You can have the user pass the desired precision in the constructor and then handle two inputs of varying precision in a sensible way. > int is not (misleadingly) a machine word, but represents what it sounds like: the entire range of integers, using a bigint type. The Big int type in extra would probably be fine, if it were optimised more. I noticed that there were pull requests for large performance improvements in bigint, but they were rejected for lack of comments. I suspect, if it where given its rightful place as the only fully capable integer type in the libraries, then it would rapidly gain performance through patches, too. A pointer-size integer type is required. A big integer type cannot be implemented without library support, and will always be significantly slower than hardware integer types. A Rust big integer implementation is not going to be competitive with libraries like `gmp` for at least a decade. An enormous amount of work is required to implement the whole range of algorithms with better asymptomatic performance, then optimize with per-platform assembly and figure out the heuristics for selecting the algorithms. Placing a huge performance burden on all Rust code and pushing it far behind Java in performance is not going to result in a fantasy world where big integers are the same speed. > Range checking be implemented in debug and optimisation compiler modes, to support the above, and for the general (ada-like) safety benefits that range-checking of numbers would provide. If it?s REALLY such a compilation-speed turn-off, it could be enabled with specific compiler flags. Range checking also results in significant performance overhead. Two's complement arithmetic is also often desired, especially in cryptography and hashing algorithms. Checked overflow is already provided in the standard library and alternate types handling overflow in a different way than two's complement arithmetic could be added. Pretty much the only useful thing here would be implementing an enum using a hardware integer for small values, and overflowing to a big integer. > Rust compilers can optimise int to i32 etc. _automatically_, iff it knows there are no problems doing so, because of the number ranges involved in calculations. This isn't going to happen in the real-world. Compilers are not magic, and can't just go changing the size of a type across the program and somehow figure out where all of the pointers go. > Likewise, f64, etc. are considered optimisations of real, and can either be optimised by hand, or ? potentially, if the compiler work is done ? automatically. Real number precision is always going to be a compromise. There is no such thing as perfect precision, and Rust doesn't need to choose a default. The only time I can imagine you would be able to lower the precision is if someone casts a 32-bit floating point number to 64-bit, performs an operation and then stores it back as a 32-bit number. It's not going to scale. > equality comparisons are accurate for math by default They are already accurate. > number range checking would be available, either by default or as an optional compiler feature / optimisation flag It's already available and you can write an integer type with checked overflow. The performance is not impressive, and there's nothing Rust can do about it. It's outputting the checked overflow intrinsics and you can choose to handle the overflow flag however you wish. > New x86_64 CPUs will (may already) implement decimal types in hardware ? in a way that?s compatible with C++?s new decimal types AFAIK this isn't implemented in hardware. Anyway, IEEE754 decimal floats have the same caveats as binary floats except that they won't have lower precision than literals written as decimals. > Slower math by default. A compiler flag could override this, or people could manually specify a faster f32/f64/i64 type, for example, if they care. I do not think this is a significant problem. This isn't a significant problem? Rust is a systems language, and as a systems language it is going to expose the fast low-level primitive types. If it doesn't offer C level performance, then it's not a very useful language. Brushing aside performance issues by pretending optimizing compilers are omnipresent, magical tools does not work. The language you're looking for isn't Rust, because you don't care at all about performance. # What can actually be done? I have already opened an issue about removing the fallback of integer literals to `int` when another type can be inferred. If there's no fallback, then it's only a matter of adding support for generic literals like Haskell to have all integer types as first-class citizens. Rust doesn't need a default integer type. It doesn't need to make any choices about this at all. It can offer 32-bit, 64-bit and eventually 128-bit IEEE754 floating point numbers. It can offer 8-bit, 16-bit, 32-bit and 64-bit variants of two's complement arithmetic integers. It can offer big integers, rational numbers, arbitrary precision binary floats and arbitrary precision decimal floats. You can use the suitable tool for the job without burdening everyone with significant performance overhead and turning Rust into something that's not a systems language. From dbau.pp at gmail.com Fri Jan 10 22:05:17 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 11 Jan 2014 17:05:17 +1100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0DDA3.8040501@isaac.cedarswampstudios.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> Message-ID: <52D0DF1D.1080805@gmail.com> On 11/01/14 16:58, Isaac Dupree wrote: > Scheme's numeric tower is one of the best in extant languages. Take a > look at it. Of course, its dynamic typing is poorly suited for Rust. > > Arbitrary-precision arithmetic can get you mathematically perfect > integers and rational numbers, but not real numbers. There are an > uncountably infinite number of real numbers and sophisticated computer > algebra systems are devoted the problem (or estimates are used, or you > become unable to compare two real numbers for equality). The MPFR C > library implements arbitrarily high precision floating point, but that > still has all the pitfalls of floating-point that you complain about. > For starters, try representing sqrt(2) and testing its equality with > e^(0.5 ln 2). > > In general, Rust is a systems language, so fixed-size integral types > are important to have. They are better-behaved than in C and C++ in > that signed types are modulo, not undefined behaviour, on overflow. > It could be nice to have integral types that are task-failure on > overflow as an option too. We do already have some Checked* traits (using the LLVM intrinsics internally), which let you have task failure as one possibility on overflow. e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html (and Mul, Sub, Div too). Huon > As you note, bignum integers are important too; it's good they're > available. I think bignum rationals would be a fine additional choice > to have (Haskell and GMP offer them, for example). > > -Isaac > > > On 01/11/2014 12:15 AM, Lee Braiden wrote: >> This may be go nowhere, especially so late in Rust's development, but I >> feel like this is an important, relatively small change (though a >> high-profile one). I believe it could have a large, positive impact in >> terms of targeting new developer communities, gaining more libraries and >> applications, giving a better impression of the language, AND on >> performance and futureproofing. >> >> However, a lot of people who are interested in performance will probably >> baulk at this, on first sight. If you're in that group, let me >> encourage you to keep reading, at least until the points on performance >> /improvements/. Then baulk, if you like ;) >> >> Also, I said it in the post as well, but it's late here, so apologies >> for any readability / editing issues. I tried, but sleep beckons ;) >> >> >> http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ >> >> >> >> -- >> Lee >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Fri Jan 10 22:05:34 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:05:34 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0DB38.4030001@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DB38.4030001@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton wrote: > On 1/10/14 9:41 PM, Corey Richardson wrote: >> >> The current consensus on this subject, afaik, is the rename int/uint >> to intptr/uintptr. They're awful names, but it frees up int for a >> *fast* bigint type. Fast here is key. We can't have a suboptimal >> numeric type be the recommended default. We need to perform at least >> as well as GMP for me to even consider it. Additionally we'd have >> generic numeric literals. I don't think anyone wants what we current >> have for *numerics*. Fixed-size integers are necessary for some tasks, >> but numerics is not one of them. > > I wasn't aware of this consensus. I'm not sure what I think; int and uint as > they are is pretty nice for array indexing. > > Patrick I think it's very important to remove the default fallback to `int` so Rust can leave this as an explicit choice for the programmer. It's too easy to accidentally fall back to a fixed-size signed integer and since the length varies based on the pointer-size, you may not run into the bugs on the platform you're developing on. It would be nice to name them based on what they are instead of making them out as good defaults, because this should really be an explicit choice. High-level logic will often (but not always) want a big integer type, and it's too easy to just use `int` because it's the "default". From danielmicay at gmail.com Fri Jan 10 22:08:15 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:08:15 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0DF1D.1080805@gmail.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> Message-ID: On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: > On 11/01/14 16:58, Isaac Dupree wrote: >> >> Scheme's numeric tower is one of the best in extant languages. Take a >> look at it. Of course, its dynamic typing is poorly suited for Rust. >> >> Arbitrary-precision arithmetic can get you mathematically perfect integers >> and rational numbers, but not real numbers. There are an uncountably >> infinite number of real numbers and sophisticated computer algebra systems >> are devoted the problem (or estimates are used, or you become unable to >> compare two real numbers for equality). The MPFR C library implements >> arbitrarily high precision floating point, but that still has all the >> pitfalls of floating-point that you complain about. For starters, try >> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >> >> In general, Rust is a systems language, so fixed-size integral types are >> important to have. They are better-behaved than in C and C++ in that signed >> types are modulo, not undefined behaviour, on overflow. It could be nice to >> have integral types that are task-failure on overflow as an option too. > > > We do already have some Checked* traits (using the LLVM intrinsics > internally), which let you have task failure as one possibility on overflow. > e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html > (and Mul, Sub, Div too). I don't think failure on overflow is very useful. It's still a bug if you overflow when you don't intend it. If we did have a fast big integer type, it would make sense to wrap it with an enum heading down a separate branch for small and large integers, and branching on the overflow flag to expand to a big integer. I think this is how Python's integers are implemented. From banderson at mozilla.com Fri Jan 10 22:18:12 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 10 Jan 2014 22:18:12 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> Message-ID: <52D0E224.7060103@mozilla.com> On 01/10/2014 10:08 PM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: >> On 11/01/14 16:58, Isaac Dupree wrote: >>> Scheme's numeric tower is one of the best in extant languages. Take a >>> look at it. Of course, its dynamic typing is poorly suited for Rust. >>> >>> Arbitrary-precision arithmetic can get you mathematically perfect integers >>> and rational numbers, but not real numbers. There are an uncountably >>> infinite number of real numbers and sophisticated computer algebra systems >>> are devoted the problem (or estimates are used, or you become unable to >>> compare two real numbers for equality). The MPFR C library implements >>> arbitrarily high precision floating point, but that still has all the >>> pitfalls of floating-point that you complain about. For starters, try >>> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >>> >>> In general, Rust is a systems language, so fixed-size integral types are >>> important to have. They are better-behaved than in C and C++ in that signed >>> types are modulo, not undefined behaviour, on overflow. It could be nice to >>> have integral types that are task-failure on overflow as an option too. >> >> We do already have some Checked* traits (using the LLVM intrinsics >> internally), which let you have task failure as one possibility on overflow. >> e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html >> (and Mul, Sub, Div too). > I don't think failure on overflow is very useful. It's still a bug if > you overflow when you don't intend it. If we did have a fast big > integer type, it would make sense to wrap it with an enum heading down > a separate branch for small and large integers, and branching on the > overflow flag to expand to a big integer. I think this is how Python's > integers are implemented. I do think it's useful and is potentially a good compromise for the performance of the default integer type. Overflow with failure is a bug that tells you there's a bug. Wrapping is a bug that pretends it's not a bug. Hitting a slow path unexpectedly on overflow seems to me like a recipe for unpredictable performance, which doesn't seem inline with Rust's usual goals. From danielmicay at gmail.com Fri Jan 10 22:20:52 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:20:52 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0E224.7060103@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: >>> >>> On 11/01/14 16:58, Isaac Dupree wrote: >>>> >>>> Scheme's numeric tower is one of the best in extant languages. Take a >>>> look at it. Of course, its dynamic typing is poorly suited for Rust. >>>> >>>> Arbitrary-precision arithmetic can get you mathematically perfect >>>> integers >>>> and rational numbers, but not real numbers. There are an uncountably >>>> infinite number of real numbers and sophisticated computer algebra >>>> systems >>>> are devoted the problem (or estimates are used, or you become unable to >>>> compare two real numbers for equality). The MPFR C library implements >>>> arbitrarily high precision floating point, but that still has all the >>>> pitfalls of floating-point that you complain about. For starters, try >>>> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >>>> >>>> In general, Rust is a systems language, so fixed-size integral types are >>>> important to have. They are better-behaved than in C and C++ in that >>>> signed >>>> types are modulo, not undefined behaviour, on overflow. It could be >>>> nice to >>>> have integral types that are task-failure on overflow as an option too. >>> >>> >>> We do already have some Checked* traits (using the LLVM intrinsics >>> internally), which let you have task failure as one possibility on >>> overflow. >>> e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html >>> (and Mul, Sub, Div too). >> >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. If we did have a fast big >> integer type, it would make sense to wrap it with an enum heading down >> a separate branch for small and large integers, and branching on the >> overflow flag to expand to a big integer. I think this is how Python's >> integers are implemented. > > > I do think it's useful and is potentially a good compromise for the > performance of the default integer type. Overflow with failure is a bug that > tells you there's a bug. Wrapping is a bug that pretends it's not a bug. > > Hitting a slow path unexpectedly on overflow seems to me like a recipe for > unpredictable performance, which doesn't seem inline with Rust's usual > goals. The branch on the overflow flag results in a very significant loss in performance. For example, I had to carefully write the vector `push` method for my `Vec` type to only perform one overflow check. With two checks, it's over 5 times slower due to failed branch predictions. From pnathan at vandals.uidaho.edu Fri Jan 10 22:21:16 2014 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Fri, 10 Jan 2014 22:21:16 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DB38.4030001@mozilla.com> Message-ID: <52D0E2DC.3090209@vandals.uidaho.edu> On 1/10/14 10:05 PM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton wrote: >> On 1/10/14 9:41 PM, Corey Richardson wrote: >>> >>> The current consensus on this subject, afaik, is the rename int/uint >>> to intptr/uintptr. They're awful names, but it frees up int for a >>> *fast* bigint type. Fast here is key. We can't have a suboptimal >>> numeric type be the recommended default. We need to perform at least >>> as well as GMP for me to even consider it. Additionally we'd have >>> generic numeric literals. I don't think anyone wants what we current >>> have for *numerics*. Fixed-size integers are necessary for some tasks, >>> but numerics is not one of them. >> >> I wasn't aware of this consensus. I'm not sure what I think; int and uint as >> they are is pretty nice for array indexing. >> >> Patrick > > I think it's very important to remove the default fallback to `int` so > Rust can leave this as an explicit choice for the programmer. It's too > easy to accidentally fall back to a fixed-size signed integer and > since the length varies based on the pointer-size, you may not run > into the bugs on the platform you're developing on. > > It would be nice to name them based on what they are instead of making > them out as good defaults, because this should really be an explicit > choice. High-level logic will often (but not always) want a big > integer type, and it's too easy to just use `int` because it's the > "default". > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > . > One of the common style rules in C/C++ codebases (IME and from what I've read) is to have an explicit typedef'd int type: i.e., typedef unsigned char uint8; typedef unsigned short uint16; typedef unsigned long uint32; // and so forth. This way it's clearly seen what the width is in the code. It would seem to me to be an obvious choice of "optimize for the correct case" to remove "int" and require choosing the width as part of the type declaration (much like has been done for floats). Note - I have zero experience in numerical analysis; my experience here largely lies in the embedded/low-level space. A numerical analyst may disagree 100% and prefer a generic "bigint" type for correctness of computation. No idea. Not my area so far. -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Fri Jan 10 22:23:29 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:23:29 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson wrote: > > We need to perform at least as well as GMP for me to even consider it. The only realistic way to accomplish this is using GMP. Lots of other big integer implementations exist with lots of work put into them and the performance is not even in the same ballpark. It's difficult just to implement all of the required algorithms: https://gmplib.org/manual/Division-Algorithms.html#Division-Algorithms Then, consider that you're going to need to write the low-level code by hand in assembly so you're going to need domain experts for several architectures. Processors and compilers are terrible at dealing with the side effects like carry/overflow flags and can't deal with this kind of code well. You'll need versions for different revisions of the CPU instruction set too, since useful features are added all of the time. For example, Haswell introduces the `MULX` instruction (among others) and Broadwell will introduce `ADCX` and `ADOX`. From danielmicay at gmail.com Fri Jan 10 22:26:07 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 01:26:07 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0E2DC.3090209@vandals.uidaho.edu> References: <52D0D385.1080200@gmail.com> <52D0DB38.4030001@mozilla.com> <52D0E2DC.3090209@vandals.uidaho.edu> Message-ID: C and C++ have a `stdint.h` header defining fixed-size integers. Rust doesn't have any arbitrarily defined integer types like C. It has 8/16/32/64-bit variants of both signed and unsigned integers, along with pointer-size integers covering the address space (int and uint). From corey at octayn.net Fri Jan 10 22:27:26 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 11 Jan 2014 01:27:26 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: Simple answer: then it shouldn't be our default numeric type. You say earlier that we don't need a default, and that is a case I hadn't considered before. But I'm growing to like it. On Sat, Jan 11, 2014 at 1:23 AM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson wrote: >> >> We need to perform at least as well as GMP for me to even consider it. > > The only realistic way to accomplish this is using GMP. Lots of other > big integer implementations exist with lots of work put into them and > the performance is not even in the same ballpark. It's difficult just > to implement all of the required algorithms: > > https://gmplib.org/manual/Division-Algorithms.html#Division-Algorithms > > Then, consider that you're going to need to write the low-level code > by hand in assembly so you're going to need domain experts for several > architectures. Processors and compilers are terrible at dealing with > the side effects like carry/overflow flags and can't deal with this > kind of code well. > > You'll need versions for different revisions of the CPU instruction > set too, since useful features are added all of the time. For example, > Haswell introduces the `MULX` instruction (among others) and Broadwell > will introduce `ADCX` and `ADOX`. From vadimcn at gmail.com Fri Jan 10 22:44:37 2014 From: vadimcn at gmail.com (Vadim) Date: Fri, 10 Jan 2014 22:44:37 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: > The branch on the overflow flag results in a very significant loss in > performance. For example, I had to carefully write the vector `push` > method for my `Vec` type to only perform one overflow check. With > two checks, it's over 5 times slower due to failed branch predictions. > Huh, that's a bit surprising. I'd have expected branch predictor to learn really quick that the branch is never taken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Jan 10 23:06:25 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 11 Jan 2014 02:06:25 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: corey, those would be very very nice refinments and a healthy progressive yet conservative stance that leaves the room for evolving healthy defaults (I've a slow boil program to bring breaking changes to fix numerical warts in haskell over the next 2-3 years, ) @corey, one example of a "Real" number type can be found in mpfr http://www.mpfr.org/ (C library for multiple-precision floating-point computations with *correct rounding*), though note its LGPL, on the rational number front, i believe theres 1-2 decent bsd/mit style such libs, and i know in haskell, GHC devs are evaluating how to move away from GMP (though this may not have any impact till whenver ghc 7.10 happens) @patrick yes, (u)int types that are the same size as pointers are good for indexing into in memory arrays! What int type is suitable for indexing into larger than ram sized arrays that are memmapped in regions in a demand driven way? (this is actually a problem i'm trying to figure out generally for some of my own engineering work currently, and it really needs a way that lets one talk about larger than ram arrays on 16, 32 and 64 bit systems, because those exist! Also similar problems come up when working with distributed arrays too! The latter perhaps using something like openmpi or infiniband as the management layer) @Bob, well said! Even ignoring floating point imprecision, numerical computing still has to deal with rounding, well conditioned / wellposed-ness of the problem being solved, and to some extent performance! Any "exact real" type either is unbounded (and thus provides unbounded performance woes if used carelessly) or bounded and will eventually suffer some precision issues in some example along with being several orders of slower. @bob also good point about generic support for integer/rational/floating point literal support. Providing good literal support for those via a suitable trait would probably help this become a much less contentious issue (though if done poorly it does create some lockin woes) anyways: numerical library design is very hard, and all i can say is I hope that at least for the near term that rust errs on the side of avoiding lockin on a bad design. And any call to action needs to have very concrete worked out details, because the devil is in those details (well, recursively even!) keep up the great work! -Carter On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson wrote: > The current consensus on this subject, afaik, is the rename int/uint > to intptr/uintptr. They're awful names, but it frees up int for a > *fast* bigint type. Fast here is key. We can't have a suboptimal > numeric type be the recommended default. We need to perform at least > as well as GMP for me to even consider it. Additionally we'd have > generic numeric literals. I don't think anyone wants what we current > have for *numerics*. Fixed-size integers are necessary for some tasks, > but numerics is not one of them. > > As long as we rename int/uint to intptr/uintptr and leave int etc > reserved, I think we can defer the language issues to post-1.0. It > should be entirely backwards compatible. Development of robust > numerics can happen outside the standard library. Talk to bjz about > this, he has some ideas :) > > As an aside, you mention a "real" in your blog post like it's > something that exists. Rust does not have any such type. > > On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden wrote: > > This may be go nowhere, especially so late in Rust's development, but I > feel > > like this is an important, relatively small change (though a high-profile > > one). I believe it could have a large, positive impact in terms of > > targeting new developer communities, gaining more libraries and > > applications, giving a better impression of the language, AND on > performance > > and futureproofing. > > > > However, a lot of people who are interested in performance will probably > > baulk at this, on first sight. If you're in that group, let me encourage > > you to keep reading, at least until the points on performance > improvements. > > Then baulk, if you like ;) > > > > Also, I said it in the post as well, but it's late here, so apologies for > > any readability / editing issues. I tried, but sleep beckons ;) > > > > > > > > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > > > > > > -- > > Lee > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Jan 10 23:27:16 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 02:27:16 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald wrote: > corey, those would be very very nice refinments and a healthy progressive > yet conservative stance that leaves the room for evolving healthy defaults > (I've a slow boil program to bring breaking changes to fix numerical warts > in haskell over the next 2-3 years, ) > > @corey, one example of a "Real" number type can be found in mpfr > http://www.mpfr.org/ (C library for multiple-precision floating-point > computations with correct rounding), though note its LGPL, You choose a precision upon construction of a floating point value. You also have to choose the precision for the output values. The correct rounding is in comparison to the raw `mpf_t` offered by GMP that I think it uses under the hood. > on the rational number front, i believe theres 1-2 decent bsd/mit style such > libs, and i know in haskell, GHC devs are evaluating how to move away from > GMP (though this may not have any impact till whenver ghc 7.10 happens) None of which are comparable in performance for anything but small integers. LGPL isn't really that big a deal, because the implication for closed-source projects is that they have to ship linkable object files. > > @Bob, well said! Even ignoring floating point imprecision, numerical > computing still has to deal with rounding, well conditioned / wellposed-ness > of the problem being solved, and to some extent performance! Any "exact > real" type either is unbounded (and thus provides unbounded performance woes > if used carelessly) or bounded and will eventually suffer some precision > issues in some example along with being several orders of slower. No real number type has unbounded precision. Arbitrary precision means the user passes the precision they desire up-front. On the other hand, a rational number type implemented with big integers will never lose any precision. However, you don't get `sqrt`, `sin`, `cos`, etc. From carter.schonwald at gmail.com Fri Jan 10 23:52:09 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 11 Jan 2014 02:52:09 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: sounds like we agree! (and thanks for clarifying some of the detail points i neglected) On Sat, Jan 11, 2014 at 2:27 AM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald > wrote: > > corey, those would be very very nice refinments and a healthy progressive > > yet conservative stance that leaves the room for evolving healthy > defaults > > (I've a slow boil program to bring breaking changes to fix numerical > warts > > in haskell over the next 2-3 years, ) > > > > @corey, one example of a "Real" number type can be found in mpfr > > http://www.mpfr.org/ (C library for multiple-precision floating-point > > computations with correct rounding), though note its LGPL, > > You choose a precision upon construction of a floating point value. > You also have to choose the precision for the output values. The > correct rounding is in comparison to the raw `mpf_t` offered by GMP > that I think it uses under the hood. > > > on the rational number front, i believe theres 1-2 decent bsd/mit style > such > > libs, and i know in haskell, GHC devs are evaluating how to move away > from > > GMP (though this may not have any impact till whenver ghc 7.10 happens) > > None of which are comparable in performance for anything but small > integers. LGPL isn't really that big a deal, because the implication > for closed-source projects is that they have to ship linkable object > files. > > > > @Bob, well said! Even ignoring floating point imprecision, numerical > > computing still has to deal with rounding, well conditioned / > wellposed-ness > > of the problem being solved, and to some extent performance! Any "exact > > real" type either is unbounded (and thus provides unbounded performance > woes > > if used carelessly) or bounded and will eventually suffer some precision > > issues in some example along with being several orders of slower. > > No real number type has unbounded precision. Arbitrary precision means > the user passes the precision they desire up-front. > > On the other hand, a rational number type implemented with big > integers will never lose any precision. However, you don't get `sqrt`, > `sin`, `cos`, etc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Fri Jan 10 23:56:46 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Sat, 11 Jan 2014 09:56:46 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52CFB098.8010100@gmail.com> References: <52CFB098.8010100@gmail.com> Message-ID: <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> There is little reason to believe that having a build system in Rust would make It harder for people to package. I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. G. Lee Braiden wrote: >On 10/01/14 08:16, Gaetan wrote: >> >> I am not in favor of a customized build system. For instance boost >> library use their jam build system, and i never figured how to use it > >> in my projects. >> >> I push to use standard and well proved build system like cmake or >> scons, at least for major components. This would give a nice example >> of how to use it in any projects. >> > >I'd agree with that on both counts: the principle of using something >standard, and the two recommendations. > >CMake would probably get my vote, because it's not so much a build >tool, >as a meta tool for whichever system you prefer, so it would fit in well > >with various platform-specific IDEs, unusual platforms (android, >embedded, ...), etc. That said, scons is also a strong contender, and >which of the two is more open to integrating patches and working with >new languages is very much worth considering. > >I think Rust will be contributing to the wider community by lending its > >support (and patches) to a common, modern build system, AND it will get > >something back in terms of users who already know the build system. > > >> On Friday, January 10, 2014, George Makrydakis wrote: >> >> >> Hello, >> >> Having a build system entirely dependent of Rust alone, would >> make the entire experience in deploying the language >extremely >> cohere. The only counter - argument is indeed that it would >> require some work to get this to fruition. I would like to >> know if this has any chance of getting priority soon enough. >> > >Bear in mind that Debian are having a lot of issues packaging Rust >already, because it self-compiles. If the build tool also had a Rust >pre-dependency, that would be a big step backwards. From dpx.infinity at gmail.com Sat Jan 11 00:15:39 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Sat, 11 Jan 2014 12:15:39 +0400 Subject: [rust-dev] Exporting macros: #[macro_escape] usage In-Reply-To: References: Message-ID: Oh, thanks. It does work now. Are macro scoping rules documented somewhere except the compiler source code? 2014/1/11 Chris Morgan : > The macro is being defined after the module is defined. You need to move the > macro definition before the "pub mod submod;" line. Also due to the scoping > rules of macros, you don't need #[macro_escape] there---it's a child, so it > gets the macro. Only siblings, parents, uncles, aunts, cousins, &c. would > need it. > > On Jan 11, 2014 9:46 AM, "Vladimir Matveev" wrote: >> >> Hi, >> >> As far as I understand, the current way to export macros is to >> annotate the module with macro_rules definition with #[macro_escape] >> annotation. But I just can't get it right, and my macro is not visible >> in other module :( >> >> Here is what I have: >> >> ----- START ----- >> /lib.rs: >> #[feature(macro_rules)]; >> >> pub mod m1; >> >> -- >> /m1/mod.rs: >> #[macro_escape]; >> >> pub mod submod; >> >> macro_rules! example_rule( >> () => (mod test;) >> ) >> >> -- >> /m1/submod.rs: >> use m1; >> >> example_rule!() >> ----- END ----- >> >> I have assumed that putting #[macro_escape] annotation to a module >> makes all macros from that module available in all modules which >> import this module, but apparently I'm wrong because the code above >> does not work with 'macro undefined' error. >> >> Could please someone explain how #[macro_escape] works in detail? I >> couldn't find any documentation on it, and looking through standard >> libs was not helpful. >> >> Thanks, >> Vladimir. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev From marijnh at gmail.com Sat Jan 11 02:18:41 2014 From: marijnh at gmail.com (Marijn Haverbeke) Date: Sat, 11 Jan 2014 11:18:41 +0100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: I am not aware of an efficient way to provide automatic-overflow-to-bignum semantics in a non-garbage-collected language, without also imposing the burden of references/move semantics/etc on users of small integers. I.e. integers, if they may hold references to allocated memory can no longer sanely be considered a simple value type, which doesn't seem like it'd be a good idea for Rust. If there is a good solution to this, I'd love to find out about it. From mneumann at ntecs.de Sat Jan 11 02:42:21 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Sat, 11 Jan 2014 11:42:21 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: <52D1200D.8050600@ntecs.de> rustc is "just" another regular Rust application. So use the tools that any other Rust application (will) use ;-) I think at some point in time there will be a capable build tool written in Rust (like there is for all the other languages). Then it would make sense to switch using it for the compiler as well. Michael Am 11.01.2014 08:56, schrieb George Makrydakis: > There is little reason to believe that having a build system in Rust would make It harder for people to package. > > I do understand the predependecy argument, but the Rust compiler itself in order to compile has predependencies anyway, as does any similar project. Therefore the decisional weight of choosing a non - rust based solution over a rust one because Debian packagers have problems packaging a compiler is not adequately justified. > > Using a well known build system as a means to appeal to programmers is seemingly an advantage, but it does not exonerate them from having to be competent in Rust before they write useful programs. And that has a learning curve superior to that of a build system. > > As for boost's jam I have nothing to say other than boost having its own build system makes it easy for boost first; this does not mean that their needs are those of everybody else and boost is a library, not a programming language itself. So, again, a decision based on picking a popular solution on the basis of such a comparison, has flawed background. > > Lastly, imagine the irony of Rust proposing to use python, c, c++ based build tools for simple packages. That would make packagers more frustrated because of a wider set of dependecies. While end users would have to also deal with a known system, its eventual inadequacies could not be met directly by Rust devs unless they start amending that system in order to deal with them. Therefore, maintenance overhead is inescapable either way, with the pessimization of relying in another nom - Rust project in order to make it worth your while to enjoy programming in Rust. > > The only valid argument against having a build system proposed as the official, defacto, cross - platform way of building rust packages written in rust is its development and maintenance overhead for the rust core team itself. > > That problem is easily circumvented by not proposing one right now and letting it to the end developer decide. If however an official build system is to be proposed, Rust developers merit having it done on their own platform, thus proving rust's worth. It is 2014 after all. > > G. > > > > Lee Braiden wrote: >> On 10/01/14 08:16, Gaetan wrote: >>> I am not in favor of a customized build system. For instance boost >>> library use their jam build system, and i never figured how to use it >>> in my projects. >>> >>> I push to use standard and well proved build system like cmake or >>> scons, at least for major components. This would give a nice example >>> of how to use it in any projects. >>> >> I'd agree with that on both counts: the principle of using something >> standard, and the two recommendations. >> >> CMake would probably get my vote, because it's not so much a build >> tool, >> as a meta tool for whichever system you prefer, so it would fit in well >> >> with various platform-specific IDEs, unusual platforms (android, >> embedded, ...), etc. That said, scons is also a strong contender, and >> which of the two is more open to integrating patches and working with >> new languages is very much worth considering. >> >> I think Rust will be contributing to the wider community by lending its >> >> support (and patches) to a common, modern build system, AND it will get >> >> something back in terms of users who already know the build system. >> >> >>> On Friday, January 10, 2014, George Makrydakis wrote: >>> >>> >>> Hello, >>> >>> Having a build system entirely dependent of Rust alone, would >>> make the entire experience in deploying the language >> extremely >>> cohere. The only counter - argument is indeed that it would >>> require some work to get this to fruition. I would like to >>> know if this has any chance of getting priority soon enough. >>> >> Bear in mind that Debian are having a lot of issues packaging Rust >> already, because it self-compiles. If the build tool also had a Rust >> pre-dependency, that would be a big step backwards. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From irrequietus at gmail.com Sat Jan 11 03:26:23 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Sat, 11 Jan 2014 13:26:23 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D1200D.8050600@ntecs.de> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D1200D.8050600@ntecs.de> Message-ID: Indeed. I fully agree with your apt foreshadowing of events. If it is not feasible to have a rust based tool now, as long as any other tool is not given priviledged status formally speaking, using whatever ready means appropriate is a strategy that scales well within a limited time period. >From this thread it seems a reasonably acceptable compromise - until a rust tool is given priority; but it is not clear if this is the actual plan. I think that discussing about the merits of other build systems should not be transmuted into an agenda of using them as the blessed defaults. Specifying this is very important for rust to be a modern, cohere platform - level solution with easy exchange of libraries among users, relying on a common environment that is compatible with the goals of Rust itself. This is why it should be fully controlled by the Rust community, thus written in Rust. Think about the merit of having such a system in rust, eventually deployed by other projects, unrelated to rust, because it ends up being *that* good. This is a matter that should be definitively discussed after Rust 1.0, when the language starts being backwards - reliable to a considerable extent. G. Michael Neumann wrote: >rustc is "just" another regular Rust application. So use the tools that > >any other Rust application (will) use ;-) > >I think at some point in time there will be a capable build tool >written >in Rust (like there is for all the other languages). Then it would make >sense to switch using it for the compiler as well. > >Michael > >Am 11.01.2014 08:56, schrieb George Makrydakis: >> There is little reason to believe that having a build system in Rust >would make It harder for people to package. >> >> I do understand the predependecy argument, but the Rust compiler >itself in order to compile has predependencies anyway, as does any >similar project. Therefore the decisional weight of choosing a non - >rust based solution over a rust one because Debian packagers have >problems packaging a compiler is not adequately justified. >> >> Using a well known build system as a means to appeal to programmers >is seemingly an advantage, but it does not exonerate them from having >to be competent in Rust before they write useful programs. And that has >a learning curve superior to that of a build system. >> >> As for boost's jam I have nothing to say other than boost having its >own build system makes it easy for boost first; this does not mean that >their needs are those of everybody else and boost is a library, not a >programming language itself. So, again, a decision based on picking a >popular solution on the basis of such a comparison, has flawed >background. >> >> Lastly, imagine the irony of Rust proposing to use python, c, c++ >based build tools for simple packages. That would make packagers more >frustrated because of a wider set of dependecies. While end users would >have to also deal with a known system, its eventual inadequacies could >not be met directly by Rust devs unless they start amending that system >in order to deal with them. Therefore, maintenance overhead is >inescapable either way, with the pessimization of relying in another >nom - Rust project in order to make it worth your while to enjoy >programming in Rust. >> >> The only valid argument against having a build system proposed as the >official, defacto, cross - platform way of building rust packages >written in rust is its development and maintenance overhead for the >rust core team itself. >> >> That problem is easily circumvented by not proposing one right now >and letting it to the end developer decide. If however an official >build system is to be proposed, Rust developers merit having it done on >their own platform, thus proving rust's worth. It is 2014 after all. >> >> G. >> >> >> >> Lee Braiden wrote: >>> On 10/01/14 08:16, Gaetan wrote: >>>> I am not in favor of a customized build system. For instance boost >>>> library use their jam build system, and i never figured how to use >it >>>> in my projects. >>>> >>>> I push to use standard and well proved build system like cmake or >>>> scons, at least for major components. This would give a nice >example >>>> of how to use it in any projects. >>>> >>> I'd agree with that on both counts: the principle of using something >>> standard, and the two recommendations. >>> >>> CMake would probably get my vote, because it's not so much a build >>> tool, >>> as a meta tool for whichever system you prefer, so it would fit in >well >>> >>> with various platform-specific IDEs, unusual platforms (android, >>> embedded, ...), etc. That said, scons is also a strong contender, >and >>> which of the two is more open to integrating patches and working >with >>> new languages is very much worth considering. >>> >>> I think Rust will be contributing to the wider community by lending >its >>> >>> support (and patches) to a common, modern build system, AND it will >get >>> >>> something back in terms of users who already know the build system. >>> >>> >>>> On Friday, January 10, 2014, George Makrydakis wrote: >>>> >>>> >>>> Hello, >>>> >>>> Having a build system entirely dependent of Rust alone, >would >>>> make the entire experience in deploying the language >>> extremely >>>> cohere. The only counter - argument is indeed that it >would >>>> require some work to get this to fruition. I would like to >>>> know if this has any chance of getting priority soon >enough. >>>> >>> Bear in mind that Debian are having a lot of issues packaging Rust >>> already, because it self-compiles. If the build tool also had a >Rust >>> pre-dependency, that would be a big step backwards. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at dhardy.name Sat Jan 11 03:51:57 2014 From: lists at dhardy.name (Diggory Hardy) Date: Sat, 11 Jan 2014 12:51:57 +0100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: <4727130.mmVhLcRl2C@yoga.dhardy> There is static analysis (i.e. determine ahead of time exactly what values variables may take), but it's certainly not a panacea: the analysis step is slow (probably too slow to fully integrate into a compiler), not everything can be solved, and most existing solvers are not free software as far as I am aware. It could perhaps be used for a little optimisation and for proofs that overflow doesn't occur in some cases, but integrating a static analysis system with a compiler would be no easy task. Leon is the most advanced version I'm aware of (though it's not really my field): http://lara.epfl.ch/w/leon On Saturday 11 January 2014 11:18:41 Marijn Haverbeke wrote: > I am not aware of an efficient way to provide > automatic-overflow-to-bignum semantics in a non-garbage-collected > language, without also imposing the burden of references/move > semantics/etc on users of small integers. I.e. integers, if they may > hold references to allocated memory can no longer sanely be considered > a simple value type, which doesn't seem like it'd be a good idea for > Rust. > > If there is a good solution to this, I'd love to find out about it. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From james at mansionfamily.plus.com Sat Jan 11 03:59:59 2014 From: james at mansionfamily.plus.com (james) Date: Sat, 11 Jan 2014 11:59:59 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: <52D1323F.1030505@mansionfamily.plus.com> On 11/01/2014 07:56, George Makrydakis wrote: > There is little reason to believe that having a build system in Rust would make It harder for people to package. Surely you just need an alternate that is a script generated as a from-clean dry run with -j1? It gives you the commands needed, in an order that works. From james at mansionfamily.plus.com Sat Jan 11 04:03:54 2014 From: james at mansionfamily.plus.com (james) Date: Sat, 11 Jan 2014 12:03:54 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: <52D1332A.1000300@mansionfamily.plus.com> On 10/01/2014 08:54, Jan Niklas Hasse wrote: > Also cmake still depends on make (or even worse Visual Studio / Xcode). We use cmake with ninja at work, and that seems to work pretty well. I suggest if you want to write a tool, then you first write something that generates ninja files. Then you immediately have a bootstrap mechanism, plus something that will do builds rather quickly thereafter. scons can be (very) slow. My experience with waf was better, but I think generating a nnja script is superior and there are several tools to do that. You could look at gyp, for example. From glaebhoerl at gmail.com Sat Jan 11 06:03:09 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sat, 11 Jan 2014 15:03:09 +0100 Subject: [rust-dev] returning functions in rust In-Reply-To: References: <52D0397C.3010305@mozilla.com> <4e49b135-fa55-49a6-96b5-d3c6270a8115@email.android.com> Message-ID: On Fri, Jan 10, 2014 at 8:01 PM, Daniel Micay wrote: > On Fri, Jan 10, 2014 at 1:57 PM, Patrick Walton > wrote: > > It doesn't exist, outside of traits. Unboxed closures will probably make > it > > possible to express once again though. > > > > Patrick > > The tricky part is the need to infer the return type if it's defined > inside the function since it's different per-closure. > I wrote up a small proposal for a feature that could help with this: https://github.com/mozilla/rust/issues/11455 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Sat Jan 11 08:53:54 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Sat, 11 Jan 2014 18:53:54 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D1332A.1000300@mansionfamily.plus.com> References: <52D1332A.1000300@mansionfamily.plus.com> Message-ID: I would not exclude ninja from the candidates of an in - between solution for the time being. Imagine the power of ninja but implementing its conceptual machinery in expressive Rust code. It would be an interesting combination indeed. That could bring even more advantages since it would be implemented in Rust. On Sat, Jan 11, 2014 at 2:03 PM, james wrote: > On 10/01/2014 08:54, Jan Niklas Hasse wrote: > >> Also cmake still depends on make (or even worse Visual Studio / Xcode). >> > We use cmake with ninja at work, and that seems to work pretty well. > > I suggest if you want to write a tool, then you first write something that > generates ninja files. Then you immediately have a bootstrap mechanism, > plus something that will do builds rather quickly thereafter. scons can be > (very) slow. My experience with waf was better, but I think generating a > nnja script is superior and there are several tools to do that. You could > look at gyp, for example. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen.shepherd at e43.eu Sat Jan 11 08:54:41 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sat, 11 Jan 2014 16:54:41 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On 11 January 2014 06:20, Daniel Micay wrote: > The branch on the overflow flag results in a very significant loss in > performance. For example, I had to carefully write the vector `push` > method for my `Vec` type to only perform one overflow check. With > two checks, it's over 5 times slower due to failed branch predictions. > What did the generated code look like? I suspect that LLVM wasn't generating optimal code, perhaps because Rust wasn't giving it appropriate hints or because of optimizer bugs. For reference, on AMD64 the code should look something like the following hypothetical code: vec_allocate: MOV $SIZE, %eax MUL %rsi JC Lerror ADD $HEADER_SIZE, %rax JC Lerror MOV %rax, %rsi JMP malloc Lerror: // Code to raise error here Note that the ordering is EXTREMELY important! x86 doesn't give you any separate branch hints (excluding two obsolete ones which only the Pentium IV ever cared about) so your only clue to the optimizer is the branch direction. I suspect your generated code had forward branches for the no overflow case. Thats absolutely no good (codegen inerting "islands" of failure case code); it will screw up the branch predictor. x86 defaults to predicting all (conditional) forward jumps not taken, all conditional backwards jumps taken (Loops!). If the optimizer wasn't informed correctly, it will probably not have obeyed that. Being as the overflow case should basically be never hit, there is no reason for it to ever be loaded into the optimizer, so that is good (P.S. If the rust compiler is really good it'll convince LLVM to put the error case branch code in a separate section so it can all be packed together far away from useful cache lines and TLB entries) -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Sat Jan 11 09:08:56 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Sat, 11 Jan 2014 19:08:56 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D1323F.1030505@mansionfamily.plus.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D1323F.1030505@mansionfamily.plus.com> Message-ID: Which is why the argument of easier packaging because tool X is used by person Y advocating it, is meaningless from both a theoretical and practical point of view. In the end, it is just an application of graph theory, which is widely used in dependency resolution. Another option would be a sat solver producing the same result as for example is the case for libzypp in openSuSE. Again, it is a matter of combining any of these solutions with a reliable and simple to understand format in order to produce a build system that is consistent first, fool - proof most of the time. Surely, doing this in Rust should be quite easily doable, given the fact that it is designed to be a systems language. Handling entire package life cycles would be a natural fit for a language with Rust's problem domain, even beyond the purposes of Rust itself. Think big, then bigger. G. On Sat, Jan 11, 2014 at 1:59 PM, james wrote: > On 11/01/2014 07:56, George Makrydakis wrote: > >> There is little reason to believe that having a build system in Rust >> would make It harder for people to package. >> > Surely you just need an alternate that is a script generated as a > from-clean dry run with -j1? It gives you the commands needed, in an order > that works. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexlen at gmail.com Sat Jan 11 09:17:21 2014 From: rexlen at gmail.com (Renato Lenzi) Date: Sat, 11 Jan 2014 18:17:21 +0100 Subject: [rust-dev] Failure Message-ID: The code is trivial: fn main() { let x = 3; println(x.to_str()); } the error is this (on Win7) d:\Rust09\bin>rustc 00025.rs 00025.rs:4:11: 4:22 error: multiple applicable methods in scope 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #1 is `std::int::ToStr$int::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #2 is `std::i8::ToStr$i8::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #3 is `std::i16::ToStr$i16::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #4 is `std::i32::ToStr$i32::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #5 is `std::i64::ToStr$i64::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #6 is `std::uint::ToStr$uint::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #7 is `std::u8::ToStr$u8::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #8 is `std::u16::ToStr$u16::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #9 is `std::u32::ToStr$u32::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ 00025.rs:4:11: 4:22 note: candidate #10 is `std::u64::ToStr$u64::to_str` 00025.rs:4 println(x.to_str()); ^~~~~~~~~~~ error: aborting due to previous error task 'rustc' failed at 'explicit failure', C:\bot\slave\dist2-win\build\src\libs yntax\diagnostic.rs:75 task '

' failed at 'explicit failure', C:\bot\slave\dist2-win\build\src\lib rustc\lib.rs:453 any idea? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Jan 11 09:21:56 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 11 Jan 2014 12:21:56 -0500 Subject: [rust-dev] Failure In-Reply-To: References: Message-ID: What type is `3`? There's know way to know. Use `3i` for int, `3u` for uint, etc. On Sat, Jan 11, 2014 at 12:17 PM, Renato Lenzi wrote: > The code is trivial: > > fn main() > { > let x = 3; > println(x.to_str()); > } > > the error is this (on Win7) > > d:\Rust09\bin>rustc 00025.rs > 00025.rs:4:11: 4:22 error: multiple applicable methods in scope > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #1 is `std::int::ToStr$int::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #2 is `std::i8::ToStr$i8::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #3 is `std::i16::ToStr$i16::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #4 is `std::i32::ToStr$i32::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #5 is `std::i64::ToStr$i64::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #6 is `std::uint::ToStr$uint::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #7 is `std::u8::ToStr$u8::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #8 is `std::u16::ToStr$u16::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #9 is `std::u32::ToStr$u32::to_str` > 00025.rs:4 println(x.to_str()); > ^~~~~~~~~~~ > 00025.rs:4:11: 4:22 note: candidate #10 is `std::u64::ToStr$u64::to_str` > 00025.rs:4 println(x.to_str()); > > ^~~~~~~~~~~ > error: aborting due to previous error > task 'rustc' failed at 'explicit failure', > C:\bot\slave\dist2-win\build\src\libs > yntax\diagnostic.rs:75 > task '
' failed at 'explicit failure', > C:\bot\slave\dist2-win\build\src\lib > rustc\lib.rs:453 > > any idea? > thanks. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From danielmicay at gmail.com Sat Jan 11 11:33:02 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 14:33:02 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 11:54 AM, Owen Shepherd wrote: > On 11 January 2014 06:20, Daniel Micay wrote: >> >> The branch on the overflow flag results in a very significant loss in >> performance. For example, I had to carefully write the vector `push` >> method for my `Vec` type to only perform one overflow check. With >> two checks, it's over 5 times slower due to failed branch predictions. > > > What did the generated code look like? I suspect that LLVM wasn't generating > optimal code, perhaps because Rust wasn't giving it appropriate hints or > because of optimizer bugs. For reference, on AMD64 the code should look > something like the following hypothetical code: > > vec_allocate: > MOV $SIZE, %eax > MUL %rsi > JC Lerror > ADD $HEADER_SIZE, %rax > JC Lerror > MOV %rax, %rsi > JMP malloc > Lerror: > // Code to raise error here > > Note that the ordering is EXTREMELY important! x86 doesn't give you any > separate branch hints (excluding two obsolete ones which only the Pentium IV > ever cared about) so your only clue to the optimizer is the branch > direction. > > I suspect your generated code had forward branches for the no overflow case. > Thats absolutely no good (codegen inerting "islands" of failure case code); > it will screw up the branch predictor. > > x86 defaults to predicting all (conditional) forward jumps not taken, all > conditional backwards jumps taken (Loops!). If the optimizer wasn't informed > correctly, it will probably not have obeyed that. > > Being as the overflow case should basically be never hit, there is no reason > for it to ever be loaded into the optimizer, so that is good > > (P.S. If the rust compiler is really good it'll convince LLVM to put the > error case branch code in a separate section so it can all be packed > together far away from useful cache lines and TLB entries) Rust directly exposes the checked overflow intrinsics so these are what was used. It already considers branches calling a `noreturn` function to be colder, so adding an explicit branch hint (which is easy enough via `llvm.expect` doesn't help). Feel free to implement it yourself if you think you can do better. The compiler work is already implemented. I doubt you'll get something performing in the same ballpark as plain integers. From danielmicay at gmail.com Sat Jan 11 11:43:25 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 14:43:25 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0E224.7060103@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: >>> >>> On 11/01/14 16:58, Isaac Dupree wrote: >>>> >>>> Scheme's numeric tower is one of the best in extant languages. Take a >>>> look at it. Of course, its dynamic typing is poorly suited for Rust. >>>> >>>> Arbitrary-precision arithmetic can get you mathematically perfect >>>> integers >>>> and rational numbers, but not real numbers. There are an uncountably >>>> infinite number of real numbers and sophisticated computer algebra >>>> systems >>>> are devoted the problem (or estimates are used, or you become unable to >>>> compare two real numbers for equality). The MPFR C library implements >>>> arbitrarily high precision floating point, but that still has all the >>>> pitfalls of floating-point that you complain about. For starters, try >>>> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >>>> >>>> In general, Rust is a systems language, so fixed-size integral types are >>>> important to have. They are better-behaved than in C and C++ in that >>>> signed >>>> types are modulo, not undefined behaviour, on overflow. It could be >>>> nice to >>>> have integral types that are task-failure on overflow as an option too. >>> >>> >>> We do already have some Checked* traits (using the LLVM intrinsics >>> internally), which let you have task failure as one possibility on >>> overflow. >>> e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html >>> (and Mul, Sub, Div too). >> >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. If we did have a fast big >> integer type, it would make sense to wrap it with an enum heading down >> a separate branch for small and large integers, and branching on the >> overflow flag to expand to a big integer. I think this is how Python's >> integers are implemented. > > > I do think it's useful and is potentially a good compromise for the > performance of the default integer type. Overflow with failure is a bug that > tells you there's a bug. Wrapping is a bug that pretends it's not a bug. This is why `clang` exposes sanitize options for integer overflow. You could use `-ftrapv` in production... but why bother using C if you're taking a significant performance hit like that? > Hitting a slow path unexpectedly on overflow seems to me like a recipe for > unpredictable performance, which doesn't seem inline with Rust's usual > goals. It's certainly better than the process exiting, which is what's going to happen in real systems when failure occurs. Either that, or they're going to lose a bunch of data from the task it caused to unwind. The only way to make overflow not a bug is to expand to a big integer or use a big integer from the start. From vadimcn at gmail.com Sat Jan 11 13:06:34 2014 From: vadimcn at gmail.com (Vadim) Date: Sat, 11 Jan 2014 13:06:34 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: > > Hitting a slow path unexpectedly on overflow seems to me like a recipe > for > > unpredictable performance, which doesn't seem inline with Rust's usual > > goals. > > It's certainly better than the process exiting, which is what's going > to happen in real systems when failure occurs. Either that, or they're > going to lose a bunch of data from the task it caused to unwind. The > only way to make overflow not a bug is to expand to a big integer or > use a big integer from the start. > IMHO, integer overflow detection should be considered strictly a security feature. I can think of very few cases, when after expansion to a bigint, the program wouldn't have bombed out anyways a few lines later - on some array access or a system API call. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen.shepherd at e43.eu Sat Jan 11 13:31:00 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sat, 11 Jan 2014 21:31:00 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: So I just did a test. Took the following rust code: pub fn test_wrap(x : u32, y : u32) -> u32 { return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); } And got the following blob of assembly out. What we have there, my friends, is a complete failure of the optimizer (N.B. it works for the simple case of checked_add alone) Preamble: __ZN9test_wrap19hc4c136f599917215af4v0.0E: .cfi_startproc cmpl %fs:20, %esp ja LBB0_2 pushl $12 pushl $20 calll ___morestack ret LBB0_2: pushl %ebp Ltmp2: .cfi_def_cfa_offset 8 Ltmp3: .cfi_offset %ebp, -8 movl %esp, %ebp Ltmp4: .cfi_def_cfa_register %ebp Align stack (for what? We don't do any SSE) andl $-8, %esp subl $16, %esp Multiply x * y movl 12(%ebp), %eax mull 16(%ebp) jno LBB0_4 If it didn't overflow, stash a 0 at top of stack movb $0, (%esp) jmp LBB0_5 If it did overflow, stash a 1 at top of stack (we are building an Option here) LBB0_4: movb $1, (%esp) movl %eax, 4(%esp) Take pointer to &this for __thiscall: LBB0_5: leal (%esp), %ecx calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E Do the addition to the result addl $16, %eax Repeat the previous circus jae LBB0_7 movb $0, 8(%esp) jmp LBB0_8 LBB0_7: movb $1, 8(%esp) movl %eax, 12(%esp) LBB0_8: leal 8(%esp), %ecx calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E movl %ebp, %esp popl %ebp ret .cfi_endproc Yeah. Its' not fast because its' not inlining through option::unwrap. I'm not sure what can be done for this, and whether its' on the LLVM side or the Rust side of things. My first instinct: find out what happens when fail! is moved out-of-line from unwrap() into its' own function (especially if that function can be marked noinline!), because optimizers often choke around EH. I tried to test the "optimal" situation in a synthetic benchmark: https://gist.github.com/oshepherd/8376705 (In C for expediency. N.B. you must set core affinity before running this benchmark because I hackishly just read the TSC. i386 only.) but the results are really bizzare and seem to have a multitude of affecting factors (For example, if you minimally unroll and have the JCs jump straight to abort, you get vastly different performance from jumping to a closer location and then onwards to abort. Bear in mind that the overflow case never happens during the test). It would be interesting to do a test in which a "trivial" implementation of trap-on-overflow is added to rustc (read: the overflow case just jumps straight to abort or similar, to minimize optimizer influence and variability) to see how defaulting to trapping ints affects real world workloads. I wonder what level of performance impact would be considered "acceptable" for improved safety by default? Mind you, I think that what I'd propose is that i32 = Trapping, i32w = wrapping, i32s = saturating, or something similar Owen Shepherd http://owenshepherd.net | owen.shepherd at e43.eu On 11 January 2014 19:33, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 11:54 AM, Owen Shepherd > wrote: > > On 11 January 2014 06:20, Daniel Micay wrote: > >> > >> The branch on the overflow flag results in a very significant loss in > >> performance. For example, I had to carefully write the vector `push` > >> method for my `Vec` type to only perform one overflow check. With > >> two checks, it's over 5 times slower due to failed branch predictions. > > > > > > What did the generated code look like? I suspect that LLVM wasn't > generating > > optimal code, perhaps because Rust wasn't giving it appropriate hints or > > because of optimizer bugs. For reference, on AMD64 the code should look > > something like the following hypothetical code: > > > > vec_allocate: > > MOV $SIZE, %eax > > MUL %rsi > > JC Lerror > > ADD $HEADER_SIZE, %rax > > JC Lerror > > MOV %rax, %rsi > > JMP malloc > > Lerror: > > // Code to raise error here > > > > Note that the ordering is EXTREMELY important! x86 doesn't give you any > > separate branch hints (excluding two obsolete ones which only the > Pentium IV > > ever cared about) so your only clue to the optimizer is the branch > > direction. > > > > I suspect your generated code had forward branches for the no overflow > case. > > Thats absolutely no good (codegen inerting "islands" of failure case > code); > > it will screw up the branch predictor. > > > > x86 defaults to predicting all (conditional) forward jumps not taken, all > > conditional backwards jumps taken (Loops!). If the optimizer wasn't > informed > > correctly, it will probably not have obeyed that. > > > > Being as the overflow case should basically be never hit, there is no > reason > > for it to ever be loaded into the optimizer, so that is good > > > > (P.S. If the rust compiler is really good it'll convince LLVM to put the > > error case branch code in a separate section so it can all be packed > > together far away from useful cache lines and TLB entries) > > Rust directly exposes the checked overflow intrinsics so these are > what was used. It already considers branches calling a `noreturn` > function to be colder, so adding an explicit branch hint (which is > easy enough via `llvm.expect` doesn't help). Feel free to implement it > yourself if you think you can do better. The compiler work is already > implemented. I doubt you'll get something performing in the same > ballpark as plain integers. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 11 13:42:40 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 16:42:40 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd wrote: > So I just did a test. Took the following rust code: > pub fn test_wrap(x : u32, y : u32) -> u32 { > return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); > } > > And got the following blob of assembly out. What we have there, my friends, > is a complete failure of the optimizer (N.B. it works for the simple case of > checked_add alone) > > Preamble: > > __ZN9test_wrap19hc4c136f599917215af4v0.0E: > .cfi_startproc > cmpl %fs:20, %esp > ja LBB0_2 > pushl $12 > pushl $20 > calll ___morestack > ret > LBB0_2: > pushl %ebp > Ltmp2: > .cfi_def_cfa_offset 8 > Ltmp3: > .cfi_offset %ebp, -8 > movl %esp, %ebp > Ltmp4: > .cfi_def_cfa_register %ebp > > Align stack (for what? We don't do any SSE) > > andl $-8, %esp > subl $16, %esp The compiler aligns the stack for performance. > Multiply x * y > > movl 12(%ebp), %eax > mull 16(%ebp) > jno LBB0_4 > > If it didn't overflow, stash a 0 at top of stack > > movb $0, (%esp) > jmp LBB0_5 > > If it did overflow, stash a 1 at top of stack (we are building an > Option here) > LBB0_4: > movb $1, (%esp) > movl %eax, 4(%esp) > > Take pointer to &this for __thiscall: > LBB0_5: > leal (%esp), %ecx > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E > > Do the addition to the result > > addl $16, %eax > > Repeat the previous circus > > jae LBB0_7 > movb $0, 8(%esp) > jmp LBB0_8 > LBB0_7: > movb $1, 8(%esp) > movl %eax, 12(%esp) > LBB0_8: > leal 8(%esp), %ecx > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E > movl %ebp, %esp > popl %ebp > ret > .cfi_endproc > > > Yeah. Its' not fast because its' not inlining through option::unwrap. The code to initiate failure is gigantic and LLVM doesn't do partial inlining by default. It's likely far above the inlining threshold. > I'm not sure what can be done for this, and whether its' on the LLVM side or > the Rust side of things. My first instinct: find out what happens when fail! > is moved out-of-line from unwrap() into its' own function (especially if > that function can be marked noinline!), because optimizers often choke > around EH. I was testing with `rust-core` and calling `abort`, as it doesn't use unwinding. > I tried to test the "optimal" situation in a synthetic benchmark: > https://gist.github.com/oshepherd/8376705 > (In C for expediency. N.B. you must set core affinity before running this > benchmark because I hackishly just read the TSC. i386 only.) > > > but the results are really bizzare and seem to have a multitude of affecting > factors (For example, if you minimally unroll and have the JCs jump straight > to abort, you get vastly different performance from jumping to a closer > location and then onwards to abort. Bear in mind that the overflow case > never happens during the test). It would be interesting to do a test in > which a "trivial" implementation of trap-on-overflow is added to rustc > (read: the overflow case just jumps straight to abort or similar, to > minimize optimizer influence and variability) to see how defaulting to > trapping ints affects real world workloads. > > I wonder what level of performance impact would be considered "acceptable" > for improved safety by default? > > Mind you, I think that what I'd propose is that i32 = Trapping, i32w = > wrapping, i32s = saturating, or something similar A purely synthetic benchmark only executing the unchecked or checked instruction isn't interesting. You need to include several optimizations in the loop as real code would use, and you will often see a massive drop in performance from the serialization of the pipeline. Register renaming is not as clever as you'd expect. The impact of trapping is known, because `clang` and `gcc` expose `-ftrapv`. Integer-heavy workloads like cryptography and video codecs are several times slower with the checks. From adamson.benjamin at gmail.com Sat Jan 11 14:03:53 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Sat, 11 Jan 2014 14:03:53 -0800 Subject: [rust-dev] NewType change in 0.9 Message-ID: Hello Rust community! I've been busying myself over the past few weeks learning the different features of rust, and I have been working on an implementation of Conway's game of life (while trying to explore different features of rust. In 0.9, it was changed so that you cannot dereference haskell-like "NewTypes" with the * operator. In the 0.9 documentation, it says we can use pattern matching to extract the underlying type. Right here in my 0.8 code I dererenced the row parameter here: https://github.com/ShortStomp/ConwayGameOfLife-RUST/blob/master/grid.rs#L42 which is a simple 'NewType', with underlying type uint. My question is, instead of dereferencing the 'Row' and 'Column' types, how can I use pattern matching here, to get the underlying uint to index the array with the code I just linked? Thanks in advance! :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Sat Jan 11 14:06:37 2014 From: sfackler at gmail.com (Steven Fackler) Date: Sat, 11 Jan 2014 14:06:37 -0800 Subject: [rust-dev] NewType change in 0.9 In-Reply-To: References: Message-ID: Something like this should work: pub fn cell_alive(&self, Row(row): Row, Column(column): Column) -> uint { return match self.inner[row][column].value { dead => 0, alive => 1 }; } Steven Fackler On Sat, Jan 11, 2014 at 2:03 PM, benjamin adamson < adamson.benjamin at gmail.com> wrote: > Hello Rust community! > > I've been busying myself over the past few weeks learning the different > features of rust, and I have been working on an implementation of Conway's > game of life (while trying to explore different features of rust. > > In 0.9, it was changed so that you cannot dereference haskell-like > "NewTypes" with the * operator. In the 0.9 documentation, it says we can > use pattern matching to extract the underlying type. > > Right here in my 0.8 code I dererenced the row parameter here: > https://github.com/ShortStomp/ConwayGameOfLife-RUST/blob/master/grid.rs#L42 > > which is a simple 'NewType', with underlying type uint. > > My question is, instead of dereferencing the 'Row' and 'Column' types, how > can I use pattern matching here, to get the underlying uint to index the > array with the code I just linked? > > Thanks in advance! :) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamson.benjamin at gmail.com Sat Jan 11 14:13:07 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Sat, 11 Jan 2014 14:13:07 -0800 Subject: [rust-dev] NewType change in 0.9 In-Reply-To: References: Message-ID: Thanks! That did work. However I have no idea what this is doing: Row(row): Row, Column(column): Column The way I understood variable declaration, is that it goes: name : type. What does wrapping the 'name' of the variable with it's type on the LHS of the : as well as having it on the RHS? Is this some special syntax related to 'NewTypes' ?? On Sat, Jan 11, 2014 at 2:06 PM, Steven Fackler wrote: > Something like this should work: > > > pub fn cell_alive(&self, Row(row): Row, Column(column): Column) -> uint { > > > return match self.inner[row][column].value { > > > dead => 0, > > > alive => 1 > }; > > } > > > Steven Fackler > > > On Sat, Jan 11, 2014 at 2:03 PM, benjamin adamson < > adamson.benjamin at gmail.com> wrote: > >> Hello Rust community! >> >> I've been busying myself over the past few weeks learning the different >> features of rust, and I have been working on an implementation of Conway's >> game of life (while trying to explore different features of rust. >> >> In 0.9, it was changed so that you cannot dereference haskell-like >> "NewTypes" with the * operator. In the 0.9 documentation, it says we can >> use pattern matching to extract the underlying type. >> >> Right here in my 0.8 code I dererenced the row parameter here: >> >> https://github.com/ShortStomp/ConwayGameOfLife-RUST/blob/master/grid.rs#L42 >> >> which is a simple 'NewType', with underlying type uint. >> >> My question is, instead of dereferencing the 'Row' and 'Column' types, >> how can I use pattern matching here, to get the underlying uint to index >> the array with the code I just linked? >> >> Thanks in advance! :) >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen.shepherd at e43.eu Sat Jan 11 14:13:39 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sat, 11 Jan 2014 22:13:39 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On 11 January 2014 21:42, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd > wrote: > > So I just did a test. Took the following rust code: > > pub fn test_wrap(x : u32, y : u32) -> u32 { > > return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); > > } > > > > And got the following blob of assembly out. What we have there, my > friends, > > is a complete failure of the optimizer (N.B. it works for the simple > case of > > checked_add alone) > > > > Preamble: > > > > __ZN9test_wrap19hc4c136f599917215af4v0.0E: > > .cfi_startproc > > cmpl %fs:20, %esp > > ja LBB0_2 > > pushl $12 > > pushl $20 > > calll ___morestack > > ret > > LBB0_2: > > pushl %ebp > > Ltmp2: > > .cfi_def_cfa_offset 8 > > Ltmp3: > > .cfi_offset %ebp, -8 > > movl %esp, %ebp > > Ltmp4: > > .cfi_def_cfa_register %ebp > > > > Align stack (for what? We don't do any SSE) > > > > andl $-8, %esp > > subl $16, %esp > > The compiler aligns the stack for performance. > > Oops, I misread and thought there was 16 byte alignment going on there, not 8. > > Multiply x * y > > > > movl 12(%ebp), %eax > > mull 16(%ebp) > > jno LBB0_4 > > > > If it didn't overflow, stash a 0 at top of stack > > > > movb $0, (%esp) > > jmp LBB0_5 > > > > If it did overflow, stash a 1 at top of stack (we are building an > > Option here) > > LBB0_4: > > movb $1, (%esp) > > movl %eax, 4(%esp) > > > > Take pointer to &this for __thiscall: > > LBB0_5: > > leal (%esp), %ecx > > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E > > > > Do the addition to the result > > > > addl $16, %eax > > > > Repeat the previous circus > > > > jae LBB0_7 > > movb $0, 8(%esp) > > jmp LBB0_8 > > LBB0_7: > > movb $1, 8(%esp) > > movl %eax, 12(%esp) > > LBB0_8: > > leal 8(%esp), %ecx > > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E > > movl %ebp, %esp > > popl %ebp > > ret > > .cfi_endproc > > > > > > Yeah. Its' not fast because its' not inlining through option::unwrap. > > The code to initiate failure is gigantic and LLVM doesn't do partial > inlining by default. It's likely far above the inlining threshold. > > Right, why I suggested explicitly moving the failure code out of line into a separate function. > A purely synthetic benchmark only executing the unchecked or checked > instruction isn't interesting. You need to include several > optimizations in the loop as real code would use, and you will often > see a massive drop in performance from the serialization of the > pipeline. Register renaming is not as clever as you'd expect. > > Agreed. The variability within that tiny benchmark tells me that it can't really glean any valuable information. > The impact of trapping is known, because `clang` and `gcc` expose > `-ftrapv`. > Integer-heavy workloads like cryptography and video codecs are > several times slower with the checks. > What about other workloads? As I mentioned: What I'd propose is trapping by default, with non-trapping math along the lines of a single additonal character on a type declaration away. Also, I did manage to convince Rust + LLVM to optimize things cleanly, by defining an unwrap which invoked libc's abort() -> !, so there's that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 11 14:22:37 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 17:22:37 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd wrote: > > What about other workloads? It just depends on how much of it is doing integer arithmetic. Many applications are bounded by I/O and memory bandwidth and wouldn't be hurt by integer arithmetic resulting in significantly slower code. > As I mentioned: What I'd propose is trapping by default, with non-trapping math along the lines of a single additonal character on a type declaration away. Why would it be a language feature? It's not an operation Rust needs to expose at a language level because it can be implemented as a library type. From marijnh at gmail.com Sat Jan 11 14:33:15 2014 From: marijnh at gmail.com (Marijn Haverbeke) Date: Sat, 11 Jan 2014 23:33:15 +0100 Subject: [rust-dev] NewType change in 0.9 In-Reply-To: References: Message-ID: > What does wrapping the 'name' of the variable with it's type on the LHS of > the : as well as having it on the RHS? It's a destructuring pattern, extracting the content of the Row/Column values and binding a variable to it. From owen.shepherd at e43.eu Sat Jan 11 14:38:48 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sat, 11 Jan 2014 22:38:48 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: On 11 January 2014 22:22, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd > wrote: > > > > What about other workloads? > > It just depends on how much of it is doing integer arithmetic. Many > applications are bounded by I/O and memory bandwidth and wouldn't be > hurt by integer arithmetic resulting in significantly slower code. > > > As I mentioned: What I'd propose is trapping by default, with > non-trapping math along the lines of a single additonal character on a type > declaration away. > > Why would it be a language feature? It's not an operation Rust needs > to expose at a language level because it can be implemented as a > library type. > I agree, however, I feel that the names like "i32" and "u32" should be trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) or similar. Why? Because I expect that otherwise people will default to the wrapping types. Less typing. "It'll never be a security issue", or "Looks safe to me", etc, etc. Secure by default is a good thing, IMO. So I agree, no reason it couldn't be implemented in libstd. Just... there are currently type names in the way. (I note that there has been a mixed opinion in this thread each way) Owen Shepherd http://owenshepherd.net | owen.shepherd at e43.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Jan 11 14:50:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 11 Jan 2014 17:50:30 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: excellent point owen. I'd agree myself, seeing how that exact same platform dependent int/uint size gotchas (wrapping style semantics) are a recurrent source of surprise in GHC Haskell, and other languages. In my own applications I like wrapping semantics, but for most people, a signed counter wrapping into negative numbers isn't a welcome suprise! On Sat, Jan 11, 2014 at 5:38 PM, Owen Shepherd wrote: > On 11 January 2014 22:22, Daniel Micay wrote: > >> On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd >> wrote: >> > >> > What about other workloads? >> >> It just depends on how much of it is doing integer arithmetic. Many >> applications are bounded by I/O and memory bandwidth and wouldn't be >> hurt by integer arithmetic resulting in significantly slower code. >> >> > As I mentioned: What I'd propose is trapping by default, with >> non-trapping math along the lines of a single additonal character on a type >> declaration away. >> >> Why would it be a language feature? It's not an operation Rust needs >> to expose at a language level because it can be implemented as a >> library type. >> > > I agree, however, I feel that the names like "i32" and "u32" should be > trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) > or similar. > > Why? Because I expect that otherwise people will default to the wrapping > types. Less typing. "It'll never be a security issue", or "Looks safe to > me", etc, etc. Secure by default is a good thing, IMO. > > So I agree, no reason it couldn't be implemented in libstd. Just... there > are currently type names in the way. > > (I note that there has been a mixed opinion in this thread each way) > > Owen Shepherd > http://owenshepherd.net | owen.shepherd at e43.eu > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Sat Jan 11 15:06:26 2014 From: ncm at cantrip.org (Nathan Myers) Date: Sat, 11 Jan 2014 15:06:26 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> Message-ID: <52D1CE72.8070003@cantrip.org> On 01/10/2014 10:08 PM, Daniel Micay wrote: > I don't think failure on overflow is very useful. It's still a bug if > you overflow when you don't intend it. If we did have a fast big > integer type, it would make sense to wrap it with an enum heading down > a separate branch for small and large integers, and branching on the > overflow flag to expand to a big integer. I think this is how Python's > integers are implemented. Failure on overflow *can* be useful in production code, using tasks to encapsulate suspect computations. Big-integer types can be useful, too. A big-integer type that uses small-integer arithmetic until overflow is a clever trick, but it's purely an implementation trick. Architecturally, it makes no sense to expose the trick to users. The fundamental error in the original posting was saying machine word types are somehow not "CORRECT". Such types have perfectly defined behavior and performance in all conditions. They just don't pretend to model what a mathematician calls an "integer". They *do* model what actual machines actually do. It makes sense to call them something else than "integer", but "i32" *is* something else. It also makes sense to make a library that tries to emulate an actual integer type. That belongs in a library because it's purely a construct: nothing in any physical machine resembles an actual integer. Furthermore, since it is an emulation, details vary for practical reasons. No single big-integer or overflow-trapping type can meet all needs. (If you try, you fail users who need it simple.) That's OK, because anyone can code another, and a simple default can satisfy most users. In fact, i64 satisifies almost all users almost all the time. Nathan Myers From pwalton at mozilla.com Sat Jan 11 15:10:05 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 11 Jan 2014 15:10:05 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: <63a21691-7299-49e6-b5c9-e7dca0feeaea@email.android.com> I think failure may have quite different inlining costs once we move to libunwind-based backtraces instead of hardcoding file/line number information into the generated code. The file and line number information tends to pollute generated code a lot and it's basically unnecessary with proper DWARF info and a functioning set of libunwind bindings, which we now have thanks to a couple of awesome contributions from you all. :) Patrick Owen Shepherd wrote: >On 11 January 2014 21:42, Daniel Micay wrote: > >> On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd >> wrote: >> > So I just did a test. Took the following rust code: >> > pub fn test_wrap(x : u32, y : u32) -> u32 { >> > return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); >> > } >> > >> > And got the following blob of assembly out. What we have there, my >> friends, >> > is a complete failure of the optimizer (N.B. it works for the >simple >> case of >> > checked_add alone) >> > >> > Preamble: >> > >> > __ZN9test_wrap19hc4c136f599917215af4v0.0E: >> > .cfi_startproc >> > cmpl %fs:20, %esp >> > ja LBB0_2 >> > pushl $12 >> > pushl $20 >> > calll ___morestack >> > ret >> > LBB0_2: >> > pushl %ebp >> > Ltmp2: >> > .cfi_def_cfa_offset 8 >> > Ltmp3: >> > .cfi_offset %ebp, -8 >> > movl %esp, %ebp >> > Ltmp4: >> > .cfi_def_cfa_register %ebp >> > >> > Align stack (for what? We don't do any SSE) >> > >> > andl $-8, %esp >> > subl $16, %esp >> >> The compiler aligns the stack for performance. >> >> > >Oops, I misread and thought there was 16 byte alignment going on there, >not >8. > > >> > Multiply x * y >> > >> > movl 12(%ebp), %eax >> > mull 16(%ebp) >> > jno LBB0_4 >> > >> > If it didn't overflow, stash a 0 at top of stack >> > >> > movb $0, (%esp) >> > jmp LBB0_5 >> > >> > If it did overflow, stash a 1 at top of stack (we are building an >> > Option here) >> > LBB0_4: >> > movb $1, (%esp) >> > movl %eax, 4(%esp) >> > >> > Take pointer to &this for __thiscall: >> > LBB0_5: >> > leal (%esp), %ecx >> > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E >> > >> > Do the addition to the result >> > >> > addl $16, %eax >> > >> > Repeat the previous circus >> > >> > jae LBB0_7 >> > movb $0, 8(%esp) >> > jmp LBB0_8 >> > LBB0_7: >> > movb $1, 8(%esp) >> > movl %eax, 12(%esp) >> > LBB0_8: >> > leal 8(%esp), %ecx >> > calll __ZN6option6Option6unwrap21h05c5cb6c47a61795Zcat4v0.0E >> > movl %ebp, %esp >> > popl %ebp >> > ret >> > .cfi_endproc >> > >> > >> > Yeah. Its' not fast because its' not inlining through >option::unwrap. >> >> The code to initiate failure is gigantic and LLVM doesn't do partial >> inlining by default. It's likely far above the inlining threshold. >> >> >Right, why I suggested explicitly moving the failure code out of line >into >a separate function. > > >> A purely synthetic benchmark only executing the unchecked or checked >> instruction isn't interesting. You need to include several >> optimizations in the loop as real code would use, and you will often >> see a massive drop in performance from the serialization of the >> pipeline. Register renaming is not as clever as you'd expect. >> >> >Agreed. The variability within that tiny benchmark tells me that it >can't >really glean any valuable information. > > >> The impact of trapping is known, because `clang` and `gcc` expose >> `-ftrapv`. >> Integer-heavy workloads like cryptography and video codecs are >> several times slower with the checks. >> > >What about other workloads? > >As I mentioned: What I'd propose is trapping by default, with >non-trapping >math along the lines of a single additonal character on a type >declaration >away. > >Also, I did manage to convince Rust + LLVM to optimize things cleanly, >by >defining an unwrap which invoked libc's abort() -> !, so there's that. > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jan 11 15:14:50 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 11 Jan 2014 18:14:50 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D1CE72.8070003@cantrip.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1CE72.8070003@cantrip.org> Message-ID: On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. If we did have a fast big >> integer type, it would make sense to wrap it with an enum heading down >> a separate branch for small and large integers, and branching on the >> overflow flag to expand to a big integer. I think this is how Python's >> integers are implemented. > > Failure on overflow *can* be useful in production code, using > tasks to encapsulate suspect computations. Big-integer types > can be useful, too. A big-integer type that uses small-integer > arithmetic until overflow is a clever trick, but it's purely > an implementation trick. Architecturally, it makes no sense > to expose the trick to users. I didn't suggest exposing it to users. I suggested defining a wrapper around the big integer type with better performance characteristics for small integers. > The fundamental error in the original posting was saying machine > word types are somehow not "CORRECT". Such types have perfectly > defined behavior and performance in all conditions. They just > don't pretend to model what a mathematician calls an "integer". > They *do* model what actual machines actually do. It makes > sense to call them something else than "integer", but "i32" > *is* something else. Rings, fields and modular arithmetic are certainly very real mathematical concepts. Unsigned fixed-size integers behave as a mathematician would model them, while signed ones do not really have sane high-level semantics. > It also makes sense to make a library that tries to emulate > an actual integer type. That belongs in a library because it's > purely a construct: nothing in any physical machine resembles > an actual integer. Furthermore, since it is an emulation, > details vary for practical reasons. No single big-integer or > overflow-trapping type can meet all needs. (If you try, you > fail users who need it simple.) That's OK, because anyone > can code another, and a simple default can satisfy most users. What do you mean by default? If you don't know the bounds, a big integer is clearly the only correct choice. If you do know the bounds, you can use a fixed-size integer. I don't think any default other than a big integer is sane, so I don't think Rust needs a default inference fallback. From pcwalton at mozilla.com Sat Jan 11 15:59:17 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 11 Jan 2014 15:59:17 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> Message-ID: <52D1DAD5.2080308@mozilla.com> On 1/10/14 10:08 PM, Daniel Micay wrote: > I don't think failure on overflow is very useful. It's still a bug if > you overflow when you don't intend it. Of course it's useful. It prevents attackers from weaponizing out-of-bounds reads and writes in unsafe code. Patrick From thadguidry at gmail.com Sat Jan 11 17:24:44 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Sat, 11 Jan 2014 19:24:44 -0600 Subject: [rust-dev] Properly licensing Rust documentation and wiki In-Reply-To: <52D0BE18.2070106@mozilla.com> References: <52D0BE18.2070106@mozilla.com> Message-ID: I touched the wiki. All "Thad Guidry" edits are Public Domain, of course. Or MIT/ASL2 license if you so desire. On Fri, Jan 10, 2014 at 9:44 PM, Brian Anderson wrote: > Hey. > > Time for more legal stuff. Per https://github.com/mozilla/rust/issues/5831the licensing of our documentation is not clear. Like all things Rust we > want to make our doc license as permissive as possible, so after getting > some legal advice here is what I intend to do: > > * Rust documentation will be MIT/ASL2 licensed like everything else. > * Add the license as a *footer* to existing in-tree documentation, under > the argument that it is already licensed according to the same terms as the > rest of the repo. > * Gather new statements from wiki contributors asserting that they > contrtibuted under the MIT/ASL2, as we did when we relicensed Rust. > * Put the license as footers on all pages of the wiki. > > For the most part this should not affect anybody, though if you've ever > touched the wiki you may recieve an email from me about this in the future. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Sat Jan 11 17:49:44 2014 From: ncm at cantrip.org (Nathan Myers) Date: Sat, 11 Jan 2014 17:49:44 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1CE72.8070003@cantrip.org> Message-ID: <52D1F4B8.7040805@cantrip.org> On 01/11/2014 03:14 PM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers wrote: >> A big-integer type that uses small-integer >> arithmetic until overflow is a clever trick, but it's purely >> an implementation trick. Architecturally, it makes no sense >> to expose the trick to users. > > I didn't suggest exposing it to users. I suggested defining a wrapper > around the big integer type with better performance characteristics > for small integers. Your wrapper sounds to me like THE big-integer type. The thing you called a "big integer" doesn't need a name. >> No single big-integer or >> overflow-trapping type can meet all needs. (If you try, you >> fail users who need it simple.) That's OK, because anyone >> can code another, and a simple default can satisfy most users. > > What do you mean by default? If you don't know the bounds, a big > integer is clearly the only correct choice. If you do know the > bounds,you can use a fixed-size integer. I don't think any default > other than a big integer is sane, so I don't think Rust needs a > default inference fallback. As I said, >> In fact, i64 satisifies almost all users almost all the time. No one would complain about a built-in "i128" type. The thing about a fixed-size type is that there are no implementation choices to leak out. Overflowing an i128 variable is quite difficult, and 128-bit operations are still lots faster than on any variable-precision type. I could live with "int" == "i128". Nathan Myers From marcianx at gmail.com Sat Jan 11 18:40:26 2014 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 11 Jan 2014 21:40:26 -0500 Subject: [rust-dev] Macros expanding to multiple statements Message-ID: Rust 0.9 indicates that support for expansion of macros into multiple statements is now supported, and the following example from the test suite works for me. https://github.com/mozilla/rust/blob/master/src/test/run-pass/macro-multiple-items.rs However, I receive an error for the following code #[feature(macro_rules)]; macro_rules! my_print( ($a:expr, $b:expr) => ( println!("{:?}", a); println!("{:?}", b); ); ) fn main() { let a = 1; let b = 2; my_print!(a, b); } (Note that the ^~~~~~~ below points at println.) $ rustc macro_ignores_second_line.rs macro_ignores_second_line.rs:6:9: 6:16 error: macro expansion ignores token `println` and any following macro_ignores_second_line.rs:6 println!("{:?}", b); ^~~~~~~ error: aborting due to previous error task 'rustc' failed at 'explicit failure', /home/marcianx/devel/rust/checkout/rust/src/libsyntax/diagnostic.rs:75 task '
' failed at 'explicit failure', /home/marcianx/devel/rust/checkout/rust/src/librustc/lib.rs:453 What's the right way to do this? Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sat Jan 11 18:43:54 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sun, 12 Jan 2014 13:43:54 +1100 Subject: [rust-dev] Macros expanding to multiple statements In-Reply-To: References: Message-ID: <52D2016A.6030605@gmail.com> That test is for multiple *items*, not statements. For the moment, you just have to wrap the interior of a macro expanding to an expression in a set of braces, so that it becomes a single statement. macro_rules! my_print( ($a:expr, $b:expr) => ( { println!("{:?}", a); println!("{:?}", b); } ); ) Multi-statement macros are covered by https://github.com/mozilla/rust/issues/10681 . Huon On 12/01/14 13:40, Ashish Myles wrote: > Rust 0.9 indicates that support for expansion of macros into multiple > statements is now supported, and the following example from the test > suite works for me. > https://github.com/mozilla/rust/blob/master/src/test/run-pass/macro-multiple-items.rs > > However, I receive an error for the following code > > #[feature(macro_rules)]; > > macro_rules! my_print( > ($a:expr, $b:expr) => ( > println!("{:?}", a); > println!("{:?}", b); > ); > ) > > fn main() { > let a = 1; > let b = 2; > my_print!(a, b); > } > > (Note that the ^~~~~~~ below points at println.) > > $ rustc macro_ignores_second_line.rs > macro_ignores_second_line.rs:6:9: 6:16 error: macro expansion ignores > token `println` and any following > macro_ignores_second_line.rs:6 > println!("{:?}", b); > ^~~~~~~ > error: aborting due to previous error > task 'rustc' failed at 'explicit failure', > /home/marcianx/devel/rust/checkout/rust/src/libsyntax/diagnostic.rs:75 > > task '
' failed at 'explicit failure', > /home/marcianx/devel/rust/checkout/rust/src/librustc/lib.rs:453 > > > > What's the right way to do this? > > Ashish > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcianx at gmail.com Sat Jan 11 19:13:59 2014 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 11 Jan 2014 22:13:59 -0500 Subject: [rust-dev] Macros expanding to multiple statements In-Reply-To: <52D2016A.6030605@gmail.com> References: <52D2016A.6030605@gmail.com> Message-ID: Ah, I didn't realize the distinction. I am comparing the code in the first comment in the bug you linked against the test suite example I linked. I guess the distinction between items and statements is that items correspond to code outside any method, whereas statements are defined as code within a method, and macro expansions in the latter case seem to be broken even in the case of a single statement. Please correct me if I am wrong. Ashish On Sat, Jan 11, 2014 at 9:43 PM, Huon Wilson wrote: > That test is for multiple *items*, not statements. > > For the moment, you just have to wrap the interior of a macro expanding to > an expression in a set of braces, so that it becomes a single statement. > > > macro_rules! my_print( > ($a:expr, $b:expr) => ( > { > println!("{:?}", a); > println!("{:?}", b); > } > ); > ) > > Multi-statement macros are covered by > https://github.com/mozilla/rust/issues/10681 . > > > Huon > > > > On 12/01/14 13:40, Ashish Myles wrote: > > Rust 0.9 indicates that support for expansion of macros into multiple > statements is now supported, and the following example from the test suite > works for me. > > https://github.com/mozilla/rust/blob/master/src/test/run-pass/macro-multiple-items.rs > > However, I receive an error for the following code > > #[feature(macro_rules)]; > > macro_rules! my_print( > ($a:expr, $b:expr) => ( > println!("{:?}", a); > println!("{:?}", b); > ); > ) > > fn main() { > let a = 1; > let b = 2; > my_print!(a, b); > } > > (Note that the ^~~~~~~ below points at println.) > > $ rustc macro_ignores_second_line.rs > macro_ignores_second_line.rs:6:9: 6:16 error: macro expansion ignores > token `println` and any following > macro_ignores_second_line.rs:6 println!("{:?}", b); > ^~~~~~~ > error: aborting due to previous error > task 'rustc' failed at 'explicit failure', > /home/marcianx/devel/rust/checkout/rust/src/libsyntax/diagnostic.rs:75 > task '
' failed at 'explicit failure', > /home/marcianx/devel/rust/checkout/rust/src/librustc/lib.rs:453 > > > What's the right way to do this? > > Ashish > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at du.nham.ca Sun Jan 12 00:08:29 2014 From: andrew at du.nham.ca (Andrew Dunham) Date: Sun, 12 Jan 2014 00:08:29 -0800 Subject: [rust-dev] Properly licensing Rust documentation and wiki In-Reply-To: References: <52D0BE18.2070106@mozilla.com> Message-ID: I think I touched one of the installation instruction pages at one point. Either way, all my edits are in the public domain or in whatever license Mozilla requests. --Andrew D On Sat, Jan 11, 2014 at 5:24 PM, Thad Guidry wrote: > I touched the wiki. All "Thad Guidry" edits are Public Domain, of course. > Or MIT/ASL2 license if you so desire. > > > On Fri, Jan 10, 2014 at 9:44 PM, Brian Anderson wrote: > >> Hey. >> >> Time for more legal stuff. Per https://github.com/mozilla/ >> rust/issues/5831 the licensing of our documentation is not clear. Like >> all things Rust we want to make our doc license as permissive as possible, >> so after getting some legal advice here is what I intend to do: >> >> * Rust documentation will be MIT/ASL2 licensed like everything else. >> * Add the license as a *footer* to existing in-tree documentation, under >> the argument that it is already licensed according to the same terms as the >> rest of the repo. >> * Gather new statements from wiki contributors asserting that they >> contrtibuted under the MIT/ASL2, as we did when we relicensed Rust. >> * Put the license as footers on all pages of the wiki. >> >> For the most part this should not affect anybody, though if you've ever >> touched the wiki you may recieve an email from me about this in the future. >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abe.egnor at gmail.com Sun Jan 12 05:09:13 2014 From: abe.egnor at gmail.com (Abraham Egnor) Date: Sun, 12 Jan 2014 08:09:13 -0500 Subject: [rust-dev] Questions from a newcomer Message-ID: Hello! The 0.9 release prompted me to poke at my nascent rust code. Very impressed with the language and the progress since I last looked (0.4 maybe?). Some questions that I wasn't able to find answers for: * Is there any built-in way to iterate over all values of a C-like enum? It's not hard to define an iterator method that implements this for any given type, but it's tedious boilerplate that seems better left to the compiler. * Is it possible to express "if a type implements trait A, here is a default implementation of trait B"? I tried the obvious way ("impl TraitB for T"), but it looks like the rust compiler can't disambiguate between that impl and type-specific impls. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abe.egnor at gmail.com Sun Jan 12 05:16:33 2014 From: abe.egnor at gmail.com (Abraham Egnor) Date: Sun, 12 Jan 2014 08:16:33 -0500 Subject: [rust-dev] Questions from a newcomer In-Reply-To: References: Message-ID: Oh yes, and one more: * Why does the do-notation require a function that takes a proc()? Given that || is the recommended type for HOFs it seems like it would be much more convenient if it worked with functions expecting a proc() or a ||. On Sun, Jan 12, 2014 at 8:09 AM, Abraham Egnor wrote: > Hello! The 0.9 release prompted me to poke at my nascent rust code. Very > impressed with the language and the progress since I last looked (0.4 > maybe?). > > Some questions that I wasn't able to find answers for: > > * Is there any built-in way to iterate over all values of a C-like enum? > It's not hard to define an iterator method that implements this for any > given type, but it's tedious boilerplate that seems better left to the > compiler. > > * Is it possible to express "if a type implements trait A, here is a > default implementation of trait B"? I tried the obvious way ("impl TraitA> TraitB for T"), but it looks like the rust compiler can't > disambiguate between that impl and type-specific impls. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at mansionfamily.plus.com Sun Jan 12 05:23:57 2014 From: james at mansionfamily.plus.com (james) Date: Sun, 12 Jan 2014 13:23:57 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> Message-ID: <52D2976D.60808@mansionfamily.plus.com> On 11/01/2014 22:38, Owen Shepherd wrote: > I agree, however, I feel that the names like "i32" and "u32" should be > trap-on-overflow types. The non overflow ones should be "i32w" > (wrapping) or similar. > > Why? Because I expect that otherwise people will default to the > wrapping types. Less typing. "It'll never be a security issue", or > "Looks safe to me", etc, etc. Secure by default is a good thing, IMO I don't think making 'i32' have different semantics by default from int32_t (or from the 'i32' typedef most of us will have used for years) is a good idea in a wannabe systems programming language. It is too surprising. There might be a good case for having a pragma control some 'check for overflow' in a paranoid test mode, but i think that most programmers, most of the time, will expect 2s complement arithmetic 'as usual'. From dbau.pp at gmail.com Sun Jan 12 05:27:33 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Mon, 13 Jan 2014 00:27:33 +1100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D2976D.60808@mansionfamily.plus.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> <52D2976D.60808@mansionfamily.plus.com> Message-ID: <52D29845.6060403@gmail.com> On 13/01/14 00:23, james wrote: > On 11/01/2014 22:38, Owen Shepherd wrote: >> I agree, however, I feel that the names like "i32" and "u32" should >> be trap-on-overflow types. The non overflow ones should be "i32w" >> (wrapping) or similar. >> >> Why? Because I expect that otherwise people will default to the >> wrapping types. Less typing. "It'll never be a security issue", or >> "Looks safe to me", etc, etc. Secure by default is a good thing, IMO > I don't think making 'i32' have different semantics by default from > int32_t (or from the 'i32' typedef most of us will have used for > years) is a good idea in a wannabe systems programming language. It > is too surprising. > > There might be a good case for having a pragma control some 'check for > overflow' in a paranoid test mode, but i think that most programmers, > most of the time, will expect 2s complement arithmetic 'as usual'. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev Coincidentally, i32 already has different semantics to int32_t: overflow of signed types is undefined behaviour in C, but is defined (as wrap-around) in Rust. Huon From owen.shepherd at e43.eu Sun Jan 12 05:34:32 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sun, 12 Jan 2014 13:34:32 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D2976D.60808@mansionfamily.plus.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> <52D2976D.60808@mansionfamily.plus.com> Message-ID: On 12 January 2014 13:23, james wrote: > On 11/01/2014 22:38, Owen Shepherd wrote: > >> I agree, however, I feel that the names like "i32" and "u32" should be >> trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) >> or similar. >> >> Why? Because I expect that otherwise people will default to the wrapping >> types. Less typing. "It'll never be a security issue", or "Looks safe to >> me", etc, etc. Secure by default is a good thing, IMO >> > I don't think making 'i32' have different semantics by default from > int32_t (or from the 'i32' typedef most of us will have used for years) is > a good idea in a wannabe systems programming language. It is too > surprising. > > There might be a good case for having a pragma control some 'check for > overflow' in a paranoid test mode, but i think that most programmers, most > of the time, will expect 2s complement arithmetic 'as usual'. > Signd integers have no defined behavior on overflow in C or C++. Go on, compile this program with optimizations enabled: #include #include int main() { for(int i = INT_MAX; i > 0; i++) { printf("Hello\n"); } } Watch it loop endlessly, because since UB is undefined, the compiler assumes it never occurs, and therefore i will always be greater than 0 since it starts higher. I think defined behavior by default is better than undefined behavior, and I also think that overflow detection by default is better than random wrapping by default. There are applications where wrapping is useful, or where checking for overflow is too expensive. For those, unchecked integers should be only a short distance away. But I also feel that by making the unchecked ones the shorter name, the language would be implicitly sending a message that they're preferred. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Sun Jan 12 08:29:00 2014 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Mon, 13 Jan 2014 03:29:00 +1100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D0E224.7060103@mozilla.com> <52D2976D.60808@mansionfamily.plus.com> Message-ID: <2B63D70F-15CA-454B-8333-16AFADBE27E3@yahoo.com.au> On 13 Jan 2014, at 12:34 am, Owen Shepherd wrote: > But I also feel that by making the unchecked ones the shorter name, the language would be implicitly sending a message that they're preferred. Custom operator time! Say hello to our checked operators: trait CheckedAdd { fn infix +| (a: &Self, b: &Self) -> Self; } trait CheckedSub { fn infix -| (a: &Self, b: &Self) -> Self; } trait CheckedMul { fn infix *| (a: &Self, b: &Self) -> Self; } xD ~Brendan From rexlen at gmail.com Sun Jan 12 08:48:42 2014 From: rexlen at gmail.com (Renato Lenzi) Date: Sun, 12 Jan 2014 17:48:42 +0100 Subject: [rust-dev] line params Message-ID: If i want to access line command params i used code like this: fn main() { let args: ~[~str] = ::std::os::args(); println(args[0]); } Is this the best way to play with such params or the best is using print_args? i've found no examples using print_args.... thanks, regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sun Jan 12 09:00:29 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 12 Jan 2014 12:00:29 -0500 Subject: [rust-dev] line params In-Reply-To: References: Message-ID: I don't know what print_args is, but there's a getopt-alike in extra::getopts On Sun, Jan 12, 2014 at 11:48 AM, Renato Lenzi wrote: > If i want to access line command params i used code like this: > > fn main() { > let args: ~[~str] = ::std::os::args(); > println(args[0]); > } > > > Is this the best way to play with such params or the best is using > print_args? i've found no examples using print_args.... > > thanks, regards. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From thadguidry at gmail.com Sun Jan 12 09:14:24 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Sun, 12 Jan 2014 11:14:24 -0600 Subject: [rust-dev] Fast inverse square root in Rust Message-ID: Where is the fast inverse square root function in Rust ? http://en.wikipedia.org/wiki/Fast_inverse_square_root Anyone know if this semi-accurate function is at a hardware level and built in to Intel chipsets since MMX ? How does this affect LLVM and Rust compilation on 64 bit ? Thanks in advance, -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sun Jan 12 09:16:09 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 12 Jan 2014 12:16:09 -0500 Subject: [rust-dev] Questions from a newcomer In-Reply-To: References: Message-ID: Hi Abraham, > * Is there any built-in way to iterate over all values of a C-like enum? > It's not hard to define an iterator method that implements this for any > given type, but it's tedious boilerplate that seems better left to the > compiler. > Not really. What is your usecase? One boilerplate-avoiding workaround is to use FromPrimitive[1] and put `#[deriving(FromPrimitive)]` on your enum. Then, to iterate over the valid discriminants, you can use: range(0, std::uint::max_value).filter_map(|x| FromPrimitive::from_uint(x).map(|y| y as uint)) Note that this iterates over the entire range of uint. This is required for an enum like: enum WhatAPain { A, B = 42, C = 12312455 } Needless to say this is not going to perform well. You can substitute the variant whose discriminant is the largest to make it cheaper: range(0, C as uint).filter_map(|x| FromPrimitive::from_uint(x).map(|y| y as uint)) > * Is it possible to express "if a type implements trait A, here is a > default implementation of trait B"? I tried the obvious way ("impl TraitA> TraitB for T"), but it looks like the rust compiler can't > disambiguate between that impl and type-specific impls. > You are doing it correctly. There is an issue open about this: https://github.com/mozilla/rust/issues/10601 > * Why does the do-notation require a function that takes a proc()? Given > that || is the recommended type for HOFs it seems like it would be much more > convenient if it worked with functions expecting a proc() or a ||. > `do` previously applied to any closure type but that was removed because the meaning of `do` can change wildly depending on what you apply it to. In particular, using the old syntax, do applied to a `fn(~fn())` will have an allocation, whereas `fn(&fn())` will not. To make such costs obvious, `do` no longer works with `&fn()` (now written `||`). `proc()` corresponds to `~once fn()`, that is, a closure which may be called once and whose environment is allocated on the heap. The advantage of this is that it allows for moving values into the body of `do`. [1]: http://static.rust-lang.org/doc/0.9/std/num/trait.FromPrimitive.html From carter.schonwald at gmail.com Sun Jan 12 09:31:59 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 12 Jan 2014 12:31:59 -0500 Subject: [rust-dev] Fast inverse square root in Rust In-Reply-To: References: Message-ID: http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html On Sunday, January 12, 2014, Thad Guidry wrote: > Where is the fast inverse square root function in Rust ? > http://en.wikipedia.org/wiki/Fast_inverse_square_root > > Anyone know if this semi-accurate function is at a hardware level and > built in to Intel chipsets since MMX ? > > How does this affect LLVM and Rust compilation on 64 bit ? > > Thanks in advance, > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen.shepherd at e43.eu Sun Jan 12 09:51:14 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sun, 12 Jan 2014 17:51:14 +0000 Subject: [rust-dev] Fast inverse square root in Rust In-Reply-To: References: Message-ID: The "Fast inverse square root" is no longer fast. SSE implements accurate square root which is faster. Owen Shepherd http://owenshepherd.net | owen.shepherd at e43.eu On 12 January 2014 17:31, Carter Schonwald wrote: > > http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html > > On Sunday, January 12, 2014, Thad Guidry wrote: > >> Where is the fast inverse square root function in Rust ? >> http://en.wikipedia.org/wiki/Fast_inverse_square_root >> >> Anyone know if this semi-accurate function is at a hardware level and >> built in to Intel chipsets since MMX ? >> >> How does this affect LLVM and Rust compilation on 64 bit ? >> >> Thanks in advance, >> >> -- >> -Thad >> +ThadGuidry >> Thad on LinkedIn >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Sun Jan 12 10:00:14 2014 From: me at kevincantu.org (Kevin Cantu) Date: Sun, 12 Jan 2014 18:00:14 +0000 Subject: [rust-dev] 1/28 Bay Area Rust meetup: Rust 0.9 and DST In-Reply-To: References: <52CE82C5.8030509@seld.be> Message-ID: If anybody else on the list is in Cambridge, UK, we whould get together someplace and watch the video later that day! Kevin On Jan 9, 2014 2:38 PM, "Erick Tryzelaar" wrote: > You are in luck. They all are posted on air.mozilla.org. You can find all > the other meetup presentations here: > > https://air.mozilla.org/search/?q=Rust > > On Thursday, January 9, 2014, Jordi Boggiano wrote: > >> On 08/01/2014 16:58, Erick Tryzelaar wrote: >> >>> Hello Rusticians! >>> >>> I'm happy to announce the next Bay Area Rust meetup on 1/28! You can >>> sign up for it here: >>> >>> http://www.meetup.com/Rust-Bay-Area/events/153909222/ >>> >> >> If possible it'd be awesome to post recordings here after the meetup, for >> those that can't physically make it. >> >> Cheers >> >> -- >> Jordi Boggiano >> @seldaek - http://nelm.io/jordi >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Sun Jan 12 10:19:11 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Sun, 12 Jan 2014 12:19:11 -0600 Subject: [rust-dev] Fast inverse square root in Rust In-Reply-To: References: Message-ID: Is that implemented through LLVM at http://llvm.org/docs/doxygen/html/TargetTransformInfo_8h_source.html 00265 /// haveFastSqrt -- Return true if the hardware has a fast square-root00266 /// instruction.00267 virtual bool haveFastSqrt (Type *Ty) const; How does that pass from Rust ??? On Sun, Jan 12, 2014 at 11:51 AM, Owen Shepherd wrote: > The "Fast inverse square root" is no longer fast. SSE implements accurate > square root which is faster. > > Owen Shepherd > http://owenshepherd.net | owen.shepherd at e43.eu > > > On 12 January 2014 17:31, Carter Schonwald wrote: > >> >> http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html >> >> On Sunday, January 12, 2014, Thad Guidry wrote: >> >>> Where is the fast inverse square root function in Rust ? >>> http://en.wikipedia.org/wiki/Fast_inverse_square_root >>> >>> Anyone know if this semi-accurate function is at a hardware level and >>> built in to Intel chipsets since MMX ? >>> >>> How does this affect LLVM and Rust compilation on 64 bit ? >>> >>> Thanks in advance, >>> >>> -- >>> -Thad >>> +ThadGuidry >>> Thad on LinkedIn >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Sun Jan 12 10:23:46 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Sun, 12 Jan 2014 18:23:46 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> Message-ID: <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> Isaac Dupree wrote: > In general, Rust is a systems language, so fixed-size integral types are > important to have. They are better-behaved than in C and C++ in that > signed types are modulo, not undefined behaviour, on overflow. It could > be nice to have integral types that are task-failure on overflow as an > option too. As you note, bignum integers are important too; it's good > they're available. I think bignum rationals would be a fine additional > choice to have (Haskell and GMP offer them, for example). Wrapping overflow is just as bad as undefined behavior IMO. I cannot remember a single case of using signed integers where wrapping would make any sense. And you lose some optimization opportunities. Trapping overflow is a bit better security wise, but performance is worse. Also IIRC it does not play nicely with existing code that assumes otherwise. Checking only at runtime is also not optimal. Bigints are secure but IMO not suited as default for a systems PL. So why not take the path of the rust memory management and enforce bounds statically? It would need annotations on the types, like lifetimes, but it would be very rusty. Like C but safe. Tobi From ml at isaac.cedarswampstudios.org Sun Jan 12 11:02:02 2014 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun, 12 Jan 2014 14:02:02 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D0DDA3.8040501@isaac.cedarswampstudios.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> Message-ID: <52D2E6AA.7070403@isaac.cedarswampstudios.org> Another sweet spot for a few applications is larger-than-word-sized fixed-width types, such as a 128 or 192 bit (u)int. This is useful for code that has to deal with values larger than 64 bits but within, say, 256 or 512 bits (above this, I think the costs of dynamic allocation and non-inlined numeric code become cheap-ish compared to the numeric computation and storage costs). I've done this with C++ templates; it works pretty okay; it sure makes GCC/LLVM's register allocator work hard! -Isaac From carter.schonwald at gmail.com Sun Jan 12 11:06:38 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 12 Jan 2014 14:06:38 -0500 Subject: [rust-dev] Fast inverse square root in Rust In-Reply-To: References: Message-ID: Note that on modern hardware the fast inv trick, which is a very specific trick indeed, is just one approach. Modern intel CPUs do have some special instructions support that's related. Note that many of these tricks / primops do not provide the full available representable precision. That actually raises a good point: for finite precision real number types like f64 /f32 etc, what are the desired precision/numerical stability guarantees of routines included I the std lib? For operations on IEEE floating point types, how do these guarantees carry these composite operations in the presence of rounding modes? These are nuanced questions. And maybe there should different types / traits depending on the assumptions needed. (A fun question is: "when is multiplication commutative and associative?", because it's not for matrices, floats and groups) Anyways, numerical computation is subtle :-) On Sunday, January 12, 2014, Carter Schonwald wrote: > > http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html > > On Sunday, January 12, 2014, Thad Guidry wrote: > >> Where is the fast inverse square root function in Rust ? >> http://en.wikipedia.org/wiki/Fast_inverse_square_root >> >> Anyone know if this semi-accurate function is at a hardware level and >> built in to Intel chipsets since MMX ? >> >> How does this affect LLVM and Rust compilation on 64 bit ? >> >> Thanks in advance, >> >> -- >> -Thad >> +ThadGuidry >> Thad on LinkedIn >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen.shepherd at e43.eu Sun Jan 12 11:09:37 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Sun, 12 Jan 2014 19:09:37 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D2E6AA.7070403@isaac.cedarswampstudios.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D2E6AA.7070403@isaac.cedarswampstudios.org> Message-ID: On 12 January 2014 19:02, Isaac Dupree wrote: > Another sweet spot for a few applications is larger-than-word-sized > fixed-width types, such as a 128 or 192 bit (u)int. This is useful for > code that has to deal with values larger than 64 bits but within, say, 256 > or 512 bits (above this, I think the costs of dynamic allocation and > non-inlined numeric code become cheap-ish compared to the numeric > computation and storage costs). I've done this with C++ templates; it > works pretty okay; it sure makes GCC/LLVM's register allocator work hard! > -Isaac > > A minor variation of "checked_add" (i.e. add_with_carry) would take care of this. Obviously also need a multiply which returns the two result halves also. For implementing bignum arithmetic, this is obviously a point where a "natural int" type would be best (probably the biggest which fits a single register) Owen Shepherd http://owenshepherd.net | owen.shepherd at e43.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Jan 12 12:24:08 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 12 Jan 2014 15:24:08 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> Message-ID: On Sun, Jan 12, 2014 at 1:23 PM, Tobias M?ller wrote: > Isaac Dupree > wrote: >> In general, Rust is a systems language, so fixed-size integral types are >> important to have. They are better-behaved than in C and C++ in that >> signed types are modulo, not undefined behaviour, on overflow. It could >> be nice to have integral types that are task-failure on overflow as an >> option too. As you note, bignum integers are important too; it's good >> they're available. I think bignum rationals would be a fine additional >> choice to have (Haskell and GMP offer them, for example). > > Wrapping overflow is just as bad as undefined behavior IMO. Do you know what undefined behavior is? It doesn't mean unspecified. > I cannot remember a single case of using signed integers where wrapping would make any sense. It often makes sense in codecs, hashing algorithms and cryptography. If you don't have clear bounds and don't want modular arithmetic, you need big integers. > And you lose some optimization opportunities. It's treated as undefined because there are more optimization opportunities that way. > So why not take the path of the rust memory management and enforce bounds > statically? It would need annotations on the types, like lifetimes, but it > would be very rusty. Like C but safe. Rust isn't supposed to be really hard to write. Complex dependent typing would From danielmicay at gmail.com Sun Jan 12 12:25:40 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 12 Jan 2014 15:25:40 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D2E6AA.7070403@isaac.cedarswampstudios.org> Message-ID: On Sun, Jan 12, 2014 at 2:09 PM, Owen Shepherd wrote: > > For implementing bignum arithmetic, this is obviously a point where a > "natural int" type would be best (probably the biggest which fits a single > register) If you plan on writing a competitive big integer library, then the integer size is the least of your worries. You're going to be using specialized instructions per-revision of different platforms not provided outside of inline assembly or per-platform LLVM intrinsics. From glaebhoerl at gmail.com Sun Jan 12 12:55:17 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 12 Jan 2014 21:55:17 +0100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke wrote: > I am not aware of an efficient way to provide > automatic-overflow-to-bignum semantics in a non-garbage-collected > language, without also imposing the burden of references/move > semantics/etc on users of small integers. I.e. integers, if they may > hold references to allocated memory can no longer sanely be considered > a simple value type, which doesn't seem like it'd be a good idea for > Rust. > > If there is a good solution to this, I'd love to find out about it. > This is a very good point. My thinking w.r.t. checking for overflow used to be that if you're taking the performance hit for it, you might as well expand to a big integer instead of failing, because if the use case is indexing into an array, then the bounds check will catch it, and in other use cases it's likely preferable. But checked integers are POD and big/expanding ones aren't, which is a big advantage for the former. All of this really makes me wish hardware supported overflow checking in an efficient manner natively. If it can throw an exception for divide by zero, then why not overflow? (...I expect someone will actually have an answer for this.) > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Jan 12 13:08:22 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 12 Jan 2014 16:08:22 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: On Sun, Jan 12, 2014 at 3:55 PM, G?bor Lehel wrote: > > > > On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke > wrote: >> >> I am not aware of an efficient way to provide >> automatic-overflow-to-bignum semantics in a non-garbage-collected >> language, without also imposing the burden of references/move >> semantics/etc on users of small integers. I.e. integers, if they may >> hold references to allocated memory can no longer sanely be considered >> a simple value type, which doesn't seem like it'd be a good idea for >> Rust. >> >> If there is a good solution to this, I'd love to find out about it. > > This is a very good point. My thinking w.r.t. checking for overflow used to > be that if you're taking the performance hit for it, you might as well > expand to a big integer instead of failing, because if the use case is > indexing into an array, then the bounds check will catch it, and in other > use cases it's likely preferable. An overflow check adds a branch and the pipeline serialization from reading the carry/overflow flag. Expanding to a big integer requires another branch. Both can be compiled in such a way that they are always predicted correctly, but it still adds very significant overhead. > But checked integers are POD and big/expanding ones aren't, which is a big > advantage for the former. In almost every case, the overflow-checked integer hitting the bound is still going to be a bug. An expanding type is actually higher-level. > All of this really makes me wish hardware supported overflow checking in an > efficient manner natively. If it can throw an exception for divide by zero, > then why not overflow? (...I expect someone will actually have an answer for > this.) Rust can't make use of this kind of CPU support, since it wants to use (Rust-specific) unwinding. From pwalton at mozilla.com Sun Jan 12 14:08:31 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 12 Jan 2014 14:08:31 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> Message-ID: <034226e8-9817-469d-9cd4-21e5805b101a@email.android.com> I think in theory we could arrange for the signal handler to trigger unwinding or use Windows SEH, which is zero cost on 64 bit AIUI. Daniel Micay wrote: >On Sun, Jan 12, 2014 at 3:55 PM, G?bor Lehel >wrote: >> >> >> >> On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke > >> wrote: >>> >>> I am not aware of an efficient way to provide >>> automatic-overflow-to-bignum semantics in a non-garbage-collected >>> language, without also imposing the burden of references/move >>> semantics/etc on users of small integers. I.e. integers, if they may >>> hold references to allocated memory can no longer sanely be >considered >>> a simple value type, which doesn't seem like it'd be a good idea for >>> Rust. >>> >>> If there is a good solution to this, I'd love to find out about it. >> >> This is a very good point. My thinking w.r.t. checking for overflow >used to >> be that if you're taking the performance hit for it, you might as >well >> expand to a big integer instead of failing, because if the use case >is >> indexing into an array, then the bounds check will catch it, and in >other >> use cases it's likely preferable. > >An overflow check adds a branch and the pipeline serialization from >reading the carry/overflow flag. Expanding to a big integer requires >another >branch. > >Both can be compiled in such a way that they are always predicted >correctly, but it still adds very significant overhead. > >> But checked integers are POD and big/expanding ones aren't, which is >a big >> advantage for the former. > >In almost every case, the overflow-checked integer hitting the bound >is still going to be a bug. An expanding type is actually >higher-level. > >> All of this really makes me wish hardware supported overflow checking >in an >> efficient manner natively. If it can throw an exception for divide by >zero, >> then why not overflow? (...I expect someone will actually have an >answer for >> this.) > >Rust can't make use of this kind of CPU support, since it wants to use >(Rust-specific) unwinding. >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From artella.coding at googlemail.com Sun Jan 12 15:13:53 2014 From: artella.coding at googlemail.com (Artella Coding) Date: Sun, 12 Jan 2014 23:13:53 +0000 Subject: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB Message-ID: Suppose I have the following program : ********************************************** //prog1.rs use std::rand::{task_rng, Rng}; fn main() { let names = ["Alice", "Bob", "Carol"]; for name in names.iter() { let v = task_rng().shuffle(~[1,2,3]); for num in v.iter() { println!("{:s} says: {:d}", *name, *num); } } } ********************************************** In previous versions of rust it was possible to put a breakpoint on "shuffle" e.g. One would first compile via : rustc -Z debug-info prog1.rs and then one could proceed to put a breakpoint on "shuffle" : gdb ./prog1 (gdb) break shuffle (gdb) run However now it doesn't seem possible to put a breakpoint on shuffle. Why is this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Sun Jan 12 17:01:43 2014 From: robert at ocallahan.org (Robert O'Callahan) Date: Mon, 13 Jan 2014 14:01:43 +1300 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D1DAD5.2080308@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> Message-ID: On Sun, Jan 12, 2014 at 12:59 PM, Patrick Walton wrote: > On 1/10/14 10:08 PM, Daniel Micay wrote: > >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. >> > > Of course it's useful. It prevents attackers from weaponizing > out-of-bounds reads and writes in unsafe code. > Yes. And as a browser developer, I still want trap-on-overflow by default in the browser if it can be cheap. Overflowing integer coordinates can lead to infinite loops and incorrect layout or rendering, the latter of which can occasionally have security implications. Task failure is better than both of those. Generally, the sooner we detect bugs and fail the more robust we will be against malicious input. Being able to harden the code against a common class of bugs without making the language any more complicated is very attractive to me. I examined Gecko's gfx module a while back and determined that the only adds and subtracts that *should* overflow were in hash functions, a miniscule fraction of the total. Adding crypto and codecs into the mix wouldn't make much difference. (You aren't going to write those in Rust without SIMD anyway.) Daniel's points about cost are interesting but there's a lot of things that could be tried before declaring the problem intractable. Since most Rust side effects commute with task failure, you could do a lot of trap code motion and coalescing. The absence of overflow lets the compiler reason more effectively about arithmetic, benefiting optimizations such as array bounds check elimination. Range analysis becomes very important so you want work at it harder. Etc. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaxwell at gmail.com Sun Jan 12 17:19:06 2014 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 12 Jan 2014 17:19:06 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D1F4B8.7040805@cantrip.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1CE72.8070003@cantrip.org> <52D1F4B8.7040805@cantrip.org> Message-ID: On Sat, Jan 11, 2014 at 5:49 PM, Nathan Myers wrote: > No one would complain about a built-in "i128" type. The thing > about a fixed-size type is that there are no implementation > choices to leak out. Overflowing an i128 variable is quite > difficult, and 128-bit operations are still lots faster than on > any variable-precision type. I could live with "int" == "i128". It's certainly harder to overflow a 128 bit type by accident, though I think you over-state it: iterating foo *= foo 128 times will overflow even if foo is initially just 1, but moreover overflow that arises by chance is not the only sort programs have to deal with: malicious parties trigger overflow to cause unexpected behavior. I think a bigger argument for range checked types is not related to how easy the overflow is to trigger but, rather, how likely it is that the software cannot actually handle it when it is triggered? the same problem with null pointers. In C a lot of software is not null safe, its difficulty to tell at a glance if any particular function is null safe, and difficult to tell if a function needs to be null safe, and (apparently) difficult for many to keep null safety in mind when writing software. "Surprise! this value can be null! Hope you weren't going to deference it!" is a lot like "Surprise! these integers can have crazy values! Hope you weren't going to square one of them". [Not that having a 128 bit type wouldn't be great since x86 has the lower and upper multiplies having a 128 bit type makes it easy to get access to 64x64->128 without using assembly. I just don't think adding larger types really makes a meaningful improvement with respect to safety... and the overhead is equal or higher than having a 64 bit type and a tag that indicates the the stored value is really a pointer to a multiprecision integer.] From danielmicay at gmail.com Sun Jan 12 17:22:43 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 12 Jan 2014 20:22:43 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> Message-ID: On Sun, Jan 12, 2014 at 8:01 PM, Robert O'Callahan wrote: > On Sun, Jan 12, 2014 at 12:59 PM, Patrick Walton > wrote: >> >> On 1/10/14 10:08 PM, Daniel Micay wrote: >>> >>> I don't think failure on overflow is very useful. It's still a bug if >>> you overflow when you don't intend it. >> >> >> Of course it's useful. It prevents attackers from weaponizing >> out-of-bounds reads and writes in unsafe code. > > > Yes. And as a browser developer, I still want trap-on-overflow by default in > the browser if it can be cheap. Overflowing integer coordinates can lead to > infinite loops and incorrect layout or rendering, the latter of which can > occasionally have security implications. Task failure is better than both of > those. Generally, the sooner we detect bugs and fail the more robust we will > be against malicious input. Being able to harden the code against a common > class of bugs without making the language any more complicated is very > attractive to me. -fsanitize=signed-integer-overflow: Signed integer overflow, including all the checks added by -ftrapv, and checking for overflow in signed division (INT_MIN / -1). Why not measure the impact of this on Firefox performance? We'll have a concrete answer about half of the picture (but not about the cost for unsigned or checks on overlong shifts and for division by zero). > Daniel's points about cost are interesting but there's a lot of things that > could be tried before declaring the problem intractable. Since most Rust > side effects commute with task failure, you could do a lot of trap code > motion and coalescing. The absence of overflow lets the compiler reason more > effectively about arithmetic, benefiting optimizations such as array bounds > check elimination. Range analysis becomes very important so you want work at > it harder. Etc. Inter-procedural optimization in LLVM can only eliminate dead code, propagate constants, inline/merge functions and bubble up effects. As far as I know, doing more takes way too long. Eliminating array bounds checks and reasoning about arithmetic just doesn't really happen. The best hope for an inner loop is for loop-vectorize/slp-vectorize to do their work, and they won't if there are overflow/carry checks. LLVM is designed to optimize C code, and deviating from that kind of code generation without losing a lot of performance means doing your own optimizations on your own intermediate format like Haskell. From pcwalton at mozilla.com Sun Jan 12 17:30:12 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 12 Jan 2014 17:30:12 -0800 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> Message-ID: <52D341A4.7060300@mozilla.com> On 1/12/14 5:22 PM, Daniel Micay wrote: > As far as I know, doing more takes way too long. Eliminating array > bounds checks and reasoning about arithmetic just doesn't really > happen. I think the jury is still out. See "A Fast and Low-Overhead Technique to Secure Programs Against Integer Overflows" by Rodrigues et al., CGO '2013: http://homepages.dcc.ufmg.br/~fernando/publications/papers/CGO13_raphael.pdf This has been implemented as an LLVM pass: http://code.google.com/p/range-analysis/ They cite a slowdown of merely 1.73% on the LLVM benchmark suite with their analysis, which is quite impressive. Given that range analysis can also eliminate bounds checks in Rust, I suspect that this is worth pursuing. That said I'm not sure we can gate 1.0 on this, since there's undoubtedly work needed to get this up to production quality. This is bleeding-edge stuff. However, I would personally definitely be interested in pursuing this post-1.0 for Servo and other apps that want to be hardened against overflows. Patrick From robert at ocallahan.org Sun Jan 12 17:53:41 2014 From: robert at ocallahan.org (Robert O'Callahan) Date: Mon, 13 Jan 2014 14:53:41 +1300 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> Message-ID: On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay wrote: > -fsanitize=signed-integer-overflow: Signed integer overflow, including > all the checks added by -ftrapv, and checking for overflow in signed > division (INT_MIN / -1). > > Why not measure the impact of this on Firefox performance? We'll have > a concrete answer about half of the picture (but not about the cost > for unsigned or checks on overlong shifts and for division by zero). > That would give us neither an upper bound on overhead (due to excluding unsigned), nor a lower bound (due to no range analysis or LLVM changes). But it might be interesting... Inter-procedural optimization in LLVM can only eliminate dead code, > propagate constants, inline/merge functions and bubble up effects. > > As far as I know, doing more takes way too long. Eliminating array > bounds checks and reasoning about arithmetic just doesn't really > happen. > So not even as good as Java and JS JITs? Sad. > The best hope for an inner loop is for loop-vectorize/slp-vectorize to > do their work, and they won't if there are overflow/carry checks. > > LLVM is designed to optimize C code, and deviating from that kind of > code generation without losing a lot of performance means doing your > own optimizations on your own intermediate format like Haskell. > I would rather not treat LLVM as immutable. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Jan 12 19:53:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 12 Jan 2014 22:53:58 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> Message-ID: @daniel, the GHC haskell IR predates LLVM, and theres actually some pretty nice examples of LLVM doing AMAZING optimization of bit fiddling haskell code (in fact, for any performance ratio, i can manufacture a natural bit fiddlign example where ghc -fllvm is that much better than ghc -fasm for bit fiddling code currently). Mind you this only happens in bit fiddling code where LLVM can basically cancel out the composition of long sequences of bit fiddling of the form mortonShuffle . inverseMortonShuffle . mortonShuffle . inverseMortonShuffle, llvm is able to take the GHC IR and algebraically turn it into a No Op function. That said, I definitely think theres ways LLVM can improve support for langs that aren't C, and I've certainly gotten the impression LLVM devs are open to contributions that leave everyone better off. On Sun, Jan 12, 2014 at 8:53 PM, Robert O'Callahan wrote: > On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay wrote: > >> -fsanitize=signed-integer-overflow: Signed integer overflow, including >> all the checks added by -ftrapv, and checking for overflow in signed >> division (INT_MIN / -1). >> >> Why not measure the impact of this on Firefox performance? We'll have >> a concrete answer about half of the picture (but not about the cost >> for unsigned or checks on overlong shifts and for division by zero). >> > > That would give us neither an upper bound on overhead (due to excluding > unsigned), nor a lower bound (due to no range analysis or LLVM changes). > But it might be interesting... > > Inter-procedural optimization in LLVM can only eliminate dead code, >> propagate constants, inline/merge functions and bubble up effects. >> >> As far as I know, doing more takes way too long. Eliminating array >> bounds checks and reasoning about arithmetic just doesn't really >> happen. >> > > So not even as good as Java and JS JITs? Sad. > > >> The best hope for an inner loop is for loop-vectorize/slp-vectorize to >> do their work, and they won't if there are overflow/carry checks. >> >> LLVM is designed to optimize C code, and deviating from that kind of >> code generation without losing a lot of performance means doing your >> own optimizations on your own intermediate format like Haskell. >> > > I would rather not treat LLVM as immutable. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.de Sun Jan 12 23:42:53 2014 From: michaelwoerister at posteo.de (Michael Woerister) Date: Mon, 13 Jan 2014 08:42:53 +0100 Subject: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB In-Reply-To: References: Message-ID: <52D398FD.7070408@posteo.de> Hi, the `break` command can be a bit particular where function names are concerned, especially when namespaces and generics are involved. The correct full name of the shuffle method would be something like `std::rand::TaskRng::shuffle` (there is a seperate function for every set of concrete type parameters, so `shuffle` would be different from `shuffle`). My recommendation here is to either * set the breakpoint using line numbers: break prog.rs:7 * or use the `rbreak` command which takes a regular expression as argument, that is, `rbreak shuffle` will match any function containing the string "shuffle" in its name. Don't be shy to ask further questions if you have any :) -Michael On 13.01.2014 00:13, Artella Coding wrote: > Suppose I have the following program : > > ********************************************** > //prog1.rs > use std::rand::{task_rng, Rng}; > fn main() { > let names = ["Alice", "Bob", "Carol"]; > for name in names.iter() { > let v = task_rng().shuffle(~[1,2,3]); > for num in v.iter() { > println!("{:s} says: {:d}", *name, *num); > } > } > } > ********************************************** > > In previous versions of rust it was possible to put > a breakpoint on "shuffle" e.g. > > One would first compile via : > > rustc -Z debug-info prog1.rs > > and then one could proceed to put a breakpoint on "shuffle" : > > gdb ./prog1 > (gdb) break shuffle > (gdb) run > > However now it doesn't seem possible to put a breakpoint on shuffle. > Why is this? Thanks. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Mon Jan 13 02:43:26 2014 From: gaetan at xeberon.net (Gaetan) Date: Mon, 13 Jan 2014 11:43:26 +0100 Subject: [rust-dev] Call for central external packages repository Message-ID: Hi I know this question has been debated, however I'd like to highly recommend to give a clean infrastructure to register, list, search and describe external libraries developed by everyone. For instance, how do I know which http server lib should I use for rust 0.9? This mailing list is quite good for announcing new package, but not for find existing project that might have solved a given problem before me. rust-ci -------- This is the main candidate for this job, however I find it quite difficult to find which project does what. It miss a "one line project description" column. Its main purpose seem to watch for this set of projects still compile against the master git branch, but there are other lib that are not listed here. I would recommend a central repository web site, working like pypi or other community based repo, that would stimulate user contribution. Such central repository would provide the following features: - hierarchical project organisation (look at here ) - provide clean forms to submit, review, publish, vote project - clealy display which version of rust compiler (0.8, 0.9, master,...) this lib is validated. For master, this would be linked to rust-ci. I also like the idea of having automatic rust-ci validation for rust 0.8, 0.9,... Maybe with several level of validation: compile validated, peer/administrator validated, recommended,... - good search form. This is how users look for a given project - popular project. I tend to choose a project over its popularity. The more "popular" a project is, or the more downloads count a lib have, the more I think it will be actively maintained or more stable than the others. - clear project dependency listing - be promoted by rust homepage (repo.rust.org? rustpkg.rust.org,...?), so any lambda user can easy find it At first sight, I think we could just extending rust-ci to do this, reoriented for package listing for a given rust version, by adding new pages "package index for 0.9" with just a project name column ("rust-http" and not "chris-morgan/rust-http ") and a description column (extracted from github project description?.. this also force to have to be on github for any project?). And what about tarball or non github project? What do you think about this idea? I am interested on working on this matter, but would like to have your opinion on it. Thanks ----- Gaetan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansjorg at gmail.com Mon Jan 13 03:09:22 2014 From: hansjorg at gmail.com (=?ISO-8859-1?Q?Hans_J=F8rgen_Hoel?=) Date: Mon, 13 Jan 2014 12:09:22 +0100 Subject: [rust-dev] Call for central external packages repository In-Reply-To: References: Message-ID: Hi, Regarding rust-ci, I'm about to deploy some changes for it sometime in the next few days. Changes will include: - project editing enabled (including removal of projects :)) - possibility for adding categories to projects and a category based index - documentation upload from Travis CI builds (by adding two lines to the .travis.yml) I've also started working on search which would index project descriptions, uploaded documentation and sources. Source for the webapp will be available on GitHub soon if anyone is interested in collaborating. Regards, Hans J?rgen On 13 January 2014 11:43, Gaetan wrote: > Hi > > I know this question has been debated, however I'd like to highly > recommend to give a clean infrastructure to register, list, search and > describe external libraries developed by everyone. > > For instance, how do I know which http server lib should I use for rust > 0.9? > > This mailing list is quite good for announcing new package, but not for > find existing project that might have solved a given problem before me. > > rust-ci > -------- > > This is the main candidate for this job, however I find it quite difficult > to find which project does what. It miss a "one line project description" > column. Its main purpose seem to watch for this set of projects still > compile against the master git branch, but there are other lib that are not > listed here. > > I would recommend a central repository web site, working like pypi or > other community based repo, that would stimulate user contribution. > > Such central repository would provide the following features: > - hierarchical project organisation (look at here > ) > - provide clean forms to submit, review, publish, vote project > - clealy display which version of rust compiler (0.8, 0.9, master,...) > this lib is validated. For master, this would be linked to rust-ci. I also > like the idea of having automatic rust-ci validation for rust 0.8, 0.9,... > Maybe with several level of validation: compile validated, > peer/administrator validated, recommended,... > - good search form. This is how users look for a given project > - popular project. I tend to choose a project over its popularity. The > more "popular" a project is, or the more downloads count a lib have, the > more I think it will be actively maintained or more stable than the others. > - clear project dependency listing > - be promoted by rust homepage (repo.rust.org? rustpkg.rust.org,...?), so > any lambda user can easy find it > > At first sight, I think we could just extending rust-ci to do this, > reoriented for package listing for a given rust version, by adding new > pages "package index for 0.9" with just a project name column ("rust-http" > and not "chris-morgan/rust-http") > and a description column (extracted from github project description?.. this > also force to have to be on github for any project?). And what about > tarball or non github project? > > What do you think about this idea? I am interested on working on this > matter, but would like to have your opinion on it. > > Thanks > ----- > Gaetan > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Mon Jan 13 03:19:02 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Mon, 13 Jan 2014 22:19:02 +1100 Subject: [rust-dev] Call for central external packages repository In-Reply-To: References: Message-ID: <52D3CBA6.6090409@gmail.com> On 13/01/14 22:09, Hans J?rgen Hoel wrote: > Hi, > > Regarding rust-ci, I'm about to deploy some changes for it sometime in > the next few days. > > Changes will include: > > - project editing enabled (including removal of projects :)) > - possibility for adding categories to projects and a category based index > - documentation upload from Travis CI builds (by adding two lines to > the .travis.yml) Woah, woah. This sounds awesome. Huon > > I've also started working on search which would index project > descriptions, uploaded documentation and sources. > > Source for the webapp will be available on GitHub soon if anyone is > interested in collaborating. > > Regards, > > Hans J?rgen > > > On 13 January 2014 11:43, Gaetan > wrote: > > Hi > > I know this question has been debated, however I'd like to highly > recommend to give a clean infrastructure to register, list, search > and describe external libraries developed by everyone. > > For instance, how do I know which http server lib should I use for > rust 0.9? > > This mailing list is quite good for announcing new package, but > not for find existing project that might have solved a given > problem before me. > > rust-ci > -------- > > This is the main candidate for this job, however I find it quite > difficult to find which project does what. It miss a "one line > project description" column. Its main purpose seem to watch for > this set of projects still compile against the master git branch, > but there are other lib that are not listed here. > > I would recommend a central repository web site, working like pypi > or other community based repo, that would stimulate user contribution. > > Such central repository would provide the following features: > - hierarchical project organisation (look at here > ) > - provide clean forms to submit, review, publish, vote project > - clealy display which version of rust compiler (0.8, 0.9, > master,...) this lib is validated. For master, this would be > linked to rust-ci. I also like the idea of having automatic > rust-ci validation for rust 0.8, 0.9,... Maybe with several level > of validation: compile validated, peer/administrator validated, > recommended,... > - good search form. This is how users look for a given project > - popular project. I tend to choose a project over its popularity. > The more "popular" a project is, or the more downloads count a lib > have, the more I think it will be actively maintained or more > stable than the others. > - clear project dependency listing > - be promoted by rust homepage (repo.rust.org > ? rustpkg.rust.org > ,...?), so any lambda user can easy find it > > At first sight, I think we could just extending rust-ci to do > this, reoriented for package listing for a given rust version, by > adding new pages "package index for 0.9" with just a project name > column ("rust-http" and not "chris-morgan/rust-http > ") and a description > column (extracted from github project description?.. this also > force to have to be on github for any project?). And what about > tarball or non github project? > > What do you think about this idea? I am interested on working on > this matter, but would like to have your opinion on it. > > Thanks > ----- > Gaetan > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Mon Jan 13 03:42:32 2014 From: robert at ocallahan.org (Robert O'Callahan) Date: Tue, 14 Jan 2014 00:42:32 +1300 Subject: [rust-dev] Impact of -ftrapv on Firefox Message-ID: On Mon, Jan 13, 2014 at 2:53 PM, Robert O'Callahan wrote: > On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay wrote: > >> -fsanitize=signed-integer-overflow: Signed integer overflow, including >> all the checks added by -ftrapv, and checking for overflow in signed >> division (INT_MIN / -1). >> >> Why not measure the impact of this on Firefox performance? We'll have >> a concrete answer about half of the picture (but not about the cost >> for unsigned or checks on overlong shifts and for division by zero). >> > > That would give us neither an upper bound on overhead (due to excluding > unsigned), nor a lower bound (due to no range analysis or LLVM changes). > But it might be interesting... > Just for fun I did a Firefox build with -ftrapv. The most surprising thing is that the browser actually worked, on Linux64 at least. Not so much on Linux32 and Mac. https://tbpl.mozilla.org/?tree=Try&rev=45b9932ca819 The Talos performance results aren't exactly science, but it looks like the performance impact is negligible. For example, tp5o (page load time test) reported 285, central is around 280 (lower is better). Dromaeo-CSS reported 5408, whereas central is around 5500 (but noisy) (higher is better). Like I said, I don't really know what this means, but it sounds hopeful to me. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaebhoerl at gmail.com Mon Jan 13 03:50:59 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Mon, 13 Jan 2014 12:50:59 +0100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <52D341A4.7060300@mozilla.com> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <52D0DF1D.1080805@gmail.com> <52D1DAD5.2080308@mozilla.com> <52D341A4.7060300@mozilla.com> Message-ID: Would it be accurate to say that the only significant changes required at the language level for all this would be not having a default integer type, and then probably polymorphic number literals a la Haskell? And that the rest of this discussion is only about policy and ergonomics? On Mon, Jan 13, 2014 at 2:30 AM, Patrick Walton wrote: > On 1/12/14 5:22 PM, Daniel Micay wrote: > >> As far as I know, doing more takes way too long. Eliminating array >> bounds checks and reasoning about arithmetic just doesn't really >> happen. >> > > I think the jury is still out. See "A Fast and Low-Overhead Technique to > Secure Programs Against Integer Overflows" by Rodrigues et al., CGO '2013: > > http://homepages.dcc.ufmg.br/~fernando/publications/papers/ > CGO13_raphael.pdf > > This has been implemented as an LLVM pass: > > http://code.google.com/p/range-analysis/ > > They cite a slowdown of merely 1.73% on the LLVM benchmark suite with > their analysis, which is quite impressive. Given that range analysis can > also eliminate bounds checks in Rust, I suspect that this is worth pursuing. > > That said I'm not sure we can gate 1.0 on this, since there's undoubtedly > work needed to get this up to production quality. This is bleeding-edge > stuff. However, I would personally definitely be interested in pursuing > this post-1.0 for Servo and other apps that want to be hardened against > overflows. > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Mon Jan 13 03:52:47 2014 From: jon.mb at proinbox.com (John Mija) Date: Mon, 13 Jan 2014 11:52:47 +0000 Subject: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB In-Reply-To: <52D398FD.7070408@posteo.de> References: <52D398FD.7070408@posteo.de> Message-ID: <52D3D38F.4000104@proinbox.com> There is a web front-end for gdb to debug applications in Go, C and C++. I'm supposed that it also could be used to debug Rust apps. https://github.com/sirnewton01/godbg El 13/01/14 07:42, Michael Woerister escribi?: > Hi, > the `break` command can be a bit particular where function names are > concerned, especially when namespaces and generics are involved. The > correct full name of the shuffle method would be something like > `std::rand::TaskRng::shuffle` (there is a seperate function for > every set of concrete type parameters, so `shuffle` would be > different from `shuffle`). > > My recommendation here is to either > * set the breakpoint using line numbers: break prog.rs:7 > * or use the `rbreak` command which takes a regular expression as > argument, that is, `rbreak shuffle` will match any function containing > the string "shuffle" in its name. > > Don't be shy to ask further questions if you have any :) > > -Michael > > On 13.01.2014 00:13, Artella Coding wrote: >> Suppose I have the following program : >> >> ********************************************** >> //prog1.rs >> use std::rand::{task_rng, Rng}; >> fn main() { >> let names = ["Alice", "Bob", "Carol"]; >> for name in names.iter() { >> let v = task_rng().shuffle(~[1,2,3]); >> for num in v.iter() { >> println!("{:s} says: {:d}", *name, *num); >> } >> } >> } >> ********************************************** >> >> In previous versions of rust it was possible to put >> a breakpoint on "shuffle" e.g. >> >> One would first compile via : >> >> rustc -Z debug-info prog1.rs >> >> and then one could proceed to put a breakpoint on "shuffle" : >> >> gdb ./prog1 >> (gdb) break shuffle >> (gdb) run >> >> However now it doesn't seem possible to put a breakpoint on shuffle. >> Why is this? Thanks. >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From gaetan at xeberon.net Mon Jan 13 04:49:32 2014 From: gaetan at xeberon.net (Gaetan) Date: Mon, 13 Jan 2014 13:49:32 +0100 Subject: [rust-dev] Call for central external packages repository In-Reply-To: <52D3CBA6.6090409@gmail.com> References: <52D3CBA6.6090409@gmail.com> Message-ID: Sounds great. Can you replace the "last commit msg" by "project description"? I think this much more relevant. ----- Gaetan 2014/1/13 Huon Wilson > On 13/01/14 22:09, Hans J?rgen Hoel wrote: > > Hi, > > Regarding rust-ci, I'm about to deploy some changes for it sometime in > the next few days. > > Changes will include: > > - project editing enabled (including removal of projects :)) > - possibility for adding categories to projects and a category based index > - documentation upload from Travis CI builds (by adding two lines to the > .travis.yml) > > > Woah, woah. This sounds awesome. > > > > Huon > > > > > I've also started working on search which would index project > descriptions, uploaded documentation and sources. > > Source for the webapp will be available on GitHub soon if anyone is > interested in collaborating. > > Regards, > > Hans J?rgen > > > On 13 January 2014 11:43, Gaetan wrote: > >> Hi >> >> I know this question has been debated, however I'd like to highly >> recommend to give a clean infrastructure to register, list, search and >> describe external libraries developed by everyone. >> >> For instance, how do I know which http server lib should I use for rust >> 0.9? >> >> This mailing list is quite good for announcing new package, but not for >> find existing project that might have solved a given problem before me. >> >> rust-ci >> -------- >> >> This is the main candidate for this job, however I find it quite >> difficult to find which project does what. It miss a "one line project >> description" column. Its main purpose seem to watch for this set of >> projects still compile against the master git branch, but there are other >> lib that are not listed here. >> >> I would recommend a central repository web site, working like pypi or >> other community based repo, that would stimulate user contribution. >> >> Such central repository would provide the following features: >> - hierarchical project organisation (look at here >> ) >> - provide clean forms to submit, review, publish, vote project >> - clealy display which version of rust compiler (0.8, 0.9, master,...) >> this lib is validated. For master, this would be linked to rust-ci. I also >> like the idea of having automatic rust-ci validation for rust 0.8, 0.9,... >> Maybe with several level of validation: compile validated, >> peer/administrator validated, recommended,... >> - good search form. This is how users look for a given project >> - popular project. I tend to choose a project over its popularity. The >> more "popular" a project is, or the more downloads count a lib have, the >> more I think it will be actively maintained or more stable than the others. >> - clear project dependency listing >> - be promoted by rust homepage (repo.rust.org? rustpkg.rust.org,...?), >> so any lambda user can easy find it >> >> At first sight, I think we could just extending rust-ci to do this, >> reoriented for package listing for a given rust version, by adding new >> pages "package index for 0.9" with just a project name column ("rust-http" >> and not "chris-morgan/rust-http") >> and a description column (extracted from github project description?.. this >> also force to have to be on github for any project?). And what about >> tarball or non github project? >> >> What do you think about this idea? I am interested on working on this >> matter, but would like to have your opinion on it. >> >> Thanks >> ----- >> Gaetan >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Mon Jan 13 05:46:20 2014 From: gaetan at xeberon.net (Gaetan) Date: Mon, 13 Jan 2014 14:46:20 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: what about using a well known build system as a transition to a custom, rust-written build tool? If this is not planned in rust roadmap, I can't see how this will work. For me it's the same old dilemna: write my tool or use an existing one? Same for doc... should we use sphinx or write a customized tool? ----- Gaetan 2014/1/11 George Makrydakis > There is little reason to believe that having a build system in Rust would > make It harder for people to package. > > I do understand the predependecy argument, but the Rust compiler itself in > order to compile has predependencies anyway, as does any similar project. > Therefore the decisional weight of choosing a non - rust based solution > over a rust one because Debian packagers have problems packaging a compiler > is not adequately justified. > > Using a well known build system as a means to appeal to programmers is > seemingly an advantage, but it does not exonerate them from having to be > competent in Rust before they write useful programs. And that has a > learning curve superior to that of a build system. > > As for boost's jam I have nothing to say other than boost having its own > build system makes it easy for boost first; this does not mean that their > needs are those of everybody else and boost is a library, not a programming > language itself. So, again, a decision based on picking a popular solution > on the basis of such a comparison, has flawed background. > > Lastly, imagine the irony of Rust proposing to use python, c, c++ based > build tools for simple packages. That would make packagers more frustrated > because of a wider set of dependecies. While end users would have to also > deal with a known system, its eventual inadequacies could not be met > directly by Rust devs unless they start amending that system in order to > deal with them. Therefore, maintenance overhead is inescapable either way, > with the pessimization of relying in another nom - Rust project in order to > make it worth your while to enjoy programming in Rust. > > The only valid argument against having a build system proposed as the > official, defacto, cross - platform way of building rust packages written > in rust is its development and maintenance overhead for the rust core team > itself. > > That problem is easily circumvented by not proposing one right now and > letting it to the end developer decide. If however an official build system > is to be proposed, Rust developers merit having it done on their own > platform, thus proving rust's worth. It is 2014 after all. > > G. > > > > Lee Braiden wrote: > >On 10/01/14 08:16, Gaetan wrote: > >> > >> I am not in favor of a customized build system. For instance boost > >> library use their jam build system, and i never figured how to use it > > > >> in my projects. > >> > >> I push to use standard and well proved build system like cmake or > >> scons, at least for major components. This would give a nice example > >> of how to use it in any projects. > >> > > > >I'd agree with that on both counts: the principle of using something > >standard, and the two recommendations. > > > >CMake would probably get my vote, because it's not so much a build > >tool, > >as a meta tool for whichever system you prefer, so it would fit in well > > > >with various platform-specific IDEs, unusual platforms (android, > >embedded, ...), etc. That said, scons is also a strong contender, and > >which of the two is more open to integrating patches and working with > >new languages is very much worth considering. > > > >I think Rust will be contributing to the wider community by lending its > > > >support (and patches) to a common, modern build system, AND it will get > > > >something back in terms of users who already know the build system. > > > > > >> On Friday, January 10, 2014, George Makrydakis wrote: > >> > >> > >> Hello, > >> > >> Having a build system entirely dependent of Rust alone, would > >> make the entire experience in deploying the language > >extremely > >> cohere. The only counter - argument is indeed that it would > >> require some work to get this to fruition. I would like to > >> know if this has any chance of getting priority soon enough. > >> > > > >Bear in mind that Debian are having a lot of issues packaging Rust > >already, because it self-compiles. If the build tool also had a Rust > >pre-dependency, that would be a big step backwards. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhasse at gmail.com Mon Jan 13 06:46:43 2014 From: jhasse at gmail.com (Jan Niklas Hasse) Date: Mon, 13 Jan 2014 15:46:43 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: Message-ID: 2014/1/10 Corey Richardson : > 3. Write a build system in Rust. > > This would take care of everything for us, using ourselves. We'd have > a small script fetch the snapshot and build the build system, and then > hand off the rest of the build to it. This has the advantage of one > less build-time dependency, but the disadvantage that it's going to be > a lot of work. This could also potentially output tup, ninja[3], or > another form of build script after taking configuration options and > so-forth. It could also integrate with librustc for smart handling of > comments-or-test-only changes, an issue near to my heart[4]. This > build system could potentially be rustpkg, but as I understand it the > current idea is to *remove* rustpkg's ability as a build system and > keep it as a package manager. (At least, that is what I've understood > of recent discussion; this could be wrong.) Do you have any links of those discussions? I'm new to the mailing list. IMHO rustpkg should keep the ability of a build system. Lots of work has already been put into it and why rewrite that? I think this rust-written build tool should be rustpkg. From irrequietus at gmail.com Mon Jan 13 07:30:22 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Mon, 13 Jan 2014 17:30:22 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: Several lengthy emails have full argumentation in supporting that as an interim solution given the current status of Rust itself. It is the adoption of a third party tool, not written in rust, as the defacto standard to use with official blessing, that should be discarded for reasons already discussed. Again, note that this rather long thread is about discussing in the end what the official stance should be. There is no valid reason other than lack of manpower and / or language immaturity for having to depend on ruby, python, autotools, cmake or whatever else in order to build rust software. Is Rust capable, as a systems language, of having a build system in Rust for Rust, or it should depend on other languages, *officially* for such a thing? Personal preferences matter up to a point, but no more. Gaetan wrote: >what about using a well known build system as a transition to a custom, >rust-written build tool? If this is not planned in rust roadmap, I >can't >see how this will work. > >For me it's the same old dilemna: write my tool or use an existing one? >Same for doc... should we use sphinx or write a customized tool? > >----- >Gaetan > > > >2014/1/11 George Makrydakis > >> There is little reason to believe that having a build system in Rust >would >> make It harder for people to package. >> >> I do understand the predependecy argument, but the Rust compiler >itself in >> order to compile has predependencies anyway, as does any similar >project. >> Therefore the decisional weight of choosing a non - rust based >solution >> over a rust one because Debian packagers have problems packaging a >compiler >> is not adequately justified. >> >> Using a well known build system as a means to appeal to programmers >is >> seemingly an advantage, but it does not exonerate them from having to >be >> competent in Rust before they write useful programs. And that has a >> learning curve superior to that of a build system. >> >> As for boost's jam I have nothing to say other than boost having its >own >> build system makes it easy for boost first; this does not mean that >their >> needs are those of everybody else and boost is a library, not a >programming >> language itself. So, again, a decision based on picking a popular >solution >> on the basis of such a comparison, has flawed background. >> >> Lastly, imagine the irony of Rust proposing to use python, c, c++ >based >> build tools for simple packages. That would make packagers more >frustrated >> because of a wider set of dependecies. While end users would have to >also >> deal with a known system, its eventual inadequacies could not be met >> directly by Rust devs unless they start amending that system in order >to >> deal with them. Therefore, maintenance overhead is inescapable either >way, >> with the pessimization of relying in another nom - Rust project in >order to >> make it worth your while to enjoy programming in Rust. >> >> The only valid argument against having a build system proposed as the >> official, defacto, cross - platform way of building rust packages >written >> in rust is its development and maintenance overhead for the rust core >team >> itself. >> >> That problem is easily circumvented by not proposing one right now >and >> letting it to the end developer decide. If however an official build >system >> is to be proposed, Rust developers merit having it done on their own >> platform, thus proving rust's worth. It is 2014 after all. >> >> G. >> >> >> >> Lee Braiden wrote: >> >On 10/01/14 08:16, Gaetan wrote: >> >> >> >> I am not in favor of a customized build system. For instance boost >> >> library use their jam build system, and i never figured how to use >it >> > >> >> in my projects. >> >> >> >> I push to use standard and well proved build system like cmake or >> >> scons, at least for major components. This would give a nice >example >> >> of how to use it in any projects. >> >> >> > >> >I'd agree with that on both counts: the principle of using something >> >standard, and the two recommendations. >> > >> >CMake would probably get my vote, because it's not so much a build >> >tool, >> >as a meta tool for whichever system you prefer, so it would fit in >well >> > >> >with various platform-specific IDEs, unusual platforms (android, >> >embedded, ...), etc. That said, scons is also a strong contender, >and >> >which of the two is more open to integrating patches and working >with >> >new languages is very much worth considering. >> > >> >I think Rust will be contributing to the wider community by lending >its >> > >> >support (and patches) to a common, modern build system, AND it will >get >> > >> >something back in terms of users who already know the build system. >> > >> > >> >> On Friday, January 10, 2014, George Makrydakis wrote: >> >> >> >> >> >> Hello, >> >> >> >> Having a build system entirely dependent of Rust alone, >would >> >> make the entire experience in deploying the language >> >extremely >> >> cohere. The only counter - argument is indeed that it >would >> >> require some work to get this to fruition. I would like to >> >> know if this has any chance of getting priority soon >enough. >> >> >> > >> >Bear in mind that Debian are having a lot of issues packaging Rust >> >already, because it self-compiles. If the build tool also had a >Rust >> >pre-dependency, that would be a big step backwards. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Jan 13 09:08:02 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 13 Jan 2014 11:08:02 -0600 Subject: [rust-dev] RFC: "A 30 minute introduction to Rust" Message-ID: Also posted to my blog: http://words.steveklabnik.com/a-30-minute-introduction-to-rust I've just kept this in Markdown even though the email is in plain text, should still be easy on the eyes. I recently gave a [proposal for Rust's documentation](https://air.mozilla.org/rust-meetup-december-2013/). An important component of my overall proposal is a short, simple introduction for people who may have heard of Rust, so that they can figure out if Rust is right for them. The other day, I saw [this excellent presentation](http://www.youtube.com/watch?v=gfCtbGiHcg0), and thought it might serve as a great basis for this introduction. Consider this an RFC for such an introduction. Feedback very welcome. If you all like it, I'll submit it to our documentation. --------------------------------------------------------------------- Rust is a systems programming language that focuses on strong compile-time correctness guarantees. It improves upon the ideas other systems languages like C++, D, and Cyclone by providing very strong guarantees and explicit control over the life cycle of memory. Strong memory guarantees make writing correct concurrent Rust code easier than in other languages. This might sound very complex, but it's easier than it sounds! This tutorial will give you an idea of what Rust is like in about thirty minutes. It expects that you're at least vaguely familiar with a previous 'curly brace' language. The concepts are more important than the syntax, so don't worry if you don't get every last detail: the [tutorial](http://static.rust-lang.org/doc/master/tutorial.html) can help you out with that later. Let's talk about the most important concept in Rust, "ownership," and its implications on a task that programmers usually find very difficult: concurrency. ## Ownership Ownership is central to Rust, and is one of its more interesting and unique features. "Ownership" refers to which parts of your code are allowed to modify various parts of memory. Let's start by looking at some C++ code: ``` int *dangling(void) { int i = 1234; return &i; } int add_one(void) { int *num = dangling(); return *num + 1; } ``` This function allocates an integer on the stack, and stores it in a variable, `i`. It then returns a reference to the variable `i`. There's just one problem: stack memory becomes invalid when the function returns. This means that in the second line of `add_one`, `num` points to some garbage values, and we won't get the effect that we want. While this is a trivial example, it can happen quite often in C++ code. There's a similar problem when memory on the heap is allocated with `malloc` (or `new`), then freed with `free` (or `delete`), yet your code attempts to do something with the pointer to that memory. More modern C++ uses RAII with constructors/destructors, but it amounts to the same thing. This problem is called a 'dangling pointer,' and it's not possible to write Rust code that has it. Let's try: ``` fn dangling() -> &int { let i = 1234; return &i; } fn add_one() -> int { let num = dangling(); return *num + 1; } ``` When you try to compile this program, you'll get an interesting (and long) error message: ``` temp.rs:3:11: 3:13 error: borrowed value does not live long enough temp.rs:3 return &i; temp.rs:1:22: 4:1 note: borrowed pointer must be valid for the anonymous lifetime #1 defined on the block at 1:22... temp.rs:1 fn dangling() -> &int { temp.rs:2 let i = 1234; temp.rs:3 return &i; temp.rs:4 } temp.rs:1:22: 4:1 note: ...but borrowed value is only valid for the block at 1:22 temp.rs:1 fn dangling() -> &int { temp.rs:2 let i = 1234; temp.rs:3 return &i; temp.rs:4 } error: aborting due to previous error ``` In order to fully understand this error message, we need to talk about what it means to "own" something. So for now, let's just accept that Rust will not allow us to write code with a dangling pointer, and we'll come back to this code once we understand ownership. Let's forget about programming for a second and talk about books. I like to read physical books, and sometimes I really like one and tell my friends they should read it. While I'm reading my book, I own it: the book is in my possession. When I loan the book out to someone else for a while, they "borrow" it from me. And when you borrow a book, it's for a certain period of time, and then you give it back to me, and I own it again. Right? This concept applies directly to Rust code as well: some code "owns" a particular pointer to memory. It's the sole owner of that pointer. It can also lend that memory out to some other code for a while: the code "borrows" it. It borrows it for a certain period of time, called a "lifetime." That's all there is to it. That doesn't seem so hard, right? Let's go back to that error message: `error: borrowed value does not live long enough`. We tried to loan out a particular variable, `i`, using Rust's borrowed pointers: the `&`. But Rust knew that the variable would be invalid after the function returns, and so it tells us that: `borrowed pointer must be valid for the anonymous lifetime #1... but borrowed value is only valid for the block`. Neat! That's a great example for stack memory, but what about heap memory? Rust has a second kind of pointer, a 'unique' pointer, that you can create with a `~`. Check it out: ``` fn dangling() -> ~int { let i = ~1234; return i; } fn add_one() -> int { let num = dangling(); return *num + 1; } ``` This code will successfully compile. Note that instead of a stack allocated `1234`, we use an owned pointer to that value instead: `~1234`. You can roughly compare these two lines: ``` // rust let i = ~1234; // C++ int *i = new int; *i = 1234; ``` Rust is able to infer the size of the type, then allocates the correct amount of memory and sets it to the value you asked for. This means that it's impossible to allocate uninitialized memory: Rust does not have the concept of null. Hooray! There's one other difference between this line of Rust and the C++: The Rust compiler also figures out the lifetime of `i`, and then inserts a corresponding `free` call after it's invalid, like a destructor in C++. You get all of the benefits of manually allocated heap memory without having to do all the bookkeeping yourself. Furthermore, all of this checking is done at compile time, so there's no runtime overhead. You'll get (basically) the exact same code that you'd get if you wrote the correct C++, but it's impossible to write the incorrect version, thanks to the compiler. You've seen one way that ownership and lifetimes are useful to prevent code that would normally be dangerous in a less-strict language, but let's talk about another: concurrency. ## Concurrency Concurrency is an incredibly hot topic in the software world right now. It's always been an interesting area of study for computer scientists, but as usage of the Internet explodes, people are looking to improve the number of users a given service can handle. Concurrency is one way of achieving this goal. There is a pretty big drawback to concurrent code, though: it can be hard to reason about, because it is non-deterministic. There are a few different approaches to writing good concurrent code, but let's talk about how Rust's notions of ownership and lifetimes can assist with achieving correct but concurrent code. First, let's go over a simple concurrency example in Rust. Rust allows you to spin up 'tasks,' which are lightweight, 'green' threads. These tasks do not have any shared memory, and so, we communicate between tasks with a 'channel'. Like this: ``` fn main() { let numbers = [1,2,3]; let (port, chan) = Chan::new(); chan.send(numbers); do spawn { let numbers = port.recv(); println!("{:d}", numbers[0]); } } ``` In this example, we create a vector of numbers. We then make a new `Chan`, which is the name of the package Rust implements channels with. This returns two different ends of the channel: a channel and a port. You send data into the channel end, and it comes out the port end. The `spawn` function spins up a new task. As you can see in the code, we call `port.recv()` (short for 'receive') inside of the new task, and we call `chan.send()` outside, passing in our vector. We then print the first element of the vector. This works out because Rust copies the vector when it is sent through the channel. That way, if it were mutable, there wouldn't be a race condition. However, if we're making a lot of tasks, or if our data is very large, making a copy for each task inflates our memory usage with no real benefit. Enter Arc. Arc stands for 'atomically reference counted,' and it's a way to share immutable data between multiple tasks. Here's some code: ``` extern mod extra; use extra::arc::Arc; fn main() { let numbers = [1,2,3]; let numbers_arc = Arc::new(numbers); for num in range(0, 3) { let (port, chan) = Chan::new(); chan.send(numbers_arc.clone()); do spawn { let local_arc = port.recv(); let task_numbers = local_arc.get(); println!("{:d}", task_numbers[num]); } } } ``` This is very similar to the code we had before, except now we loop three times, making three tasks, and sending an `Arc` between them. `Arc::new` creates a new Arc, `.clone()` makes a new reference to that Arc, and `.get()` gets the value out of the Arc. So we make a new reference for each task, send that reference down the channel, and then use the reference to print out a number. Now we're not copying our vector. Arcs are great for immutable data, but what about mutable data? Shared mutable state is the bane of the concurrent programmer. You can use a mutex to protect shared mutable state, but if you forget to acquire the mutex, bad things can happen. Rust provides a tool for shared mutable state: `RWArc`. This variant of an Arc allows the contents of the Arc to be mutated. Check it out: ``` extern mod extra; use extra::arc::RWArc; fn main() { let numbers = [1,2,3]; let numbers_arc = RWArc::new(numbers); for num in range(0, 3) { let (port, chan) = Chan::new(); chan.send(numbers_arc.clone()); do spawn { let local_arc = port.recv(); local_arc.write(|nums| { nums[num] += 1 }); local_arc.read(|nums| { println!("{:d}", nums[num]); }) } } } ``` We now use the `RWArc` package to get a read/write Arc. The read/write Arc has a slightly different API than `Arc`: `read` and `write` allow you to, well, read and write the data. They both take closures as arguments, and the read/write Arc will, in the case of write, acquire a mutex, and then pass the data to this closure. After the closure does its thing, the mutex is released. You can see how this makes it impossible to mutate the state without remembering to aquire the lock. We gain the efficiency of shared mutable state, while retaining the safety of disallowing shared mutable state. But wait, how is that possible? We can't both allow and disallow mutable state. What gives? ## A footnote: unsafe So, the Rust language does not allow for shared mutable state, yet I just showed you some code that has it. How's this possible? The answer: `unsafe`. You see, while the Rust compiler is very smart, and saves you from making mistakes you might normally make, it's not an artificial intelligence. Because we're smarter than the compiler, sometimes, we need to over-ride this safe behavior. For this purpose, Rust has an `unsafe` keyword. Within an `unsafe` block, Rust turns off many of its safety checks. If something bad happens to your program, you only have to audit what you've done inside `unsafe`, and not the entire program itself. If one of the major goals of Rust was safety, why allow that safety to be turned off? Well, there are really only three main reasons to do it: interfacing with external code, such as doing FFI into a C library, performance (in certain cases), and to provide a safe abstraction around operations that normally would not be safe. Our Arcs are an example of this last purpose. We can safely hand out multiple references to the `Arc`, because we are sure the data is immutable, and therefore it is safe to share. We can hand out multiple references to the `RWArc`, because we know that we've wrapped the data in a mutex, and therefore it is safe to share. But the Rust compiler can't know that we've made these choices, so _inside_ the implementation of the Arcs, we use `unsafe` blocks to do (normally) dangerous things. But we expose a safe interface, which means that the Arcs are impossible to use incorrectly. This is how Rust's type system allows you to not make some of the mistakes that make concurrent programming difficult, yet get the efficiency of languages such as C++. ## That's all, folks I hope that this taste of Rust has given you an idea if Rust is the right language for you. If that's true, I encourage you to check out [the tutorial](http://rust-lang.org//doc/tutorial.html) for a full, in-depth exploration of Rust's syntax and concepts. From troplin at bluewin.ch Mon Jan 13 09:18:17 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Mon, 13 Jan 2014 17:18:17 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> Message-ID: <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> Daniel Micay wrote: > On Sun, Jan 12, 2014 at 1:23 PM, Tobias M?ller wrote: >> Isaac Dupree >> wrote: >>> In general, Rust is a systems language, so fixed-size integral types are >>> important to have. They are better-behaved than in C and C++ in that >>> signed types are modulo, not undefined behaviour, on overflow. It could >>> be nice to have integral types that are task-failure on overflow as an >>> option too. As you note, bignum integers are important too; it's good >>> they're available. I think bignum rationals would be a fine additional >>> choice to have (Haskell and GMP offer them, for example). >> >> Wrapping overflow is just as bad as undefined behavior IMO. > > Do you know what undefined behavior is? It doesn't mean unspecified. True, but despite beeing so often cited it won't format your hard disk (even in C). The result of an integer addition will always be an integer in every compiler I know so in this specific case I don't fear the UB. >> I cannot remember a single case of using signed integers where wrapping >> would make any sense. > > It often makes sense in codecs, hashing algorithms and cryptography. I'm sure there exist many cases where _unsigned_ int overflow makes sense. For _signed_ integers I'm a bit sceptical but I am no expert in that field. In any case it should not be the default but rather 'opt-in'. But this is not what I meant. Let me rephrase it differently: Assume that signed int overflow is UB (like in C). That means, all actual overflows at runtime have to be considered bugs. Now I cannot imagine any such case (bug) where guaranteed wrapping would actually behave nicer. > If you don't have clear bounds and don't want modular arithmetic, you > need big integers. Or proper input validation. The type defines the bounds. >> And you lose some optimization opportunities. > > It's treated as undefined because there are more optimization > opportunities that way. That's what I wanted to say. If you guarantee wrapping overflow you lose those opportunities. >> So why not take the path of the rust memory management and enforce bounds >> statically? It would need annotations on the types, like lifetimes, but it >> would be very rusty. Like C but safe. > > Rust isn't supposed to be really hard to write. Complex dependent typing would I'm not sure that this would be so complex. At least not more than the lifetime system. Is simple arithmetics on the bounds. In reality (rust beeing a systems PL) fixed width ints _will_ be used, and I am sure that overflow will often just be neglected. So why not enforce it statically? Tobi From thadguidry at gmail.com Mon Jan 13 09:30:20 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Mon, 13 Jan 2014 11:30:20 -0600 Subject: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB In-Reply-To: <52D3D38F.4000104@proinbox.com> References: <52D398FD.7070408@posteo.de> <52D3D38F.4000104@proinbox.com> Message-ID: Eclipse also has a GDB plugin to assist with debugging. http://wiki.eclipse.org/Linux_Tools_Project/GDB/User_Guide On Mon, Jan 13, 2014 at 5:52 AM, John Mija wrote: > There is a web front-end for gdb to debug applications in Go, C and C++. > I'm supposed that it also could be used to debug Rust apps. > > https://github.com/sirnewton01/godbg > > El 13/01/14 07:42, Michael Woerister escribi?: > >> Hi, >> the `break` command can be a bit particular where function names are >> concerned, especially when namespaces and generics are involved. The >> correct full name of the shuffle method would be something like >> `std::rand::TaskRng::shuffle` (there is a seperate function for >> every set of concrete type parameters, so `shuffle` would be >> different from `shuffle`). >> >> My recommendation here is to either >> * set the breakpoint using line numbers: break prog.rs:7 >> * or use the `rbreak` command which takes a regular expression as >> argument, that is, `rbreak shuffle` will match any function containing >> the string "shuffle" in its name. >> >> Don't be shy to ask further questions if you have any :) >> >> -Michael >> >> On 13.01.2014 00:13, Artella Coding wrote: >> >>> Suppose I have the following program : >>> >>> ********************************************** >>> //prog1.rs >>> >>> use std::rand::{task_rng, Rng}; >>> fn main() { >>> let names = ["Alice", "Bob", "Carol"]; >>> for name in names.iter() { >>> let v = task_rng().shuffle(~[1,2,3]); >>> for num in v.iter() { >>> println!("{:s} says: {:d}", *name, *num); >>> } >>> } >>> } >>> ********************************************** >>> >>> In previous versions of rust it was possible to put >>> a breakpoint on "shuffle" e.g. >>> >>> One would first compile via : >>> >>> rustc -Z debug-info prog1.rs >>> >>> >>> and then one could proceed to put a breakpoint on "shuffle" : >>> >>> gdb ./prog1 >>> (gdb) break shuffle >>> (gdb) run >>> >>> However now it doesn't seem possible to put a breakpoint on shuffle. >>> Why is this? Thanks. >>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Mon Jan 13 09:55:00 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Mon, 13 Jan 2014 11:55:00 -0600 Subject: [rust-dev] RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: I think Mozilla just found their new hire for documentation writing ! Excellent Steve ! That's the kind of story and style that makes learning actually fun for folks; By giving good examples and analogies to foreign concepts along the way (books). -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Jan 13 10:30:20 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 13 Jan 2014 12:30:20 -0600 Subject: [rust-dev] RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: > By giving good examples and analogies to foreign concepts along the way (books). To be clear, that was in the source presentation, it was not my invention. From carter.schonwald at gmail.com Mon Jan 13 10:40:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 13 Jan 2014 13:40:53 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> Message-ID: enforce what statically? There is a very really very subtle tradeoff in how powerful a static verification scheme can be vs how easily it can be used (the sweet spot being somewhere in between nothing and complete proof based verification). It sounds like there are valid arguments for several different error semantics for fixed size numbers, and those should perhaps be different builtin types. Everyone is right about the tradeoffs for their own needs, and choosing one semantics over another in that context is a mixed bag / iffy proposition. Tradeoffs are real, the best a language can do is make it easy to choose the right tradeoffs for you! -Carter On Mon, Jan 13, 2014 at 12:18 PM, Tobias M?ller wrote: > Daniel Micay wrote: > > On Sun, Jan 12, 2014 at 1:23 PM, Tobias M?ller > wrote: > >> Isaac Dupree > >> wrote: > >>> In general, Rust is a systems language, so fixed-size integral types > are > >>> important to have. They are better-behaved than in C and C++ in that > >>> signed types are modulo, not undefined behaviour, on overflow. It > could > >>> be nice to have integral types that are task-failure on overflow as an > >>> option too. As you note, bignum integers are important too; it's good > >>> they're available. I think bignum rationals would be a fine additional > >>> choice to have (Haskell and GMP offer them, for example). > >> > >> Wrapping overflow is just as bad as undefined behavior IMO. > > > > Do you know what undefined behavior is? It doesn't mean unspecified. > > True, but despite beeing so often cited it won't format your hard disk > (even in C). > The result of an integer addition will always be an integer in every > compiler I know so in this specific case I don't fear the UB. > > >> I cannot remember a single case of using signed integers where wrapping > >> would make any sense. > > > > It often makes sense in codecs, hashing algorithms and cryptography. > > I'm sure there exist many cases where _unsigned_ int overflow makes sense. > For _signed_ integers I'm a bit sceptical but I am no expert in that field. > > In any case it should not be the default but rather 'opt-in'. > > But this is not what I meant. Let me rephrase it differently: > Assume that signed int overflow is UB (like in C). That means, all actual > overflows at runtime have to be considered bugs. > Now I cannot imagine any such case (bug) where guaranteed wrapping would > actually behave nicer. > > > If you don't have clear bounds and don't want modular arithmetic, you > > need big integers. > > Or proper input validation. The type defines the bounds. > > >> And you lose some optimization opportunities. > > > > It's treated as undefined because there are more optimization > > opportunities that way. > > That's what I wanted to say. If you guarantee wrapping overflow you lose > those opportunities. > > >> So why not take the path of the rust memory management and enforce > bounds > >> statically? It would need annotations on the types, like lifetimes, but > it > >> would be very rusty. Like C but safe. > > > > Rust isn't supposed to be really hard to write. Complex dependent typing > would > > I'm not sure that this would be so complex. At least not more than the > lifetime system. Is simple arithmetics on the bounds. > > In reality (rust beeing a systems PL) fixed width ints _will_ be used, and > I am sure that overflow will often just be neglected. So why not enforce it > statically? > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Mon Jan 13 10:46:31 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 13 Jan 2014 10:46:31 -0800 Subject: [rust-dev] Call for central external packages repository In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 2:43 AM, Gaetan wrote: > I know this question has been debated, however I'd like to highly > recommend to give a clean infrastructure to register, list, search and > describe external libraries developed by everyone. > If there's interest in this, I'd highly encourage taking a look at The Update Framework as a way to build *secure* software update systems: https://github.com/theupdateframework/tuf -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon Jan 13 11:36:20 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 13 Jan 2014 11:36:20 -0800 Subject: [rust-dev] RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: <52D44034.9090008@mozilla.com> This is awesome, and with some refinement this may be what we want to make the official introductory documentation. I left some feedback on HN. On 01/13/2014 09:08 AM, Steve Klabnik wrote: > Also posted to my blog: > http://words.steveklabnik.com/a-30-minute-introduction-to-rust > > I've just kept this in Markdown even though the email is in plain > text, should still be easy on the eyes. > > I recently gave a [proposal for Rust's > documentation](https://air.mozilla.org/rust-meetup-december-2013/). An > important component of my overall proposal is a short, simple > introduction for people who may have heard of Rust, so that they can > figure out if Rust is right for them. The other day, I saw [this > excellent presentation](http://www.youtube.com/watch?v=gfCtbGiHcg0), > and thought it might serve as a great basis for this introduction. > Consider this an RFC for such an introduction. Feedback very welcome. > If you all like it, I'll submit it to our documentation. > > --------------------------------------------------------------------- > > Rust is a systems programming language that focuses on strong > compile-time correctness guarantees. It improves upon the ideas other > systems languages like C++, D, and Cyclone by providing very strong > guarantees and explicit control over the life cycle of memory. Strong > memory guarantees make writing correct concurrent Rust code easier > than in other languages. This might sound very complex, but it's > easier than it sounds! This tutorial will give you an idea of what > Rust is like in about thirty minutes. It expects that you're at least > vaguely familiar with a previous 'curly brace' language. The concepts > are more important than the syntax, so don't worry if you don't get > every last detail: the > [tutorial](http://static.rust-lang.org/doc/master/tutorial.html) can > help you out with that later. > > Let's talk about the most important concept in Rust, "ownership," and > its implications on a task that programmers usually find very > difficult: concurrency. > > ## Ownership > > Ownership is central to Rust, and is one of its more interesting and > unique features. "Ownership" refers to which parts of your code are > allowed to modify various parts of memory. Let's start by looking at > some C++ code: > > ``` > int *dangling(void) > { > int i = 1234; > return &i; > } > > int add_one(void) > { > int *num = dangling(); > return *num + 1; > } > ``` > > This function allocates an integer on the stack, and stores it in a > variable, `i`. It then returns a reference to the variable `i`. > There's just one problem: stack memory becomes invalid when the > function returns. This means that in the second line of `add_one`, > `num` points to some garbage values, and we won't get the effect that > we want. While this is a trivial example, it can happen quite often in > C++ code. There's a similar problem when memory on the heap is > allocated with `malloc` (or `new`), then freed with `free` (or > `delete`), yet your code attempts to do something with the pointer to > that memory. More modern C++ uses RAII with constructors/destructors, > but it amounts to the same thing. This problem is called a 'dangling > pointer,' and it's not possible to write Rust code that has it. Let's > try: > > ``` > fn dangling() -> &int { > let i = 1234; > return &i; > } > > fn add_one() -> int { > let num = dangling(); > return *num + 1; > } > ``` > > When you try to compile this program, you'll get an interesting (and > long) error message: > > ``` > temp.rs:3:11: 3:13 error: borrowed value does not live long enough > temp.rs:3 return &i; > > temp.rs:1:22: 4:1 note: borrowed pointer must be valid for the > anonymous lifetime #1 defined on the block at 1:22... > temp.rs:1 fn dangling() -> &int { > temp.rs:2 let i = 1234; > temp.rs:3 return &i; > temp.rs:4 } > > temp.rs:1:22: 4:1 note: ...but borrowed value is only valid for the > block at 1:22 > temp.rs:1 fn dangling() -> &int { > temp.rs:2 let i = 1234; > temp.rs:3 return &i; > temp.rs:4 } > error: aborting due to previous error > ``` > > In order to fully understand this error message, we need to talk about > what it means to "own" something. So for now, let's just accept that > Rust will not allow us to write code with a dangling pointer, and > we'll come back to this code once we understand ownership. > > Let's forget about programming for a second and talk about books. I > like to read physical books, and sometimes I really like one and tell > my friends they should read it. While I'm reading my book, I own it: > the book is in my possession. When I loan the book out to someone else > for a while, they "borrow" it from me. And when you borrow a book, > it's for a certain period of time, and then you give it back to me, > and I own it again. Right? > > This concept applies directly to Rust code as well: some code "owns" a > particular pointer to memory. It's the sole owner of that pointer. It > can also lend that memory out to some other code for a while: the code > "borrows" it. It borrows it for a certain period of time, called a > "lifetime." > > That's all there is to it. That doesn't seem so hard, right? Let's go > back to that error message: `error: borrowed value does not live long > enough`. We tried to loan out a particular variable, `i`, using Rust's > borrowed pointers: the `&`. But Rust knew that the variable would be > invalid after the function returns, and so it tells us that: `borrowed > pointer must be valid for the anonymous lifetime #1... but borrowed > value is only valid for the block`. Neat! > > That's a great example for stack memory, but what about heap memory? > Rust has a second kind of pointer, a 'unique' pointer, that you can > create with a `~`. Check it out: > > ``` > fn dangling() -> ~int { > let i = ~1234; > return i; > } > > fn add_one() -> int { > let num = dangling(); > return *num + 1; > } > ``` > > This code will successfully compile. Note that instead of a stack > allocated `1234`, we use an owned pointer to that value instead: > `~1234`. You can roughly compare these two lines: > > ``` > // rust > let i = ~1234; > > // C++ > int *i = new int; > *i = 1234; > ``` > > Rust is able to infer the size of the type, then allocates the correct > amount of memory and sets it to the value you asked for. This means > that it's impossible to allocate uninitialized memory: Rust does not > have the concept of null. Hooray! There's one other difference between > this line of Rust and the C++: The Rust compiler also figures out the > lifetime of `i`, and then inserts a corresponding `free` call after > it's invalid, like a destructor in C++. You get all of the benefits of > manually allocated heap memory without having to do all the > bookkeeping yourself. Furthermore, all of this checking is done at > compile time, so there's no runtime overhead. You'll get (basically) > the exact same code that you'd get if you wrote the correct C++, but > it's impossible to write the incorrect version, thanks to the > compiler. > > You've seen one way that ownership and lifetimes are useful to prevent > code that would normally be dangerous in a less-strict language, but > let's talk about another: concurrency. > > ## Concurrency > > Concurrency is an incredibly hot topic in the software world right > now. It's always been an interesting area of study for computer > scientists, but as usage of the Internet explodes, people are looking > to improve the number of users a given service can handle. Concurrency > is one way of achieving this goal. There is a pretty big drawback to > concurrent code, though: it can be hard to reason about, because it is > non-deterministic. There are a few different approaches to writing > good concurrent code, but let's talk about how Rust's notions of > ownership and lifetimes can assist with achieving correct but > concurrent code. > > First, let's go over a simple concurrency example in Rust. Rust allows > you to spin up 'tasks,' which are lightweight, 'green' threads. These > tasks do not have any shared memory, and so, we communicate between > tasks with a 'channel'. Like this: > > ``` > fn main() { > let numbers = [1,2,3]; > > let (port, chan) = Chan::new(); > chan.send(numbers); > > do spawn { > let numbers = port.recv(); > println!("{:d}", numbers[0]); > } > } > ``` > > In this example, we create a vector of numbers. We then make a new > `Chan`, which is the name of the package Rust implements channels > with. This returns two different ends of the channel: a channel and a > port. You send data into the channel end, and it comes out the port > end. The `spawn` function spins up a new task. As you can see in the > code, we call `port.recv()` (short for 'receive') inside of the new > task, and we call `chan.send()` outside, passing in our vector. We > then print the first element of the vector. > > This works out because Rust copies the vector when it is sent through > the channel. That way, if it were mutable, there wouldn't be a race > condition. However, if we're making a lot of tasks, or if our data is > very large, making a copy for each task inflates our memory usage with > no real benefit. > > Enter Arc. Arc stands for 'atomically reference counted,' and it's a > way to share immutable data between multiple tasks. Here's some code: > > ``` > extern mod extra; > use extra::arc::Arc; > > fn main() { > let numbers = [1,2,3]; > > let numbers_arc = Arc::new(numbers); > > for num in range(0, 3) { > let (port, chan) = Chan::new(); > chan.send(numbers_arc.clone()); > > do spawn { > let local_arc = port.recv(); > let task_numbers = local_arc.get(); > println!("{:d}", task_numbers[num]); > } > } > } > ``` > > This is very similar to the code we had before, except now we loop > three times, making three tasks, and sending an `Arc` between them. > `Arc::new` creates a new Arc, `.clone()` makes a new reference to that > Arc, and `.get()` gets the value out of the Arc. So we make a new > reference for each task, send that reference down the channel, and > then use the reference to print out a number. Now we're not copying > our vector. > > Arcs are great for immutable data, but what about mutable data? Shared > mutable state is the bane of the concurrent programmer. You can use a > mutex to protect shared mutable state, but if you forget to acquire > the mutex, bad things can happen. > > Rust provides a tool for shared mutable state: `RWArc`. This variant > of an Arc allows the contents of the Arc to be mutated. Check it out: > > ``` > extern mod extra; > use extra::arc::RWArc; > > fn main() { > let numbers = [1,2,3]; > > let numbers_arc = RWArc::new(numbers); > > for num in range(0, 3) { > let (port, chan) = Chan::new(); > chan.send(numbers_arc.clone()); > > do spawn { > let local_arc = port.recv(); > > local_arc.write(|nums| { > nums[num] += 1 > }); > > local_arc.read(|nums| { > println!("{:d}", nums[num]); > }) > } > } > } > ``` > > We now use the `RWArc` package to get a read/write Arc. The read/write > Arc has a slightly different API than `Arc`: `read` and `write` allow > you to, well, read and write the data. They both take closures as > arguments, and the read/write Arc will, in the case of write, acquire > a mutex, and then pass the data to this closure. After the closure > does its thing, the mutex is released. > > You can see how this makes it impossible to mutate the state without > remembering to aquire the lock. We gain the efficiency of shared > mutable state, while retaining the safety of disallowing shared > mutable state. > > But wait, how is that possible? We can't both allow and disallow > mutable state. What gives? > > ## A footnote: unsafe > > So, the Rust language does not allow for shared mutable state, yet I > just showed you some code that has it. How's this possible? The > answer: `unsafe`. > > You see, while the Rust compiler is very smart, and saves you from > making mistakes you might normally make, it's not an artificial > intelligence. Because we're smarter than the compiler, sometimes, we > need to over-ride this safe behavior. For this purpose, Rust has an > `unsafe` keyword. Within an `unsafe` block, Rust turns off many of its > safety checks. If something bad happens to your program, you only have > to audit what you've done inside `unsafe`, and not the entire program > itself. > > If one of the major goals of Rust was safety, why allow that safety to > be turned off? Well, there are really only three main reasons to do > it: interfacing with external code, such as doing FFI into a C > library, performance (in certain cases), and to provide a safe > abstraction around operations that normally would not be safe. Our > Arcs are an example of this last purpose. We can safely hand out > multiple references to the `Arc`, because we are sure the data is > immutable, and therefore it is safe to share. We can hand out multiple > references to the `RWArc`, because we know that we've wrapped the data > in a mutex, and therefore it is safe to share. But the Rust compiler > can't know that we've made these choices, so _inside_ the > implementation of the Arcs, we use `unsafe` blocks to do (normally) > dangerous things. But we expose a safe interface, which means that the > Arcs are impossible to use incorrectly. > > This is how Rust's type system allows you to not make some of the > mistakes that make concurrent programming difficult, yet get the > efficiency of languages such as C++. > > ## That's all, folks > > I hope that this taste of Rust has given you an idea if Rust is the > right language for you. If that's true, I encourage you to check out > [the tutorial](http://rust-lang.org//doc/tutorial.html) for a full, > in-depth exploration of Rust's syntax and concepts. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From troplin at bluewin.ch Mon Jan 13 13:06:40 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Mon, 13 Jan 2014 21:06:40 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> Message-ID: <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Carter Schonwald wrote: > enforce what statically? There is a very really very subtle tradeoff in > how powerful a static verification scheme can be vs how easily it can be > used (the sweet spot being somewhere in between nothing and complete > proof based verification). Enforce that integer overflow never happens. Roughly, I was thinking of the following: Every int variable/parameter/binding has an associated range (lower and upper bound): int If no bound is specified, the min and max values of the type are used. Every operation on ints specify the range of the result using the range of the operands: int + int = int ... If the result does not fit into an int the compiler throws an error. To resolve an error, you can: - annotate the operands with appropriate bounds - use a bigger type for the operation and check the result. To go from a bigger to a smaller range you use: let x : int match x { int<0,255> => ... _ => fail() } Sorry for the sketchy syntax, I'm just following this list but have never actually used rust. > It sounds like there are valid arguments for several different error > semantics for fixed size numbers, and those should perhaps be different > builtin types. Everyone is right about the tradeoffs for their own needs, > and choosing one semantics over another in that context is a mixed bag / > iffy proposition. Tradeoffs are real, the best a language can do is make > it easy to choose the right tradeoffs for you! But also different languages choose different tradeoffs and rust aims to be a systems PL. By banning the fastest int version from the language by making overflow wrapping or failing at runtime, you actually limit the choice already. Tobi From carter.schonwald at gmail.com Mon Jan 13 13:25:12 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 13 Jan 2014 16:25:12 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Message-ID: indeed, hence why i was saying there should be sized int variants for each of those semantics (wrapping, trapping, overflowing, etc). This is something that many people seem to favor, and is the right choice for supporting smart engineers build reliable sophisticated software. Namely, really spell out what each alternative means, make sure they're all first class options, etc etc. staticly verifying bounded ranges in a language is really subtle. You're proposing what easily turns into a pretty tricky flow analysis (to have it have any precision!), and it'd have to happen in type checker too... On Mon, Jan 13, 2014 at 4:06 PM, Tobias M?ller wrote: > Carter Schonwald > wrote: > > enforce what statically? There is a very really very subtle tradeoff in > > how powerful a static verification scheme can be vs how easily it can be > > used (the sweet spot being somewhere in between nothing and complete > > proof based verification). > > Enforce that integer overflow never happens. > > Roughly, I was thinking of the following: > > Every int variable/parameter/binding has an associated range (lower and > upper bound): > int > If no bound is specified, the min and max values of the type are used. > > Every operation on ints specify the range of the result using the range of > the operands: > > int + int = int > ... > > If the result does not fit into an int the compiler throws an error. > To resolve an error, you can: > - annotate the operands with appropriate bounds > - use a bigger type for the operation and check the result. > > To go from a bigger to a smaller range you use: > let x : int > match x { > int<0,255> => ... > _ => fail() > } > > Sorry for the sketchy syntax, I'm just following this list but have never > actually used rust. > > > It sounds like there are valid arguments for several different error > > semantics for fixed size numbers, and those should perhaps be different > > builtin types. Everyone is right about the tradeoffs for their own needs, > > and choosing one semantics over another in that context is a mixed bag / > > iffy proposition. Tradeoffs are real, the best a language can do is make > > it easy to choose the right tradeoffs for you! > > But also different languages choose different tradeoffs and rust aims to be > a systems PL. > > By banning the fastest int version from the language by making overflow > wrapping or failing at runtime, you actually limit the choice already. > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Mon Jan 13 13:52:23 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Mon, 13 Jan 2014 21:52:23 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Message-ID: <347414999411341860.389844troplin-bluewin.ch@news.gmane.org> Carter Schonwald wrote: > indeed, hence why i was saying there should be sized int variants for > each of those semantics (wrapping, trapping, overflowing, etc). This is > something that many people seem to favor, and is the right choice for > supporting smart engineers build reliable sophisticated software. Namely, > really spell out what each alternative means, make sure they're all first > class options, etc etc. > > staticly verifying bounded ranges in a language is really subtle. You're > proposing what easily turns into a pretty tricky flow analysis (to have > it have any precision!), and it'd have to happen in type checker too... I was actually trying to avoid flow analysis. With my proposal, the range would be "attached" to the type and cannot change over time. That's why I was proposing a case match binding for going to a smaller range. Some time ago I was reading a blog post (I think it was from Patrick Walton) about why you abandoned type state and how it can be replaced with a less dynamic system that is easier to reason about. In that system the dynamic type state was replaced by a more static type parameter. I don't want type state for integers but this 'replacement'. (I don't know how it was called, need to read it up again) Tobi From danielmicay at gmail.com Mon Jan 13 15:08:26 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 13 Jan 2014 18:08:26 -0500 Subject: [rust-dev] Impact of -ftrapv on Firefox In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 6:42 AM, Robert O'Callahan wrote: > On Mon, Jan 13, 2014 at 2:53 PM, Robert O'Callahan > wrote: >> >> On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay >> wrote: >>> >>> -fsanitize=signed-integer-overflow: Signed integer overflow, including >>> all the checks added by -ftrapv, and checking for overflow in signed >>> division (INT_MIN / -1). >>> >>> Why not measure the impact of this on Firefox performance? We'll have >>> a concrete answer about half of the picture (but not about the cost >>> for unsigned or checks on overlong shifts and for division by zero). >> >> >> That would give us neither an upper bound on overhead (due to excluding >> unsigned), nor a lower bound (due to no range analysis or LLVM changes). But >> it might be interesting... > > > Just for fun I did a Firefox build with -ftrapv. The most surprising thing > is that the browser actually worked, on Linux64 at least. Not so much on > Linux32 and Mac. https://tbpl.mozilla.org/?tree=Try&rev=45b9932ca819 > > The Talos performance results aren't exactly science, but it looks like the > performance impact is negligible. For example, tp5o (page load time test) > reported 285, central is around 280 (lower is better). Dromaeo-CSS reported > 5408, whereas central is around 5500 (but noisy) (higher is better). > > Like I said, I don't really know what this means, but it sounds hopeful to > me. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le > atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w Is this with `clang`? I don't think `-ftrapv` actually works in `gcc`. Simple test showing it doesn't work: foo.c ``` #include extern int bar; int main(void) { int x = INT_MAX; int y = x + bar; return 0; } ``` bar.c ``` int bar = 1; ``` gcc foo.c bar.c -ftrapv && ./a.out # no error clang foo.c bar.c -ftrapv && ./a.out # zsh: illegal hardware instruction From danielmicay at gmail.com Mon Jan 13 15:11:53 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 13 Jan 2014 18:11:53 -0500 Subject: [rust-dev] Impact of -ftrapv on Firefox In-Reply-To: References: Message-ID: There's also the issue that libgcc_s is missing the function LLVM will generate for 64-bit overflow checked multiplication on most architectures. It's there on x86_64, but on x86 you'll need a `clang` set up to use `compiler-rt`. It's hilarious that `gcc` is totally broken though... From andrew.pennebaker at gmail.com Mon Jan 13 16:48:53 2014 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Mon, 13 Jan 2014 19:48:53 -0500 Subject: [rust-dev] Is it just me, or do the API docs lie about getopt() in rust v0.8? Message-ID: I'm following tutorials and snippets to get my code to work with rust 0.8 (I'm behind, I know). The rust docs for v0.8 say that getopt() accepts an array of OptGroup (long options), and my code is written to use that. http://static.rust-lang.org/doc/0.8/extra/getopts/groups/fn.getopts.html But when I dig through the rust source code around version 0.8, this is not the API that I find. https://github.com/mozilla/rust/blob/7c92435f8f93344330e47fb0cca4f79297896bd2/src/libextra/getopts.rs#L396 Am I doing something wrong? What's the easiest way to convert an array of long options into an array of short options for the purposes of using getopt()? Is this discrepancy fixed in 0.9? -- Cheers, Andrew Pennebaker www.yellosoft.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Jan 13 16:50:17 2014 From: corey at octayn.net (Corey Richardson) Date: Mon, 13 Jan 2014 19:50:17 -0500 Subject: [rust-dev] Is it just me, or do the API docs lie about getopt() in rust v0.8? In-Reply-To: References: Message-ID: You're looking at the wrong getopts function. You're looking at extra::getopts::getopts, but citing the documentation for extra::getopts::groups::getopts. On Mon, Jan 13, 2014 at 7:48 PM, Andrew Pennebaker wrote: > I'm following tutorials and snippets to get my code to work with rust 0.8 > (I'm behind, I know). > > The rust docs for v0.8 say that getopt() accepts an array of OptGroup (long > options), and my code is written to use that. > > http://static.rust-lang.org/doc/0.8/extra/getopts/groups/fn.getopts.html > > But when I dig through the rust source code around version 0.8, this is not > the API that I find. > > https://github.com/mozilla/rust/blob/7c92435f8f93344330e47fb0cca4f79297896bd2/src/libextra/getopts.rs#L396 > > Am I doing something wrong? > > What's the easiest way to convert an array of long options into an array of > short options for the purposes of using getopt()? > > Is this discrepancy fixed in 0.9? > > -- > Cheers, > > Andrew Pennebaker > www.yellosoft.us > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From robert at ocallahan.org Mon Jan 13 17:19:25 2014 From: robert at ocallahan.org (Robert O'Callahan) Date: Tue, 14 Jan 2014 14:19:25 +1300 Subject: [rust-dev] Impact of -ftrapv on Firefox In-Reply-To: References: Message-ID: On Tue, Jan 14, 2014 at 12:11 PM, Daniel Micay wrote: > There's also the issue that libgcc_s is missing the function LLVM will > generate for 64-bit overflow checked multiplication on most > architectures. It's there on x86_64, but on x86 you'll need a `clang` > set up to use `compiler-rt`. > > It's hilarious that `gcc` is totally broken though... > Thanks for catching that. My experiments indicate that -ftrapv works in gcc for x86 but not x86-64. Which explains why the Firefox try builds only work for x86-64. Which makes sense, since Firefox contains code that would depend on overflow wrapping around. So we're back to not knowing anything :-). Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.pennebaker at gmail.com Mon Jan 13 17:25:50 2014 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Mon, 13 Jan 2014 20:25:50 -0500 Subject: [rust-dev] Rust docs for 0.8: "No idea what this does" Message-ID: Who wrote these 0.8 docs: http://static.rust-lang.org/doc/0.8/extra/getopts/struct.Matches.html Fortunately, they're much improved in 0.9. -- Cheers, Andrew Pennebaker www.yellosoft.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Jan 13 17:30:42 2014 From: corey at octayn.net (Corey Richardson) Date: Mon, 13 Jan 2014 20:30:42 -0500 Subject: [rust-dev] Rust docs for 0.8: "No idea what this does" In-Reply-To: References: Message-ID: You realize you're using a 3 month old unsupported release of a pre-alpha language, right? Anyway I don't know how those got promoted to doc comments, they used to just be comments. On Mon, Jan 13, 2014 at 8:25 PM, Andrew Pennebaker wrote: > Who wrote these 0.8 docs: > > http://static.rust-lang.org/doc/0.8/extra/getopts/struct.Matches.html > > Fortunately, they're much improved in 0.9. > > -- > Cheers, > > Andrew Pennebaker > www.yellosoft.us > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From banderson at mozilla.com Mon Jan 13 17:31:47 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 13 Jan 2014 17:31:47 -0800 Subject: [rust-dev] Rust docs for 0.8: "No idea what this does" In-Reply-To: References: Message-ID: <52D49383.3050403@mozilla.com> After seeing the title of this email I hoped that it was me. Regardless there's no need to blame anyone. Somebody was nice enough to go through and add docs and put in a FIXME. All part of the process. On 01/13/2014 05:25 PM, Andrew Pennebaker wrote: > Who wrote these 0.8 docs: > > http://static.rust-lang.org/doc/0.8/extra/getopts/struct.Matches.html > > Fortunately, they're much improved in 0.9. > > -- > Cheers, > > Andrew Pennebaker > www.yellosoft.us > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From palmercox at gmail.com Mon Jan 13 17:50:03 2014 From: palmercox at gmail.com (Palmer Cox) Date: Mon, 13 Jan 2014 20:50:03 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> Message-ID: On Mon, Jan 13, 2014 at 12:18 PM, Tobias M?ller wrote: > Daniel Micay wrote: > > On Sun, Jan 12, 2014 at 1:23 PM, Tobias M?ller > wrote: > >> Isaac Dupree > >> wrote: > >>> In general, Rust is a systems language, so fixed-size integral types > are > >>> important to have. They are better-behaved than in C and C++ in that > >>> signed types are modulo, not undefined behaviour, on overflow. It > could > >>> be nice to have integral types that are task-failure on overflow as an > >>> option too. As you note, bignum integers are important too; it's good > >>> they're available. I think bignum rationals would be a fine additional > >>> choice to have (Haskell and GMP offer them, for example). > >> > >> Wrapping overflow is just as bad as undefined behavior IMO. > > > > Do you know what undefined behavior is? It doesn't mean unspecified. > > True, but despite beeing so often cited it won't format your hard disk > (even in C). > The result of an integer addition will always be an integer in every > compiler I know so in this specific case I don't fear the UB. I don't think that's quite accurate. Its true that the result of undefined behavior is unlikely to be that your harddrive is formatted. However, you aren't guaranteed to end up with an integer in any compiler that I'm aware of either. Its subtle, but important to remember that the instruction that actually overflows the integer register isn't really the undefined behavior. Its not that a program is operating in a defined mode and then the integer overflow occurs and then the program transitions into an undefined mode. Instead, a program that will execute an integer overflow at some point in the future is as the mercy of undefined behavior from the very first instruction. The compiler, knowing that you aren't allowed to overflow an integer, uses that information to do a variety of optimizations, including dead code elimination. Since overflowing an integer is undefined, the compiler assumes that you won't do it and will use that assumption to eliminate as much code as possible. So, the end result could be that an entire branch of the program is eliminated. See http://blog.regehr.org/archives/213 (look for "Type 3 Functions) for an example. So, the end result of integer overflow undefined behavior might not an actual overflow since the compiler could remove the add instruction along with whatever else it thinks it can. This could result in a program that works fine in debug modes, but once you crank up the optimization level, it fails to run. Or, it could result in a program that runs fine on a particular compiler version, but then fails mysteriously after an update. Or, as in the example, it could result in a program that runs fine, but silently doesn't do an important check. > >> I cannot remember a single case of using signed integers where wrapping > >> would make any sense. > > > > It often makes sense in codecs, hashing algorithms and cryptography. > > I'm sure there exist many cases where _unsigned_ int overflow makes sense. > For _signed_ integers I'm a bit sceptical but I am no expert in that field. > > In any case it should not be the default but rather 'opt-in'. > > But this is not what I meant. Let me rephrase it differently: > Assume that signed int overflow is UB (like in C). That means, all actual > overflows at runtime have to be considered bugs. > Now I cannot imagine any such case (bug) where guaranteed wrapping would > actually behave nicer. > > > If you don't have clear bounds and don't want modular arithmetic, you > > need big integers. > > Or proper input validation. The type defines the bounds. > > >> And you lose some optimization opportunities. > > > > It's treated as undefined because there are more optimization > > opportunities that way. > > That's what I wanted to say. If you guarantee wrapping overflow you lose > those opportunities. > > >> So why not take the path of the rust memory management and enforce > bounds > >> statically? It would need annotations on the types, like lifetimes, but > it > >> would be very rusty. Like C but safe. > > > > Rust isn't supposed to be really hard to write. Complex dependent typing > would > > I'm not sure that this would be so complex. At least not more than the > lifetime system. Is simple arithmetics on the bounds. > > In reality (rust beeing a systems PL) fixed width ints _will_ be used, and > I am sure that overflow will often just be neglected. So why not enforce it > statically? > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.pennebaker at gmail.com Mon Jan 13 18:17:48 2014 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Mon, 13 Jan 2014 21:17:48 -0500 Subject: [rust-dev] Rust docs for 0.8: "No idea what this does" In-Reply-To: References: Message-ID: I won't bother using git blame, it's just weird to see such comments in doc files. If you don't know what something does, why not leave it blank? On Jan 13, 2014 9:03 PM, "Steve Klabnik" wrote: > No reason to be so harsh, especially since they've been improved. > There is a way you can find out, but I'm not telling you. > > I love 'these docs are poor' comments, as they help me figure out what > needs to be improved, but there's no reason to pick something that's > already been fixed and try to make someone feel bad. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon Jan 13 18:48:04 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 13 Jan 2014 18:48:04 -0800 Subject: [rust-dev] RFC: New Rust channel proposal Message-ID: <52D4A564.4090602@mozilla.com> In light of the general consensus that unbounded channels are not so hot, here's a new proposal for how Rust's channels should operate. This is based on the following assumptions: * Running out of memory is an awful failure mode for debugging. * Choosing an appropriate bounded queue size is hard. * Dealing with backpressure is hard. * Most channels are not filled without bound. This proposal has two facets: making the current channels appropriate for more use cases; adding additional channel types for specialized use cases. I'm still operating under the premise that there should be a "default" channel type that can be successfully used in most instances, and people should only need to pick something else when their message passing behavior calls for it. Not all of these recommendations are about resolving the unbounded channel debate. # Changes to `Chan` Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up some of our complexity budget to add more channel types, and partly a concession to usability. A cloned channel will automatically upgrade itself to a multi-producer queue. This will add a small amount of overhead to various operations. Secondly, in order to accommodate the very common case where a channel is used just once, we optimize the single-send use case to not allocate. Essentially, we store a single element directly in the shared state between the channel and port. This restores the `oneshot` functionality we lost in the last channel rewrite. Again, this will add a small amount of overhead to some operations, though possibly not above the overhead incurred by combining `Chan` and `SharedChan`. Finally, my main suggestion about how to deal with OOM, let's put an arbitrary bound to the size of the queue on `Chan`. This isn't to say let's turn `Chan` into a bounded queue (which is difficult for implementation reasons), but instead that we add a feature that helps debug when you've actually chosen the wrong kind of channel because your producer sends without bound. When you hit this bound the send will fail and you know that you need to think harder about the behavior of this particular channel. If you *really* want an unbounded channel then you can construct it with `Chan::unbounded`, otherwise you pick ... # Synchronous and bounded channels Let's add `SyncChan` which is a bounded multi-producer single-consumer queue backed by a ring buffer. This supports `send`, which blocks by default, and `try_send` which returns an enum representing whether the send succeeded, the channel is full, or the channel is closed (the last two cases returning the message). In the special case where the channel bound is 0, we don't use a ringbuffer and just do a rendezvousing send and recieve. The default bound is 0. Comments? Regards, Brian From jack at metajack.im Mon Jan 13 19:25:53 2014 From: jack at metajack.im (Jack Moffitt) Date: Mon, 13 Jan 2014 20:25:53 -0700 Subject: [rust-dev] Rust docs for 0.8: "No idea what this does" In-Reply-To: References: Message-ID: The explanation was already given by Corey. It was a normal comment but mistakenly got promoted by someone to a doc comment. Perhaps it was a search and replace gone wrong. At least it was amusing :) jack. On Mon, Jan 13, 2014 at 7:17 PM, Andrew Pennebaker wrote: > I won't bother using git blame, it's just weird to see such comments in doc > files. If you don't know what something does, why not leave it blank? > > On Jan 13, 2014 9:03 PM, "Steve Klabnik" wrote: >> >> No reason to be so harsh, especially since they've been improved. >> There is a way you can find out, but I'm not telling you. >> >> I love 'these docs are poor' comments, as they help me figure out what >> needs to be improved, but there's no reason to pick something that's >> already been fixed and try to make someone feel bad. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From olson.jeffery at gmail.com Mon Jan 13 20:09:58 2014 From: olson.jeffery at gmail.com (Jeffery Olson) Date: Mon, 13 Jan 2014 20:09:58 -0800 Subject: [rust-dev] RFC: New Rust channel proposal In-Reply-To: <52D4A564.4090602@mozilla.com> References: <52D4A564.4090602@mozilla.com> Message-ID: This is a great proposal, Brian. I have no criticisms of the proposal itself, feeling that it's a level-headed response to the previous threads on this issue. But I do have a request (something I know Daniel Micay brought up in #rust): What would it take to get shared-Port like functionality in a similar fashion to the "upgradable" shared-Chan? I think multi-producer, multi-consumer would be pretty swell as within reach defaults. I understand, in previous runtime implementations, doing sendable Ports was pretty much Out Of The Question. I'm curious if things have changed enough to warrant revisiting to see if it's worth it? Do you think it's a bridge too far? I know this distracts from the current issue that your proposal is addressing and I apologize for that. I'm just curious if it's worth throwing into the mix. As it currently stands, though, your proposal gets a +1 from me. Cheers On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote: > In light of the general consensus that unbounded channels are not so hot, > here's a new proposal for how Rust's channels should operate. This is based > on the following assumptions: > > * Running out of memory is an awful failure mode for debugging. > * Choosing an appropriate bounded queue size is hard. > * Dealing with backpressure is hard. > * Most channels are not filled without bound. > > This proposal has two facets: making the current channels appropriate for > more use cases; adding additional channel types for specialized use cases. > I'm still operating under the premise that there should be a "default" > channel type that can be successfully used in most instances, and people > should only need to pick something else when their message passing behavior > calls for it. Not all of these recommendations are about resolving the > unbounded channel debate. > > # Changes to `Chan` > > Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up > some of our complexity budget to add more channel types, and partly a > concession to usability. A cloned channel will automatically upgrade itself > to a multi-producer queue. This will add a small amount of overhead to > various operations. > > Secondly, in order to accommodate the very common case where a channel is > used just once, we optimize the single-send use case to not allocate. > Essentially, we store a single element directly in the shared state between > the channel and port. This restores the `oneshot` functionality we lost in > the last channel rewrite. Again, this will add a small amount of overhead > to some operations, though possibly not above the overhead incurred by > combining `Chan` and `SharedChan`. > > Finally, my main suggestion about how to deal with OOM, let's put an > arbitrary bound to the size of the queue on `Chan`. This isn't to say let's > turn `Chan` into a bounded queue (which is difficult for implementation > reasons), but instead that we add a feature that helps debug when you've > actually chosen the wrong kind of channel because your producer sends > without bound. > > When you hit this bound the send will fail and you know that you need to > think harder about the behavior of this particular channel. If you *really* > want an unbounded channel then you can construct it with `Chan::unbounded`, > otherwise you pick ... > > # Synchronous and bounded channels > > Let's add `SyncChan` which is a bounded multi-producer single-consumer > queue backed by a ring buffer. This supports `send`, which blocks by > default, and `try_send` which returns an enum representing whether the send > succeeded, the channel is full, or the channel is closed (the last two > cases returning the message). In the special case where the channel bound > is 0, we don't use a ringbuffer and just do a rendezvousing send and > recieve. The default bound is 0. > > Comments? > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Mon Jan 13 20:56:29 2014 From: comexk at gmail.com (comex) Date: Mon, 13 Jan 2014 23:56:29 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Message-ID: On Mon, Jan 13, 2014 at 4:06 PM, Tobias M?ller wrote: > int + int = int > ... > > If the result does not fit into an int the compiler throws an error. > To resolve an error, you can: > - annotate the operands with appropriate bounds > - use a bigger type for the operation and check the result. I remember wondering whether this type of solution would be feasible or too much of a hassle in practice. As I see it, many values which might be arithmetic operands are sizes or counts, and really ought to be size_t sized, and any mutable variable which is operated on in a loop can't be bounded with a lot more complexity, so it might lean toward the latter. From com.liigo at gmail.com Mon Jan 13 22:15:52 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Tue, 14 Jan 2014 14:15:52 +0800 Subject: [rust-dev] RFC: New Rust channel proposal In-Reply-To: <52D4A564.4090602@mozilla.com> References: <52D4A564.4090602@mozilla.com> Message-ID: People should rethink the Chan api that Chan::new() does not returns a value of type Chan (instead, a tuple), which is strange, and inconsistent with other Type::new(). 2014/1/14 Brian Anderson > In light of the general consensus that unbounded channels are not so hot, > here's a new proposal for how Rust's channels should operate. This is based > on the following assumptions: > > * Running out of memory is an awful failure mode for debugging. > * Choosing an appropriate bounded queue size is hard. > * Dealing with backpressure is hard. > * Most channels are not filled without bound. > > This proposal has two facets: making the current channels appropriate for > more use cases; adding additional channel types for specialized use cases. > I'm still operating under the premise that there should be a "default" > channel type that can be successfully used in most instances, and people > should only need to pick something else when their message passing behavior > calls for it. Not all of these recommendations are about resolving the > unbounded channel debate. > > # Changes to `Chan` > > Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up > some of our complexity budget to add more channel types, and partly a > concession to usability. A cloned channel will automatically upgrade itself > to a multi-producer queue. This will add a small amount of overhead to > various operations. > > Secondly, in order to accommodate the very common case where a channel is > used just once, we optimize the single-send use case to not allocate. > Essentially, we store a single element directly in the shared state between > the channel and port. This restores the `oneshot` functionality we lost in > the last channel rewrite. Again, this will add a small amount of overhead > to some operations, though possibly not above the overhead incurred by > combining `Chan` and `SharedChan`. > > Finally, my main suggestion about how to deal with OOM, let's put an > arbitrary bound to the size of the queue on `Chan`. This isn't to say let's > turn `Chan` into a bounded queue (which is difficult for implementation > reasons), but instead that we add a feature that helps debug when you've > actually chosen the wrong kind of channel because your producer sends > without bound. > > When you hit this bound the send will fail and you know that you need to > think harder about the behavior of this particular channel. If you *really* > want an unbounded channel then you can construct it with `Chan::unbounded`, > otherwise you pick ... > > # Synchronous and bounded channels > > Let's add `SyncChan` which is a bounded multi-producer single-consumer > queue backed by a ring buffer. This supports `send`, which blocks by > default, and `try_send` which returns an enum representing whether the send > succeeded, the channel is full, or the channel is closed (the last two > cases returning the message). In the special case where the channel bound > is 0, we don't use a ringbuffer and just do a rendezvousing send and > recieve. The default bound is 0. > > Comments? > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Jan 13 22:19:30 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 14 Jan 2014 01:19:30 -0500 Subject: [rust-dev] Impact of -ftrapv on Firefox In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 8:19 PM, Robert O'Callahan wrote: > > Thanks for catching that. My experiments indicate that -ftrapv works in gcc > for x86 but not x86-64. Which explains why the Firefox try builds only work > for x86-64. Which makes sense, since Firefox contains code that would depend > on overflow wrapping around. That's a bit scary since `-ftrapv` is only for signed integers and it's probably not using `-fwrapv` to make it defined :). From comexk at gmail.com Tue Jan 14 01:29:17 2014 From: comexk at gmail.com (comex) Date: Tue, 14 Jan 2014 04:29:17 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis wrote: > Again, note that this rather long thread is about discussing in the end what > the official stance should be. There is no valid reason other than lack of > manpower and / or language immaturity for having to depend on ruby, python, > autotools, cmake or whatever else in order to build rust software. There is no reason every language should have its own build system written from scratch (or package manager, for that matter); the goals of each language community are really mostly identical, and the existing duplication leads to software that's worse than it has to be (e.g. inconsistent support for signed packages), a waste of time relearning the same concepts for multiple build systems / package managers, and difficulty for packages that include code written in multiple languages. Meanwhile, satisfying the dependencies you mentioned is trivial on most systems. However, I'd say there is a stunning lack of existing build systems that actually combine a clean design, flexibility, portability, and performance. autotools fails badly on design, performance, and (ironically) portability; cmake fails on design (seriously, try to read any cmake script) and flexibility (a lot of stuff is hard coded in C++ and hard to change); most of the alternatives I know about are at least slow, and often poorly maintained, insufficiently general, et cetera. The only build tool I really like is ninja, and it's designed to be used with input generated from a separate tool rather than alone. So I'd personally like to see a new build system regardless. From gaetan at xeberon.net Tue Jan 14 02:03:49 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 11:03:49 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: > > However, I'd say there is a stunning lack of existing build systems > that actually combine a clean design, flexibility, portability, and > performance. autotools fails badly on design, performance, and > (ironically) portability; cmake fails on design (seriously, try to > read any cmake script) Same than any language, you can write bloated code or quite pretty things. Just be consistent and think reusability > and flexibility (a lot of stuff is hard coded > in C++ and hard to change); I don't see what you say is hardcoded? At worst, I simply had to rewrite a import module. > most of the alternatives I know about are > at least slow, and often poorly maintained, insufficiently general, et > cetera. The only build tool I really like is ninja, and it's > designed to be used with input generated from a separate tool rather > than alone. So I'd personally like to see a new build system regardless. > I also agree that having a proper build system sounds sexy, however do the rust dev team has enough man power for that? Why not try to assemble a task that will evaluate several existing build system instead of just trolling in this thread, to see exactly what are the advantages and flaws of each candidates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Tue Jan 14 08:09:55 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Tue, 14 Jan 2014 18:09:55 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: Rust is early in its lifecycle as a language and at a stage where useful applications implemented in it are about to break ground. Deciding on a build system without the multitude of pitfalls that affect curent status quo solutions is detrimental to the language now, not after it has established its own legacy. Your argument can be generalized into language design. By analogy, we should all stick to what we know, depend on older languages and multitudes of dependencies because they work well. If you consider Rust a systems language, surely you see how bizzare - if not somewhat ludicrous - it will sound for Rust to have an *official* (which this thread is all about) build system that needs language relic X to work. You do conclude however in indeed wanting to see some new build system beyond the usual graph theory rehash. On that, we agree. Rust is capable of doing this just for Rust. comex wrote: >On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis > wrote: >> Again, note that this rather long thread is about discussing in the >end what >> the official stance should be. There is no valid reason other than >lack of >> manpower and / or language immaturity for having to depend on ruby, >python, >> autotools, cmake or whatever else in order to build rust software. > >There is no reason every language should have its own build system >written from scratch (or package manager, for that matter); the goals >of each language community are really mostly identical, and the >existing duplication leads to software that's worse than it has to be >(e.g. inconsistent support for signed packages), a waste of time >relearning the same concepts for multiple build systems / package >managers, and difficulty for packages that include code written in >multiple languages. Meanwhile, satisfying the dependencies you >mentioned is trivial on most systems. > >However, I'd say there is a stunning lack of existing build systems >that actually combine a clean design, flexibility, portability, and >performance. autotools fails badly on design, performance, and >(ironically) portability; cmake fails on design (seriously, try to >read any cmake script) and flexibility (a lot of stuff is hard coded >in C++ and hard to change); most of the alternatives I know about are >at least slow, and often poorly maintained, insufficiently general, et >cetera. The only build tool I really like is ninja, and it's >designed to be used with input generated from a separate tool rather >than alone. So I'd personally like to see a new build system >regardless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Tue Jan 14 08:22:58 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Tue, 14 Jan 2014 18:22:58 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: <3beb6623-1e7c-41bf-aa15-785f25d72e32@email.android.com> Lack of manpower. Correct. As I have written elsewhere in these threads, this is why an interim solution of a third party tool should perhaps be choosen, instead of sactioning a build system in any language relic X as the official tool. Closer to 1.0, the need will become more apparent. I do not see a task team / working group proposing this and in order for any official guideline to be followed, this is a step to be taken. Wasn't this the purpose of this thread? Perhaps this is what comex is trying to say, albeit with his own peculiar rhetorical structure - I doubt that anybody is "trolling", knowingly. I still think that for the intended scope, Rust should just need Rust. Gaetan wrote: >> >> However, I'd say there is a stunning lack of existing build systems >> that actually combine a clean design, flexibility, portability, and >> performance. autotools fails badly on design, performance, and >> (ironically) portability; cmake fails on design (seriously, try to >> read any cmake script) > >Same than any language, you can write bloated code or quite pretty >things. >Just be consistent and think reusability > > >> and flexibility (a lot of stuff is hard coded >> in C++ and hard to change); > >I don't see what you say is hardcoded? At worst, I simply had to >rewrite a >import module. > > >> most of the alternatives I know about are >> at least slow, and often poorly maintained, insufficiently general, >et >> cetera. The only build tool I really like is ninja, and it's >> designed to be used with input generated from a separate tool rather >> than alone. So I'd personally like to see a new build system >regardless. >> > >I also agree that having a proper build system sounds sexy, however do >the >rust dev team has enough man power for that? > >Why not try to assemble a task that will evaluate several existing >build >system instead of just trolling in this thread, to see exactly what are >the >advantages and flaws of each candidates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Jan 14 08:28:49 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 17:28:49 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <3beb6623-1e7c-41bf-aa15-785f25d72e32@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <3beb6623-1e7c-41bf-aa15-785f25d72e32@email.android.com> Message-ID: rust need llvm, make, wget, bash script, python, autotools... it's just a matter of choice of which external tool you accept to rely on.... ----- Gaetan 2014/1/14 George Makrydakis > Lack of manpower. Correct. As I have written elsewhere in these threads, > this is why an interim solution of a third party tool should perhaps be > choosen, instead of sactioning a build system in any language relic X as > the official tool. > > Closer to 1.0, the need will become more apparent. I do not see a task > team / working group proposing this and in order for any official guideline > to be followed, this is a step to be taken. Wasn't this the purpose of this > thread? > > Perhaps this is what comex is trying to say, albeit with his own peculiar > rhetorical structure - I doubt that anybody is "trolling", knowingly. I > still think that for the intended scope, Rust should just need Rust. > > > Gaetan wrote: >> >> However, I'd say there is a stunning lack of existing build systems >>> that actually combine a clean design, flexibility, portability, and >>> performance. autotools fails badly on design, performance, and >>> (ironically) portability; cmake fails on design (seriously, try to >>> read any cmake script) >> >> Same than any language, you can write bloated code or quite pretty >> things. Just be consistent and think reusability >> >> >>> and flexibility (a lot of stuff is hard coded >>> in C++ and hard to change); >> >> I don't see what you say is hardcoded? At worst, I simply had to rewrite >> a import module. >> >> >>> most of the alternatives I know about are >>> at least slow, and often poorly maintained, insufficiently general, et >>> cetera. The only build tool I really like is ninja, and it's >>> designed to be used with input generated from a separate tool rather >>> than alone. So I'd personally like to see a new build system regardless. >>> >> >> I also agree that having a proper build system sounds sexy, however do >> the rust dev team has enough man power for that? >> >> Why not try to assemble a task that will evaluate several existing build >> system instead of just trolling in this thread, to see exactly what are the >> advantages and flaws of each candidates? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Jan 14 09:15:32 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 18:15:32 +0100 Subject: [rust-dev] sticker Message-ID: Just came accross this good presentation: http://www.youtube.com/watch?v=gfCtbGiHcg0 A question poped into my head: where could I find rust stickers ? ----- Gaetan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Tue Jan 14 09:25:16 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 14 Jan 2014 09:25:16 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> Message-ID: <52D572FC.5050200@mozilla.com> On 1/14/14 1:29 AM, comex wrote: > On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis > wrote: >> Again, note that this rather long thread is about discussing in the end what >> the official stance should be. There is no valid reason other than lack of >> manpower and / or language immaturity for having to depend on ruby, python, >> autotools, cmake or whatever else in order to build rust software. > > There is no reason every language should have its own build system > written from scratch (or package manager, for that matter); the goals > of each language community are really mostly identical, and the > existing duplication leads to software that's worse than it has to be > (e.g. inconsistent support for signed packages), a waste of time > relearning the same concepts for multiple build systems / package > managers, and difficulty for packages that include code written in > multiple languages. Meanwhile, satisfying the dependencies you > mentioned is trivial on most systems. > > However, I'd say there is a stunning lack of existing build systems > that actually combine a clean design, flexibility, portability, and > performance. autotools fails badly on design, performance, and > (ironically) portability; cmake fails on design (seriously, try to > read any cmake script) and flexibility (a lot of stuff is hard coded > in C++ and hard to change); most of the alternatives I know about are > at least slow, and often poorly maintained, insufficiently general, et > cetera. The only build tool I really like is ninja, and it's > designed to be used with input generated from a separate tool rather > than alone. So I'd personally like to see a new build system regardless. This e-mail sums up my feelings to a T, and it's why I'm conflicted about the whole matter. Patrick From wichard at vitalitystudios.com Tue Jan 14 09:33:30 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Tue, 14 Jan 2014 11:33:30 -0600 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling Message-ID: Basically the idea here is to support shuffling for SIMD types in a way that can be easily lowered to IR (LLVM's shufflevector requires the mask be a vector of constants, so an intrinsic function is out of the question), however I image this sugar could extend to tuples with multiple types. Some examples: let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0, 0, 0)"? assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); let single_x = vec -> (0); assert_eq!(single_x, (1.0f32)); let mut vec = vec; vec <- (0) = 5.0f32; // set x only vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); let vec = vec; // the mask may be arbitrarily long: assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, 5.0f32)); // leaves vec unchanged let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); // functional_update would take it's type from vec assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); A couple of things would need to be disallowed, however: let mut vec = vec; // no duplicate assignments/functional updates: vec <- (0, 0) = (..); let _ = vec -> (0, 1, 2, 3, 0) .. (..); // no out-of-bounds: vec <- (5, 9000) = (..); let _ = vec -> (5, 9001); let _ = vec -> (5, 9002) .. (..); let _ = vec -> (0, 1, 2, 3, 4) .. (..); // all mask values must be a const expr: let mut non_const_expr = 15; vec <- (non_const_expr) = (..); let _ = vec -> (non_const_expr) .. (..); let _ = vec -> (non_const_expr); // mismatched tuple sizes: vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); let _ = vec -> (0) .. (0.0f32, 0.0f32); AIUI, the notation would be: tuple_mask : '(' integer [ ',' integer ] * ')' ; tuple_expr : '(' expr [ ',' expr ] * ')' | tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; I'm willing to write this myself, but I'd like some consensus/feedback regarding ze proposed sugar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flaper87 at gmail.com Tue Jan 14 09:53:24 2014 From: flaper87 at gmail.com (Flaper87) Date: Tue, 14 Jan 2014 18:53:24 +0100 Subject: [rust-dev] sticker In-Reply-To: References: Message-ID: 2014/1/14 Gaetan > Just came accross this good presentation: > http://www.youtube.com/watch?v=gfCtbGiHcg0 > > A question poped into my head: where could I find rust stickers ? > I was wondering the same thing! I love stickers and I definitely want a Rust sticker :D -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Tue Jan 14 10:25:50 2014 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue, 14 Jan 2014 10:25:50 -0800 Subject: [rust-dev] sticker In-Reply-To: References: Message-ID: If you organize a Rust meetup near you and email Brian Anderson or one of the other core Rust developers who work for Mozilla, I suspect they would be happy to send you a batch of stickers to hand out. That's one way, anyway :-) Cheers, Tim On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 wrote: > > > > 2014/1/14 Gaetan >> >> Just came accross this good presentation: >> http://www.youtube.com/watch?v=gfCtbGiHcg0 >> >> A question poped into my head: where could I find rust stickers ? > > > I was wondering the same thing! I love stickers and I definitely want a Rust > sticker :D > > > > -- > Flavio (@flaper87) Percoco > http://www.flaper87.com > http://github.com/FlaPer87 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at 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 From bascule at gmail.com Tue Jan 14 10:37:49 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 14 Jan 2014 10:37:49 -0800 Subject: [rust-dev] sticker In-Reply-To: References: Message-ID: Have you considered selling the stickers through something like DevSwag.com? I'm sure Yehuda can get you connected ;) On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier wrote: > If you organize a Rust meetup near you and email Brian Anderson or one > of the other core Rust developers who work for Mozilla, I suspect they > would be happy to send you a batch of stickers to hand out. That's one > way, anyway :-) > > Cheers, > Tim > > On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 wrote: > > > > > > > > 2014/1/14 Gaetan > >> > >> Just came accross this good presentation: > >> http://www.youtube.com/watch?v=gfCtbGiHcg0 > >> > >> A question poped into my head: where could I find rust stickers ? > > > > > > I was wondering the same thing! I love stickers and I definitely want a > Rust > > sticker :D > > > > > > > > -- > > Flavio (@flaper87) Percoco > > http://www.flaper87.com > > http://github.com/FlaPer87 > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at 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 at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Tue Jan 14 10:42:59 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 14 Jan 2014 10:42:59 -0800 Subject: [rust-dev] RFC: New Rust channel proposal In-Reply-To: <52D4A564.4090602@mozilla.com> References: <52D4A564.4090602@mozilla.com> Message-ID: On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote: > Let's add `SyncChan` which is a bounded multi-producer single-consumer > queue backed by a ring buffer. This supports `send`, which blocks by > default, and `try_send` which returns an enum representing whether the send > succeeded, the channel is full, or the channel is closed (the last two > cases returning the message). In the special case where the channel bound > is 0, we don't use a ringbuffer and just do a rendezvousing send and > recieve. The default bound is 0. Nice! This sounds awesome. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 11:07:34 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 14:07:34 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: Neat proposal: thoughts 0) seems like you need to add a notion of const expr to the type system for this proposal, right? I started staring at that and it's pretty subtle (though I may have been looking at it wrong) 1) do rust tuples actually map to the llvm simd vector types? 2) so this would require some special syntax support right? Could it be prototyped with a procedural macro plus having the shuffle ast code generated internally? 3) would the internal rep properly treat the shuffle mask ints as part of the op itself so that it won't get cse'd or the like? 4) would the syntax do a type / syntax error when you use a tuple position index that's too large? 5) the llvm shuffle vector intrinsic takes two vectors of values and let's you express interleaving them, not just rearranging a single one (which seems to be a restriction on your example). Both styles matter, and respectively correspond to different platform specific shuffle instructions I like the idea of something like this, and it's definitely simpler than the shuffle proposals I've been trying to draft, though using a word like "shuffle" may be. Though it doesn't give a way to use the same idea for someone using the platform specific shuffle intrinsics that hopefully would be added eventually. (Any such platform specific intrinsics would be for fixed tuple size and type). *An Alternative approach*? *Int * One way around the const expr requirement for the type system that someone suggested was pretty neat: expose the various platform specific simd shuffle ops, an have their shuffle mask int args actually be "type args". Apparently there's some protean support for type level numbers because of sized vectors, and because rust requires all generics to be monomorphized, this actually would capture the right "constness at compile time" an example of this idea would be to take the VSHUFPD intel instruction (in the intel architecture), and modify the intrinsic from the c code version (nb: __m256d == v4f64 in rust parlance) __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select); into fn _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d I'm not sure how such a type level int application would work out, but It may be the nicest way to conservatively add type safe SIMD shuffle primops to rust, though I could be completely wrong. (I was initially meh on this type application idea, but its grown on me, it exploits the way rust generics work very very nicely!) *note* while exposing the architecture specific intrinsics would be bit more work, it would also mean that the SIMD support in rust have a more transparent mapping to various architectures, allow better architecture/cpu microarchitecture based tuning (writing an version of BLIS http://code.google.com/p/blis/ in rust might be a good stress test), and it'd be less coupled to the vagaries of how LLVM lowers the shuffle instruction to the target architecture. This actually matters in the context of writing code that uses the "optimal" instruction sequence by detecting the cpu micro architecture at runtime and branching to the tune variant internally, something OpenBLAS does very nicely, see here for examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64 That said, having a systematic way to support the llvm shuffle intrinsic In it's full generality would be lovely, it's a much more friendly operation that people can use to get started with doing simd in a somewhat user friendly way. point being: I support there being better shuffle simd support / simd support period :), though how to do it best seems unclear to me (and theres also a few ways that arent good too) -Carter On Tuesday, January 14, 2014, Richard Diamond wrote: > Basically the idea here is to support shuffling for SIMD types in a way > that can be easily lowered to IR (LLVM's shufflevector requires the mask be > a vector of constants, so an intrinsic function is out of the question), > however I image this sugar could extend to tuples with multiple types. > > Some examples: > > let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); > let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0, > 0, 0)"? > assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); > let single_x = vec -> (0); > assert_eq!(single_x, (1.0f32)); > > let mut vec = vec; > vec <- (0) = 5.0f32; // set x only > vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z > assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); > > let vec = vec; > // the mask may be arbitrarily long: > assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, > 5.0f32)); > > // leaves vec unchanged > let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); > // functional_update would take it's type from vec > assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); > assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); > > A couple of things would need to be disallowed, however: > > let mut vec = vec; > // no duplicate assignments/functional updates: > vec <- (0, 0) = (..); > let _ = vec -> (0, 1, 2, 3, 0) .. (..); > // no out-of-bounds: > vec <- (5, 9000) = (..); > let _ = vec -> (5, 9001); > let _ = vec -> (5, 9002) .. (..); > let _ = vec -> (0, 1, 2, 3, 4) .. (..); > // all mask values must be a const expr: > let mut non_const_expr = 15; > vec <- (non_const_expr) = (..); > let _ = vec -> (non_const_expr) .. (..); > let _ = vec -> (non_const_expr); > // mismatched tuple sizes: > vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); > let _ = vec -> (0) .. (0.0f32, 0.0f32); > > AIUI, the notation would be: > tuple_mask : '(' integer [ ',' integer ] * ')' ; > tuple_expr : '(' expr [ ',' expr ] * ')' | > tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; > > I'm willing to write this myself, but I'd like some consensus/feedback > regarding ze proposed sugar. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Tue Jan 14 11:35:07 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Tue, 14 Jan 2014 20:35:07 +0100 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Message-ID: On Tue, Jan 14, 2014 at 5:56 AM, comex wrote: > On Mon, Jan 13, 2014 at 4:06 PM, Tobias M?ller wrote: > > int + int = int > > ... > > > > If the result does not fit into an int the compiler throws an error. > > To resolve an error, you can: > > - annotate the operands with appropriate bounds > > - use a bigger type for the operation and check the result. > > I remember wondering whether this type of solution would be feasible > or too much of a hassle in practice. As I see it, many values which > might be arithmetic operands are sizes or counts, and really ought to > be size_t sized, and any mutable variable which is operated on in a > loop can't be bounded with a lot more complexity, so it might lean > toward the latter. It's indeed a risk that such an annotation might be too annoying (especially since addition is actually quite easy, the bounds grow faster on multiplication)... but on the other hand, you do need dynamic checks anyway to verify that the value of type "u32<0, 4_294_967_295>" won't overflow if you multiply it by "3". So as I see it, you can do either of: "let result = to>(size) * 3;" OR "let result = to(to(size) * 3);". Of course, compared to "let result = size * 3;" it seems the annotation tax is high, however the latter may overflow (and wrap, certainly, but that is still a bogus answer in most languages). So, maybe it one could just use a couple primitives: - wrapping integers (for hashes) - saturating integers (useful for colors) - fail-on-overflow integers - compile-time range-checked integers u32w, u32s, u32o and u32c ? Note: as far as I know Rust *plans* on having non-type template parameters but does not have them yet, so the compile-time range-checked integers are out of question for now. Note 2: having all those in the core language would be unnecessary if the syntax 3u32c () was sugar coating for u32c::new(3) like C++ suffix literals; with "new" using some "default" integer type (I vote for the fail-on-overflow, it catches the bugs) and the compiler verifying that the "raw" number can be expressed in that "default" integer type perfectly. Then libraries could add the other modes. -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 11:35:32 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 19:35:32 +0000 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> Message-ID: <52D59184.7090008@gmail.com> On 14/01/14 01:50, Palmer Cox wrote: > > On Mon, Jan 13, 2014 at 12:18 PM, Tobias M?ller > wrote: > > Daniel Micay > wrote: > > Do you know what undefined behavior is? It doesn't mean unspecified. > > True, but despite beeing so often cited it won't format your hard disk > (even in C). > Actually, it's possible, at least on systems without MMU protection --- some embedded systems, for example. Ints are often used (not just in your own code but in library code) to index a jump table. If that index is a different number than you expected it to be, you could end up executing calling random "functions" in memory. Said "functions" could (and probably would) crash within 1--2 instructions, but even then, it's not INCONCEIVABLE that those instructions could equate to "1) load hard drive device number into the first arg register; 2) call the OS format_drive function". This all leaves the realm of remote possibility and enters the realm of unacceptable risk, at least for some software on some systems, when you factor in malicious individuals trying to manipulate what address gets called and/or what code is sitting at the address called, waiting to execute. As I understand it, there are essentially three bugs that can cause a segfault: 1) write to memory you're not allowed to write to. 2) read memory you're not allowed to read from. 3) execute code in memory you're not allowed to execute code from. The third kind of bug is basically saying "do anything you like computer, I don't care." It's very much undefined behaviour, very much like calling a function pointer that's NULL. Mostly, you get a segfault, thanks to the MMU, but in portable code, you can't depend on that -- either the compiler handles it, or you have to remember to check everything carefully, treating your coding environment as a hostile one, full of adversaries. -- Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 11:46:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 14:46:37 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: to further elaborate, from the perspective of translating the syntax to llvm ir, the proposal seem to correspond to shuffleVector(aV,aV,maskVectorLiteral), while the llvm instruction allows shuffleVector(aV,bV,maskVectorLiteral), and you need the latter to express stuff like the _mm256_shuffle_pd operation! http://llvm.org/docs/LangRef.html#shufflevector-instruction On Tue, Jan 14, 2014 at 2:07 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Neat proposal: > thoughts > 0) seems like you need to add a notion of const expr to the type system > for this proposal, right? I started staring at that and it's pretty subtle > (though I may have been looking at it wrong) > > 1) do rust tuples actually map to the llvm simd vector types? > 2) so this would require some special syntax support right? Could it be > prototyped with a procedural macro plus having the shuffle ast code > generated internally? > 3) would the internal rep properly treat the shuffle mask ints as part of > the op itself so that it won't get cse'd or the like? > 4) would the syntax do a type / syntax error when you use a tuple position > index that's too large? > > 5) the llvm shuffle vector intrinsic takes two vectors of values and let's > you express interleaving them, not just rearranging a single one (which > seems to be a restriction on your example). Both styles matter, and > respectively correspond to different platform specific shuffle instructions > > I like the idea of something like this, and it's definitely simpler than > the shuffle proposals I've been trying to draft, though using a word like > "shuffle" may be. Though it doesn't give a way to use the same idea for > someone using the platform specific shuffle intrinsics that hopefully would > be added eventually. (Any such platform specific intrinsics would be for > fixed tuple size and type). > > *An Alternative approach*? *Int * > > One way around the const expr requirement for the type system that someone > suggested was pretty neat: expose the various platform specific simd > shuffle ops, an have their shuffle mask int args actually be "type args". > Apparently there's some protean support for type level numbers because of > sized vectors, and because rust requires all generics to be monomorphized, > this actually would capture the right "constness at compile time" > > an example of this idea would be to take the VSHUFPD intel instruction (in > the intel architecture), and modify the intrinsic from the c code version > > (nb: __m256d == v4f64 in rust parlance) > __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select); > > into > > fn _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d > > I'm not sure how such a type level int application would work out, but It > may be the nicest way to conservatively add type safe SIMD shuffle primops > to rust, though I could be completely wrong. (I was initially meh on this > type application idea, but its grown on me, it exploits the way rust > generics work very very nicely!) > > *note* while exposing the architecture specific intrinsics would be bit > more work, it would also mean that the SIMD support in rust have a more > transparent mapping to various architectures, allow better architecture/cpu > microarchitecture based tuning (writing an version of BLIS > http://code.google.com/p/blis/ in rust might be a good stress test), and > it'd be less coupled to the vagaries of how LLVM lowers the shuffle > instruction to the target architecture. This actually matters in the > context of writing code that uses the "optimal" instruction sequence by > detecting the cpu micro architecture at runtime and branching to the tune > variant internally, something OpenBLAS does very nicely, see here for > examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64 > > That said, having a systematic way to support the llvm shuffle intrinsic > In it's full generality would be lovely, it's a much more friendly > operation that people can use to get started with doing simd in a somewhat > user friendly way. > > point being: I support there being better shuffle simd support / simd > support period :), though how to do it best seems unclear to me (and > theres also a few ways that arent good too) > -Carter > > > On Tuesday, January 14, 2014, Richard Diamond wrote: > >> Basically the idea here is to support shuffling for SIMD types in a way >> that can be easily lowered to IR (LLVM's shufflevector requires the mask be >> a vector of constants, so an intrinsic function is out of the question), >> however I image this sugar could extend to tuples with multiple types. >> >> Some examples: >> >> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); >> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0, >> 0, 0)"? >> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); >> let single_x = vec -> (0); >> assert_eq!(single_x, (1.0f32)); >> >> let mut vec = vec; >> vec <- (0) = 5.0f32; // set x only >> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z >> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >> >> let vec = vec; >> // the mask may be arbitrarily long: >> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, >> 5.0f32)); >> >> // leaves vec unchanged >> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); >> // functional_update would take it's type from vec >> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); >> >> A couple of things would need to be disallowed, however: >> >> let mut vec = vec; >> // no duplicate assignments/functional updates: >> vec <- (0, 0) = (..); >> let _ = vec -> (0, 1, 2, 3, 0) .. (..); >> // no out-of-bounds: >> vec <- (5, 9000) = (..); >> let _ = vec -> (5, 9001); >> let _ = vec -> (5, 9002) .. (..); >> let _ = vec -> (0, 1, 2, 3, 4) .. (..); >> // all mask values must be a const expr: >> let mut non_const_expr = 15; >> vec <- (non_const_expr) = (..); >> let _ = vec -> (non_const_expr) .. (..); >> let _ = vec -> (non_const_expr); >> // mismatched tuple sizes: >> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); >> let _ = vec -> (0) .. (0.0f32, 0.0f32); >> >> AIUI, the notation would be: >> tuple_mask : '(' integer [ ',' integer ] * ')' ; >> tuple_expr : '(' expr [ ',' expr ] * ')' | >> tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; >> >> I'm willing to write this myself, but I'd like some consensus/feedback >> regarding ze proposed sugar. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wichard at vitalitystudios.com Tue Jan 14 12:06:57 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Tue, 14 Jan 2014 14:06:57 -0600 Subject: [rust-dev] Re: RFC: Tuple Swizzling/Shuffling Message-ID: On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Neat proposal: > thoughts > 0) seems like you need to add a notion of const expr to the type system > for this proposal, right? I started staring at that and it's pretty subtle > (though I may have been looking at it wrong) > I did add the const expr notion a bit, but it's only in anticipation of somebody wanting to specify the mask in such terms. Of course, boarder support for const expr's would be required. 1) do rust tuples actually map to the llvm simd vector types? > They do with #[simd]. Though I think it would be worth considering whether all tuples of a single primitive type should be automatically considered #[simd] and be lowered to a LLVM vector type. In fact one way I'm considering impling this is to treat the mask as a tuple and lower it as a vector into a shufflevector mask operand. 2) so this would require some special syntax support right? Could it be > prototyped with a procedural macro plus having the shuffle ast code > generated internally? > Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a stage where tuple type info is known, so such a macro would only be able to operate on literals and still wouldn't be able to dictate trans. 3) would the internal rep properly treat the shuffle mask ints as part of > the op itself so that it won't get cse'd or the like? > Yes. 4) would the syntax do a type / syntax error when you use a tuple position > index that's too large? > Yes. > 5) the llvm shuffle vector intrinsic takes two vectors of values and let's > you express interleaving them, not just rearranging a single one (which > seems to be a restriction on your example). Both styles matter, and > respectively correspond to different platform specific shuffle instructions > Yeah, not even ten minutes after sending the proposal, I realized I had forgotten about that one detail. I'm not terribly fond of any of my envisioned solutions, but the best one uses the recently removed '@': let vec1 = (10, 11, 12, 13); let vec2 = (9, 8, 7, 6); let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think concATenate; it'll likely be thought of as such in rustc. As an aside, note the arrows point towards what type of value the expression is supposed to be (lvalue is <-, rvalue is ->). I like the idea of something like this, and it's definitely simpler than > the shuffle proposals I've been trying to draft, though using a word like > "shuffle" may be. Though it doesn't give a way to use the same idea for > someone using the platform specific shuffle intrinsics that hopefully would > be added eventually. (Any such platform specific intrinsics would be for > fixed tuple size and type). > Thank you! The intent is to lean on LLVM's platform independenceness; LLVM supports vectors (the SIMD type) of any length, so in an effort to be forward compatible with future SIMD sizes, offer a generic way to 'do the shuffle'. Access to more specialized shuffles could be done via functions with a #[link_name] attribute (because such instructions operate on operands of specific types anyway, they wouldn't be very amenable to a generic solution) in unstable::simd or an external library. But that's another project ;) > > *An Alternative approach*? *Int * > > One way around the const expr requirement for the type system that someone > suggested was pretty neat: expose the various platform specific simd > shuffle ops, an have their shuffle mask int args actually be "type args". > Apparently there's some protean support for type level numbers because of > sized vectors, and because rust requires all generics to be monomorphized, > this actually would capture the right "constness at compile time" > > an example of this idea would be to take the VSHUFPD intel instruction (in > the intel architecture), and modify the intrinsic from the c code version > > (nb: __m256d == v4f64 in rust parlance) > __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select); > > into > > fn _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d > > I'm not sure how such a type level int application would work out, but It > may be the nicest way to conservatively add type safe SIMD shuffle primops > to rust, though I could be completely wrong. (I was initially meh on this > type application idea, but its grown on me, it exploits the way rust > generics work very very nicely!) > > *note* while exposing the architecture specific intrinsics would be bit > more work, it would also mean that the SIMD support in rust have a more > transparent mapping to various architectures, allow better architecture/cpu > microarchitecture based tuning (writing an version of BLIS > http://code.google.com/p/blis/ in rust might be a good stress test), and > it'd be less coupled to the vagaries of how LLVM lowers the shuffle > instruction to the target architecture. This actually matters in the > context of writing code that uses the "optimal" instruction sequence by > detecting the cpu micro architecture at runtime and branching to the tune > variant internally, something OpenBLAS does very nicely, see here for > examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64 > > That said, having a systematic way to support the llvm shuffle intrinsic > In it's full generality would be lovely, it's a much more friendly > operation that people can use to get started with doing simd in a somewhat > user friendly way. > > point being: I support there being better shuffle simd support / simd > support period :), though how to do it best seems unclear to me (and > theres also a few ways that arent good too) > -Carter > > > On Tuesday, January 14, 2014, Richard Diamond wrote: > >> Basically the idea here is to support shuffling for SIMD types in a way >> that can be easily lowered to IR (LLVM's shufflevector requires the mask be >> a vector of constants, so an intrinsic function is out of the question), >> however I image this sugar could extend to tuples with multiple types. >> >> Some examples: >> >> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); >> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0, >> 0, 0)"? >> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); >> let single_x = vec -> (0); >> assert_eq!(single_x, (1.0f32)); >> >> let mut vec = vec; >> vec <- (0) = 5.0f32; // set x only >> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z >> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >> >> let vec = vec; >> // the mask may be arbitrarily long: >> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, >> 5.0f32)); >> >> // leaves vec unchanged >> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); >> // functional_update would take it's type from vec >> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); >> >> A couple of things would need to be disallowed, however: >> >> let mut vec = vec; >> // no duplicate assignments/functional updates: >> vec <- (0, 0) = (..); >> let _ = vec -> (0, 1, 2, 3, 0) .. (..); >> // no out-of-bounds: >> vec <- (5, 9000) = (..); >> let _ = vec -> (5, 9001); >> let _ = vec -> (5, 9002) .. (..); >> let _ = vec -> (0, 1, 2, 3, 4) .. (..); >> // all mask values must be a const expr: >> let mut non_const_expr = 15; >> vec <- (non_const_expr) = (..); >> let _ = vec -> (non_const_expr) .. (..); >> let _ = vec -> (non_const_expr); >> // mismatched tuple sizes: >> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); >> let _ = vec -> (0) .. (0.0f32, 0.0f32); >> >> AIUI, the notation would be: >> tuple_mask : '(' integer [ ',' integer ] * ')' ; >> tuple_expr : '(' expr [ ',' expr ] * ')' | >> tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; >> >> I'm willing to write this myself, but I'd like some consensus/feedback >> regarding ze proposed sugar. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Jan 14 12:09:43 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 14 Jan 2014 15:09:43 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond wrote: > > They do with #[simd]. Though I think it would be worth considering whether > all tuples of a single primitive type should be automatically considered > #[simd] and be lowered to a LLVM vector type. In fact one way I'm > considering impling this is to treat the mask as a tuple and lower it as a > vector into a shufflevector mask operand. This isn't possible due to alignment issues. Only very recent Intel CPUs lack the requirement of alignment for SIMD instructions. From carter.schonwald at gmail.com Tue Jan 14 12:14:01 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 15:14:01 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: good points all! why not have the operation just be shuffleSimdVector(a,b,masktuple) ? seems a bit more human friendly than a mix of @ and <- and -> I'm a bit confused about the l/rvalue remark, could you explain more? On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond < wichard at vitalitystudios.com> wrote: > > On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Neat proposal: >> thoughts >> 0) seems like you need to add a notion of const expr to the type system >> for this proposal, right? I started staring at that and it's pretty subtle >> (though I may have been looking at it wrong) >> > I did add the const expr notion a bit, but it's only in anticipation of > somebody wanting to specify the mask in such terms. Of course, boarder > support for const expr's would be required. > > 1) do rust tuples actually map to the llvm simd vector types? >> > They do with #[simd]. Though I think it would be worth considering whether > all tuples of a single primitive type should be automatically considered > #[simd] and be lowered to a LLVM vector type. In fact one way I'm > considering impling this is to treat the mask as a tuple and lower it as a > vector into a shufflevector mask operand. > > 2) so this would require some special syntax support right? Could it be >> prototyped with a procedural macro plus having the shuffle ast code >> generated internally? >> > Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a > stage where tuple type info is known, so such a macro would only be able to > operate on literals and still wouldn't be able to dictate trans. > > 3) would the internal rep properly treat the shuffle mask ints as part of >> the op itself so that it won't get cse'd or the like? >> > Yes. > > 4) would the syntax do a type / syntax error when you use a tuple position >> index that's too large? >> > Yes. > > >> 5) the llvm shuffle vector intrinsic takes two vectors of values and >> let's you express interleaving them, not just rearranging a single one >> (which seems to be a restriction on your example). Both styles matter, and >> respectively correspond to different platform specific shuffle instructions >> > Yeah, not even ten minutes after sending the proposal, I realized I had > forgotten about that one detail. I'm not terribly fond of any of my > envisioned solutions, but the best one uses the recently removed '@': > let vec1 = (10, 11, 12, 13); > let vec2 = (9, 8, 7, 6); > let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think > concATenate; it'll likely be thought of as such in rustc. > > As an aside, note the arrows point towards what type of value the > expression is supposed to be (lvalue is <-, rvalue is ->). > > I like the idea of something like this, and it's definitely simpler than >> the shuffle proposals I've been trying to draft, though using a word like >> "shuffle" may be. Though it doesn't give a way to use the same idea for >> someone using the platform specific shuffle intrinsics that hopefully would >> be added eventually. (Any such platform specific intrinsics would be for >> fixed tuple size and type). >> > Thank you! > The intent is to lean on LLVM's platform independenceness; LLVM supports > vectors (the SIMD type) of any length, so in an effort to be forward > compatible with future SIMD sizes, offer a generic way to 'do the shuffle'. > Access to more specialized shuffles could be done via functions with a > #[link_name] attribute (because such instructions operate on operands of > specific types anyway, they wouldn't be very amenable to a generic > solution) in unstable::simd or an external library. But that's another > project ;) > >> >> *An Alternative approach*? *Int * >> >> One way around the const expr requirement for the type system >> that someone suggested was pretty neat: expose the various platform >> specific simd shuffle ops, an have their shuffle mask int args actually be >> "type args". Apparently there's some protean support for type level numbers >> because of sized vectors, and because rust requires all generics to be >> monomorphized, this actually would capture the right "constness at compile >> time" >> > >> an example of this idea would be to take the VSHUFPD intel instruction >> (in the intel architecture), and modify the intrinsic from the c code >> version >> >> (nb: __m256d == v4f64 in rust parlance) >> __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select); >> >> into >> >> fn _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d >> >> I'm not sure how such a type level int application would work out, but It >> may be the nicest way to conservatively add type safe SIMD shuffle primops >> to rust, though I could be completely wrong. (I was initially meh on this >> type application idea, but its grown on me, it exploits the way rust >> generics work very very nicely!) >> >> *note* while exposing the architecture specific intrinsics would be bit >> more work, it would also mean that the SIMD support in rust have a more >> transparent mapping to various architectures, allow better architecture/cpu >> microarchitecture based tuning (writing an version of BLIS >> http://code.google.com/p/blis/ in rust might be a good stress test), and >> it'd be less coupled to the vagaries of how LLVM lowers the shuffle >> instruction to the target architecture. This actually matters in the >> context of writing code that uses the "optimal" instruction sequence by >> detecting the cpu micro architecture at runtime and branching to the tune >> variant internally, something OpenBLAS does very nicely, see here for >> examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64 >> >> That said, having a systematic way to support the llvm shuffle intrinsic >> In it's full generality would be lovely, it's a much more friendly >> operation that people can use to get started with doing simd in a somewhat >> user friendly way. >> >> point being: I support there being better shuffle simd support / simd >> support period :), though how to do it best seems unclear to me (and >> theres also a few ways that arent good too) >> -Carter >> >> >> On Tuesday, January 14, 2014, Richard Diamond wrote: >> >>> Basically the idea here is to support shuffling for SIMD types in a way >>> that can be easily lowered to IR (LLVM's shufflevector requires the mask be >>> a vector of constants, so an intrinsic function is out of the question), >>> however I image this sugar could extend to tuples with multiple types. >>> >>> Some examples: >>> >>> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); >>> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, >>> 0, 0, 0)"? >>> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); >>> let single_x = vec -> (0); >>> assert_eq!(single_x, (1.0f32)); >>> >>> let mut vec = vec; >>> vec <- (0) = 5.0f32; // set x only >>> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z >>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >>> >>> let vec = vec; >>> // the mask may be arbitrarily long: >>> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, >>> 5.0f32)); >>> >>> // leaves vec unchanged >>> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); >>> // functional_update would take it's type from vec >>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >>> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); >>> >>> A couple of things would need to be disallowed, however: >>> >>> let mut vec = vec; >>> // no duplicate assignments/functional updates: >>> vec <- (0, 0) = (..); >>> let _ = vec -> (0, 1, 2, 3, 0) .. (..); >>> // no out-of-bounds: >>> vec <- (5, 9000) = (..); >>> let _ = vec -> (5, 9001); >>> let _ = vec -> (5, 9002) .. (..); >>> let _ = vec -> (0, 1, 2, 3, 4) .. (..); >>> // all mask values must be a const expr: >>> let mut non_const_expr = 15; >>> vec <- (non_const_expr) = (..); >>> let _ = vec -> (non_const_expr) .. (..); >>> let _ = vec -> (non_const_expr); >>> // mismatched tuple sizes: >>> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); >>> let _ = vec -> (0) .. (0.0f32, 0.0f32); >>> >>> AIUI, the notation would be: >>> tuple_mask : '(' integer [ ',' integer ] * ')' ; >>> tuple_expr : '(' expr [ ',' expr ] * ')' | >>> tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; >>> >>> I'm willing to write this myself, but I'd like some consensus/feedback >>> regarding ze proposed sugar. >>> >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Tue Jan 14 12:16:04 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Tue, 14 Jan 2014 20:16:04 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <52D59184.7090008@gmail.com> Message-ID: <859122086411422198.599410troplin-bluewin.ch@news.gmane.org> Lee Braiden wrote: > On 14/01/14 01:50, Palmer Cox wrote: > > On Mon, Jan 13, 2014 at 12:18 PM, Tobias M?ller > > wrote: > > Daniel Micay > wrote: > > Do you know what undefined behavior is? It doesn't mean unspecified. > > True, but despite beeing so often cited it won't format your hard disk (even in C). > > Actually, it's possible, at least on systems without MMU protection --- > some embedded systems, for example. Ints are often used (not just in > your own code but in library code) to index a jump table. If that index > is a different number than you expected it to be, you could end up > executing calling random "functions" in memory. Said "functions" could > (and probably would) crash within 1--2 instructions, but even then, it's > not INCONCEIVABLE that those instructions could equate to "1) load hard > drive device number into the first arg register; 2) call the OS format_drive function". But this is just as likely with wrapping integers. _Any_ deviation from the expected behavior is as dangerous as UB. > This all leaves the realm of remote possibility and enters the realm of > unacceptable risk, at least for some software on some systems, when you > factor in malicious individuals trying to manipulate what address gets > called and/or what code is sitting at the address called, waiting to execute. > > As I understand it, there are essentially three bugs that can cause a > segfault: 1) write to memory you're not allowed to write to. 2) read > memory you're not allowed to read from. 3) execute code in memory > you're not allowed to execute code from. The third kind of bug is > basically saying "do anything you like computer, I don't care." It's > very much undefined behaviour, very much like calling a function pointer > that's NULL. Mostly, you get a segfault, thanks to the MMU, but in > portable code, you can't depend on that -- either the compiler handles > it, or you have to remember to check everything carefully, treating your > coding environment as a hostile one, full of adversaries. And that's just why I want to help the programmer with those checks as much as possible. Lifetimes and non-nullable pointers do a great job ensuring this for memory management, int overflow is missing such a feature. Tobi From irrequietus at gmail.com Tue Jan 14 12:17:06 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Tue, 14 Jan 2014 22:17:06 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <3beb6623-1e7c-41bf-aa15-785f25d72e32@email.android.com> Message-ID: <84f179c1-80c3-4b71-a393-84261da76ddc@email.android.com> Already too much I guess. Gaetan wrote: >rust need llvm, make, wget, bash script, python, autotools... it's just >a >matter of choice of which external tool you accept to rely on.... > >----- >Gaetan > > > >2014/1/14 George Makrydakis > >> Lack of manpower. Correct. As I have written elsewhere in these >threads, >> this is why an interim solution of a third party tool should perhaps >be >> choosen, instead of sactioning a build system in any language relic X >as >> the official tool. >> >> Closer to 1.0, the need will become more apparent. I do not see a >task >> team / working group proposing this and in order for any official >guideline >> to be followed, this is a step to be taken. Wasn't this the purpose >of this >> thread? >> >> Perhaps this is what comex is trying to say, albeit with his own >peculiar >> rhetorical structure - I doubt that anybody is "trolling", knowingly. >I >> still think that for the intended scope, Rust should just need Rust. >> >> >> Gaetan wrote: >>> >>> However, I'd say there is a stunning lack of existing build systems >>>> that actually combine a clean design, flexibility, portability, and >>>> performance. autotools fails badly on design, performance, and >>>> (ironically) portability; cmake fails on design (seriously, try to >>>> read any cmake script) >>> >>> Same than any language, you can write bloated code or quite pretty >>> things. Just be consistent and think reusability >>> >>> >>>> and flexibility (a lot of stuff is hard coded >>>> in C++ and hard to change); >>> >>> I don't see what you say is hardcoded? At worst, I simply had to >rewrite >>> a import module. >>> >>> >>>> most of the alternatives I know about are >>>> at least slow, and often poorly maintained, insufficiently general, >et >>>> cetera. The only build tool I really like is ninja, and it's >>>> designed to be used with input generated from a separate tool >rather >>>> than alone. So I'd personally like to see a new build system >regardless. >>>> >>> >>> I also agree that having a proper build system sounds sexy, however >do >>> the rust dev team has enough man power for that? >>> >>> Why not try to assemble a task that will evaluate several existing >build >>> system instead of just trolling in this thread, to see exactly what >are the >>> advantages and flaws of each candidates? >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wichard at vitalitystudios.com Tue Jan 14 12:22:01 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Tue, 14 Jan 2014 14:22:01 -0600 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: Take a look at http://static.rust-lang.org/doc/master/rust.html#lvalues-rvalues-and-temporaries or http://en.wikipedia.org/wiki/Value_(computer_science) On Tue, Jan 14, 2014 at 2:14 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > good points all! > > why not have the operation just be > shuffleSimdVector(a,b,masktuple) ? > seems a bit more human friendly than a mix of @ and <- and -> > > I'm a bit confused about the l/rvalue remark, could you explain more? > > > On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond < > wichard at vitalitystudios.com> wrote: > >> >> On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> Neat proposal: >>> thoughts >>> 0) seems like you need to add a notion of const expr to the type system >>> for this proposal, right? I started staring at that and it's pretty subtle >>> (though I may have been looking at it wrong) >>> >> I did add the const expr notion a bit, but it's only in anticipation of >> somebody wanting to specify the mask in such terms. Of course, boarder >> support for const expr's would be required. >> >> 1) do rust tuples actually map to the llvm simd vector types? >>> >> They do with #[simd]. Though I think it would be worth considering >> whether all tuples of a single primitive type should be automatically >> considered #[simd] and be lowered to a LLVM vector type. In fact one way >> I'm considering impling this is to treat the mask as a tuple and lower it >> as a vector into a shufflevector mask operand. >> >> 2) so this would require some special syntax support right? Could it be >>> prototyped with a procedural macro plus having the shuffle ast code >>> generated internally? >>> >> Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a >> stage where tuple type info is known, so such a macro would only be able to >> operate on literals and still wouldn't be able to dictate trans. >> >> 3) would the internal rep properly treat the shuffle mask ints as part of >>> the op itself so that it won't get cse'd or the like? >>> >> Yes. >> >> 4) would the syntax do a type / syntax error when you use a tuple >>> position index that's too large? >>> >> Yes. >> >> >>> 5) the llvm shuffle vector intrinsic takes two vectors of values and >>> let's you express interleaving them, not just rearranging a single one >>> (which seems to be a restriction on your example). Both styles matter, and >>> respectively correspond to different platform specific shuffle instructions >>> >> Yeah, not even ten minutes after sending the proposal, I realized I had >> forgotten about that one detail. I'm not terribly fond of any of my >> envisioned solutions, but the best one uses the recently removed '@': >> let vec1 = (10, 11, 12, 13); >> let vec2 = (9, 8, 7, 6); >> let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think >> concATenate; it'll likely be thought of as such in rustc. >> >> As an aside, note the arrows point towards what type of value the >> expression is supposed to be (lvalue is <-, rvalue is ->). >> >> I like the idea of something like this, and it's definitely simpler than >>> the shuffle proposals I've been trying to draft, though using a word like >>> "shuffle" may be. Though it doesn't give a way to use the same idea for >>> someone using the platform specific shuffle intrinsics that hopefully would >>> be added eventually. (Any such platform specific intrinsics would be for >>> fixed tuple size and type). >>> >> Thank you! >> The intent is to lean on LLVM's platform independenceness; LLVM supports >> vectors (the SIMD type) of any length, so in an effort to be forward >> compatible with future SIMD sizes, offer a generic way to 'do the shuffle'. >> Access to more specialized shuffles could be done via functions with a >> #[link_name] attribute (because such instructions operate on operands of >> specific types anyway, they wouldn't be very amenable to a generic >> solution) in unstable::simd or an external library. But that's another >> project ;) >> >>> >>> *An Alternative approach*? *Int * >>> >>> One way around the const expr requirement for the type system >>> that someone suggested was pretty neat: expose the various platform >>> specific simd shuffle ops, an have their shuffle mask int args actually be >>> "type args". Apparently there's some protean support for type level numbers >>> because of sized vectors, and because rust requires all generics to be >>> monomorphized, this actually would capture the right "constness at compile >>> time" >>> >> >>> an example of this idea would be to take the VSHUFPD intel instruction >>> (in the intel architecture), and modify the intrinsic from the c code >>> version >>> >>> (nb: __m256d == v4f64 in rust parlance) >>> __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select); >>> >>> into >>> >>> fn _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d >>> >>> I'm not sure how such a type level int application would work out, but >>> It may be the nicest way to conservatively add type safe SIMD shuffle >>> primops to rust, though I could be completely wrong. (I was initially meh >>> on this type application idea, but its grown on me, it exploits the way >>> rust generics work very very nicely!) >>> >>> *note* while exposing the architecture specific intrinsics would be bit >>> more work, it would also mean that the SIMD support in rust have a more >>> transparent mapping to various architectures, allow better architecture/cpu >>> microarchitecture based tuning (writing an version of BLIS >>> http://code.google.com/p/blis/ in rust might be a good stress test), >>> and it'd be less coupled to the vagaries of how LLVM lowers the shuffle >>> instruction to the target architecture. This actually matters in the >>> context of writing code that uses the "optimal" instruction sequence by >>> detecting the cpu micro architecture at runtime and branching to the tune >>> variant internally, something OpenBLAS does very nicely, see here for >>> examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64 >>> >>> That said, having a systematic way to support the llvm shuffle intrinsic >>> In it's full generality would be lovely, it's a much more friendly >>> operation that people can use to get started with doing simd in a somewhat >>> user friendly way. >>> >>> point being: I support there being better shuffle simd support / simd >>> support period :), though how to do it best seems unclear to me (and >>> theres also a few ways that arent good too) >>> -Carter >>> >>> >>> On Tuesday, January 14, 2014, Richard Diamond wrote: >>> >>>> Basically the idea here is to support shuffling for SIMD types in a way >>>> that can be easily lowered to IR (LLVM's shufflevector requires the mask be >>>> a vector of constants, so an intrinsic function is out of the question), >>>> however I image this sugar could extend to tuples with multiple types. >>>> >>>> Some examples: >>>> >>>> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32); >>>> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, >>>> 0, 0, 0)"? >>>> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32)); >>>> let single_x = vec -> (0); >>>> assert_eq!(single_x, (1.0f32)); >>>> >>>> let mut vec = vec; >>>> vec <- (0) = 5.0f32; // set x only >>>> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z >>>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >>>> >>>> let vec = vec; >>>> // the mask may be arbitrarily long: >>>> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32, >>>> 5.0f32)); >>>> >>>> // leaves vec unchanged >>>> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32); >>>> // functional_update would take it's type from vec >>>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32)); >>>> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32)); >>>> >>>> A couple of things would need to be disallowed, however: >>>> >>>> let mut vec = vec; >>>> // no duplicate assignments/functional updates: >>>> vec <- (0, 0) = (..); >>>> let _ = vec -> (0, 1, 2, 3, 0) .. (..); >>>> // no out-of-bounds: >>>> vec <- (5, 9000) = (..); >>>> let _ = vec -> (5, 9001); >>>> let _ = vec -> (5, 9002) .. (..); >>>> let _ = vec -> (0, 1, 2, 3, 4) .. (..); >>>> // all mask values must be a const expr: >>>> let mut non_const_expr = 15; >>>> vec <- (non_const_expr) = (..); >>>> let _ = vec -> (non_const_expr) .. (..); >>>> let _ = vec -> (non_const_expr); >>>> // mismatched tuple sizes: >>>> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32); >>>> let _ = vec -> (0) .. (0.0f32, 0.0f32); >>>> >>>> AIUI, the notation would be: >>>> tuple_mask : '(' integer [ ',' integer ] * ')' ; >>>> tuple_expr : '(' expr [ ',' expr ] * ')' | >>>> tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ; >>>> >>>> I'm willing to write this myself, but I'd like some consensus/feedback >>>> regarding ze proposed sugar. >>>> >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irrequietus at gmail.com Tue Jan 14 12:24:20 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Tue, 14 Jan 2014 22:24:20 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D572FC.5050200@mozilla.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> Message-ID: Then, as we discuss on the replies to this, shouldn't there be a "task force" dealing with the matter for what it concerns Rust? Personal preferences lead to conflicts; reaching a consensus requires a wider set of options discussed inproper setting and community audience. So far, there is little more presented here than personal preferences. These could be used as a basis for what the definitive solution to this matter should be. Patrick Walton wrote: >On 1/14/14 1:29 AM, comex wrote: >> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >> wrote: >>> Again, note that this rather long thread is about discussing in the >end what >>> the official stance should be. There is no valid reason other than >lack of >>> manpower and / or language immaturity for having to depend on ruby, >python, >>> autotools, cmake or whatever else in order to build rust software. >> >> There is no reason every language should have its own build system >> written from scratch (or package manager, for that matter); the goals >> of each language community are really mostly identical, and the >> existing duplication leads to software that's worse than it has to be >> (e.g. inconsistent support for signed packages), a waste of time >> relearning the same concepts for multiple build systems / package >> managers, and difficulty for packages that include code written in >> multiple languages. Meanwhile, satisfying the dependencies you >> mentioned is trivial on most systems. >> >> However, I'd say there is a stunning lack of existing build systems >> that actually combine a clean design, flexibility, portability, and >> performance. autotools fails badly on design, performance, and >> (ironically) portability; cmake fails on design (seriously, try to >> read any cmake script) and flexibility (a lot of stuff is hard coded >> in C++ and hard to change); most of the alternatives I know about are >> at least slow, and often poorly maintained, insufficiently general, >et >> cetera. The only build tool I really like is ninja, and it's >> designed to be used with input generated from a separate tool rather >> than alone. So I'd personally like to see a new build system >regardless. > >This e-mail sums up my feelings to a T, and it's why I'm conflicted >about the whole matter. > >Patrick > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Tue Jan 14 12:26:30 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Tue, 14 Jan 2014 20:26:30 +0000 (UTC) Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <1654420187411338464.740972troplin-bluewin.ch@news.gmane.org> Message-ID: <514130363411423479.211216troplin-bluewin.ch@news.gmane.org> comex wrote: > On Mon, Jan 13, 2014 at 4:06 PM, Tobias M?ller wrote: >> int + int = int >> ... >> >> If the result does not fit into an int the compiler throws an error. >> To resolve an error, you can: >> - annotate the operands with appropriate bounds >> - use a bigger type for the operation and check the result. > > I remember wondering whether this type of solution would be feasible > or too much of a hassle in practice. As I see it, many values which > might be arithmetic operands are sizes or counts, and really ought to > be size_t sized, and any mutable variable which is operated on in a > loop can't be bounded with a lot more complexity, so it might lean > toward the latter. You are right, mutations that depend on previous values of the same variable are a problem. For example it would be impossible to determine bounds for i in 'i = i + 1'. But you could shadow i like 'let i = i + 1'. However that is no more mutation but definition of a new variable. Tobi From danielmicay at gmail.com Tue Jan 14 12:27:11 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 14 Jan 2014 15:27:11 -0500 Subject: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0 In-Reply-To: <859122086411422198.599410troplin-bluewin.ch@news.gmane.org> References: <52D0D385.1080200@gmail.com> <52D0DDA3.8040501@isaac.cedarswampstudios.org> <1190503484411242604.533060troplin-bluewin.ch@news.gmane.org> <1493431469411324195.606317troplin-bluewin.ch@news.gmane.org> <52D59184.7090008@gmail.com> <859122086411422198.599410troplin-bluewin.ch@news.gmane.org> Message-ID: On Tue, Jan 14, 2014 at 3:16 PM, Tobias M?ller wrote: > Lee Braiden wrote: >> On 14/01/14 01:50, Palmer Cox wrote: >> >> On Mon, Jan 13, 2014 at 12:18 PM, Tobias M?ller >> > > wrote: >> >> Daniel Micay > > wrote: >> > Do you know what undefined behavior is? It doesn't mean unspecified. >> >> True, but despite beeing so often cited it won't format your hard disk (even in C). >> >> Actually, it's possible, at least on systems without MMU protection --- >> some embedded systems, for example. Ints are often used (not just in >> your own code but in library code) to index a jump table. If that index >> is a different number than you expected it to be, you could end up >> executing calling random "functions" in memory. Said "functions" could >> (and probably would) crash within 1--2 instructions, but even then, it's >> not INCONCEIVABLE that those instructions could equate to "1) load hard >> drive device number into the first arg register; 2) call the OS format_drive function". > > But this is just as likely with wrapping integers. _Any_ deviation from the > expected behavior is as dangerous as UB. That's not how undefined behaviour works in LLVM (and C). If you perform an integer arithmetic operation with undefined behaviour, it does not mean that you get an undefined result back. Undefined values and undefined behaviour are not the same thing. An arithmetic operation in LLVM can be marked as undefined on overflow with `nsw` or `nuw` rather than wrapping. `clang` uses `nsw` on signed integers when `-fwrapv` is not passed to communicate this guarantee. LLVM can then assume that signed integers never overflow, enabling more optimizations. It can become aware that makes loops must terminate, and even gain the ability to count the number of iterations. It can also glean information on the possible ranges of values based on the invariants provided by most arithmetic operations. If it sees `x + INT_MAX`, then `x` is less than or equal to zero. Invoking undefined behaviour is always a safety issue. You would need to look at the assembly for the whole program in detail to know whether an optimization pass made an assumption that's not going to hold. This will of course change across every compiler version, which is why C programs so often break with a new `gcc` release. Wrapping on overflow is a logic error and in rare cases may become a safety issue if it's then used in a specific kind of `unsafe` code. The `unsafe` code needs to make the assumption that the integer is in some valid range, without checking it. > And that's just why I want to help the programmer with those checks as much > as possible. Lifetimes and non-nullable pointers do a great job ensuring > this for memory management, int overflow is missing such a feature. Rust has support for big integers. It also has support for library-defined overflow checks via the LLVM overflow checking intrinsics. A language feature is not necessary to support this. From wichard at vitalitystudios.com Tue Jan 14 12:27:48 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Tue, 14 Jan 2014 14:27:48 -0600 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay wrote: > On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond > wrote: > > > > They do with #[simd]. Though I think it would be worth considering > whether > > all tuples of a single primitive type should be automatically considered > > #[simd] and be lowered to a LLVM vector type. In fact one way I'm > > considering impling this is to treat the mask as a tuple and lower it as > a > > vector into a shufflevector mask operand. > > This isn't possible due to alignment issues. Only very recent Intel > CPUs lack the requirement of alignment for SIMD instructions. > Obviously, battlefield promotions will be necessary when shifting between heap and stack. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 12:27:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 15:27:31 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: good point, SIMD vectors are values where you can't take pointers / addresses (except when suitable cpu dependent intrinsics are available that load a value from a memory and do an operation and optionally store it again ) On Tue, Jan 14, 2014 at 3:09 PM, Daniel Micay wrote: > On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond > wrote: > > > > They do with #[simd]. Though I think it would be worth considering > whether > > all tuples of a single primitive type should be automatically considered > > #[simd] and be lowered to a LLVM vector type. In fact one way I'm > > considering impling this is to treat the mask as a tuple and lower it as > a > > vector into a shufflevector mask operand. > > This isn't possible due to alignment issues. Only very recent Intel > CPUs lack the requirement of alignment for SIMD instructions. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 12:30:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 15:30:37 -0500 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: ummm, the whole point of SIMD vector values is they work in register. Sure, sometimes the register allocator may spill to stack, but while an *ARRAY* of values of type T can have notion of an address, a SIMD Vector of T (likely f64/f32/int32/int64) doesn't really have the same idea.. On Tue, Jan 14, 2014 at 3:27 PM, Richard Diamond < wichard at vitalitystudios.com> wrote: > > > > On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay wrote: > >> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond >> wrote: >> > >> > They do with #[simd]. Though I think it would be worth considering >> whether >> > all tuples of a single primitive type should be automatically considered >> > #[simd] and be lowered to a LLVM vector type. In fact one way I'm >> > considering impling this is to treat the mask as a tuple and lower it >> as a >> > vector into a shufflevector mask operand. >> >> This isn't possible due to alignment issues. Only very recent Intel >> CPUs lack the requirement of alignment for SIMD instructions. >> > Obviously, battlefield promotions will be necessary when shifting between > heap and stack. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 12:43:36 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 20:43:36 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D572FC.5050200@mozilla.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> Message-ID: <52D5A178.6060009@gmail.com> On 14/01/14 17:25, Patrick Walton wrote: > On 1/14/14 1:29 AM, comex wrote: >> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >> wrote: >>> Again, note that this rather long thread is about discussing in the >>> end what >>> the official stance should be. There is no valid reason other than >>> lack of >>> manpower and / or language immaturity for having to depend on ruby, >>> python, >>> autotools, cmake or whatever else in order to build rust software. >> >> There is no reason every language should have its own build system >> written from scratch (or package manager, for that matter); the goals >> of each language community are really mostly identical >> >> However, I'd say there is a stunning lack of existing build systems >> that actually combine a clean design, flexibility, portability, and >> performance > This e-mail sums up my feelings to a T, and it's why I'm conflicted > about the whole matter. The more people talk about different build systems and how we can't choose one yet, the more I agree. So, rethinking, it seems to me that important part seems, is to be COMPATIBLE with everyone's project hosting, build system, and/or package manager of choice. That would include command line build tools, pretty website download catalogs, yum, synaptic, cabal, etc. So, much more important than choosing TOOLS, I think Rust needs to standardise INFORMATION that any tool can use. Perhaps something like this? [ "project": { "name": "someproject", "brief-description": "some description", "limited-description": [ "Para-one.", "Para-two.", "Para-three." ], "web": "http://buggysoft.com", "screenshots": { "screenshot one": { "uri": "http://www.buggypics.com/massivebug.png", "alt-text": "Features massive bugs", }, }, "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", "authors": { "author1": { "email": "author1 at someplace.com", "web": "http://someplace.com", }, }, "copyright": { "license-file": "docs/LICENSE.TXT", "license-flags": "SHAREALIKE | ATTRIBUTION | ADVERTISING_CLAUSE", }, "build-info": { "build-type": "library", "target": "libx.so" "source-files": [ "src/*.rs", "somedir/a_file.rs" ], }, "developer-support-info": { "rust-ide-doc-file": "docs/libx.rustapi", "rust-ide-completion-file": "docs/libx.rusttags", }, "dependencies": { "rust-projects": { "someotherproject": { # from that projects "project" -> "name" entry # following fields are optional; any specified filter the list # the list of suitable candidates. "min-version": "0.1", "max-version": "0.1", "gitrepo": "http://somehub.com/someuser/someotherproject/", "min-git-tag": "04a453543", "max-git-tag": "045ead634", "tarball-uri": "http://someotherproject.com/somepath-${version}.tgz", "distro-version-ok": "true" } }, "external-libs": { "libssl": { "min-version": "0.1", "max-version": "0.1", "gitrepo": "http://somehub.com/someuser/someotherproject/", "min-git-tag": "04a453543", "max-git-tag": "045ead634", "tarball-uri": "http://someotherproject.com/somepath-${version}.tgz" "distro-version-ok": "true", } }, } } ] -- Lee From jens at nockert.se Tue Jan 14 12:48:18 2014 From: jens at nockert.se (Jens Nockert) Date: Tue, 14 Jan 2014 21:48:18 +0100 Subject: [rust-dev] RFC: Tuple Swizzling/Shuffling In-Reply-To: References: Message-ID: <4721BD8C-7DD1-4720-9219-AFC3F49AE52F@nockert.se> I just want to point out that there has already been implementations of swizzling/shuffling, (https://github.com/jensnockert/rust/commit/d3709e3e7426fc41666e971b35cb683e0de15a79) the issue back then was just syntax. If people can agree on a syntax, implementation should be really simple, just a few hundred lines. From irrequietus at gmail.com Tue Jan 14 12:51:55 2014 From: irrequietus at gmail.com (George Makrydakis) Date: Tue, 14 Jan 2014 22:51:55 +0200 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5A178.6060009@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> Message-ID: <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> That would be a good start. But are you advocating that it should be third party tools thatcshould be given guidelines on how to comply? What would be their incentive to do so? Or should this be used as a basis for creating a prototype deploying duch information... which would inevitably ask again: Should Rust have its own build tool, given your proposal of standardized representational information ? Dealing with such metadata forces you to design a new system. Lee Braiden wrote: >On 14/01/14 17:25, Patrick Walton wrote: >> On 1/14/14 1:29 AM, comex wrote: >>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >>> wrote: >>>> Again, note that this rather long thread is about discussing in the > >>>> end what >>>> the official stance should be. There is no valid reason other than >>>> lack of >>>> manpower and / or language immaturity for having to depend on ruby, > >>>> python, >>>> autotools, cmake or whatever else in order to build rust software. >>> >>> There is no reason every language should have its own build system >>> written from scratch (or package manager, for that matter); the >goals >>> of each language community are really mostly identical >>> >>> However, I'd say there is a stunning lack of existing build systems >>> that actually combine a clean design, flexibility, portability, and >>> performance >> This e-mail sums up my feelings to a T, and it's why I'm conflicted >> about the whole matter. > >The more people talk about different build systems and how we can't >choose one yet, the more I agree. > >So, rethinking, it seems to me that important part seems, is to be >COMPATIBLE with everyone's project hosting, build system, and/or >package >manager of choice. That would include command line build tools, pretty > >website download catalogs, yum, synaptic, cabal, etc. > > >So, much more important than choosing TOOLS, I think Rust needs to >standardise INFORMATION that any tool can use. Perhaps something like >this? > >[ > "project": { > "name": "someproject", > > "brief-description": "some description", > > "limited-description": [ > "Para-one.", > "Para-two.", > "Para-three." >], > > "web": "http://buggysoft.com", > > "screenshots": { > "screenshot one": { > "uri": "http://www.buggypics.com/massivebug.png", > "alt-text": "Features massive bugs", > }, > }, > > "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", > > "authors": { > "author1": { > "email": "author1 at someplace.com", > "web": "http://someplace.com", > }, > }, > > "copyright": { > "license-file": "docs/LICENSE.TXT", > "license-flags": "SHAREALIKE | ATTRIBUTION | >ADVERTISING_CLAUSE", > }, > > "build-info": { > "build-type": "library", > "target": "libx.so" > "source-files": [ "src/*.rs", "somedir/a_file.rs" ], > }, > > "developer-support-info": { > "rust-ide-doc-file": "docs/libx.rustapi", > "rust-ide-completion-file": "docs/libx.rusttags", > }, > > "dependencies": { > "rust-projects": { > "someotherproject": { # from that projects >"project" -> "name" entry > > # following fields are optional; any >specified filter the list > # the list of suitable candidates. > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": >"http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": >"http://someotherproject.com/somepath-${version}.tgz", > > "distro-version-ok": "true" > } > }, > > "external-libs": { > "libssl": { > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": >"http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": >"http://someotherproject.com/somepath-${version}.tgz" > > "distro-version-ok": "true", > } > }, > } > } >] > >-- >Lee > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 14:11:19 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 22:11:19 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> Message-ID: <52D5B607.5070003@gmail.com> On 14/01/14 20:51, George Makrydakis wrote: > > That would be a good start. But are you advocating that it should be > third party tools thatcshould be given guidelines on how to comply? > What would be their incentive to do so? Or should this be used as a > basis for creating a prototype deploying duch information... which > would inevitably ask again: > > Should Rust have its own build tool, given your proposal of > standardized representational information ? Dealing with such metadata > forces you to design a new system. > I guess I'm saying that, no matter what solution you choose: a) People will want their own version, either because they know and prefer something else, OR just because they run, say, debian, and it manages 26000 packages on their system, and they want Rust to be managed that way too.** b) This kind of information will be needed ** For instance, Debian has tools to create debian packages from git repositories, PHP's pear packages, perl packages, google earth tarballs, etc. Arch, BSD ports, and the like import packages using a thin wrapper around whatever package system upstream developers use. There's a will, in Linux, in Mac, with MacPorts, in cygwin, etc., and in mobile, to integrate package management into one system for all. We don't necessarily have to provide "build" tools for each platform, so integration tools for each IDE, syntax highlighting for each editor, or API documentation/tags for each IDE. At least, to start with, all we need to do is make it possible for people who want to do these things, to do them. But, what I think is pretty important, is to establish the standard as early as possible, to allow people to build tools for as many Rust packages as possible. In many ways, speaking as a general developer rather than a rust developer, knowing that any rust package / repository will contain a .rust-info file, say, which tells me all the metadata I need to know to integrate that package into my website, buildtool, or whatever... that's much more valuable to me, than knowing that I can download some package, on any of 3 platforms, and it'll just just build. The tool is short term convenience, but the data lets me build short term tools AND long-term infrastructure. -- Lee > > > Lee Braiden wrote: > > On 14/01/14 17:25, Patrick Walton wrote: > > On 1/14/14 1:29 AM, comex wrote: > > On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis > wrote: > > Again, note that this rather long thread is about > discussing in the end what the official stance should > be. There is no valid reason other than lack of > manpower and / or language immaturity for having to > depend on ruby, python, autotools, cmake or whatever > else in order to build rust software. > > There is no reason every language should have its own > build system written from scratch (or package manager, for > that matter); the goals of each language community are > really mostly identical However, I'd say there is a > stunning lack of existing build systems that actually > combine a clean design, flexibility, portability, and > performance > > This e-mail sums up my feelings to a T, and it's why I'm > conflicted about the whole matter. > > > The more people talk about different build systems and how we can't > choose one yet, the more I agree. > > So, rethinking, it seems to me that important part seems, is to be > COMPATIBLE with everyone's project hosting, build system, and/or package > manager of choice. That would include command line build tools, pretty > website download catalogs, yum, synaptic, cabal, etc. > > > So, much more important than choosing TOOLS, I think Rust needs to > standardise INFORMATION that any > tool can use. Perhaps something like this? > > [ > "project": { > "name": "someproject", > > "brief-description": "some description", > > "limited-description": [ > "Para-one.", > "Para-two.", > "Para-three." > ], > > "web": "http://buggysoft.com", > > "screenshots": { > "screenshot one": { > "uri": "http://www.buggypics.com/massivebug.png", > "alt-text": "Features massive bugs", > }, > }, > > "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", > > "authors": { > "author1": { > "email": "author1 at someplace.com", > > "web": "http://someplace.com", > }, > }, > > "copyright": { > "license-file": "docs/LICENSE.TXT", > "license-flags": "SHAREALIKE | ATTRIBUTION | > ADVERTISING_CLAUSE", > }, > > "build-info": { > "build-type": "library", > "target": "libx.so " > "source-files": [ "src/*.rs", "somedir/a_file.rs " ], > }, > > "developer-support-info": { > "rust-ide-doc-file": "docs/libx.rustapi", > "rust-ide-completion-file": "docs/libx.rusttags", > }, > > "dependencies": { > "rust-projects": { > "someotherproject": { # from that projects > "project" -> "name" > entry > > # following fields are optional; any > specified filter the list > # the list of suitable candidates. > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": > "http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": > "http://someotherproject.com/somepath-${version}.tgz", > > "distro-version-ok": "true" > } > }, > > "external-libs": { > "libssl": { > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": > "http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": > "http://someotherproject.com/somepath-${version}.tgz" > > "distro-version-ok": "true", > } > }, > } > } > ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhasse at gmail.com Tue Jan 14 14:31:00 2014 From: jhasse at gmail.com (Jan Niklas Hasse) Date: Tue, 14 Jan 2014 23:31:00 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5B607.5070003@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> Message-ID: <52D5BAA4.8070405@gmail.com> Am 14.01.2014 23:11, schrieb Lee Braiden: > On 14/01/14 20:51, George Makrydakis wrote: >> >> That would be a good start. But are you advocating that it should be >> third party tools thatcshould be given guidelines on how to comply? >> What would be their incentive to do so? Or should this be used as a >> basis for creating a prototype deploying duch information... which >> would inevitably ask again: >> >> Should Rust have its own build tool, given your proposal of >> standardized representational information ? Dealing with such >> metadata forces you to design a new system. >> > > I guess I'm saying that, no matter what solution you choose: > > a) People will want their own version, either because they know and > prefer something else, OR just because they run, say, debian, and it > manages 26000 packages on their system, and they want Rust to be > managed that way too.** I don't understand what debian's package manager has to do with a build system? There's no reason why apt-get install librust-sdl2-dev shouldn't work, no matter what rust-sdl2 uses for building itself. The package will just contain a rlib file and put it inside /usr/lib/rustlib//. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Jan 14 14:32:17 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 23:32:17 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5A178.6060009@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> Message-ID: this looks like POM :) I always dreamt of writing a proper build system with such high level structure, deal with project dependencies, but that is way more complex than that. if a project in rust start with this matter, I volunteer to participate to it. ----- Gaetan 2014/1/14 Lee Braiden > On 14/01/14 17:25, Patrick Walton wrote: > >> On 1/14/14 1:29 AM, comex wrote: >> >>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >>> wrote: >>> >>>> Again, note that this rather long thread is about discussing in the end >>>> what >>>> the official stance should be. There is no valid reason other than lack >>>> of >>>> manpower and / or language immaturity for having to depend on ruby, >>>> python, >>>> autotools, cmake or whatever else in order to build rust software. >>>> >>> >>> There is no reason every language should have its own build system >>> written from scratch (or package manager, for that matter); the goals >>> of each language community are really mostly identical >>> >>> >>> However, I'd say there is a stunning lack of existing build systems >>> that actually combine a clean design, flexibility, portability, and >>> performance >>> >> This e-mail sums up my feelings to a T, and it's why I'm conflicted about >> the whole matter. >> > > The more people talk about different build systems and how we can't choose > one yet, the more I agree. > > So, rethinking, it seems to me that important part seems, is to be > COMPATIBLE with everyone's project hosting, build system, and/or package > manager of choice. That would include command line build tools, pretty > website download catalogs, yum, synaptic, cabal, etc. > > > So, much more important than choosing TOOLS, I think Rust needs to > standardise INFORMATION that any tool can use. Perhaps something like this? > > [ > "project": { > "name": "someproject", > > "brief-description": "some description", > > "limited-description": [ > "Para-one.", > "Para-two.", > "Para-three." > ], > > "web": "http://buggysoft.com", > > "screenshots": { > "screenshot one": { > "uri": "http://www.buggypics.com/massivebug.png", > "alt-text": "Features massive bugs", > }, > }, > > "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", > > "authors": { > "author1": { > "email": "author1 at someplace.com", > "web": "http://someplace.com", > }, > }, > > "copyright": { > "license-file": "docs/LICENSE.TXT", > "license-flags": "SHAREALIKE | ATTRIBUTION | > ADVERTISING_CLAUSE", > }, > > "build-info": { > "build-type": "library", > "target": "libx.so" > "source-files": [ "src/*.rs", "somedir/a_file.rs" ], > }, > > "developer-support-info": { > "rust-ide-doc-file": "docs/libx.rustapi", > "rust-ide-completion-file": "docs/libx.rusttags", > }, > > "dependencies": { > "rust-projects": { > "someotherproject": { # from that projects > "project" -> "name" entry > > # following fields are optional; any specified > filter the list > # the list of suitable candidates. > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": "http://somehub.com/someuser/ > someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": "http://someotherproject.com/ > somepath-${version}.tgz", > > "distro-version-ok": "true" > } > }, > > "external-libs": { > "libssl": { > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": "http://somehub.com/someuser/ > someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": "http://someotherproject.com/ > somepath-${version}.tgz" > > "distro-version-ok": "true", > } > }, > } > } > ] > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 14:33:39 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 22:33:39 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> Message-ID: <52D5BB43.5020101@gmail.com> Another point is that we don't really need a massively complicated "build system" right now, as far as I know. I don't know rust well yet, but it's a two-line script to load this data (excluding comments). Another few lines to figure out whether to build a library or an executable, another few to run rustc with the list of files, OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project file. With the data, you could build any tool of your choice, to use (almost) any tool of your choice, with a few lines in the language of your choice. And, you can evolve it all later, into something better. And the data format could be extended too. I should add that the data format should have a version number, so tools could parse new versions differently, or even read this file, see that it's version 2, and that a better, more file format with a different filename should be used instead. -- Lee On 14/01/14 20:51, George Makrydakis wrote: > > That would be a good start. But are you advocating that it should be > third party tools thatcshould be given guidelines on how to comply? > What would be their incentive to do so? Or should this be used as a > basis for creating a prototype deploying duch information... which > would inevitably ask again: > > Should Rust have its own build tool, given your proposal of > standardized representational information ? Dealing with such metadata > forces you to design a new system. > > > > Lee Braiden wrote: > > On 14/01/14 17:25, Patrick Walton wrote: > > On 1/14/14 1:29 AM, comex wrote: > > On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis > wrote: > > Again, note that this rather long thread is about > discussing in the end what the official stance should > be. There is no valid reason other than lack of > manpower and / or language immaturity for having to > depend on ruby, python, autotools, cmake or whatever > else in order to build rust software. > > There is no reason every language should have its own > build system written from scratch (or package manager, for > that matter); the goals of each language community are > really mostly identical However, I'd say there is a > stunning lack of existing build systems that actually > combine a clean design, flexibility, portability, and > performance > > This e-mail sums up my feelings to a T, and it's why I'm > conflicted about the whole matter. > > > The more people talk about different build systems and how we can't > choose one yet, the more I agree. > > So, rethinking, it seems to me that important part seems, is to be > COMPATIBLE with everyone's project hosting, build system, and/or package > manager of choice. That would include command line build tools, pretty > website download catalogs, yum, synaptic, cabal, etc. > > > So, much more important than choosing TOOLS, I think Rust needs to > standardise INFORMATION that any > tool can use. Perhaps something like this? > > [ > "project": { > "name": "someproject", > > "brief-description": "some description", > > "limited-description": [ > "Para-one.", > "Para-two.", > "Para-three." > ], > > "web": "http://buggysoft.com", > > "screenshots": { > "screenshot one": { > "uri": "http://www.buggypics.com/massivebug.png", > "alt-text": "Features massive bugs", > }, > }, > > "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", > > "authors": { > "author1": { > "email": "author1 at someplace.com", > > "web": "http://someplace.com", > }, > }, > > "copyright": { > "license-file": "docs/LICENSE.TXT", > "license-flags": "SHAREALIKE | ATTRIBUTION | > ADVERTISING_CLAUSE", > }, > > "build-info": { > "build-type": "library", > "target": "libx.so " > "source-files": [ "src/*.rs", "somedir/a_file.rs " ], > }, > > "developer-support-info": { > "rust-ide-doc-file": "docs/libx.rustapi", > "rust-ide-completion-file": "docs/libx.rusttags", > }, > > "dependencies": { > "rust-projects": { > "someotherproject": { # from that projects > "project" -> "name" > entry > > # following fields are optional; any > specified filter the list > # the list of suitable candidates. > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": > "http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": > "http://someotherproject.com/somepath-${version}.tgz", > > "distro-version-ok": "true" > } > }, > > "external-libs": { > "libssl": { > > "min-version": "0.1", > "max-version": "0.1", > > "gitrepo": > "http://somehub.com/someuser/someotherproject/", > "min-git-tag": "04a453543", > "max-git-tag": "045ead634", > > "tarball-uri": > "http://someotherproject.com/somepath-${version}.tgz" > > "distro-version-ok": "true", > } > }, > } > } > ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Tue Jan 14 14:35:15 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Tue, 14 Jan 2014 14:35:15 -0800 Subject: [rust-dev] RFC: New Rust channel proposal In-Reply-To: <52D4A564.4090602@mozilla.com> References: <52D4A564.4090602@mozilla.com> Message-ID: I'm skeptical about combining Chan and SharedChan. Maintaining that distinction is useful for expressing the programmer's intent and would certainly make any analysis that cared to distinguish between single and multiple producers easier to implement (off the top of my head, knowing you're the only one with a Chan means you don't have to deal with potential race conditions arising from interleaving of messages from different producers). Maybe a SharedChan should be constructed by consuming a Chan and upgrading its queue rather than duplicating all of Chan constructors? Otherwise I'm fine with this proposal. On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote: > In light of the general consensus that unbounded channels are not so hot, > here's a new proposal for how Rust's channels should operate. This is based > on the following assumptions: > > * Running out of memory is an awful failure mode for debugging. > * Choosing an appropriate bounded queue size is hard. > * Dealing with backpressure is hard. > * Most channels are not filled without bound. > > This proposal has two facets: making the current channels appropriate for > more use cases; adding additional channel types for specialized use cases. > I'm still operating under the premise that there should be a "default" > channel type that can be successfully used in most instances, and people > should only need to pick something else when their message passing behavior > calls for it. Not all of these recommendations are about resolving the > unbounded channel debate. > > # Changes to `Chan` > > Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up > some of our complexity budget to add more channel types, and partly a > concession to usability. A cloned channel will automatically upgrade itself > to a multi-producer queue. This will add a small amount of overhead to > various operations. > > Secondly, in order to accommodate the very common case where a channel is > used just once, we optimize the single-send use case to not allocate. > Essentially, we store a single element directly in the shared state between > the channel and port. This restores the `oneshot` functionality we lost in > the last channel rewrite. Again, this will add a small amount of overhead > to some operations, though possibly not above the overhead incurred by > combining `Chan` and `SharedChan`. > > Finally, my main suggestion about how to deal with OOM, let's put an > arbitrary bound to the size of the queue on `Chan`. This isn't to say let's > turn `Chan` into a bounded queue (which is difficult for implementation > reasons), but instead that we add a feature that helps debug when you've > actually chosen the wrong kind of channel because your producer sends > without bound. > > When you hit this bound the send will fail and you know that you need to > think harder about the behavior of this particular channel. If you *really* > want an unbounded channel then you can construct it with `Chan::unbounded`, > otherwise you pick ... > > # Synchronous and bounded channels > > Let's add `SyncChan` which is a bounded multi-producer single-consumer > queue backed by a ring buffer. This supports `send`, which blocks by > default, and `try_send` which returns an enum representing whether the send > succeeded, the channel is full, or the channel is closed (the last two > cases returning the message). In the special case where the channel bound > is 0, we don't use a ringbuffer and just do a rendezvousing send and > recieve. The default bound is 0. > > Comments? > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Jan 14 14:35:34 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 23:35:34 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5BB43.5020101@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5BB43.5020101@gmail.com> Message-ID: i disagree, the data structure needs to be developed with the majority of use case possible. you cannot rely on just "extending it" later when new feature will be needed, that will NOT work. ----- Gaetan 2014/1/14 Lee Braiden > Another point is that we don't really need a massively complicated > "build system" right now, as far as I know. > > I don't know rust well yet, but it's a two-line script to load this data > (excluding comments). Another few lines to figure out whether to build a > library or an executable, another few to run rustc with the list of files, > OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project > file. > > With the data, you could build any tool of your choice, to use (almost) > any tool of your choice, with a few lines in the language of your choice. > > And, you can evolve it all later, into something better. And the data > format could be extended too. I should add that the data format should > have a version number, so tools could parse new versions differently, or > even read this file, see that it's version 2, and that a better, more file > format with a different filename should be used instead. > > > -- > Lee > > > > On 14/01/14 20:51, George Makrydakis wrote: > > That would be a good start. But are you advocating that it should be third > party tools thatcshould be given guidelines on how to comply? What would be > their incentive to do so? Or should this be used as a basis for creating a > prototype deploying duch information... which would inevitably ask again: > > Should Rust have its own build tool, given your proposal of standardized > representational information ? Dealing with such metadata forces you to > design a new system. > > > Lee Braiden wrote: >> >> On 14/01/14 17:25, Patrick Walton wrote: >>> >>> On 1/14/14 1:29 AM, comex wrote: >>>> >>>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >>>> wrote: >>>>> >>>>> Again, note that this rather long thread is about discussing in the >>>>> end what >>>>> the official stance should be. There is no valid reason other than >>>>> lack of >>>>> manpower and / or language immaturity for having to depend on ruby, >>>>> python, >>>>> autotools, cmake or whatever else in order to build rust software. >>>> >>>> >>>> There is no reason every language should have its own build system >>>> >>>> written from scratch (or package manager, for that matter); the goals >>>> of each language community are really mostly identical >>>> >>>> However, I'd say there is a stunning lack of existing build systems >>>> that actually combine a clean design, flexibility, portability, and >>>> performance >>> >>> This e-mail sums up my feelings to a T, and it's why I'm conflicted >>> about the whole matter. >> >> >> The more people talk about different build systems and how we can't >> choose one yet, the more I agree. >> >> So, rethinking, it seems to me that important part seems, is to be >> COMPATIBLE with everyone's project hosting, build system, and/or package >> manager of choice. That would include command line build tools, pretty >> website download catalogs, yum, synaptic, cabal, etc. >> >> >> So, much more important than choosing TOOLS, I think Rust needs to >> standardise INFORMATION that any >> tool can use. Perhaps something like this? >> >> [ >> "project": { >> "name": "someproject", >> >> "brief-description": "some description", >> >> "limited-description": [ >> "Para-one.", >> "Para-two.", >> "Para-three." >> ], >> >> "web": "http://buggysoft.com", >> >> "screenshots": { >> "screenshot one": { >> "uri": "http://www.buggypics.com/massivebug.png", >> "alt-text": "Features massive bugs", >> }, >> }, >> >> "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", >> >> "authors": { >> "author1": { >> "email": "author1 at someplace.com" , >> >> "web": "http://someplace.com", >> }, >> }, >> >> "copyright": { >> "license-file": "docs/LICENSE.TXT", >> "license-flags": "SHAREALIKE | ATTRIBUTION | >> ADVERTISING_CLAUSE", >> }, >> >> "build-info": { >> "build-type": "library", >> "target": "libx.so" >> "source-files": [ "src/*.rs", "somedir/a_file.rs" ], >> }, >> >> "developer-support-info": { >> "rust-ide-doc-file": "docs/libx.rustapi", >> "rust-ide-completion-file": "docs/libx.rusttags", >> }, >> >> "dependencies": { >> "rust-projects": { >> "someotherproject": { # from that projects >> "project" -> "name" >> entry >> >> # following fields are optional; any >> specified filter the list >> # the list of suitable candidates. >> >> "min-version": "0.1", >> "max-version": "0.1", >> >> "gitrepo": >> "http://somehub.com/someuser/someotherproject/", >> "min-git-tag": "04a453543", >> "max-git-tag": "045ead634", >> >> "tarball-uri": >> "http://someotherproject.com/somepath-${version}.tgz", >> >> "distro-version-ok": "true" >> } >> }, >> >> "external-libs": { >> "libssl": { >> >> "min-version": "0.1", >> "max-version": "0.1", >> >> "gitrepo": >> "http://somehub.com/someuser/someotherproject/", >> "min-git-tag": "04a453543", >> "max-git-tag": "045ead634", >> >> "tarball-uri": >> "http://someotherproject.com/somepath-${version}.tgz" >> >> "distro-version-ok": "true", >> } >> }, >> } >> } >> ] >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 14:41:20 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 22:41:20 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5BAA4.8070405@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> Message-ID: <52D5BD10.9080406@gmail.com> On 14/01/14 22:31, Jan Niklas Hasse wrote: > I don't understand what debian's package manager has to do with a > build system? > > There's no reason why > > apt-get install librust-sdl2-dev > > shouldn't work, no matter what rust-sdl2 uses for building itself. The > package will just contain a rlib file and put it inside > /usr/lib/rustlib//. > There is a LOT of cross-over between package managers and build systems. In fact, I'd argue that the distinction is very blurry, if not misguided. Debian, for instance, provides: apt-get -b source packagename Which downloads and builds a package from source. Many package managers, like the BSD ports, MAINLY download and build from source. They're nothing but standardised wrappers for the many build systems out there, along with (in some package managers, like Debian's) standards for where the installed files should end up. Other packages managers will ONLY build from source. I think what you're mainly getting at, though, is why you need to care about debian choosing to say: apt-get install librust-sdl2-dev When the Rust community says: rustpkg -i rust-sdl The problem is that, the whole concept of a package manager is to standardise and maintain compatiblity between installed packages. So when debian says: apt-get install librust-sdl2-dev AND you say: rustpkg -i rust-sdl--berts-version That's a conflict. Because two open source communities failed to work together. BUT, debian, and others like BSD ports etc., very much do their part, in providing ways to install librust-sdl2-dev etc. The part that's missing is the metadata for rust-sdl--berts-version, which says, "This package provides librust-sdl, so if you install this, don't install some other librust-sdl as well." Basically, I'm saying that, if we make a little effort to create open, accessible package data, then everyone will find it easier to work with us. That shouldn't be a foreign concept. -- Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Jan 14 14:51:57 2014 From: gaetan at xeberon.net (Gaetan) Date: Tue, 14 Jan 2014 23:51:57 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5BD10.9080406@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> Message-ID: you cannot stick build environment with one system. apt is now on every system, you cannot use it under windows or mac. and apt source simply checkout the source zip from repository, this is not a proper build system. package management is one job and build is another one. you will use another package management on another system, while you expect to use the same build system on another system. in my experience, i ended up quite often with some bash script for unix like systems that generates some makefiles or trigs cmake/cpack, visual studio or eclipse projects for windows. the only portable build system i used was cmake, which exists under windows mac and unit, with ctest and cpack, even if there are quite limited. And there were a lot of "if windows..." But, i tend to NOT recommend cmake if the final goal is to be integrated into systems like debian. ----- Gaetan 2014/1/14 Lee Braiden > On 14/01/14 22:31, Jan Niklas Hasse wrote: > > I don't understand what debian's package manager has to do with a build > system? > > There's no reason why > > apt-get install librust-sdl2-dev > > shouldn't work, no matter what rust-sdl2 uses for building itself. The > package will just contain a rlib file and put it inside > /usr/lib/rustlib//. > > > There is a LOT of cross-over between package managers and build systems. > In fact, I'd argue that the distinction is very blurry, if not misguided. > Debian, for instance, provides: > > apt-get -b source packagename > > Which downloads and builds a package from source. > > Many package managers, like the BSD ports, MAINLY download and build from > source. They're nothing but standardised wrappers for the many build > systems out there, along with (in some package managers, like Debian's) > standards for where the installed files should end up. > > Other packages managers will ONLY build from source. > > > > I think what you're mainly getting at, though, is why you need to care > about debian choosing to say: > > apt-get install librust-sdl2-dev > > When the Rust community says: > > rustpkg -i rust-sdl > > > The problem is that, the whole concept of a package manager is to > standardise and maintain compatiblity between installed packages. So when > debian says: > > apt-get install librust-sdl2-dev > > AND you say: > > rustpkg -i rust-sdl--berts-version > > That's a conflict. Because two open source communities failed to work > together. BUT, debian, and others like BSD ports etc., very much do their > part, in providing ways to install librust-sdl2-dev etc. The part that's > missing is the metadata for rust-sdl--berts-version, which says, "This > package provides librust-sdl, so if you install this, don't install some > other librust-sdl as well." > > Basically, I'm saying that, if we make a little effort to create open, > accessible package data, then everyone will find it easier to work with > us. That shouldn't be a foreign concept. > > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 14:58:53 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 22:58:53 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5BB43.5020101@gmail.com> Message-ID: <52D5C12D.30001@gmail.com> Gaetan, I agree, it's important to think of use cases up-front, and I've tried to do that below, too. If you can add any necessary features or ideas, please do. And if Rustics reach consensus that this is the preferred approach, then we should definitely formalise the decision process about selecting use cases, making sure they're all covered, etc. However, from experience, it's IMPOSSIBLE to think of EVERY use case up front. Simply not knowing what technology will be invented in five years prevents it. No matter how hard you try to envisage all circumstances, and all future use-cases, something will just be obviously missing, in hindsight. The best standards ALWAYS tag versions, and leave room for forwards-compatible upgrades. It's the very reason we have to deal with packages for lots of different library versions: eventually, you want to deprecate old stuff, and embrace new stuff, and you need some version number to tell which is which. This shouldn't be threatening; it's the EASY, SAFE, GENTLE way to add new features. It's what every sensible protocol and standard on the internet does, for instance, right down to IP itself. -- Lee On 14/01/14 22:35, Gaetan wrote: > i disagree, the data structure needs to be developed with the majority > of use case possible. you cannot rely on just "extending it" later > when new feature will be needed, that will NOT work. > > ----- > Gaetan > > > > 2014/1/14 Lee Braiden > > > Another point is that we don't really need a massively complicated > "build system" right now, as far as I know. > > I don't know rust well yet, but it's a two-line script to load > this data (excluding comments). Another few lines to figure out > whether to build a library or an executable, another few to run > rustc with the list of files, OR to output that list to a > Makefile, or a CMakeList.txt, or an IDE project file. > > With the data, you could build any tool of your choice, to use > (almost) any tool of your choice, with a few lines in the language > of your choice. > > And, you can evolve it all later, into something better. And the > data format could be extended too. I should add that the data > format should have a version number, so tools could parse new > versions differently, or even read this file, see that it's > version 2, and that a better, more file format with a different > filename should be used instead. > > > -- > Lee > > > > On 14/01/14 20:51, George Makrydakis wrote: >> >> That would be a good start. But are you advocating that it should >> be third party tools thatcshould be given guidelines on how to >> comply? What would be their incentive to do so? Or should this be >> used as a basis for creating a prototype deploying duch >> information... which would inevitably ask again: >> >> Should Rust have its own build tool, given your proposal of >> standardized representational information ? Dealing with such >> metadata forces you to design a new system. >> >> >> >> Lee Braiden wrote: >> >> On 14/01/14 17:25, Patrick Walton wrote: >> >> On 1/14/14 1:29 AM, comex wrote: >> >> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis >> >> wrote: >> >> Again, note that this rather long thread is about >> discussing in the end what the official stance >> should be. There is no valid reason other than >> lack of manpower and / or language immaturity for >> having to depend on ruby, python, autotools, >> cmake or whatever else in order to build rust >> software. >> >> There is no reason every language should have its own >> build system written from scratch (or package >> manager, for that matter); the goals of each language >> community are really mostly identical However, >> I'd say there is a stunning lack of existing build >> systems that actually combine a clean design, >> flexibility, portability, and performance >> >> This e-mail sums up my feelings to a T, and it's why I'm >> conflicted about the whole matter. >> >> >> The more people talk about different build systems and how we can't >> choose one yet, the more I agree. >> >> So, rethinking, it seems to me that important part seems, is to be >> COMPATIBLE with everyone's project hosting, build system, and/or package >> manager of choice. That would include command line build tools, pretty >> website download catalogs, yum, synaptic, cabal, etc. >> >> >> So, much more important than choosing TOOLS, I think Rust needs to >> standardise INFORMATION that any >> tool can use. Perhaps something like this? >> >> [ >> "project": { >> "name": "someproject", >> >> "brief-description": "some description", >> >> "limited-description": [ >> "Para-one.", >> "Para-two.", >> "Para-three." >> ], >> >> "web": "http://buggysoft.com", >> >> "screenshots": { >> "screenshot one": { >> "uri": "http://www.buggypics.com/massivebug.png", >> "alt-text": "Features massive bugs", >> }, >> }, >> >> "bug-tickets": "http://overloaded-cloud-system.buggysoft.com", >> >> "authors": { >> "author1": { >> "email":"author1 at someplace.com" , >> >> "web": "http://someplace.com", >> }, >> }, >> >> "copyright": { >> "license-file": "docs/LICENSE.TXT", >> "license-flags": "SHAREALIKE | ATTRIBUTION | >> ADVERTISING_CLAUSE", >> }, >> >> "build-info": { >> "build-type": "library", >> "target": "libx.so " >> "source-files": [ "src/*.rs", "somedir/a_file.rs " ], >> }, >> >> "developer-support-info": { >> "rust-ide-doc-file": "docs/libx.rustapi", >> "rust-ide-completion-file": "docs/libx.rusttags", >> }, >> >> "dependencies": { >> "rust-projects": { >> "someotherproject": { # from that projects >> "project" -> "name" >> entry >> >> # following fields are optional; any >> specified filter the list >> # the list of suitable candidates. >> >> "min-version": "0.1", >> "max-version": "0.1", >> >> "gitrepo": >> "http://somehub.com/someuser/someotherproject/", >> "min-git-tag": "04a453543", >> "max-git-tag": "045ead634", >> >> "tarball-uri": >> "http://someotherproject.com/somepath-${version}.tgz", >> >> "distro-version-ok": "true" >> } >> }, >> >> "external-libs": { >> "libssl": { >> >> "min-version": "0.1", >> "max-version": "0.1", >> >> "gitrepo": >> "http://somehub.com/someuser/someotherproject/", >> "min-git-tag": "04a453543", >> "max-git-tag": "045ead634", >> >> "tarball-uri": >> "http://someotherproject.com/somepath-${version}.tgz" >> >> "distro-version-ok": "true", >> } >> }, >> } >> } >> ] >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 15:07:02 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 23:07:02 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> Message-ID: <52D5C316.9070309@gmail.com> On 14/01/14 22:51, Gaetan wrote: > you cannot stick build environment with one system. apt is now on > every system, you cannot use it under windows or mac. I think you're misunderstanding me. I don't favor debian in any way. I would like debian people (and windows people, and mac people, and BSD people, and cloud deployment people, etc.) to be able to use Rust packages in whatever why they choose, though. > and apt source simply checkout the source zip from repository, this is > not a proper build system. This is getting off topic, but no, apt-get source builds source code that's already been patched with package information. It's exactly how debian builds its packages for general use. > package management is one job and build is another one. you will use > another package management on another system, while you expect to use > the same build system on another system. That's true IF your package manager only supports third-party binaries. However, if your package manager includes some build process, as most emphatically DO, then I believe that's incorrect. However, I understand that you're saying we shouldn't rely on particular package managers. That is NOT my intention -- just the opposite :) > in my experience, i ended up quite often with some bash script for > unix like systems that generates some makefiles or trigs cmake/cpack, > visual studio or eclipse projects for windows. > the only portable build system i used was cmake, which exists under > windows mac and unit, with ctest and cpack, even if there are quite > limited. And there were a lot of "if windows..." Yes, this is what I'm saying :) > But, i tend to NOT recommend cmake if the final goal is to be > integrated into systems like debian. The final goal would be to allow every distro, every operating system, every continuous integration system, every shell script, every cloud image builder, every mobile phone developer, and custom OS writer, do work with Rust packages in whatever way suits them best. -- Lee From gaetan at xeberon.net Tue Jan 14 15:09:48 2014 From: gaetan at xeberon.net (Gaetan) Date: Wed, 15 Jan 2014 00:09:48 +0100 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5C316.9070309@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> <52D5C316.9070309@gmail.com> Message-ID: i read the ninja documentation, and this integrates well with cmake, and do the majority of the graph stuff required to compile file. i kind of like it. and i wonder why rust-pkg cannot be extended, for simple project to generate ninja files... ----- Gaetan 2014/1/15 Lee Braiden > On 14/01/14 22:51, Gaetan wrote: > >> you cannot stick build environment with one system. apt is now on every >> system, you cannot use it under windows or mac. >> > > I think you're misunderstanding me. I don't favor debian in any way. I > would like debian people (and windows people, and mac people, and BSD > people, and cloud deployment people, etc.) to be able to use Rust packages > in whatever why they choose, though. > > > > and apt source simply checkout the source zip from repository, this is >> not a proper build system. >> > > This is getting off topic, but no, apt-get source builds source code > that's already been patched with package information. It's exactly how > debian builds its packages for general use. > > > > package management is one job and build is another one. you will use >> another package management on another system, while you expect to use the >> same build system on another system. >> > > That's true IF your package manager only supports third-party binaries. > However, if your package manager includes some build process, as most > emphatically DO, then I believe that's incorrect. > > However, I understand that you're saying we shouldn't rely on particular > package managers. That is NOT my intention -- just the opposite :) > > > > in my experience, i ended up quite often with some bash script for unix >> like systems that generates some makefiles or trigs cmake/cpack, visual >> studio or eclipse projects for windows. >> the only portable build system i used was cmake, which exists under >> windows mac and unit, with ctest and cpack, even if there are quite >> limited. And there were a lot of "if windows..." >> > > Yes, this is what I'm saying :) > > > > But, i tend to NOT recommend cmake if the final goal is to be integrated >> into systems like debian. >> > > The final goal would be to allow every distro, every operating system, > every continuous integration system, every shell script, every cloud image > builder, every mobile phone developer, and custom OS writer, do work with > Rust packages in whatever way suits them best. > > > > -- > Lee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhasse at fastmail.fm Tue Jan 14 15:15:13 2014 From: jhasse at fastmail.fm (Jan Niklas Hasse) Date: Tue, 14 Jan 2014 15:15:13 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5C316.9070309@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> <52D5C316.9070309@gmail.com> Message-ID: <1389741313.32027.70816441.69B32D0C@webmail.messagingengine.com> On Tue, Jan 14, 2014, at 03:07 PM, Lee Braiden wrote: > > package management is one job and build is another one. you will use > > another package management on another system, while you expect to use > > the same build system on another system. > > That's true IF your package manager only supports third-party binaries. > However, if your package manager includes some build process, as most > emphatically DO, then I believe that's incorrect. Doesn't matter what the build system is, it's just another command to execute specified for the debian package. > The final goal would be to allow every distro, every operating system, > every continuous integration system, every shell script, every cloud > image builder, every mobile phone developer, and custom OS writer, do > work with Rust packages in whatever way suits them best. I wouldn't say *every* distro, etc. Here's an extreme example: Let's say there's a distro which forces every source package to have its filenames start with capital letters. Should we rename our files? I would say definitely no. The distro has to adapt in that case. The same goes for the build system: Debian can't handle executing "rustpkg build" instead of "make"? It's their problem! (This is of course false: Debian CAN handle exactly that) From martindemello at gmail.com Tue Jan 14 15:15:47 2014 From: martindemello at gmail.com (Martin DeMello) Date: Tue, 14 Jan 2014 15:15:47 -0800 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> <52D5C316.9070309@gmail.com> Message-ID: This would probably be a useful thing to have even if the rust project doesn't officially end up adopting it as the One True Solution. martin On Tue, Jan 14, 2014 at 3:09 PM, Gaetan wrote: > i read the ninja documentation, and this integrates well with cmake, and > do the majority of the graph stuff required to compile file. i kind of like > it. and i wonder why rust-pkg cannot be extended, for simple project to > generate ninja files... > > ----- > Gaetan > > > > 2014/1/15 Lee Braiden > >> On 14/01/14 22:51, Gaetan wrote: >> >>> you cannot stick build environment with one system. apt is now on every >>> system, you cannot use it under windows or mac. >>> >> >> I think you're misunderstanding me. I don't favor debian in any way. I >> would like debian people (and windows people, and mac people, and BSD >> people, and cloud deployment people, etc.) to be able to use Rust packages >> in whatever why they choose, though. >> >> >> >> and apt source simply checkout the source zip from repository, this is >>> not a proper build system. >>> >> >> This is getting off topic, but no, apt-get source builds source code >> that's already been patched with package information. It's exactly how >> debian builds its packages for general use. >> >> >> >> package management is one job and build is another one. you will use >>> another package management on another system, while you expect to use the >>> same build system on another system. >>> >> >> That's true IF your package manager only supports third-party binaries. >> However, if your package manager includes some build process, as most >> emphatically DO, then I believe that's incorrect. >> >> However, I understand that you're saying we shouldn't rely on particular >> package managers. That is NOT my intention -- just the opposite :) >> >> >> >> in my experience, i ended up quite often with some bash script for unix >>> like systems that generates some makefiles or trigs cmake/cpack, visual >>> studio or eclipse projects for windows. >>> the only portable build system i used was cmake, which exists under >>> windows mac and unit, with ctest and cpack, even if there are quite >>> limited. And there were a lot of "if windows..." >>> >> >> Yes, this is what I'm saying :) >> >> >> >> But, i tend to NOT recommend cmake if the final goal is to be integrated >>> into systems like debian. >>> >> >> The final goal would be to allow every distro, every operating system, >> every continuous integration system, every shell script, every cloud image >> builder, every mobile phone developer, and custom OS writer, do work with >> Rust packages in whatever way suits them best. >> >> >> >> -- >> Lee >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Jan 14 15:40:02 2014 From: leebraid at gmail.com (Lee Braiden) Date: Tue, 14 Jan 2014 23:40:02 +0000 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <1389741313.32027.70816441.69B32D0C@webmail.messagingengine.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5B607.5070003@gmail.com> <52D5BAA4.8070405@gmail.com> <52D5BD10.9080406@gmail.com> <52D5C316.9070309@gmail.com> <1389741313.32027.70816441.69B32D0C@webmail.messagingengine.com> Message-ID: <52D5CAD2.7040306@gmail.com> On 14/01/14 23:15, Jan Niklas Hasse wrote: > On Tue, Jan 14, 2014, at 03:07 PM, Lee Braiden wrote: >>> package management is one job and build is another one. you will use >>> another package management on another system, while you expect to use >>> the same build system on another system. >> That's true IF your package manager only supports third-party binaries. >> However, if your package manager includes some build process, as most >> emphatically DO, then I believe that's incorrect. > Doesn't matter what the build system is, it's just another command to > execute specified for the debian package. Well, the problem for package managers is threefold: 1) Builds involve dependencies: which source *packages* need to be installed for that package to build, and of course, what dependencies are requiring the CURRENT package to be installed in the first place. It's not enough to just be able to BUILD a package; a package manager has to know how, and why it's building something, where it will go when installed, and what that will MEAN in terms of dependency resolution, when the package is finally built and installed. Otherwise, it's not a package MANAGER: it's just front end for downloaders/installers. 2) Some packages, if Rust becomes mainstream at all, will be available from multiple sources, in multiple versions. For example, rust-std might be included with a distro, as a standard package. So might rust-sdl2. But maybe someone with that package installed decides to install rust-newgame, which requires rust-sdl2--bobs-greenthreads-patch. Then you have a conflict. If your build script blindly installs rust-sdl2--bobs-greenthreads-patch over rust-sdl2, it could break all rust packages that use SDL. 3) Packages take a lot of time to create and maintain. If we want useful rust packages to reach as many people as possible, they should be readily available in as many package managers as possible, in a standard, non-conflicting package. Now, there are two ways (that I can see so far) to achieve (3): i) Expect all operating systems' and all distros' package maintainers to find the resources to package lots of rust libraries and programs. ii) Make it easy for those maintainers to IMPORT rust libraries and programs, using information that only we know, and that we will get multiple emails requesting anyway, if we don't provide it up front, from the start. >> I wouldn't say *every* distro, etc. Here's an extreme example: Let's say >> there's a distro which forces every source package to have its filenames >> start with capital letters. Should we rename our files? I would say >> definitely no. The distro has to adapt in that case. That's a good point, and a good example of why we should think through maximum compatibility carefully. I hadn't thought of that one, but now that someone's thought of it, it should be easily solved by disallowing case-dependency in package names. That way, different tools could auto-capitalize, auto-title-case or whatever they prefer, as long as they remember to lower-case when building the URL. But yes, I take your wider point that there'll invariably be something you don't think of first time around. It's that kind of thing I'm talking about a version number for -- ensuring an upgrade path, just in case. > The same goes for the build system: Debian can't handle executing > "rustpkg build" instead of "make"? It's their problem! (This is of > course false: Debian CAN handle exactly that) Right; building itself (for most things) isn't that hard, even if you're running rustc instead of rustpkg, I suppose. It's dependencies and package conflicts that are the real issue, not just building. Otherwise, package management, DLL hell, RPM hell, etc., would have been mostly solved as soon as most builds used make. -- Lee From mozilla at mcpherrin.ca Tue Jan 14 15:43:13 2014 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Tue, 14 Jan 2014 15:43:13 -0800 Subject: [rust-dev] sticker In-Reply-To: References: Message-ID: I've heard continual rumours a proper Mozilla / Firefox store is coming alive again: Maybe somebody at MoCo can prod and see if it's possible to get some Rust schwag in that. On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri wrote: > Have you considered selling the stickers through something like DevSwag.com? > I'm sure Yehuda can get you connected ;) > > > On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier > wrote: >> >> If you organize a Rust meetup near you and email Brian Anderson or one >> of the other core Rust developers who work for Mozilla, I suspect they >> would be happy to send you a batch of stickers to hand out. That's one >> way, anyway :-) >> >> Cheers, >> Tim >> >> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 wrote: >> > >> > >> > >> > 2014/1/14 Gaetan >> >> >> >> Just came accross this good presentation: >> >> http://www.youtube.com/watch?v=gfCtbGiHcg0 >> >> >> >> A question poped into my head: where could I find rust stickers ? >> > >> > >> > I was wondering the same thing! I love stickers and I definitely want a >> > Rust >> > sticker :D >> > >> > >> > >> > -- >> > Flavio (@flaper87) Percoco >> > http://www.flaper87.com >> > http://github.com/FlaPer87 >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at 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 at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From corey at octayn.net Tue Jan 14 15:43:56 2014 From: corey at octayn.net (Corey Richardson) Date: Tue, 14 Jan 2014 18:43:56 -0500 Subject: [rust-dev] RFC: Future of the Build System In-Reply-To: <52D5BB43.5020101@gmail.com> References: <52CFB098.8010100@gmail.com> <3b3dc812-9dc6-4019-8313-4b8d1f55f921@email.android.com> <52D572FC.5050200@mozilla.com> <52D5A178.6060009@gmail.com> <730e8785-a81b-48b4-9153-e74c9fdea757@email.android.com> <52D5BB43.5020101@gmail.com> Message-ID: On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden wrote: > Another point is that we don't really need a massively complicated "build > system" right now, as far as I know. > > I don't know rust well yet, but it's a two-line script to load this data > (excluding comments). Another few lines to figure out whether to build a > library or an executable, another few to run rustc with the list of files, > OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project > file. > This thread is deviating from its purpose. The idea isn't to hash out a generic build system for all of Rust, merely for the compiler + stdlib. From christopher.meiklejohn at gmail.com Tue Jan 14 15:45:02 2014 From: christopher.meiklejohn at gmail.com (Christopher Meiklejohn) Date: Tue, 14 Jan 2014 18:45:02 -0500 Subject: [rust-dev] sticker In-Reply-To: References: Message-ID: Who do we contact if we're running a meetup? I'm in the process of organizing one in Providence, RI currently. - Chris On Tue, Jan 14, 2014 at 6:43 PM, Matthew McPherrin wrote: > I've heard continual rumours a proper Mozilla / Firefox store is > coming alive again: Maybe somebody at MoCo can prod and see if it's > possible to get some Rust schwag in that. > > On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri wrote: > > Have you considered selling the stickers through something like > DevSwag.com? > > I'm sure Yehuda can get you connected ;) > > > > > > On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier > > wrote: > >> > >> If you organize a Rust meetup near you and email Brian Anderson or one > >> of the other core Rust developers who work for Mozilla, I suspect they > >> would be happy to send you a batch of stickers to hand out. That's one > >> way, anyway :-) > >> > >> Cheers, > >> Tim > >> > >> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 wrote: > >> > > >> > > >> > > >> > 2014/1/14 Gaetan > >> >> > >> >> Just came accross this good presentation: > >> >> http://www.youtube.com/watch?v=gfCtbGiHcg0 > >> >> > >> >> A question poped into my head: where could I find rust stickers ? > >> > > >> > > >> > I was wondering the same thing! I love stickers and I definitely want > a > >> > Rust > >> > sticker :D > >> > > >> > > >> > > >> > -- > >> > Flavio (@flaper87) Percoco > >> > http://www.flaper87.com > >> > http://github.com/FlaPer87 > >> > > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > >> > > >> > >> > >> > >> -- > >> Tim Chevalier * http://catamorphism.org/ * Often in error, never in > doubt > >> "If you are silent ab