From kevin at sb.org Sun Sep 1 00:27:48 2013 From: kevin at sb.org (Kevin Ballard) Date: Sun, 1 Sep 2013 00:27:48 -0700 Subject: [rust-dev] Cross-module priv visibility? Message-ID: <43818495-56E3-48C4-9DC0-1C2FBC3F89BE@sb.org> What are the intended rules for cross-module visibility of priv items? My impression was that either parents were supposed to be able to see their children's priv items, or children could see their parents' priv items, or maybe both. But it seems that right now neither is true. I know that there are bugs right now with visibility, so I'm not sure what was actually intended here. -Kevin From jon.mb at proinbox.com Sun Sep 1 01:48:52 2013 From: jon.mb at proinbox.com (John Mija) Date: Sun, 01 Sep 2013 09:48:52 +0100 Subject: [rust-dev] Mozilla using Go Message-ID: <5222FF74.8010603@proinbox.com> Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). Then, when is better intended use case of Rust respect to Go? I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. From dobkeratops0 at yahoo.co.uk Sun Sep 1 02:19:28 2013 From: dobkeratops0 at yahoo.co.uk (Walter Walter) Date: Sun, 1 Sep 2013 10:19:28 +0100 (BST) Subject: [rust-dev] impl restriction between crates Message-ID: <1378027168.17601.YahooMailNeo@web133204.mail.ir2.yahoo.com> r.e. "impl's" on a type outside its original library crate .. i understand this is to preclude inter-crate clashes, if 2 library writers attempt to over-ride the same function. i might be barking up the wrong tree here- rust has obviously been designed with the benefit of a lot of experience behind it. but... Would it be feasible to relax this error to a warning - or perhaps enable this behaviour with compiler options; one compromise might be to only make it an error when compiling a library**. potential use cases:- [1] When writing code that is never going to be put into a library, you'd be able to extend existing types with greater ease (less traits to make.. naming is hard, the fewer things you have to name the better). People writing smaller programs might make better use of existing types - especially while they're evolving.. and what doesn't evolve.. Any difference between usability of libary types and your own provides an incentive for NIH. a current example is the iterators which need the ".iter()" on the collection.. i've been tempeted to make workarounds to that. Open-world is a big draw to rust, it's over half the reason for my interest in this language... looking for a solution to the way headers & classes interact badly in C++. [2] Greater symetry between your own code where you may not have settled on libary/module divisons .. lets say you seperate part of a program out after it? moves beyond a certain size, you'd have to start introducing extra traits... its just one more refactoring barrier. [3] I just thought about this for trying to write anIDE plugin.. .. currently you must compile an entire crate when something changes, which is very slow. But what if an IDE tool could divide the crate up into 1 crate per sourcefile, perhaps automatically generating an alternate 'main.rs' to pull these together. this is much like scenario [2]... this would involve having the same code compiling as either a multitude of crates, or being pulled together as one crate. in particular node ID's are enumerated for the entire crate, demanding a 'rebuild'. But I dont think you'd routinely/manually want to divide things up into one crate per sourcefile. personally i think i would prefer the restriction not to exist at all, i wouldn't mind the potential for libary link errors appearing; I read the opinion that it doesn't matter because you can submit changes to the original library code being opensource, but i think its *much* more feasible for members of the rust community to request changes or splits in eachother libraries versus submitting changes to the *standard* libaries, which, being used by more people are going to have greater momentum ,more disagreement, longer time to agree on the most widely accepted methods ... an individual library writer need merely be mindful of this hazrd. Doesn't matter if something is opensource .. it can be hard to change - its a point of disagreement and individuals might not considerevery other use case. In C++ I hear some people objecting to extention methods for the same reason, but this objection sounds unfounded to me because you can just make overloaded functions anyway already, and i've never ran into those being a problem. its just nicer to have the same a.foo(b) calling syntax available for everything .. is it possible for the module system to assist disambiguating if clashes do occur? there's always some use directives around.. could those prioritize the use of one supplied method over another. I know Go has a similar open world idea .. and a similar issue, no extending outside a package, just within sources of the same package, and there you have to make a new type to extend.. which is probably worse than making a new trait IMO. So perhaps rust is already the best balance here, i dont know. I do like the fact that in go methods aren't actually part of anything when defined, even less pre-planning going on, and their interfaces just gather them after they're written, but i prefer the inter-module behaviour of traits over what go does. ** .. you might say thats' inconsistent, different rules where the same source compiles, but you already have that by the fact this issue exists at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun Sep 1 02:30:01 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 1 Sep 2013 11:30:01 +0200 Subject: [rust-dev] Mozilla using Go In-Reply-To: <5222FF74.8010603@proinbox.com> References: <5222FF74.8010603@proinbox.com> Message-ID: In a practical manner, I would say that Go is production ready whilst Rust still has some way to go (!). Rust 1.0 is approaching, but is not there yet, and there are still syntax/semantic questions being examined and lots of work on the runtime... not to mention the lack of libraries (compared to Go) largely due to the language still not being finalized. I believe Rust could supplant Go (I see nothing in Go that Rust cannot do) and cast a much wider net, but first it has to mature. -- Matthieu On Sun, Sep 1, 2013 at 10:48 AM, John Mija wrote: > Hi! I've seen that Mozilla has used Go to build Heka ( > https://github.com/mozilla-**services/heka). > And although Go was meant to build servers while Rust was meant to build > concurrent applications, Rust is better engineered that Go (much safer, > more modular, optional GC). > > Then, when is better intended use case of Rust respect to Go? > I expect Rust to be the next language for desktop applications if it gains > as much maturity as Go but I'm unsure respect to the server side. > ______________________________**_________________ > 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 amitava.shee at gmail.com Sun Sep 1 05:18:04 2013 From: amitava.shee at gmail.com (Amitava Shee) Date: Sun, 1 Sep 2013 08:18:04 -0400 Subject: [rust-dev] make check fails In-Reply-To: References: Message-ID: Thanks. I added a comment in the issue with instructions to raise the file descriptor limits (temporary workaround). For the convenience of others, I am repeating it here. Reboot after running these commands echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf echo 'ulimit -n 4096' | sudo tee -a /etc/profile -Amitava On Sat, Aug 31, 2013 at 2:12 PM, Kevin Cantu wrote: > I see that, too. Filed an issue for it: seems like some kind of > libc::pipe problem on OS X with that that function. > https://github.com/mozilla/rust/issues/8904 > > > Kevin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garethdanielsmith at gmail.com Sun Sep 1 06:37:39 2013 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Sun, 01 Sep 2013 14:37:39 +0100 Subject: [rust-dev] changing roles In-Reply-To: <5221333F.1040501@mozilla.com> References: <5221333F.1040501@mozilla.com> Message-ID: <52234323.8060700@gmail.com> You have done an excellent job. Thank you. Gareth On 31/08/13 01:05, Graydon Hoare wrote: > Hi, > > As I'm sure many of you who know me are aware, my role as technical > lead on Rust has been quite draining over the years. Both to myself > and to those I've worked with, it just isn't a great fit for me. > > In recognition of this, I am stepping aside to work elsewhere in the > organization, and Brian will be assuming the role of technical lead of > Rust. > > Brian is one of the most skilled, judicious, professional and > productive developers I've ever worked with. Along with the > exceptional skill and dedication of the rest of the Rust team, I have > complete confidence in the remaining path to a successful 1.x series > of what has shaped up to be an excellent language. > > It has been a rare pleasure and privilege to work with the Rust team, > both those inside Mozilla and in the broader community. > > Thanks, > > -Graydon > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From simon.sapin at exyr.org Sun Sep 1 06:47:22 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Sun, 01 Sep 2013 14:47:22 +0100 Subject: [rust-dev] App runtime based on Servo In-Reply-To: <52224263.4010902@proinbox.com> References: <52224263.4010902@proinbox.com> Message-ID: <5223456A.5060104@exyr.org> Le 31/08/2013 20:22, John Mija a ?crit : > From my point of view, there is no technology related to User > Interfaces more advanced than web-based (HTML5/CSS3). > > [...] > > Now, what do think about to have a similar technology but using Servo? > To being able to develop desktop apps in Rust (or Go via bindings to > Rust libraris) and JS or Dart for the UI. I don?t know about adding Go or Dart to the mix, but it is definitely one of Servo?s goals to be embeddable as a library in a larger application. -- Simon Sapin From bjzaba at yahoo.com.au Sun Sep 1 06:49:03 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Sun, 1 Sep 2013 23:49:03 +1000 Subject: [rust-dev] Mozilla using Go In-Reply-To: <5222FF74.8010603@proinbox.com> References: <5222FF74.8010603@proinbox.com> Message-ID: <291C645B-D5E3-42B9-83BB-0A94851DD834@yahoo.com.au> My understanding is that Rust is meant more for real-time, performance/security critical applications, such as user-facing guis and rendering engines. This also fits nicely with games and graphics applications. There is also the real possibility of it being useful in embedded systems. Go is designed more for large, server-side applications. The core devs have said many times that they don't consider Go to be a competitor. ~Brendan On 01/09/2013, at 6:48 PM, John Mija wrote: > Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). > > Then, when is better intended use case of Rust respect to Go? > I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Sun Sep 1 06:50:42 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 1 Sep 2013 09:50:42 -0400 Subject: [rust-dev] Mozilla using Go In-Reply-To: <291C645B-D5E3-42B9-83BB-0A94851DD834@yahoo.com.au> References: <5222FF74.8010603@proinbox.com> <291C645B-D5E3-42B9-83BB-0A94851DD834@yahoo.com.au> Message-ID: IMO Rust is very applicable as a general purpose language, perhaps moreso than C++. On Sun, Sep 1, 2013 at 9:49 AM, Brendan Zabarauskas wrote: > My understanding is that Rust is meant more for real-time, performance/security critical applications, such as user-facing guis and rendering engines. This also fits nicely with games and graphics applications. There is also the real possibility of it being useful in embedded systems. Go is designed more for large, server-side applications. The core devs have said many times that they don't consider Go to be a competitor. > > ~Brendan > > On 01/09/2013, at 6:48 PM, John Mija wrote: > >> Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). >> >> Then, when is better intended use case of Rust respect to Go? >> I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. >> _______________________________________________ >> 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 reshef.dov at gmail.com Sun Sep 1 06:58:56 2013 From: reshef.dov at gmail.com (Dov Reshef) Date: Sun, 1 Sep 2013 16:58:56 +0300 Subject: [rust-dev] Cross-module priv visibility? In-Reply-To: <43818495-56E3-48C4-9DC0-1C2FBC3F89BE@sb.org> References: <43818495-56E3-48C4-9DC0-1C2FBC3F89BE@sb.org> Message-ID: Have a look here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-07-30#visibility-in-module-system . And here: https://github.com/mozilla/rust/issues/8169. On Sun, Sep 1, 2013 at 10:27 AM, Kevin Ballard wrote: > What are the intended rules for cross-module visibility of priv items? My > impression was that either parents were supposed to be able to see their > children's priv items, or children could see their parents' priv items, or > maybe both. But it seems that right now neither is true. I know that there > are bugs right now with visibility, so I'm not sure what was actually > intended here. > > -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 oren at ben-kiki.org Sun Sep 1 08:23:43 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sun, 1 Sep 2013 18:23:43 +0300 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <52213DE0.2000109@mozilla.com> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> Message-ID: Since swap seems to have its own problems - would it be possible to tweak the stealing idea so the compiler would know there's a burrowed mutable pointer to the hole, effectively preventing further access to it in the vulnerable block? I really would like to be able to use this approach, it really improved my code... On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton wrote: > On 8/30/13 3:39 PM, Patrick Walton wrote: > >> Thoughts? Does this seem useful? Are there soundness issues I didn't >> notice? >> > > Brian pointed out a massive soundness hole in this, unfortunately. The > problem is that you can read from the original locations; the right to read > is not "shut off" during the borrow. I think the fix would have to be to > replace this with some sort of "generalized swap" operation. > > > 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 pwalton at mozilla.com Sun Sep 1 08:25:07 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 01 Sep 2013 08:25:07 -0700 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> Message-ID: <52235C53.5070801@mozilla.com> On 9/1/13 8:23 AM, Oren Ben-Kiki wrote: > Since swap seems to have its own problems - would it be possible to > tweak the stealing idea so the compiler would know there's a burrowed > mutable pointer to the hole, effectively preventing further access to it > in the vulnerable block? > > I really would like to be able to use this approach, it really improved > my code... What's the problem with a generalized swap (>= 2 elements, any permutation) for your use case? Patrick From flaper87 at gmail.com Sun Sep 1 12:45:03 2013 From: flaper87 at gmail.com (Flaper87) Date: Sun, 1 Sep 2013 21:45:03 +0200 Subject: [rust-dev] Mozilla using Go In-Reply-To: References: <5222FF74.8010603@proinbox.com> <291C645B-D5E3-42B9-83BB-0A94851DD834@yahoo.com.au> Message-ID: 2013/9/1 Corey Richardson > IMO Rust is very applicable as a general purpose language, perhaps > moreso than C++. > I agree with the above! I don't see Rust being bound to a specific area, I think it can be used in many different types of applications. -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Mon Sep 2 16:37:34 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon, 2 Sep 2013 16:37:34 -0700 Subject: [rust-dev] Questions about linked lists in Rust In-Reply-To: References: Message-ID: On Wed, Aug 28, 2013 at 8:22 PM, Nicholas Bishop wrote: > Hi, > > I'm new to Rust, currently trying out a few simple tests to get a > handle on things. > > I have a few questions about linked lists. I see there are two list > modules in extra, one for ~ pointers and one for @ pointers. (I'm > using the current trunk rather than 0.7 if that makes a difference.) > Hi, Nicholas -- There are two list modules because one is a singly linked list -- list.rs -- and one is a doubly linked list -- dlist.rs . Off the top of my head I'm not sure if there's a reason why list.rs uses @ pointers. > The interfaces between the two look quite different however. Is this > because one is newer and the other hasn't caught up yet, or are the > differences by design and the two interfaces will stay more or less as > they are? > I would expect that the interfaces will be different, since one might want to use a doubly-linked list for different purposes than a singly linked list. > In extra::list, I don't see methods to append or remove a single > element. Intentional or todo? Probably to-do. > > In extra::dlist, there are methods to remove the back or front > element, but not an arbitrary link? Probably to-do. > > On a related note, I'd be interested to read about implementing data > structures in Rust. The examples of structs in the tutorial are mostly > very simple (Point, Circle, etc). The use of Rust's pointers get much > more complicated when dealing with non-tree structures. For example, > extra::dlist uses raw pointers rather than @ pointers for links. An > overview of what the tradeoffs look like (code clarity, > memory-leak/memory-corruption issues, performance numbers, memory > usage) and some cookbook patterns could be quite helpful. This would make a great topic for a blog post -- perhaps someone has even already written it! As far as existing code examples go, extra::treemap might be a good one to study. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From niko at alum.mit.edu Mon Sep 2 17:04:17 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 2 Sep 2013 20:04:17 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <52213DE0.2000109@mozilla.com> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> Message-ID: <20130903000417.GB21849@Mr-Bennet> On Fri, Aug 30, 2013 at 05:50:40PM -0700, Patrick Walton wrote: > Brian pointed out a massive soundness hole in this, unfortunately. > The problem is that you can read from the original locations; the > right to read is not "shut off" during the borrow. I think the fix > would have to be to replace this with some sort of "generalized swap" > operation. One thing that I've been wanting to do is to generalize our move rules. Currently, we do not permit you to move data from borrowed locations -- but we COULD safely permit this, under certain conso long as you From niko at alum.mit.edu Mon Sep 2 17:08:43 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 2 Sep 2013 20:08:43 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <20130903000417.GB21849@Mr-Bennet> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <20130903000417.GB21849@Mr-Bennet> Message-ID: <20130903000843.GA12491@Mr-Bennet> Sorry, sent that e-mail prematurely. Short version is that I think we could generalize our move rules somewhat precisely for the purpose of accommodating this situation, but the question is whether it would ultimately be expressive enough. There would have to be rules against making fn calls, reading const pointers, and similar things while borrowed data is in a moved out state. Ultimately, it probably winds up being equivalent to a "multi-swap" primitive, so perhaps that's a better approach anyhow! (Plus it avoids the need to worry about what to do in the case of failure, I haven't really about that before) Niko On Mon, Sep 02, 2013 at 08:04:17PM -0400, Niko Matsakis wrote: > On Fri, Aug 30, 2013 at 05:50:40PM -0700, Patrick Walton wrote: > > Brian pointed out a massive soundness hole in this, unfortunately. > > The problem is that you can read from the original locations; the > > right to read is not "shut off" during the borrow. I think the fix > > would have to be to replace this with some sort of "generalized swap" > > operation. > > One thing that I've been wanting to do is to generalize our move > rules. Currently, we do not permit you to move data from borrowed > locations -- but we COULD safely permit this, under certain > conso long as you > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From niko at alum.mit.edu Mon Sep 2 17:13:05 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 2 Sep 2013 20:13:05 -0400 Subject: [rust-dev] Questions about linked lists in Rust In-Reply-To: References: Message-ID: <20130903001305.GB12491@Mr-Bennet> On Mon, Sep 02, 2013 at 04:37:34PM -0700, Tim Chevalier wrote: > There are two list modules because one is a singly linked list -- > list.rs -- and one is a doubly linked list -- dlist.rs . Off the top > of my head I'm not sure if there's a reason why list.rs uses @ > pointers. The reason that list uses `@` pointers is because it is indended to serve as the venerable "cons-list" data structure found in Lisp and many functional languages. The real advantage of this data structure is that it is persistent, meaning you can prepend items to the list without modifying the old copies of the list. To make this convenient, garbage collection is required. If you only have one copy of the list, you might as well use a `~[]` vector. Niko From echristo at gmail.com Tue Sep 3 10:43:40 2013 From: echristo at gmail.com (Eric Christopher) Date: Tue, 3 Sep 2013 10:43:40 -0700 Subject: [rust-dev] Disabling LLVM Asserts In-Reply-To: References: Message-ID: On Sat, Aug 31, 2013 at 5:21 PM, Corey Richardson wrote: > https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-08-27#llvm-asserts > discusses disabling LLVM assertions. I don't think it just risks > segfaults, doesn't it also run the risk of invalid codegen for > incorrect uses? > It does all of these things yes. It costs, last I checked, about 5-10% of compile time in clang to leave assertions on as well as some additional code size. If another data point is useful here the chromium guys leave asserts on in the clang toolchain they use. -eric From corey at octayn.net Tue Sep 3 11:34:22 2013 From: corey at octayn.net (Corey Richardson) Date: Tue, 3 Sep 2013 14:34:22 -0400 Subject: [rust-dev] Out of -Z flags Message-ID: Right now Z flags are implemented using a bit flag stored in a uint, which is only reliably 32 bits on the platforms we use. We could extend it to a u64, or we could use an enum, but we can't continue doing this, because https://github.com/mozilla/rust/pull/8955 uses the last available bit. From josh at joshmatthews.net Tue Sep 3 11:39:54 2013 From: josh at joshmatthews.net (Josh Matthews) Date: Tue, 3 Sep 2013 14:39:54 -0400 Subject: [rust-dev] Out of -Z flags In-Reply-To: References: Message-ID: We could free one up by moving basic debug-info back into the -g flag. Now that we have automated tests, it's a lot less likely to get busted and frustrate people. On 3 September 2013 14:34, Corey Richardson wrote: > Right now Z flags are implemented using a bit flag stored in a uint, > which is only reliably 32 bits on the platforms we use. We could > extend it to a u64, or we could use an enum, but we can't continue > doing this, because https://github.com/mozilla/rust/pull/8955 uses the > last available bit. > _______________________________________________ > 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 bjzaba at yahoo.com.au Tue Sep 3 18:06:14 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Wed, 4 Sep 2013 11:06:14 +1000 Subject: [rust-dev] Formatting complex trait definitions and impls References: <64EA98D6-4174-4DF8-ACD1-C9ACAC1BEDED@yahoo.com.au> Message-ID: Has anybody worked out a decent way to lay out complex definitions? This is what I'm starting to do: pub trait AffineSpace < S: Field, V: VectorSpace > : Eq + Zero + Add + Sub + ScalarMul { // ... } impls are harder though: impl Sub, Vec3> for Point3 { ? } Any ideas? This is one way maybe, but it looks terrible: impl < S: Field > Sub < Point3, Vec3 > for Point3 { // ... } Stacking it is probably overkill for that impl, but there a most likely going to be worse ones. Maybe this is more of a problem with the current syntax? ~Brendan From niko at alum.mit.edu Wed Sep 4 03:20:10 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 4 Sep 2013 06:20:10 -0400 Subject: [rust-dev] Out of -Z flags In-Reply-To: References: Message-ID: <20130904102010.GA6112@Mr-Bennet> Just switch it to u64. Niko On Tue, Sep 03, 2013 at 02:34:22PM -0400, Corey Richardson wrote: > Right now Z flags are implemented using a bit flag stored in a uint, > which is only reliably 32 bits on the platforms we use. We could > extend it to a u64, or we could use an enum, but we can't continue > doing this, because https://github.com/mozilla/rust/pull/8955 uses the > last available bit. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From qwertie256 at gmail.com Wed Sep 4 09:58:09 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Wed, 4 Sep 2013 10:58:09 -0600 Subject: [rust-dev] Structural enums for datasort refinements In-Reply-To: References: Message-ID: On Wed, Aug 28, 2013 at 11:19 AM, David Piepgrass wrote: > > From: Bill Myers >> >> I was reading a proposal about adding "datasort refinements" to make enum >> variants first-class types, and it seems to me there is a simpler and more >> effective way of solving the problem. >> >> The idea is that if A, B and C are types, then "A | B | C" is a >> "structural" enum type that can be either A, B or C. >> >> ... > > > Hi, I'm just your friendly everyday lurker... Assuming there's nothing in > this proposal that fundamentally breaks the language, I just wanted to say > I think this idea is fantastic. You almost don't need Some(T) since > Option could just be None|T. > > I would add that I recall recently some people were discussing how to do a > "variant" type in Rust. If all struct types in a program are assigned a > unique tag, this very same feature could support a variant type, which is > defined as the union of all types. Then any struct converts implicitly to > variant (oh, and since I just wrote a parser generator that supports > inverted sets like ~('a'..'z'), it occurs to me that the type system could > readily support "any type except A | B" as well.) > > The tag could either be a unique integer index, or a pointer to a global > variable that contains type information (the latter, it seems to me, > automatically solves the dynamic linking problem "how do we ensure two > unrelated DLLs have unique tags?" DLL loaders already support relocation in > case of conflicts.) > > Oops, I just remembered that Rust implements enum types using a fixed-size memory area that is as large as the largest possible item. So a variant (or "anything except") type, having unlimited size, doesn't directly fit into that model. But the compiler could switch to a heap representation for variants. Or, better, variants could use a smart fixed-size representation in which heap allocation is used only when the variant is storing a larger type. For instance, a variant could always use two words, one word for the type tag and one word for the value. If the current data type T is one word or smaller, it is stored directly in the second word. Otherwise, the second word is a ~T pointer. Just an idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed Sep 4 12:29:48 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 04 Sep 2013 12:29:48 -0700 Subject: [rust-dev] Mozilla using Go In-Reply-To: <5222FF74.8010603@proinbox.com> References: <5222FF74.8010603@proinbox.com> Message-ID: <52278A2C.1000608@steveklabnik.com> The Rust team already has a page about Go[1]. The two languages, as you mention, aren't exactly competing. This thread has been okay so far, but I'd advise everyone to pay close attention to the Code of Conduct[2]: threads like this have a tendency to devolve quickly. Bashing other languages is not appropriate. Thanks for keeping it clean so far. :) 1: https://github.com/mozilla/rust/wiki/Doc-language-FAQ#have-you-seen-this-google-language-go-how-does-rust-compare 2: https://github.com/mozilla/rust/wiki/Note-development-policy#conduct -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From dwrenshaw at gmail.com Thu Sep 5 09:29:59 2013 From: dwrenshaw at gmail.com (David Renshaw) Date: Thu, 5 Sep 2013 09:29:59 -0700 Subject: [rust-dev] instantiating parameterized impls Message-ID: Hi, When I try to compile the below program, why do I get a "conflicting implementations" error? I do not define any implementations of Bar, so the parameterized impl of Foo should never get instantiated, right? ------------------- trait Foo { fn foo() -> Self; } trait Bar : std::num::Zero { } impl Foo for T { fn foo() -> T { std::num::Zero::zero() } } impl Foo for u16 { fn foo () -> u16 { 100 } } fn main() { // should be 100 let x : u16 = Foo::foo(); printfln!("%s", x); } // error: conflicting implementations for trait `Foo` ------------------ When I asked about this on IRC, cmr indicated that this is probably the intended behavior of rustc, but that most people want to change it. Is that true, and when can we expect a fix? Thanks, David From catamorphism at gmail.com Thu Sep 5 12:36:54 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 5 Sep 2013 12:36:54 -0700 Subject: [rust-dev] instantiating parameterized impls In-Reply-To: References: Message-ID: On Thu, Sep 5, 2013 at 9:29 AM, David Renshaw wrote: > Hi, > > When I try to compile the below program, why do I get a "conflicting > implementations" error? I do not define any implementations of Bar, so > the parameterized impl of Foo should never get instantiated, right? > > ------------------- > > trait Foo { > fn foo() -> Self; > } > > trait Bar : std::num::Zero { } > > impl Foo for T { > fn foo() -> T { > std::num::Zero::zero() > } > } > > impl Foo for u16 { > fn foo () -> u16 { > 100 > } > } > > fn main() { > > // should be 100 > let x : u16 = Foo::foo(); > printfln!("%s", x); > > } > > // error: conflicting implementations for trait `Foo` > > ------------------ > The reason is that there is no guarantee that you will never use this code in a context where another module defines an impl of Bar for u16. In that scenario, you would have two different impls of Foo for u16, and no way to disambiguate. In Haskell, this is called the "overlapping instances" problem; it happens because traits in Rust, and type classes in Haskell, are open rather than closed (when you define a trait, you don't have any way of knowing all the impls of it for a particular type). > > When I asked about this on IRC, cmr indicated that this is probably > the intended behavior of rustc, but that most people want to change > it. Is that true, and when can we expect a fix? I'm not sure that most people want to change it. Handling the issue in general is quite subtle (see http://web.cecs.pdx.edu/~jgmorris/pubs/morris-icfp2010-instances.pdf ). One workaround is to use newtypes: struct Wrapper { x: T } ... impl Foo for Wrapper { ... and then there's no ambiguity. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From steven099 at gmail.com Thu Sep 5 13:25:07 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Thu, 5 Sep 2013 16:25:07 -0400 Subject: [rust-dev] instantiating parameterized impls In-Reply-To: References: Message-ID: On Thu, Sep 5, 2013 at 3:36 PM, Tim Chevalier wrote: > The reason is that there is no guarantee that you will never use this > code in a context where another module defines an impl of Bar for u16. > In that scenario, you would have two different impls of Foo for u16, > and no way to disambiguate. In Haskell, this is called the > "overlapping instances" problem; it happens because traits in Rust, > and type classes in Haskell, are open rather than closed (when you > define a trait, you don't have any way of knowing all the impls of it > for a particular type). Strictly speaking, you know about all impls of Bar for all types available to your crate when you compile your crate, and if you own Bar, then you even know that new impls can't be introduced in your dependencies which could break your code. You could even have `impl Foo for T` and `impl Foo for T`, as long as you own at least one of Bar or Baz, since it is then possible for the compiler to know that types in other crates which depend on yours can't implement both. Its just a matter of how smart you want the compiler to be, and how much you want to avoid changes up the dependency chain being able to break things down the dependency chain (which isn't entirely avoidable anyways). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dobkeratops0 at yahoo.co.uk Thu Sep 5 15:45:29 2013 From: dobkeratops0 at yahoo.co.uk (Walter Walter) Date: Thu, 5 Sep 2013 23:45:29 +0100 (BST) Subject: [rust-dev] mod.rs.. in crate root? Message-ID: <1378421129.17008.YahooMailNeo@web133201.mail.ir2.yahoo.com> have i understood this correctly- with mod.rs in subdirectories, you can now make a rust module heirachy look exactly like the source directory tree? (nice..) ... but only so long as you dont have mutliple sources in the crate-roots' directory,just one main including each directory-module. (thats certainly the way i'll set anything up i do from now on, if so..) could this be extended to multiple sources in the crate 'root'/'root directory.. perhaps by using the same rule, if you start with "mod.rs"? as the crate root. would it have any undesirable side effects.. does it seem more consistent or less consistent.. would there be any other better ways of doing that.. is this already possible perhaps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Fri Sep 6 08:31:23 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 6 Sep 2013 11:31:23 -0400 Subject: [rust-dev] instantiating parameterized impls In-Reply-To: References: Message-ID: <20130906153123.GE30156@Mr-Bennet> Hi David, My current thinking on the matter is that eventually, I would like to take advantage of the coherence rules to permit a program like this. Coherence means that given a specific type T and trait U, we can always tell whether T implements U. This implies that we could do the check as you described it. However, implementing this is a bit far off. I think it is best done as part of a general rewrite of the trait and method resolution code. I have started that, but put it on hold to deal with #6801 (borrowck treatment of closures) and then the treatment of moves and zeroing (#5016). Also, I am not sure how much of this has been discussed and agreed to. One of my longstanding "to do" items is to write up my thinking on trait resolution as a blog post and then discuss at a meeting. You are giving me some motivation to do that, since I'd love to be able to point you to a fully explained blog post :) Niko On Thu, Sep 05, 2013 at 09:29:59AM -0700, David Renshaw wrote: > Hi, > > When I try to compile the below program, why do I get a "conflicting > implementations" error? I do not define any implementations of Bar, so > the parameterized impl of Foo should never get instantiated, right? > > ------------------- > > trait Foo { > fn foo() -> Self; > } > > trait Bar : std::num::Zero { } > > impl Foo for T { > fn foo() -> T { > std::num::Zero::zero() > } > } > > impl Foo for u16 { > fn foo () -> u16 { > 100 > } > } > > fn main() { > > // should be 100 > let x : u16 = Foo::foo(); > printfln!("%s", x); > > } > > // error: conflicting implementations for trait `Foo` > > ------------------ > > > When I asked about this on IRC, cmr indicated that this is probably > the intended behavior of rustc, but that most people want to change > it. Is that true, and when can we expect a fix? > > > Thanks, > David > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From rexlen at gmail.com Sat Sep 7 05:11:40 2013 From: rexlen at gmail.com (Renato Lenzi) Date: Sat, 7 Sep 2013 14:11:40 +0200 Subject: [rust-dev] functions Message-ID: Is it possibile, or will be possibile, to use default parameters and/or named parameters in Rust? In the docs i couldn't find anything about this (may be my fault...) Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Sat Sep 7 05:51:05 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 07 Sep 2013 22:51:05 +1000 Subject: [rust-dev] functions In-Reply-To: References: Message-ID: <522B2139.4090406@gmail.com> On 07/09/13 22:11, Renato Lenzi wrote: > Is it possibile, or will be possibile, to use default parameters > and/or named parameters in Rust? > In the docs i couldn't find anything about this (may be my fault...) > Regards. > It is not possible currently, but there's an open bug [6973] and with (quite) a bit of discussion. Two current methods for simulating them would be defining wrapper functions for the common shortcuts, or passing the default/named args as a struct and use a "functional record update" (FRU), e.g. struct FooArgs { x: int, y: int, z: int, } static DEFAULT_FOO: FooArgs = FooArgs { x: 1, y: 2, z: 3 }; /// a, b are compulsory, anything in rest is a default arg fn foo(a: uint, b: uint, rest: FooArgs) { ... } fn main() { // only defaults foo(10, 100, DEFAULT_FOO); // y = -3, defaults for the rest foo(10, 100, FooArgs { y: -3, .. DEFAULT_FOO }) // `..` indicates an FRU } This one is unfortunately ugly, but it seems to get the job done. Huon [6973]: https://github.com/mozilla/rust/issues/6973 From oren at ben-kiki.org Sat Sep 7 08:39:42 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 7 Sep 2013 18:39:42 +0300 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <52213DE0.2000109@mozilla.com> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> Message-ID: Another thought on this. Currently, either the compiler is satisfies that the code is 100% safe, or we slap an "unsafe" keyword around the code and put 100% of the responsibility on the programmer, with no support from the Rust system. Wouldn't it make sense to have a "not statically safe, but verified at run time" safety as a middle ground? In the context of the "stolen" proposal, when one "steals" a pointer, the original location could be set to null, and only be restored to a non-null pointer when the value is "put back". This means any access to it would cause an exception - which is what one would intuitively expect a hold to behave like. I have a feeling that there is a non-trivial amount of code which is "actually safe" but would impossible to convince the compiler it is "statically safe". Surely having run-time safety in such cases is better than none at all...? On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton wrote: > On 8/30/13 3:39 PM, Patrick Walton wrote: > >> Thoughts? Does this seem useful? Are there soundness issues I didn't >> notice? >> > > Brian pointed out a massive soundness hole in this, unfortunately. The > problem is that you can read from the original locations; the right to read > is not "shut off" during the borrow. I think the fix would have to be to > replace this with some sort of "generalized swap" operation. > > > 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 pwalton at mozilla.com Sat Sep 7 08:55:09 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 07 Sep 2013 08:55:09 -0700 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> Message-ID: <522B4C5D.8010400@mozilla.com> On 9/7/13 8:39 AM, Oren Ben-Kiki wrote: > I have a feeling that there is a non-trivial amount of code which is > "actually safe" but would impossible to convince the compiler it is > "statically safe". Surely having run-time safety in such cases is better > than none at all...? I would be fine with this, but one big problem is that null pointer dereferences are undefined behavior in LLVM. Patrick From oren at ben-kiki.org Sat Sep 7 09:09:20 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 7 Sep 2013 19:09:20 +0300 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <522B4C5D.8010400@mozilla.com> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> Message-ID: Is there any system in actual use where actually dereferencing a null pointer will not cause an exception? I mean, _sure_, the C spec says the result is "undefined", but isn't this just a leftover from the "bad old days", like also supporting non-byte-addressible machines (with non-power-of-two word size!), and other such horribleness? If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...) every null pointer will fault (which I strongly hope will...), then I'd be quite happy in saying formally that accessing a hole leads to "undefined behavior" and make good use of knowledge that any such access will, in fact, fault, on any machine I might be coding to today. On Sat, Sep 7, 2013 at 6:55 PM, Patrick Walton wrote: > On 9/7/13 8:39 AM, Oren Ben-Kiki wrote: > >> I have a feeling that there is a non-trivial amount of code which is >> "actually safe" but would impossible to convince the compiler it is >> "statically safe". Surely having run-time safety in such cases is better >> than none at all...? >> > > I would be fine with this, but one big problem is that null pointer > dereferences are undefined behavior in LLVM. > > Patrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Sep 7 09:20:40 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 12:20:40 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> Message-ID: On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki wrote: > If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...) > every null pointer will fault (which I strongly hope will...), then I'd be > quite happy in saying formally that accessing a hole leads to "undefined > behavior" and make good use of knowledge that any such access will, in > fact, fault, on any machine I might be coding to today. > You get a segmentation fault on Linux because the first page is marked read-only for userland processes. It's valid on almost any hardware to dereference a pointer equal to zero, which is how LLVM defines the null pointer. However, LLVM explicitly considers a dereference of the null pointer to be undefined behaviour so it doesn't matter how it could or couldn't be implemented in hardware. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Sat Sep 7 13:15:26 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 7 Sep 2013 23:15:26 +0300 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> Message-ID: I miss-spoke; when I said "machine" I meant "platform" (combination of HW and SW). Is unintentionally dereferencing a null pointer a silent error on any existing platform? But isn't a very good question either. A better one would be: Would it be _useful_ to define `steal` and use it in programs, such that it triggers a null pointer dereference (undefined behavior and all) if someone tries to access the hole? This is a softer question and I suspect the answer is "yes" - at least until a better way to safely update structures in-place is found... On Sat, Sep 7, 2013 at 7:20 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki wrote: > >> If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...) >> every null pointer will fault (which I strongly hope will...), then I'd be >> quite happy in saying formally that accessing a hole leads to "undefined >> behavior" and make good use of knowledge that any such access will, in >> fact, fault, on any machine I might be coding to today. >> > > You get a segmentation fault on Linux because the first page is marked > read-only for userland processes. It's valid on almost any hardware to > dereference a pointer equal to zero, which is how LLVM defines the null > pointer. However, LLVM explicitly considers a dereference of the null > pointer to be undefined behaviour so it doesn't matter how it could or > couldn't be implemented in hardware. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Sep 7 13:22:47 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 16:22:47 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> Message-ID: On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki wrote: > I miss-spoke; when I said "machine" I meant "platform" (combination of HW > and SW). Is unintentionally dereferencing a null pointer a silent error on > any existing platform? > Yes, it's only a segmentation fault in userland code on platforms where the kernel is set up to make the lowest page read-only. Rust still needs to be memory safe in a kernel. But isn't a very good question either. A better one would be: Would it be > _useful_ to define `steal` and use it in programs, such that it triggers a > null pointer dereference (undefined behavior and all) if someone tries to > access the hole? This is a softer question and I suspect the answer is > "yes" - at least until a better way to safely update structures in-place is > found... > It would be undefined behaviour, so it wouldn't be useful. Rust is a memory safe language and can't allow safe code to generate LLVM IR invoking undefined behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexlen at gmail.com Sat Sep 7 13:25:07 2013 From: rexlen at gmail.com (Renato Lenzi) Date: Sat, 7 Sep 2013 22:25:07 +0200 Subject: [rust-dev] Fwd: functions In-Reply-To: <522B2139.4090406@gmail.com> References: <522B2139.4090406@gmail.com> Message-ID: Yes, this is a smart workaround..... i hope we will have something better in Rust but this a good answer to this need. Regards, On 07/09/13 22:11, Renato Lenzi wrote: > Is it possibile, or will be possibile, to use default parameters and/or > named parameters in Rust? > In the docs i couldn't find anything about this (may be my fault...) > Regards. > > It is not possible currently, but there's an open bug [6973] and with (quite) a bit of discussion. Two current methods for simulating them would be defining wrapper functions for the common shortcuts, or passing the default/named args as a struct and use a "functional record update" (FRU), e.g. struct FooArgs { x: int, y: int, z: int, } static DEFAULT_FOO: FooArgs = FooArgs { x: 1, y: 2, z: 3 }; /// a, b are compulsory, anything in rest is a default arg fn foo(a: uint, b: uint, rest: FooArgs) { ... } fn main() { // only defaults foo(10, 100, DEFAULT_FOO); // y = -3, defaults for the rest foo(10, 100, FooArgs { y: -3, .. DEFAULT_FOO }) // `..` indicates an FRU } This one is unfortunately ugly, but it seems to get the job done. Huon [6973]: https://github.com/mozilla/**rust/issues/6973 ______________________________**_________________ 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 irving at naml.us Sat Sep 7 13:27:11 2013 From: irving at naml.us (Geoffrey Irving) Date: Sat, 7 Sep 2013 13:27:11 -0700 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> Message-ID: <51E9E108-658F-462A-9F08-24624931656E@naml.us> To clarify why undefined behavior is really bad in practice: if LLVM ever detects that your code performs undefined behavior according to the standard, it is *designed* to take full advantage of that fact when making optimizations. In other words, all hell will break lose, in potentially very complicated and subtle ways. Geoffrey On Sep 7, 2013, at 1:22 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki wrote: > I miss-spoke; when I said "machine" I meant "platform" (combination of HW and SW). Is unintentionally dereferencing a null pointer a silent error on any existing platform? > > Yes, it's only a segmentation fault in userland code on platforms where the kernel is set up to make the lowest page read-only. Rust still needs to be memory safe in a kernel. > > But isn't a very good question either. A better one would be: Would it be _useful_ to define `steal` and use it in programs, such that it triggers a null pointer dereference (undefined behavior and all) if someone tries to access the hole? This is a softer question and I suspect the answer is "yes" - at least until a better way to safely update structures in-place is found... > > It would be undefined behaviour, so it wouldn't be useful. Rust is a memory safe language and can't allow safe code to generate LLVM IR invoking undefined behaviour. > _______________________________________________ > 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: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From danielmicay at gmail.com Sat Sep 7 13:32:43 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 16:32:43 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <51E9E108-658F-462A-9F08-24624931656E@naml.us> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote: > To clarify why undefined behavior is really bad in practice: if LLVM ever > detects that your code performs undefined behavior according to the > standard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > Geoffrey > Note that there's no detection of undefined behaviour or optimizations based upon it being detected. LLVM simply operates on valid LLVM bytecode, and if it performs undefined behaviour it is not valid LLVM bytecode. The optimization passes and code generation will base all of their assumptions on the invariants provided by the specification, including that null pointers are never dereferenced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Sat Sep 7 13:34:49 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 7 Sep 2013 23:34:49 +0300 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: <51E9E108-658F-462A-9F08-24624931656E@naml.us> References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: Alas. So I guess it all depends on someone finding a smart safe way to generalize the swap operation, or something... as things stand, it is extremely difficult to efficiently and safely implement complex nested containers. I will admit I am using the `steal` function for now, it just makes things so much easier, but I know I'll have to pay for my sins down the line... On Sat, Sep 7, 2013 at 11:27 PM, Geoffrey Irving wrote: > To clarify why undefined behavior is really bad in practice: if LLVM ever > detects that your code performs undefined behavior according to the > standard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > Geoffrey > > On Sep 7, 2013, at 1:22 PM, Daniel Micay wrote: > > > On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki wrote: > > I miss-spoke; when I said "machine" I meant "platform" (combination of > HW and SW). Is unintentionally dereferencing a null pointer a silent error > on any existing platform? > > > > Yes, it's only a segmentation fault in userland code on platforms where > the kernel is set up to make the lowest page read-only. Rust still needs to > be memory safe in a kernel. > > > > But isn't a very good question either. A better one would be: Would it > be _useful_ to define `steal` and use it in programs, such that it triggers > a null pointer dereference (undefined behavior and all) if someone tries to > access the hole? This is a softer question and I suspect the answer is > "yes" - at least until a better way to safely update structures in-place is > found... > > > > It would be undefined behaviour, so it wouldn't be useful. Rust is a > memory safe language and can't allow safe code to generate LLVM IR invoking > undefined behaviour. > > _______________________________________________ > > 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 irving at naml.us Sat Sep 7 13:37:09 2013 From: irving at naml.us (Geoffrey Irving) Date: Sat, 7 Sep 2013 13:37:09 -0700 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote: > To clarify why undefined behavior is really bad in practice: if LLVM ever detects that your code performs undefined behavior according to the standard, it is *designed* to take full advantage of that fact when making optimizations. In other words, all hell will break lose, in potentially very complicated and subtle ways. > > Geoffrey > > Note that there's no detection of undefined behaviour or optimizations based upon it being detected. LLVM simply operates on valid LLVM bytecode, and if it performs undefined behaviour it is not valid LLVM bytecode. The optimization passes and code generation will base all of their assumptions on the invariants provided by the specification, including that null pointers are never dereferenced. That may be true; I got the opposite impression from this article: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html Geoffrey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From danielmicay at gmail.com Sat Sep 7 13:42:24 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 16:42:24 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote: > > On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote: > > > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote: > > To clarify why undefined behavior is really bad in practice: if LLVM > ever detects that your code performs undefined behavior according to the > standard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > > > Geoffrey > > > > Note that there's no detection of undefined behaviour or optimizations > based upon it being detected. LLVM simply operates on valid LLVM bytecode, > and if it performs undefined behaviour it is not valid LLVM bytecode. The > optimization passes and code generation will base all of their assumptions > on the invariants provided by the specification, including that null > pointers are never dereferenced. > > That may be true; I got the opposite impression from this article: > > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html > > Geoffrey > You're getting a very wrong impression if you think it optimizes based on those assumptions only when it can detect undefined behaviour. It completely ignores the possibility of undefined behaviour in the optimization passes by assuming all of the invariants required for the bytecode to be valid hold true. The `-fcatch-undefined-behaviour` switch inserts runtime checks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Sep 7 13:44:52 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 16:44:52 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sat, Sep 7, 2013 at 4:42 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote: > >> >> On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote: >> >> > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote: >> > To clarify why undefined behavior is really bad in practice: if LLVM >> ever detects that your code performs undefined behavior according to the >> standard, it is *designed* to take full advantage of that fact when making >> optimizations. In other words, all hell will break lose, in potentially >> very complicated and subtle ways. >> > >> > Geoffrey >> > >> > Note that there's no detection of undefined behaviour or optimizations >> based upon it being detected. LLVM simply operates on valid LLVM bytecode, >> and if it performs undefined behaviour it is not valid LLVM bytecode. The >> optimization passes and code generation will base all of their assumptions >> on the invariants provided by the specification, including that null >> pointers are never dereferenced. >> >> That may be true; I got the opposite impression from this article: >> >> >> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html >> >> Geoffrey >> > > You're getting a very wrong impression if you think it optimizes based on > those assumptions only when it can detect undefined behaviour. It > completely ignores the possibility of undefined behaviour in the > optimization passes by assuming all of the invariants required for the > bytecode to be valid hold true. > > The `-fcatch-undefined-behaviour` switch inserts runtime checks. > Note that `clang` generating traps on certain operations left undefined by C to aid in debugging is unrelated to Rust, because we don't compile to C and then compile with `clang`. There are no exceptions to the undefined behaviour rules for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irving at naml.us Sat Sep 7 13:47:40 2013 From: irving at naml.us (Geoffrey Irving) Date: Sat, 7 Sep 2013 13:47:40 -0700 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sep 7, 2013, at 1:42 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote: > > On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote: > > > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote: > > To clarify why undefined behavior is really bad in practice: if LLVM ever detects that your code performs undefined behavior according to the standard, it is *designed* to take full advantage of that fact when making optimizations. In other words, all hell will break lose, in potentially very complicated and subtle ways. > > > > Geoffrey > > > > Note that there's no detection of undefined behaviour or optimizations based upon it being detected. LLVM simply operates on valid LLVM bytecode, and if it performs undefined behaviour it is not valid LLVM bytecode. The optimization passes and code generation will base all of their assumptions on the invariants provided by the specification, including that null pointers are never dereferenced. > > That may be true; I got the opposite impression from this article: > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html > > Geoffrey > > You're getting a very wrong impression if you think it optimizes based on those assumptions only when it can detect undefined behaviour. It completely ignores the possibility of undefined behaviour in the optimization passes by assuming all of the invariants required for the bytecode to be valid hold true. > > The `-fcatch-undefined-behaviour` switch inserts runtime checks. I think we're saying the same thing: I didn't intend to imply that it optimizes based on those assumptions only if it can prove that undefined behavior never occurs. If it detects undefined behavior along certain paths, it will assume those paths can never occur, and then propagate those assumptions backwards through the program in an attempt to make simplifications. Thus, a null pointer access somewhere could easily complete a weirdly incorrect assumption causing a previous branch to be taken incorrectly. Geoffrey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From danielmicay at gmail.com Sat Sep 7 13:49:25 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 7 Sep 2013 16:49:25 -0400 Subject: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity In-Reply-To: References: <52211DE7.7050909@mozilla.com> <52213DE0.2000109@mozilla.com> <522B4C5D.8010400@mozilla.com> <51E9E108-658F-462A-9F08-24624931656E@naml.us> Message-ID: On Sat, Sep 7, 2013 at 4:47 PM, Geoffrey Irving wrote: > On Sep 7, 2013, at 1:42 PM, Daniel Micay wrote: > > > On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote: > > > > On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote: > > > > > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving > wrote: > > > To clarify why undefined behavior is really bad in practice: if LLVM > ever detects that your code performs undefined behavior according to the > standard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > > > > > Geoffrey > > > > > > Note that there's no detection of undefined behaviour or optimizations > based upon it being detected. LLVM simply operates on valid LLVM bytecode, > and if it performs undefined behaviour it is not valid LLVM bytecode. The > optimization passes and code generation will base all of their assumptions > on the invariants provided by the specification, including that null > pointers are never dereferenced. > > > > That may be true; I got the opposite impression from this article: > > > > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html > > > > Geoffrey > > > > You're getting a very wrong impression if you think it optimizes based > on those assumptions only when it can detect undefined behaviour. It > completely ignores the possibility of undefined behaviour in the > optimization passes by assuming all of the invariants required for the > bytecode to be valid hold true. > > > > The `-fcatch-undefined-behaviour` switch inserts runtime checks. > > I think we're saying the same thing: I didn't intend to imply that it > optimizes based on those assumptions only if it can prove that undefined > behavior never occurs. If it detects undefined behavior along certain > paths, it will assume those paths can never occur, and then propagate those > assumptions backwards through the program in an attempt to make > simplifications. Thus, a null pointer access somewhere could easily > complete a weirdly incorrect assumption causing a previous branch to be > taken incorrectly. > > Geoffrey > Ah okay, we're on the same page then :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Sun Sep 8 00:00:04 2013 From: martindemello at gmail.com (Martin DeMello) Date: Sun, 8 Sep 2013 00:00:04 -0700 Subject: [rust-dev] c structs with bitfields Message-ID: I was looking at the bindgen bug for incorrect bitfield handling https://github.com/crabtw/rust-bindgen/issues/8 but from a quick pass through the rust manual I can't figure out what the correct behaviour would be. What, for example, would the correct bindgen output for the following be: struct bit { int alpha : 12; int beta : 6; int gamma : 2; }; martin From corey at octayn.net Sun Sep 8 07:31:00 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 8 Sep 2013 10:31:00 -0400 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: On Sun, Sep 8, 2013 at 3:00 AM, Martin DeMello wrote: > I was looking at the bindgen bug for incorrect bitfield handling > > https://github.com/crabtw/rust-bindgen/issues/8 > > but from a quick pass through the rust manual I can't figure out what > the correct behaviour would be. > > What, for example, would the correct bindgen output for the following be: > > struct bit { > int alpha : 12; > int beta : 6; > int gamma : 2; > }; > > You'll have to check what the various C compilers do with bitfields. I imagine they pack the bitfields into the smallest integer type that will contain them all. But, almost everything about bitfields is entirely implementation defined, so it's probably going to be difficult to come up with what to do correctly in any portable way. Once you actually figure out what to generate, though, methods for getting/setting the bitfields would probably be best. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun Sep 8 10:49:08 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 8 Sep 2013 19:49:08 +0200 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: Actually, for bitfields the types into which the bits are packed are not left to the compiler. If you said "int c : 4", then it will use a "int". If you have: int a : 24; int b : 24; int c : 16; and int is 32 bits on your platform, then a will be 24 somewhere in 32 bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a single bit field cannot be split among several underlying integers. Exactly where the bits lie within the type, though, is part of the ABI. -- Matthieu On Sun, Sep 8, 2013 at 4:31 PM, Corey Richardson wrote: > On Sun, Sep 8, 2013 at 3:00 AM, Martin DeMello wrote: > >> I was looking at the bindgen bug for incorrect bitfield handling >> >> https://github.com/crabtw/rust-bindgen/issues/8 >> >> but from a quick pass through the rust manual I can't figure out what >> the correct behaviour would be. >> >> What, for example, would the correct bindgen output for the following be: >> >> struct bit { >> int alpha : 12; >> int beta : 6; >> int gamma : 2; >> }; >> >> > You'll have to check what the various C compilers do with bitfields. I > imagine they pack the bitfields into the smallest integer type that will > contain them all. But, almost everything about bitfields is entirely > implementation defined, so it's probably going to be difficult to come up > with what to do correctly in any portable way. > > Once you actually figure out what to generate, though, methods for > getting/setting the bitfields would probably be best. > > > > > _______________________________________________ > 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 corey at octayn.net Sun Sep 8 10:50:24 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 8 Sep 2013 13:50:24 -0400 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: On Sun, Sep 8, 2013 at 1:49 PM, Matthieu Monrocq wrote: > Actually, for bitfields the types into which the bits are packed are not > left to the compiler. If you said "int c : 4", then it will use a "int". > > If you have: > > int a : 24; > int b : 24; > int c : 16; > > and int is 32 bits on your platform, then a will be 24 somewhere in 32 > bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a > single bit field cannot be split among several underlying integers. > > I didn't get that understanding from my reading of the C11 standard; which standard and section says this? I could have misunderstood. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun Sep 8 12:36:10 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 8 Sep 2013 21:36:10 +0200 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: I was using the C++11 Standard actually, but I spoke from memory. Consulting n3485 9.6 [class.bit] it is indeed less clear-cut than I thought. 1/ [...] The value of the integral constant expression may be larger than the number of bits in the object representation (3.9) of the bit-field?s type; in such cases the extra bits are used as padding bits and do not participate in the value representation (3.9) of the bit-field. [...] Seems to indicate that the type used for the bit-field does matter. That is if the underlying type is too narrow, then the representable range of values is cropped. However it continue thusly: 1/ [...] Bit-fields are packed into some addressable allocation unit. [ Note: Bit-fields straddle allocation units on some machines and not on others. [...] Unfortunately it is unclear, now that I read back, what "allocation unit" truly means. I searched in gcc documentation and even them defer the decision to the ABI [1] In any case, given that: 1/ [...] Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. [...] and 1/ [...] Bit-fields are assigned right-to-left on some machines, left-to-right on others. [...] So it appears that one would really need to check the ABI even for the least properties of bit-fields. -- Matthieu [1]: http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html On Sun, Sep 8, 2013 at 7:50 PM, Corey Richardson wrote: > On Sun, Sep 8, 2013 at 1:49 PM, Matthieu Monrocq < > matthieu.monrocq at gmail.com> wrote: > >> Actually, for bitfields the types into which the bits are packed are not >> left to the compiler. If you said "int c : 4", then it will use a "int". >> >> If you have: >> >> int a : 24; >> int b : 24; >> int c : 16; >> >> and int is 32 bits on your platform, then a will be 24 somewhere in 32 >> bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a >> single bit field cannot be split among several underlying integers. >> >> > I didn't get that understanding from my reading of the C11 standard; which > standard and section says this? I could have misunderstood. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Sun Sep 8 16:20:34 2013 From: martindemello at gmail.com (Martin DeMello) Date: Sun, 8 Sep 2013 16:20:34 -0700 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: So am I right that bitfield widths would first need to be added to the rust struct definition and code generator before they can be added to bindgen? I poked around the AST and middle code a bit but couldn't find it if it was there. martin On Sun, Sep 8, 2013 at 12:36 PM, Matthieu Monrocq wrote: > I was using the C++11 Standard actually, but I spoke from memory. Consulting > n3485 9.6 [class.bit] it is indeed less clear-cut than I thought. > > 1/ [...] The value of the integral constant expression may be larger than > the number of bits in the > object representation (3.9) of the bit-field?s type; in such cases the extra > bits are used as padding bits and > do not participate in the value representation (3.9) of the bit-field. [...] > > Seems to indicate that the type used for the bit-field does matter. That is > if the underlying type is too narrow, then the representable range of values > is cropped. > > However it continue thusly: > > 1/ [...] Bit-fields are packed into some addressable allocation unit. [ > Note: Bit-fields straddle allocation units on some machines and not on > others. [...] > > Unfortunately it is unclear, now that I read back, what "allocation unit" > truly means. I searched in gcc documentation and even them defer the > decision to the ABI [1] > > > In any case, given that: > > 1/ [...] Allocation of bit-fields within a class object is > implementation-defined. Alignment of bit-fields is implementation-defined. > [...] > > and > > 1/ [...] Bit-fields are assigned right-to-left on some machines, > left-to-right on others. [...] > > So it appears that one would really need to check the ABI even for the least > properties of bit-fields. > > > -- Matthieu > > [1]: > http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html > > > > On Sun, Sep 8, 2013 at 7:50 PM, Corey Richardson wrote: >> >> On Sun, Sep 8, 2013 at 1:49 PM, Matthieu Monrocq >> wrote: >>> >>> Actually, for bitfields the types into which the bits are packed are not >>> left to the compiler. If you said "int c : 4", then it will use a "int". >>> >>> If you have: >>> >>> int a : 24; >>> int b : 24; >>> int c : 16; >>> >>> and int is 32 bits on your platform, then a will be 24 somewhere in 32 >>> bits, same thing for b, and c will be 16 bits somewhere in 32 bits; for a >>> single bit field cannot be split among several underlying integers. >>> >> >> I didn't get that understanding from my reading of the C11 standard; which >> standard and section says this? I could have misunderstood. > > From corey at octayn.net Sun Sep 8 17:14:30 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 8 Sep 2013 20:14:30 -0400 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello wrote: > So am I right that bitfield widths would first need to be added to the > rust struct definition and code generator before they can be added to > bindgen? I poked around the AST and middle code a bit but couldn't > find it if it was there. > Rust doesn't have bitfields and neither does LLVM, nor do I think we should: 1. bitfield members aren't addressable. 2. It would be near impossible to replicate the exact behavior of every C compiler for every platform and ABI it supports. 3. They add significant additional complexity. From martindemello at gmail.com Sun Sep 8 17:20:31 2013 From: martindemello at gmail.com (Martin DeMello) Date: Sun, 8 Sep 2013 17:20:31 -0700 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson wrote: > On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello wrote: >> So am I right that bitfield widths would first need to be added to the >> rust struct definition and code generator before they can be added to >> bindgen? I poked around the AST and middle code a bit but couldn't >> find it if it was there. >> > > Rust doesn't have bitfields and neither does LLVM, nor do I think we should: > > 1. bitfield members aren't addressable. > 2. It would be near impossible to replicate the exact behavior of > every C compiler for every platform and ABI it supports. > 3. They add significant additional complexity. Which returns me to the higher-level question, then - what is the correct thing for bindgen to do if handed a C struct with them? martin From corey at octayn.net Sun Sep 8 19:37:26 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 8 Sep 2013 22:37:26 -0400 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: Emit an error and fail, I'd say, unless you can tell it which ABI it's targetting so it knows how to handle it. On Sun, Sep 8, 2013 at 8:20 PM, Martin DeMello wrote: > On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson wrote: >> On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello wrote: >>> So am I right that bitfield widths would first need to be added to the >>> rust struct definition and code generator before they can be added to >>> bindgen? I poked around the AST and middle code a bit but couldn't >>> find it if it was there. >>> >> >> Rust doesn't have bitfields and neither does LLVM, nor do I think we should: >> >> 1. bitfield members aren't addressable. >> 2. It would be near impossible to replicate the exact behavior of >> every C compiler for every platform and ABI it supports. >> 3. They add significant additional complexity. > > Which returns me to the higher-level question, then - what is the > correct thing for bindgen to do if handed a C struct with them? > > martin From lists at ncameron.org Mon Sep 9 00:04:07 2013 From: lists at ncameron.org (Nick Cameron) Date: Mon, 9 Sep 2013 19:04:07 +1200 Subject: [rust-dev] Subtyping in Rust Message-ID: Is there somewhere I can look for a description of subtyping in Rust? I don't see any mention of it in the manual or tutorial. Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Sep 9 05:51:38 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 9 Sep 2013 08:51:38 -0400 Subject: [rust-dev] Subtyping in Rust In-Reply-To: References: Message-ID: On Mon, Sep 9, 2013 at 3:04 AM, Nick Cameron wrote: > Is there somewhere I can look for a description of subtyping in Rust? I > don't see any mention of it in the manual or tutorial. > Rust has 0 subtyping except that: every type is considered a subtype of `bottom` (which has no syntax, but it's the return type of a divergent function (one that never returns) such as fail!()), and every lifetime is considered a sublifetime of `'static` From niko at alum.mit.edu Mon Sep 9 06:34:58 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 9 Sep 2013 09:34:58 -0400 Subject: [rust-dev] Subtyping in Rust In-Reply-To: References: Message-ID: <20130909133458.GE3459@Mr-Bennet> By subtyping, do you mean defining class hierarchies as in C++ or Java? This is currently not supported. Typically such hierarchies are modeled either using an `enum` (most common) or using a `trait`. Enums are perfect for cases where there is a limited set of possibilities. Traits are perfect for "open-ended" situations where you have an interface and many ways to fulfill it. The two techniques *can* be combined for cases that fall between the two extremes. We have considered adding a limited form of struct inheritance (so that one struct can build on another) but afaik this feature is not planned in the short term. Niko On Mon, Sep 09, 2013 at 07:04:07PM +1200, Nick Cameron wrote: > Is there somewhere I can look for a description of subtyping in Rust? I > don't see any mention of it in the manual or tutorial. > > Thanks, Nick > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From jon.mb at proinbox.com Mon Sep 9 07:09:14 2013 From: jon.mb at proinbox.com (John Mija) Date: Mon, 09 Sep 2013 15:09:14 +0100 Subject: [rust-dev] Embed language in Rust Message-ID: <522DD68A.5080600@proinbox.com> Which would be the best way (respect to performance) to embed a language like Go in Rust? (a) Since the Go compilers are written in C, it could be wrapped the functions for compiling and linking, and then to do a system call to run the binary. (b) To call directly to the binaries to compile, link, and a last call to run the final binary. (c) Create a VM but it takes a lot of memory and it is necessary to be an export in virtual machines to get a good performance, but the negative part is that it takes a lot of memory. Lua works of this way; it is basically a library written in C with an implementation based into a VM to be easily embedded. (d) Compile Go source to Rust. * * * Why to use Go like embedded language? Go would be a great language for the user interface code of an application like a game; the syntax is simple, with garbage-collection getting simpler code that is developed faster, and the concurrency model fits well to handle events asynchronously. From chris at cmoz.me Mon Sep 9 07:17:31 2013 From: chris at cmoz.me (Chris Molozian) Date: Mon, 9 Sep 2013 15:17:31 +0100 Subject: [rust-dev] Embed language in Rust In-Reply-To: <522DD68A.5080600@proinbox.com> References: <522DD68A.5080600@proinbox.com> Message-ID: Hi John, It might be worth checking out Squirrel:?http://www.squirrel-lang.org/?as an embeddable games programming language. I've not used it myself, I always turn to Lua first (out of habit) but I've heard great things about it. It would be interesting to see bindings for it for Rust. :) Cheers, Chris On 9 September 2013 at 15:09:20, John Mija (jon.mb at proinbox.com) wrote: Which would be the best way (respect to performance) to embed a language like Go in Rust? (a) Since the Go compilers are written in C, it could be wrapped the functions for compiling and linking, and then to do a system call to run the binary. (b) To call directly to the binaries to compile, link, and a last call to run the final binary. (c) Create a VM but it takes a lot of memory and it is necessary to be an export in virtual machines to get a good performance, but the negative part is that it takes a lot of memory. Lua works of this way; it is basically a library written in C with an implementation based into a VM to be easily embedded. (d) Compile Go source to Rust. * * * Why to use Go like embedded language? Go would be a great language for the user interface code of an application like a game; the syntax is simple, with garbage-collection getting simpler code that is developed faster, and the concurrency model fits well to handle events asynchronously. _______________________________________________ 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 quixoptic at googlemail.com Fri Sep 6 12:27:49 2013 From: quixoptic at googlemail.com (Alex) Date: Fri, 6 Sep 2013 20:27:49 +0100 Subject: [rust-dev] Type parameters in trait bounds Message-ID: Hey Everyone, I'm new to rust but enjoying it a lot. I'm having trouble with the following code example: use std::hashmap::{HashMap, Map}; fn do_something<'input, M: Map> (key: int, map: &M){ match map.find(key){ Some(result) => println(fmt!("%s", result)), None => println("no match") }; } fn main(){ let map : HashMap = HashMap::new(); map.insert(1, "one"); do_something(1, map); } This fails with a compilation error: example.rs:4:44: 4:47 error: Illegal lifetime 'input: only 'self is allowed as part of a type declaration example.rs:4 fn do_something<'input, M: Map> (key: int, map: &M){ Now, I'm probably misunderstanding a bunch of things here, firstly all the example code I've seen out there uses the HashMap type directly rather than the Map trait, is this idiomatic? Secondly, I'm still getting my head around lifetimes and probably have this all muddled so any pointers there would be welcome. Thanks Alex Good -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Mon Sep 9 10:14:50 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 9 Sep 2013 20:14:50 +0300 Subject: [rust-dev] Type parameters in trait bounds In-Reply-To: References: Message-ID: Rust newbie here as well, trying to develop an intuition for these things myself :-) Off the top of my head - you are saying the map holds entries whose lifetime is 'input; but there's no guarantee that the map lifetime itself wouldn't be longer than that. Try saying &'input M instead of &M and see how it goes. Oren. On Fri, Sep 6, 2013 at 10:27 PM, Alex wrote: > Hey Everyone, > > I'm new to rust but enjoying it a lot. I'm having trouble with the > following code example: > > > use std::hashmap::{HashMap, Map}; > > > fn do_something<'input, M: Map> (key: int, map: &M){ > match map.find(key){ > Some(result) => println(fmt!("%s", result)), > None => println("no match") > }; > } > > fn main(){ > let map : HashMap = HashMap::new(); > map.insert(1, "one"); > do_something(1, map); > } > > > This fails with a compilation error: > > example.rs:4:44: 4:47 error: Illegal lifetime 'input: only 'self is > allowed as part of a type declaration > example.rs:4 fn do_something<'input, M: Map> (key: int, > map: &M){ > > > Now, I'm probably misunderstanding a bunch of things here, firstly all the > example code I've seen out there uses the HashMap type directly rather than > the Map trait, is this idiomatic? Secondly, I'm still getting my head > around lifetimes and probably have this all muddled so any pointers there > would be welcome. > > Thanks > Alex Good > > > _______________________________________________ > 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 martindemello at gmail.com Mon Sep 9 11:47:45 2013 From: martindemello at gmail.com (Martin DeMello) Date: Mon, 9 Sep 2013 11:47:45 -0700 Subject: [rust-dev] c structs with bitfields In-Reply-To: References: Message-ID: That seems less than ideal - I mean, there are definitely c libraries out there with bitfield widths in their header files, and we should be able to use them from rust. And if we do, there should be a way to generate the bindings that is systematic enough to be captured within bindgen (possibly with a flag specifying the ABI). martin On Sun, Sep 8, 2013 at 7:37 PM, Corey Richardson wrote: > Emit an error and fail, I'd say, unless you can tell it which ABI it's > targetting so it knows how to handle it. > > On Sun, Sep 8, 2013 at 8:20 PM, Martin DeMello wrote: >> On Sun, Sep 8, 2013 at 5:14 PM, Corey Richardson wrote: >>> On Sun, Sep 8, 2013 at 7:20 PM, Martin DeMello wrote: >>>> So am I right that bitfield widths would first need to be added to the >>>> rust struct definition and code generator before they can be added to >>>> bindgen? I poked around the AST and middle code a bit but couldn't >>>> find it if it was there. >>>> >>> >>> Rust doesn't have bitfields and neither does LLVM, nor do I think we should: >>> >>> 1. bitfield members aren't addressable. >>> 2. It would be near impossible to replicate the exact behavior of >>> every C compiler for every platform and ABI it supports. >>> 3. They add significant additional complexity. >> >> Which returns me to the higher-level question, then - what is the >> correct thing for bindgen to do if handed a C struct with them? >> >> martin From lists at ncameron.org Mon Sep 9 15:20:02 2013 From: lists at ncameron.org (Nick Cameron) Date: Tue, 10 Sep 2013 10:20:02 +1200 Subject: [rust-dev] Subtyping in Rust In-Reply-To: <20130909133458.GE3459@Mr-Bennet> References: <20130909133458.GE3459@Mr-Bennet> Message-ID: To clarify I meant subtyping in the sense of when are types compatible for some kind of conversion. As opposed to subsumption or subclassing (or at least, not limited to these cases). If I have |e as U| when does that succeed, and when does it fail. (Actually from the manual it was unclear how much checking is done statically vs dynamically, but that is kind of a tangent). Presumably the cast only succeeds if the dynamic type of e is a subtype of U (or it can be coerced or converted to U). An example from the manual (sect 8.1.10) shows that an instance of an impl can be cast to the type of an implemented trait, are there other relationships where casting is allowed? The manual states (sect 7.2.11.5): "A numeric value can be cast to any numeric type. A raw pointer value can be cast to or from any integral type or raw pointer type. Any other cast is unsupported and will fail to compile." But the last sentence is contradicted by the example in section 8.1.10 Separately, I remember that the various pointer types can be implicitly converted. I couldn't find anywhere where these conversions are defined. Is my memory bad or my search skills? Thanks, Nick On Tue, Sep 10, 2013 at 1:34 AM, Niko Matsakis wrote: > By subtyping, do you mean defining class hierarchies as in C++ or > Java? This is currently not supported. Typically such hierarchies > are modeled either using an `enum` (most common) or using a `trait`. > > Enums are perfect for cases where there is a limited set of > possibilities. Traits are perfect for "open-ended" situations where > you have an interface and many ways to fulfill it. The two techniques > *can* be combined for cases that fall between the two extremes. > > We have considered adding a limited form of struct inheritance (so > that one struct can build on another) but afaik this feature is not > planned in the short term. > > > Niko > > On Mon, Sep 09, 2013 at 07:04:07PM +1200, Nick Cameron wrote: > > Is there somewhere I can look for a description of subtyping in Rust? I > > don't see any mention of it in the manual or tutorial. > > > > Thanks, Nick > > > _______________________________________________ > > 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 Tue Sep 10 00:01:11 2013 From: jon.mb at proinbox.com (John Mija) Date: Tue, 10 Sep 2013 08:01:11 +0100 Subject: [rust-dev] Rust compiler bootstrapped Message-ID: <522EC3B7.4040304@proinbox.com> After of reading an article seen in HN "Strange Loops: Ken Thompson and the Self-referencing C Compiler" (https://news.ycombinator.com/item?id=6355978) I'm worried if that issue could happens in the Rust compiler. Does Rust compiler is bootstrapped? From marijnh at gmail.com Tue Sep 10 00:39:32 2013 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 10 Sep 2013 09:39:32 +0200 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: <522EC3B7.4040304@proinbox.com> References: <522EC3B7.4040304@proinbox.com> Message-ID: The Rust team is aware of this possibility, and is guarding against it by keeping a log of checksums and source git revisions for the various versions of the compiler, so that compilers downloaded from the net can be checked, and we could, if something dodgy is found, back-track to a known trusted version of the compiler (or even all the way back to the OCaml bootstrap compiler, though that'd be a lot of work). It is theoretically possible that someone manages to sneak in a commit that adds an exploit to the compiler, but since patches are reviewed, that is not terribly likely to succeed. Also, Rust is a small target still, and it would be a marvelous feat of engineering to install a functioning exploit in a compiler that is being overhauled and changed all the time. From simon.sapin at exyr.org Tue Sep 10 08:47:03 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Tue, 10 Sep 2013 17:47:03 +0200 Subject: [rust-dev] Proposed API for character encodings Message-ID: <522F3EF7.1000507@exyr.org> Hi, TR;DR: the actual proposal is at the end of this email. Rust today has good support for UTF-8 which new content definitely should use, but many systems still have to deal with legacy content that uses other character encodings. There are several projects around to implement more encodings in Rust. The most further along in my opinion is rust-encoding, notably because it implements the right specification. rust-encoding: https://github.com/lifthrasiir/rust-encoding The spec: http://encoding.spec.whatwg.org/ It has more precise definitions of error handling than some original RFCs, and better reflects the reality of legacy content on the web. There was some discussion in the past few days about importing rust-encoding (or part of it) into Rust?s libstd or libextra. Before that, I think it is important to define a good API. The spec defines one for JavaScript, but we should not copy that exactly. rust-encoding?s API is mostly good, but I think that error handling could be simplified. In abstract terms, an encoding (such as "UTF-8") is made of a decoder and an encoder. A decoder converts a stream of bytes into a stream of text (Unicode scalar values, ie. code points excluding surrogates), while an encoder does the reverse. This does not cover other kinds of stream transformation such as base64, compression, encryption, etc. Bytes are represented in Rust by u8, text by str/char. (Side note: Because of constraints imposed by JavaScript and to avoid costly conversions, Servo will probably use a different data type for representing text. This encoding API could eventually become generic over a Text trait, but I think that it should stick to str for now.) The most convenient way to represent a "stream" is with a vector or string. This however requires the whole input to be in memory before decoding/encoding can start, and that to be finished before any of the output can be used. It should definitely be possible to eg. decode some content as it arrives from the network, and parse it in a pipeline. The most fundamental type API is one where the user repeatedly "pushes" chunks of input into a decoder/encoders object (that may maintain state between chunks) and gets the output so far in return, then signals the end of the input. In iterator adapter where the users "pulls" output from the decoder which "pulls" from the input can be nicer, but is easy to build on top of a "push-based" API, while the reverse requires tasks. Iterator and Iterator are tempting, but we may need to work on big chucks at a time for efficiency: Iterator<~[u8]> and Iterator<~str>. Or could single-byte/char iterators be reliably inlined to achieve similar efficiency? Finally, this API also needs to support several kinds of errors handling. For example, a decoder should abort at the invalid byte sequence for XML, but insert U+FFFD (replacement character) for HTML. I?m not decided yet whether to just have the closed set of error handling modes defined in the spec, or make this open-ended with conditions. Based on all the above, here is a proposed API. Encoders are ommited, but they are mostly the same as decoders with [u8] and str swapped. /// Types implementing this trait are "algorithms" /// such as UTF8, UTF-16, SingleByteEncoding, etc. /// Values of these types are "encodings" as defined in the WHATWG spec: /// UTF-8, UTF-16-LE, Windows-1252, etc. trait Encoding { /// Could become an associated type with a ::new() constructor /// when the language supports that. fn new_decoder(&self) -> ~Decoder; /// Simple, "one shot" API. /// Decode a single byte string that is entirely in memory. /// May raise the decoding_error condition. fn decode(&self, input: &[u8]) -> Result<~str, DecodeError> { // Implementation (using a Decoder) left out. // This is a default method, but not meant to be overridden. } } /// Takes the invalid byte sequence. /// Return a replacement string, or None to abort with a DecodeError. condition! { pub decoding_error : ~[u8] -> Option<~str>; } struct DecodeError { input_byte_offset: uint, invalid_byte_sequence: ~[u8], } /// Each implementation of Encoding has one corresponding implementation /// of Decoder (and one of Encoder). /// /// A new Decoder instance should be used for every input. /// A Decoder instance should be discarded after DecodeError was returned. trait Decoder { /// Call this repeatedly with a chunck of input bytes. /// As much as possible of the decoded text is appended to output. /// May raise the decoding_error condition. fn feed(input: &[u8], output: &mut ~str) -> Option; /// Call this to indicate the end of the input. /// The Decoder instance should be discarded afterwards. /// Some encodings may append some final output at this point. /// May raise the decoding_error condition. fn flush(output: &mut ~str) -> Option; } /// "Pull-based" API. struct DecoderIterator { input_iterator: I, priv state: DecoderIteratorState, } impl> DecoderIterator { fn new(input_iterator: I) -> DecoderIterator { // Implementation left out. } /// Consume the whole input iterator and return a single decoded string. /// May raise the decoding_error condition. fn concat(&mut self) -> Result<~str, DecodeError> { // Implementation left out. } } impl> Iterator> for DecoderIterator { /// Call .next() once on the input iterator and decode the result. /// May raise the decoding_error condition. /// Returns None after DecodeError was returned once, /// even if the input iterator is not exhausted yet. fn next(&mut self) -> Option> { // Implementation left out. } } Cheers, -- Simon Sapin From banderson at mozilla.com Tue Sep 10 14:02:21 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 10 Sep 2013 14:02:21 -0700 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: <522EC3B7.4040304@proinbox.com> References: <522EC3B7.4040304@proinbox.com> Message-ID: <522F88DD.1080905@mozilla.com> On 09/10/2013 12:01 AM, John Mija wrote: > After of reading an article seen in HN "Strange Loops: Ken Thompson > and the Self-referencing C Compiler" > (https://news.ycombinator.com/item?id=6355978) Every month or so I waste time imagining how to add an easter egg based on this idea, but it would take a lot of effort and probably not pass review. It would primarily be an opportunity to create a pull request titled "Reflections on Trusting Rust". From kevin at sb.org Tue Sep 10 20:20:30 2013 From: kevin at sb.org (Kevin Ballard) Date: Tue, 10 Sep 2013 20:20:30 -0700 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: <522F88DD.1080905@mozilla.com> References: <522EC3B7.4040304@proinbox.com> <522F88DD.1080905@mozilla.com> Message-ID: <933AF63D-BD2A-4686-B753-050F1B470B33@sb.org> Given the degrading effect this would have on anyone's faith in the compiler, you could also call this "Reflections on Rusting Trust". -Kevin On Sep 10, 2013, at 2:02 PM, Brian Anderson wrote: > On 09/10/2013 12:01 AM, John Mija wrote: >> After of reading an article seen in HN "Strange Loops: Ken Thompson and the Self-referencing C Compiler" (https://news.ycombinator.com/item?id=6355978) > > Every month or so I waste time imagining how to add an easter egg based on this idea, but it would take a lot of effort and probably not pass review. It would primarily be an opportunity to create a pull request titled "Reflections on Trusting Rust". > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From gmaxwell at gmail.com Wed Sep 11 00:27:25 2013 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 11 Sep 2013 00:27:25 -0700 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: <522EC3B7.4040304@proinbox.com> References: <522EC3B7.4040304@proinbox.com> Message-ID: On Tue, Sep 10, 2013 at 12:01 AM, John Mija wrote: > After of reading an article seen in HN "Strange Loops: Ken Thompson and the > Self-referencing C Compiler" (https://news.ycombinator.com/item?id=6355978) > > I'm worried if that issue could happens in the Rust compiler. > Does Rust compiler is bootstrapped? Make sure you read David Wheeler's page on diverse double compilation which is the cure for this concern: http://www.dwheeler.com/trusting-trust/ Presumably before rust reaches a point of earth-shaking importance there will be an second implementation which can compile the first compiler, thus permitting this solution. :) From corey at octayn.net Wed Sep 11 05:50:39 2013 From: corey at octayn.net (Corey Richardson) Date: Wed, 11 Sep 2013 08:50:39 -0400 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: References: <522EC3B7.4040304@proinbox.com> Message-ID: On Wed, Sep 11, 2013 at 3:27 AM, Gregory Maxwell wrote: > Presumably before rust reaches a point of earth-shaking importance > there will be an second implementation which can compile the first > compiler, thus permitting this solution. :) I wouldn't be so sure of that. There's a ton of trickiness around the type and borrow checker and everything else, and I'm not sure anyone would *want* to reimplement it. What gain would there be? From zcarterc at gmail.com Wed Sep 11 06:52:59 2013 From: zcarterc at gmail.com (Carter Charbonneau) Date: Wed, 11 Sep 2013 07:52:59 -0600 Subject: [rust-dev] Fwd: Rust compiler bootstrapped In-Reply-To: References: <522EC3B7.4040304@proinbox.com> Message-ID: For trusting trust, couldn't the second compiler skip all of that and say "if it compiles with main rustc, we expect it to be correct"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at dhardy.name Wed Sep 11 08:26:48 2013 From: lists at dhardy.name (Diggory Hardy) Date: Wed, 11 Sep 2013 17:26:48 +0200 Subject: [rust-dev] Zurich/CH Meetup In-Reply-To: <51FE39B5.1040600@seld.be> References: <51FE39B5.1040600@seld.be> Message-ID: <2112333.scNfimRqL1@tph-l10036> Hello, Did anything ever happen about this? Sorry, I stopped reading the mailing list a while back... I'd be interested, if not very much involved with Rust at the moment. (I live in Basel.) Cheers On Sunday 04 August 2013 13:23:33 Jordi Boggiano wrote: > Heya, > > I know this is a long shot given I don't see many EU people on IRC, but > would there be anyone around Zurich or in Switzerland at all that wants > to gather up for a small Rust meetup (or we can just go have a beer)? > > Cheers From j.boggiano at seld.be Wed Sep 11 08:40:26 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Wed, 11 Sep 2013 17:40:26 +0200 Subject: [rust-dev] Zurich/CH Meetup In-Reply-To: <2112333.scNfimRqL1@tph-l10036> References: <51FE39B5.1040600@seld.be> <2112333.scNfimRqL1@tph-l10036> Message-ID: <52308EEA.8030300@seld.be> On 11.09.2013 17:26, Diggory Hardy wrote: > Did anything ever happen about this? Sorry, I stopped reading the mailing list > a while back... > > I'd be interested, if not very much involved with Rust at the moment. (I live > in Basel.) Nope, only one other person got back to me (off list) so I put the idea on hold for now. Maybe I will try to start something towards end of October because I don't have much time now. I put you on the spam list then :) I imagine more people from outside the rust community could be interested in at least a first "intro" meetup, then we can see where to go from there. Cheers From loebel.marvin at gmail.com Wed Sep 11 08:19:39 2013 From: loebel.marvin at gmail.com (=?windows-1252?Q?Marvin_L=F6bel?=) Date: Wed, 11 Sep 2013 17:19:39 +0200 Subject: [rust-dev] Proposed API for character encodings In-Reply-To: <522F3EF7.1000507@exyr.org> References: <522F3EF7.1000507@exyr.org> Message-ID: <52308A0B.2080108@gmail.com> On 09/10/2013 05:47 PM, Simon Sapin wrote: > Hi, > > TR;DR: the actual proposal is at the end of this email. > > Rust today has good support for UTF-8 which new content definitely > should use, but many systems still have to deal with legacy content > that uses other character encodings. There are several projects around > to implement more encodings in Rust. The most further along in my > opinion is rust-encoding, notably because it implements the right > specification. > > rust-encoding: https://github.com/lifthrasiir/rust-encoding > > The spec: http://encoding.spec.whatwg.org/ > It has more precise definitions of error handling than some original > RFCs, and better reflects the reality of legacy content on the web. > > There was some discussion in the past few days about importing > rust-encoding (or part of it) into Rust?s libstd or libextra. Before > that, I think it is important to define a good API. The spec defines > one for JavaScript, but we should not copy that exactly. > rust-encoding?s API is mostly good, but I think that error handling > could be simplified. > > > In abstract terms, an encoding (such as "UTF-8") is made of a decoder > and an encoder. A decoder converts a stream of bytes into a stream of > text (Unicode scalar values, ie. code points excluding surrogates), > while an encoder does the reverse. This does not cover other kinds of > stream transformation such as base64, compression, encryption, etc. > > Bytes are represented in Rust by u8, text by str/char. > > (Side note: Because of constraints imposed by JavaScript and to avoid > costly conversions, Servo will probably use a different data type for > representing text. This encoding API could eventually become generic > over a Text trait, but I think that it should stick to str for now.) > > > The most convenient way to represent a "stream" is with a vector or > string. This however requires the whole input to be in memory before > decoding/encoding can start, and that to be finished before any of the > output can be used. It should definitely be possible to eg. decode > some content as it arrives from the network, and parse it in a pipeline. > > The most fundamental type API is one where the user repeatedly > "pushes" chunks of input into a decoder/encoders object (that may > maintain state between chunks) and gets the output so far in return, > then signals the end of the input. > > In iterator adapter where the users "pulls" output from the decoder > which "pulls" from the input can be nicer, but is easy to build on top > of a "push-based" API, while the reverse requires tasks. > > Iterator and Iterator are tempting, but we may need to work > on big chucks at a time for efficiency: Iterator<~[u8]> and > Iterator<~str>. Or could single-byte/char iterators be reliably > inlined to achieve similar efficiency? > > > Finally, this API also needs to support several kinds of errors > handling. For example, a decoder should abort at the invalid byte > sequence for XML, but insert U+FFFD (replacement character) for HTML. > I?m not decided yet whether to just have the closed set of error > handling modes defined in the spec, or make this open-ended with > conditions. > > > Based on all the above, here is a proposed API. Encoders are ommited, > but they are mostly the same as decoders with [u8] and str swapped. > > > /// Types implementing this trait are "algorithms" > /// such as UTF8, UTF-16, SingleByteEncoding, etc. > /// Values of these types are "encodings" as defined in the WHATWG spec: > /// UTF-8, UTF-16-LE, Windows-1252, etc. > trait Encoding { > /// Could become an associated type with a ::new() constructor > /// when the language supports that. > fn new_decoder(&self) -> ~Decoder; > > /// Simple, "one shot" API. > /// Decode a single byte string that is entirely in memory. > /// May raise the decoding_error condition. > fn decode(&self, input: &[u8]) -> Result<~str, DecodeError> { > // Implementation (using a Decoder) left out. > // This is a default method, but not meant to be overridden. > } > } > > /// Takes the invalid byte sequence. > /// Return a replacement string, or None to abort with a DecodeError. > condition! { > pub decoding_error : ~[u8] -> Option<~str>; > } > > struct DecodeError { > input_byte_offset: uint, > invalid_byte_sequence: ~[u8], > } > > /// Each implementation of Encoding has one corresponding implementation > /// of Decoder (and one of Encoder). > /// > /// A new Decoder instance should be used for every input. > /// A Decoder instance should be discarded after DecodeError was > returned. > trait Decoder { > /// Call this repeatedly with a chunck of input bytes. > /// As much as possible of the decoded text is appended to output. > /// May raise the decoding_error condition. > fn feed(input: &[u8], output: &mut ~str) -> Option; > > /// Call this to indicate the end of the input. > /// The Decoder instance should be discarded afterwards. > /// Some encodings may append some final output at this point. > /// May raise the decoding_error condition. > fn flush(output: &mut ~str) -> Option; > } > > /// "Pull-based" API. > struct DecoderIterator { > input_iterator: I, > priv state: DecoderIteratorState, > } > > > impl> DecoderIterator { > fn new(input_iterator: I) -> DecoderIterator { > // Implementation left out. > } > > /// Consume the whole input iterator and return a single decoded > string. > /// May raise the decoding_error condition. > fn concat(&mut self) -> Result<~str, DecodeError> { > // Implementation left out. > } > } > > impl> Iterator> for > DecoderIterator { > /// Call .next() once on the input iterator and decode the result. > /// May raise the decoding_error condition. > /// Returns None after DecodeError was returned once, > /// even if the input iterator is not exhausted yet. > fn next(&mut self) -> Option> { > // Implementation left out. > } > } Looking at it first, I found a few things strange: - new_decoder returns an trait object, which incurs dynamic dispatch costs - Encoding uses explicit self despite not having any state - Decoder doesn't use explicit self despite having state - Decoder get's passed the target ~str on each feed and and flush call, despite it being always the same (should be passed on construction of the Decoder state and used internally) - I find the fact that flush itself can cause an DecodingError, despite not decoding anything new strange. flush should also maybe be called in the Decoder destructor. However, after playing around with it for a while I found that - If new_decoder returns a generic type, that must be passed in as a type parameter or be implemented as an assoziated type, which we don't have yet. - Calling assoziated functions on Encoding is currently impossible without an workaround because you can't specify the self type. But even if we can again it would look like this: `Encoding::::decode(source)`. Having assoziated function trait lookup on types would ease that somewhat. - Additionally, if new_decoder results in type parameters on Encoding, then you have to rely on inference for not having to specify them. - You can't pass the &mut ~str into a new Decoder using the Encoding trait because we need Higher Kinded Types for the 'self parameter. Based on this I have written two working proof of concepts of the proposed traits. I left API designs like error handling as is, but made Decoder having a proper state. The first variant implements an Encoding as I think it should work: Assoziated functions for new_decoder and decode: https://gist.github.com/Kimundi/6523377 The second variant works around the verbosity of specifying the right implementation by making trait lookup happen with a method call: https://gist.github.com/Kimundi/6522973 From quixoptic at googlemail.com Wed Sep 11 04:42:37 2013 From: quixoptic at googlemail.com (Alex) Date: Wed, 11 Sep 2013 12:42:37 +0100 Subject: [rust-dev] Type parameters in trait bounds In-Reply-To: References: Message-ID: <5230572D.9040109@gmail.com> So that solves the first error, now I have something like the following example.rs:4:44: 4:47 error: Illegal lifetime 'input: only 'self is allowed as part of a type declaration example.rs:4 fn do_something<'input, M: Map> (key: int, map: &'input M){ Which is weird because this isn't a type devlaration right? Anyway, putting 'self as the lifetime (despite that making no sense) gives me this: error: internal compiler error: unexpected failure note: the compiler hit an unexpected failure path. this is a bug note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues So I guess I'll go and report that. ^~~ Removing the 'input lifetime on str (which also doesn't really make sense to do but I thought I would try), results in example.rs:4:36: 4:40 error: Illegal anonymous lifetime: anonymous lifetimes are not permitted here example.rs:4 fn do_something<'input, M: Map> (key: int, map: &'input M){ Any other ideas? Thanks Alex On Mon 09 Sep 2013 18:14:50 BST, Oren Ben-Kiki wrote: > Rust newbie here as well, trying to develop an intuition for these > things myself :-) Off the top of my head - you are saying the map > holds entries whose lifetime is 'input; but there's no guarantee that > the map lifetime itself wouldn't be longer than that. Try saying > &'input M instead of &M and see how it goes. > > Oren. > > > On Fri, Sep 6, 2013 at 10:27 PM, Alex > wrote: > > Hey Everyone, > > I'm new to rust but enjoying it a lot. I'm having trouble with the > following code example: > > > use std::hashmap::{HashMap, Map}; > > > fn do_something<'input, M: Map> (key: int, map: &M){ > match map.find(key){ > Some(result) => println(fmt!("%s", result)), > None => println("no match") > }; > } > > fn main(){ > let map : HashMap = HashMap::new(); > map.insert(1, "one"); > do_something(1, map); > } > > > This fails with a compilation error: > > example.rs:4:44: 4:47 error: Illegal lifetime 'input: only 'self > is allowed as part of a type declaration > example.rs:4 fn do_something<'input, M: > Map> (key: int, map: &M){ > > > Now, I'm probably misunderstanding a bunch of things here, firstly > all the example code I've seen out there uses the HashMap type > directly rather than the Map trait, is this idiomatic? Secondly, > I'm still getting my head around lifetimes and probably have this > all muddled so any pointers there would be welcome. > > Thanks > Alex Good > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > From luke at snabb.co Wed Sep 11 08:50:41 2013 From: luke at snabb.co (Luke Gorrie) Date: Wed, 11 Sep 2013 17:50:41 +0200 Subject: [rust-dev] Zurich/CH Meetup In-Reply-To: <52308EEA.8030300@seld.be> References: <51FE39B5.1040600@seld.be> <2112333.scNfimRqL1@tph-l10036> <52308EEA.8030300@seld.be> Message-ID: On 11 September 2013 17:40, Jordi Boggiano wrote: > Nope, only one other person got back to me (off list) so I put the idea > on hold for now. FYI, t'was me that replied off list, and I happen to be giving a (non-Rust) talk at Zurich IT Geeks (ETH) in an hour from now. So if anybody wants to come and have a beer afterwards then we could call that an informal Rust meetup :) Details: http://www.meetup.com/zhgeeks/events/130168722/?a=cr1_grp&rv=cr1&_af_eid=130168722&_af=event(beer likely at the ETH student pub at the venue). Cheers, -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.boggiano at seld.be Wed Sep 11 09:00:23 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Wed, 11 Sep 2013 18:00:23 +0200 Subject: [rust-dev] Zurich/CH Meetup In-Reply-To: References: <51FE39B5.1040600@seld.be> <2112333.scNfimRqL1@tph-l10036> <52308EEA.8030300@seld.be> Message-ID: <52309397.9070207@seld.be> On 11.09.2013 17:50, Luke Gorrie wrote: > FYI, t'was me that replied off list, and I happen to be giving a > (non-Rust) talk at Zurich IT Geeks (ETH) in an hour from now. So if > anybody wants to come and have a beer afterwards then we could call that > an informal Rust meetup :) I was planning on coming already, so let's say two make a party ;) Cheers From niko at alum.mit.edu Wed Sep 11 09:53:30 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 11 Sep 2013 12:53:30 -0400 Subject: [rust-dev] Type parameters in trait bounds In-Reply-To: References: Message-ID: <20130911165330.GC4542@Mr-Bennet> Hi Alex, This is Issue #5121, I believe. That error message is certainly confusing but basically it's a bug and known limitation. I hope to lift it...soonish as part of the fix for finishing the work on lifetime syntax (#4846). Niko On Fri, Sep 06, 2013 at 08:27:49PM +0100, Alex wrote: > Hey Everyone, > > I'm new to rust but enjoying it a lot. I'm having trouble with the > following code example: > > > use std::hashmap::{HashMap, Map}; > > > fn do_something<'input, M: Map> (key: int, map: &M){ > match map.find(key){ > Some(result) => println(fmt!("%s", result)), > None => println("no match") > }; > } > > fn main(){ > let map : HashMap = HashMap::new(); > map.insert(1, "one"); > do_something(1, map); > } > > > This fails with a compilation error: > > example.rs:4:44: 4:47 error: Illegal lifetime 'input: only 'self is allowed > as part of a type declaration > example.rs:4 fn do_something<'input, M: Map> (key: int, > map: &M){ > > > Now, I'm probably misunderstanding a bunch of things here, firstly all the > example code I've seen out there uses the HashMap type directly rather than > the Map trait, is this idiomatic? Secondly, I'm still getting my head > around lifetimes and probably have this all muddled so any pointers there > would be welcome. > > Thanks > Alex Good > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From simon.sapin at exyr.org Wed Sep 11 15:44:15 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 12 Sep 2013 00:44:15 +0200 Subject: [rust-dev] Proposed API for character encodings In-Reply-To: <52308A0B.2080108@gmail.com> References: <522F3EF7.1000507@exyr.org> <52308A0B.2080108@gmail.com> Message-ID: <5230F23F.4030404@exyr.org> Le 11/09/2013 17:19, Marvin L?bel a ?crit : > On 09/10/2013 05:47 PM, Simon Sapin wrote: >> Hi, >> >> TR;DR: the actual proposal is at the end of this email. >> >> Rust today has good support for UTF-8 which new content definitely >> should use, but many systems still have to deal with legacy content >> that uses other character encodings. There are several projects around >> to implement more encodings in Rust. The most further along in my >> opinion is rust-encoding, notably because it implements the right >> specification. >> >> rust-encoding: https://github.com/lifthrasiir/rust-encoding >> >> The spec: http://encoding.spec.whatwg.org/ >> It has more precise definitions of error handling than some original >> RFCs, and better reflects the reality of legacy content on the web. >> >> There was some discussion in the past few days about importing >> rust-encoding (or part of it) into Rust?s libstd or libextra. Before >> that, I think it is important to define a good API. The spec defines >> one for JavaScript, but we should not copy that exactly. >> rust-encoding?s API is mostly good, but I think that error handling >> could be simplified. >> >> >> In abstract terms, an encoding (such as "UTF-8") is made of a decoder >> and an encoder. A decoder converts a stream of bytes into a stream of >> text (Unicode scalar values, ie. code points excluding surrogates), >> while an encoder does the reverse. This does not cover other kinds of >> stream transformation such as base64, compression, encryption, etc. >> >> Bytes are represented in Rust by u8, text by str/char. >> >> (Side note: Because of constraints imposed by JavaScript and to avoid >> costly conversions, Servo will probably use a different data type for >> representing text. This encoding API could eventually become generic >> over a Text trait, but I think that it should stick to str for now.) >> >> >> The most convenient way to represent a "stream" is with a vector or >> string. This however requires the whole input to be in memory before >> decoding/encoding can start, and that to be finished before any of the >> output can be used. It should definitely be possible to eg. decode >> some content as it arrives from the network, and parse it in a pipeline. >> >> The most fundamental type API is one where the user repeatedly >> "pushes" chunks of input into a decoder/encoders object (that may >> maintain state between chunks) and gets the output so far in return, >> then signals the end of the input. >> >> In iterator adapter where the users "pulls" output from the decoder >> which "pulls" from the input can be nicer, but is easy to build on top >> of a "push-based" API, while the reverse requires tasks. >> >> Iterator and Iterator are tempting, but we may need to work >> on big chucks at a time for efficiency: Iterator<~[u8]> and >> Iterator<~str>. Or could single-byte/char iterators be reliably >> inlined to achieve similar efficiency? >> >> >> Finally, this API also needs to support several kinds of errors >> handling. For example, a decoder should abort at the invalid byte >> sequence for XML, but insert U+FFFD (replacement character) for HTML. >> I?m not decided yet whether to just have the closed set of error >> handling modes defined in the spec, or make this open-ended with >> conditions. >> >> >> Based on all the above, here is a proposed API. Encoders are ommited, >> but they are mostly the same as decoders with [u8] and str swapped. >> >> >> /// Types implementing this trait are "algorithms" >> /// such as UTF8, UTF-16, SingleByteEncoding, etc. >> /// Values of these types are "encodings" as defined in the WHATWG spec: >> /// UTF-8, UTF-16-LE, Windows-1252, etc. >> trait Encoding { >> /// Could become an associated type with a ::new() constructor >> /// when the language supports that. >> fn new_decoder(&self) -> ~Decoder; >> >> /// Simple, "one shot" API. >> /// Decode a single byte string that is entirely in memory. >> /// May raise the decoding_error condition. >> fn decode(&self, input: &[u8]) -> Result<~str, DecodeError> { >> // Implementation (using a Decoder) left out. >> // This is a default method, but not meant to be overridden. >> } >> } >> >> /// Takes the invalid byte sequence. >> /// Return a replacement string, or None to abort with a DecodeError. >> condition! { >> pub decoding_error : ~[u8] -> Option<~str>; >> } >> >> struct DecodeError { >> input_byte_offset: uint, >> invalid_byte_sequence: ~[u8], >> } >> >> /// Each implementation of Encoding has one corresponding implementation >> /// of Decoder (and one of Encoder). >> /// >> /// A new Decoder instance should be used for every input. >> /// A Decoder instance should be discarded after DecodeError was >> returned. >> trait Decoder { >> /// Call this repeatedly with a chunck of input bytes. >> /// As much as possible of the decoded text is appended to output. >> /// May raise the decoding_error condition. >> fn feed(input: &[u8], output: &mut ~str) -> Option; >> >> /// Call this to indicate the end of the input. >> /// The Decoder instance should be discarded afterwards. >> /// Some encodings may append some final output at this point. >> /// May raise the decoding_error condition. >> fn flush(output: &mut ~str) -> Option; >> } >> >> /// "Pull-based" API. >> struct DecoderIterator { >> input_iterator: I, >> priv state: DecoderIteratorState, >> } >> >> >> impl> DecoderIterator { >> fn new(input_iterator: I) -> DecoderIterator { >> // Implementation left out. >> } >> >> /// Consume the whole input iterator and return a single decoded >> string. >> /// May raise the decoding_error condition. >> fn concat(&mut self) -> Result<~str, DecodeError> { >> // Implementation left out. >> } >> } >> >> impl> Iterator> for >> DecoderIterator { >> /// Call .next() once on the input iterator and decode the result. >> /// May raise the decoding_error condition. >> /// Returns None after DecodeError was returned once, >> /// even if the input iterator is not exhausted yet. >> fn next(&mut self) -> Option> { >> // Implementation left out. >> } >> } > Looking at it first, I found a few things strange: > - new_decoder returns an trait object, which incurs dynamic dispatch costs I should have added that in Servo?s main use-case, the encoding is not known at compile time but is based on a string label that typically comes from a Content-Type HTTP header: fn get_encoding_from_label(label: &str) -> ~Encoding { /* ... */ } In this case, we do want dynamic dispatch. If you know the encoding at compile time and want static dispatch, it is perfectly fine to use a specific type such as UTF8Decoder directly, without trait objects. > - Encoding uses explicit self despite not having any state It?s not exactly "state", but as explained in the comments an "encoding" is a value of a type that implements the Encoding trait, not just the type itself. For example, rust-encoding has a SingleByteEncoding representing many different encoding, with each value pointing at different tables. > - Decoder doesn't use explicit self despite having state That?s a mistake. .feed() and .flush() should be proper methods with self. > - Decoder get's passed the target ~str on each feed and and flush call, > despite it being always the same (should be passed on construction of > the Decoder state and used internally) The point is that it doesn?t have to be the same string. Each decoded chunks could be passed to the next step of a pipeline, eg. to an incremental parser. > - I find the fact that flush itself can cause an DecodingError, despite > not decoding anything new strange. .flush() indicates the end of the input. It can trigger an error eg. if the last input chunck ends with an incomplete but so far valid-looking UTF-8 byte sequence. To anticipate another possible question: .flush() most often doesn?t write any output, but it can write a termination sequence in some encodings like ISO-2022-JP. > flush should also maybe be called in > the Decoder destructor. I don?t think so. The point of .flush() is to deal with possible remaining output or error. If you?re dropping everything you don?t care about that. > However, after playing around with it for a while I found that > - If new_decoder returns a generic type, that must be passed in as a > type parameter or be implemented as an assoziated type, which we don't > have yet. Yes, as said in the comments, Decoder and Encoder should ideally be associated types and .new_decoder() would not be needed at all, but we don?t have that yet. > - Calling assoziated functions on Encoding is currently impossible > without an workaround because you can't specify the self type. But even > if we can again it would look like this: `Encoding:: Utf8>::decode(source)`. Having assoziated function trait lookup on types > would ease that somewhat. Just use self. It?s needed anyway. > - Additionally, if new_decoder results in type parameters on Encoding, > then you have to rely on inference for not having to specify them. See comments on this below. > - You can't pass the &mut ~str into a new Decoder using the Encoding > trait because we need Higher Kinded Types for the 'self parameter. Sorry, I don?t understand this part :/ > Based on this I have written two working proof of concepts of the > proposed traits. > I left API designs like error handling as is, but made Decoder having a > proper state. > > The first variant implements an Encoding as I think it should work: > Assoziated functions for new_decoder and decode: > https://gist.github.com/Kimundi/6523377 > > The second variant works around the verbosity of specifying the right > implementation by making trait lookup happen with a method call: > https://gist.github.com/Kimundi/6522973 As we discussed on IRC I believe that this does not cover the case where you do want dynamic dispatch. Thank you for your feedback! Cheers, -- Simon Sapin From steven099 at gmail.com Wed Sep 11 19:53:11 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Wed, 11 Sep 2013 22:53:11 -0400 Subject: [rust-dev] Subtyping in Rust In-Reply-To: References: <20130909133458.GE3459@Mr-Bennet> Message-ID: On Mon, Sep 9, 2013 at 6:20 PM, Nick Cameron wrote: > > Separately, I remember that the various pointer types can be implicitly > converted. I couldn't find anywhere where these conversions are defined. Is > my memory bad or my search skills? > You can implicitly borrow a pointer's referent by assigning the pointer to a compatible borrowed-pointer-typed variable / function argument. There be dragons in the manual, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lindsey at composition.al Wed Sep 11 21:17:38 2013 From: lindsey at composition.al (Lindsey Kuper) Date: Thu, 12 Sep 2013 00:17:38 -0400 Subject: [rust-dev] libsyntax default methods refactor -- anyone know what went wrong here? Message-ID: So, I've been trying to use default methods to streamline various parts of the Rust compiler and libraries. Most recently, I tried attacking the impls of Visitor in libsyntax. Since the Visitor trait already had default methods, the patch consists entirely of removed lines: https://github.com/lkuper/rust/commit/7950e5fbc26494c437237cb1a5b4583f7b6881e8 It builds without issue, but unfortunately, the results of `make check` are interesting. I get three run-pass test failures: failures: [run-pass] run-pass/issue-2216.rs [run-pass] run-pass/issue-9047.rs [run-pass] run-pass/labeled-break.rs These three tests all have something to do with labeled break/continue, and they all segfault. (Gist of all build messages here: https://gist.github.com/lkuper/6532993) Anyone have an idea why this change would result in this failure? The Visitor trait is used all over the compiler, but I didn't have to touch it at all, so it seems like the problem should be local to libsyntax. Lindsey From pnkfelix at mozilla.com Thu Sep 12 03:03:36 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Thu, 12 Sep 2013 12:03:36 +0200 Subject: [rust-dev] libsyntax default methods refactor -- anyone know what went wrong here? In-Reply-To: References: Message-ID: <52319178.2010401@mozilla.com> Lindsey (cc'ing rust-dev)- Its not due to your changes. These are problems that are in master that for some reasons bors has not caught: Issue #9127: debug no-optimize make check yields three failures https://github.com/mozilla/rust/issues/9127 Cheers, -Felix On 12/09/2013 06:17, Lindsey Kuper wrote: > So, I've been trying to use default methods to streamline various > parts of the Rust compiler and libraries. Most recently, I tried > attacking the impls of Visitor in libsyntax. Since the Visitor trait > already had default methods, the patch consists entirely of removed > lines: > > https://github.com/lkuper/rust/commit/7950e5fbc26494c437237cb1a5b4583f7b6881e8 > > It builds without issue, but unfortunately, the results of `make > check` are interesting. I get three run-pass test failures: > > failures: > [run-pass] run-pass/issue-2216.rs > [run-pass] run-pass/issue-9047.rs > [run-pass] run-pass/labeled-break.rs > > These three tests all have something to do with labeled > break/continue, and they all segfault. (Gist of all build messages > here: https://gist.github.com/lkuper/6532993) Anyone have an idea why > this change would result in this failure? The Visitor trait is used > all over the compiler, but I didn't have to touch it at all, so it > seems like the problem should be local to libsyntax. > > Lindsey > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidb at davidb.org Thu Sep 12 08:16:04 2013 From: davidb at davidb.org (David Brown) Date: Thu, 12 Sep 2013 08:16:04 -0700 Subject: [rust-dev] Compiler assertion and trait impl question Message-ID: <20130912151602.GA24598@davidb.org> Consider the following code ---------------------------------------------------------------------- pub trait Inner { fn secret(&self); } // This doesn't seem to help. impl Inner for @Inner { fn secret(&self) { self.secret(); } } pub trait Wrapper { fn blort(&self); } impl Wrapper for T { fn blort(&self) { self.secret(); } } // This function causes an assertion failure in rustc: // task failed at 'assertion failed: rp.is_none()', /home/davidb/rust/rust/src/librustc/middle/typeck/collect.rs:1108 // fn blort<'self, T: Inner>(item: &'self @T) { // item.secret(); // } struct Client; impl Inner for Client { fn secret(&self) { } } fn main() { let buf = @Client; buf.secret(); // Works // error: failed to find an implementation of trait Inner for // @Client buf.blort(); } ---------------------------------------------------------------------- This fails to compile: wrap.rs:32:4: 41:5 error: type `Client` does not implement any method in scope named `with_data` I'm modeling this after looking at the code in libstd/io.rs, but I'm not sure what I'm missing. I seem to be able to make it work by using 'impl Inner for @Client', but I'm not sure why that is required. Also, the commented out function causes an assertion failure in the compiler (it was a workaround attempt). Thanks, David From cce at ccs.neu.edu Thu Sep 12 08:49:12 2013 From: cce at ccs.neu.edu (Carl Eastlund) Date: Thu, 12 Sep 2013 11:49:12 -0400 Subject: [rust-dev] Compiler assertion and trait impl question In-Reply-To: <20130912151602.GA24598@davidb.org> References: <20130912151602.GA24598@davidb.org> Message-ID: This looks like bug 6396; function lifetimes don't work when named "self" apparently. Try naming it something else. https://github.com/mozilla/rust/issues/6396 Carl Eastlund On Thu, Sep 12, 2013 at 11:16 AM, David Brown wrote: > Consider the following code > ------------------------------**------------------------------**---------- > pub trait Inner { > fn secret(&self); > } > > // This doesn't seem to help. > impl Inner for @Inner { > fn secret(&self) { self.secret(); } > } > > pub trait Wrapper { > fn blort(&self); > } > > impl Wrapper for T { > fn blort(&self) { self.secret(); } > } > > // This function causes an assertion failure in rustc: > // task failed at 'assertion failed: rp.is_none()', > /home/davidb/rust/rust/src/**librustc/middle/typeck/collect**.rs:1108 > // fn blort<'self, T: Inner>(item: &'self @T) { > // item.secret(); > // } > > struct Client; > > impl Inner for Client { > fn secret(&self) { } > } > > fn main() { > let buf = @Client; > buf.secret(); // Works > > // error: failed to find an implementation of trait Inner for > // @Client > buf.blort(); > } > ------------------------------**------------------------------**---------- > > This fails to compile: > wrap.rs:32:4: 41:5 error: type `Client` does not implement any method in > scope named `with_data` > > I'm modeling this after looking at the code in libstd/io.rs, but I'm > not sure what I'm missing. > > I seem to be able to make it work by using 'impl Inner for @Client', > but I'm not sure why that is required. > > Also, the commented out function causes an assertion failure in the > compiler (it was a workaround attempt). > > Thanks, > David > ______________________________**_________________ > 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 Thu Sep 12 09:06:23 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 12 Sep 2013 11:06:23 -0500 Subject: [rust-dev] Windows Users can build Rust properly again ! Message-ID: I have updated and added new steps (Step 5) that correctly install the needed pthread libraries for Windows users of MinGW. Rust now correctly compiles Stage0, Stage1, Stage2 out of the box following the updated guide here: https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust The new package details for the pthread libraries provided from 'mingw-get show' , for those interested are below: Package: mingw32-libpthread-old Subsystem: mingw32 Components: dll POSIX threading library for Win32 --------------------------------- pthreads-w32 seeks to provide a freely available and high-quality implementation of pthreads for Windows. Pthreads is an API for writing multithreaded applications following the POSIX standard. The mingw32-libpthread-old package provides the MinGW pthreads-w32 runtime dll associated with MinGW GCC 4.5.2 and older. Due to an unfortunate naming choice, upgrading to newer GCC will also install the newer, renamed pthreads-w32 DLLs, removing the old DLL. While the may not affect the new GCC, threaded applications compiled using the older compiler will break, as they will miss this runtime library. Therefore, the old runtime library is provided here using a new package name: mingw32-libpthread-old, so that it can be (re)installed parallel to the new pthreads-w32 runtime libraries. Package: mingw32-libpthreadgc Subsystem: mingw32 Components: dll POSIX threading library for Win32 --------------------------------- pthreads-w32 seeks to provide a freely available and high-quality implementation of pthreads for Windows. Pthreads is an API for writing multithreaded applications following the POSIX standard. There are two mingw32 versions of the pthread-w32 runtime library: the standard one, provided by this package, is called libpthreadgc but may also be referred to as 'libpthread'. The non-standard one uses C++ exception handling, and is called libpthreadgce. (Note that the standard library may be used successfully with C++ code; indeed, on most *nix platorms the system pthreads implementation follows the behavior of mingw32-libpthreadgc, and NOT the behavior of the 'GCE' version). We recommend that most users rely on mingw32-libpthreadgc ('GC') and not mingw32-libpthreadgce ('GCE'). The mingw32-libpthreadgc and mingw32-libpthreadgce packages provide the two runtime libraries (most people need not install the 'GCE' one). The associated mingw32-pthreads-w32 package provides the documentation for the pthreads-w32 library, as well as the related development files. The mingw32-libquserex package provides optional support for enhanced standards conformance of the GCE runtime. mingw32-libpthreadgc is a required component of the MinGW Compiler Suite. -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnkfelix at mozilla.com Thu Sep 12 09:54:03 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Thu, 12 Sep 2013 18:54:03 +0200 Subject: [rust-dev] Compiler assertion and trait impl question In-Reply-To: References: <20130912151602.GA24598@davidb.org> Message-ID: <5231F1AB.3090605@mozilla.com> Carl, David (cc'ing rust-dev)_ Note that #6396 is about the 'self lifetime. That may or may not be related to the rustc assertion failure that David mentions in one of his comments, but I think the bulk of his example does not use lifetimes at all. (So I'm assuming that his main issues about `impl Inner for @Inner` are something else.) -Felix On 12/09/2013 17:49, Carl Eastlund wrote: > This looks like bug 6396; function lifetimes don't work when named > "self" apparently. Try naming it something else. > > https://github.com/mozilla/rust/issues/6396 > > Carl Eastlund > > > On Thu, Sep 12, 2013 at 11:16 AM, David Brown > wrote: > > Consider the following code > ---------------------------------------------------------------------- > pub trait Inner { > fn secret(&self); > } > > // This doesn't seem to help. > impl Inner for @Inner { > fn secret(&self) { self.secret(); } > } > > pub trait Wrapper { > fn blort(&self); > } > > impl Wrapper for T { > fn blort(&self) { self.secret(); } > } > > // This function causes an assertion failure in rustc: > // task failed at 'assertion failed: rp.is_none()', > /home/davidb/rust/rust/src/librustc/middle/typeck/collect.rs:1108 > > // fn blort<'self, T: Inner>(item: &'self @T) { > // item.secret(); > // } > > struct Client; > > impl Inner for Client { > fn secret(&self) { } > } > > fn main() { > let buf = @Client; > buf.secret(); // Works > > // error: failed to find an implementation of trait Inner for > // @Client > buf.blort(); > } > ---------------------------------------------------------------------- > > This fails to compile: > wrap.rs:32:4: 41:5 error: type `Client` does not implement any > method in scope named `with_data` > > I'm modeling this after looking at the code in libstd/io.rs > , but I'm > not sure what I'm missing. > > I seem to be able to make it work by using 'impl Inner for @Client', > but I'm not sure why that is required. > > Also, the commented out function causes an assertion failure in the > compiler (it was a workaround attempt). > > Thanks, > David > _______________________________________________ > 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 -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cce at ccs.neu.edu Thu Sep 12 10:03:19 2013 From: cce at ccs.neu.edu (Carl Eastlund) Date: Thu, 12 Sep 2013 13:03:19 -0400 Subject: [rust-dev] Compiler assertion and trait impl question In-Reply-To: <5231F1AB.3090605@mozilla.com> References: <20130912151602.GA24598@davidb.org> <5231F1AB.3090605@mozilla.com> Message-ID: Oh, yes, sorry. I saw the assertion failure and responded to that, and missed the other problem he was talking about. Carl Eastlund On Thu, Sep 12, 2013 at 12:54 PM, Felix S. Klock II wrote: > Carl, David (cc'ing rust-dev)_ > > Note that #6396 is about the 'self lifetime. > > That may or may not be related to the rustc assertion failure that David > mentions in one of his comments, but I think the bulk of his example does > not use lifetimes at all. (So I'm assuming that his main issues about > `impl Inner for @Inner` are something else.) > > -Felix > > > On 12/09/2013 17:49, Carl Eastlund wrote: > > This looks like bug 6396; function lifetimes don't work when named "self" > apparently. Try naming it something else. > > https://github.com/mozilla/rust/issues/6396 > > Carl Eastlund > > > On Thu, Sep 12, 2013 at 11:16 AM, David Brown wrote: > >> Consider the following code >> ---------------------------------------------------------------------- >> pub trait Inner { >> fn secret(&self); >> } >> >> // This doesn't seem to help. >> impl Inner for @Inner { >> fn secret(&self) { self.secret(); } >> } >> >> pub trait Wrapper { >> fn blort(&self); >> } >> >> impl Wrapper for T { >> fn blort(&self) { self.secret(); } >> } >> >> // This function causes an assertion failure in rustc: >> // task failed at 'assertion failed: rp.is_none()', >> /home/davidb/rust/rust/src/librustc/middle/typeck/collect.rs:1108 >> // fn blort<'self, T: Inner>(item: &'self @T) { >> // item.secret(); >> // } >> >> struct Client; >> >> impl Inner for Client { >> fn secret(&self) { } >> } >> >> fn main() { >> let buf = @Client; >> buf.secret(); // Works >> >> // error: failed to find an implementation of trait Inner for >> // @Client >> buf.blort(); >> } >> ---------------------------------------------------------------------- >> >> This fails to compile: >> wrap.rs:32:4: 41:5 error: type `Client` does not implement any method >> in scope named `with_data` >> >> I'm modeling this after looking at the code in libstd/io.rs, but I'm >> not sure what I'm missing. >> >> I seem to be able to make it work by using 'impl Inner for @Client', >> but I'm not sure why that is required. >> >> Also, the commented out function causes an assertion failure in the >> compiler (it was a workaround attempt). >> >> Thanks, >> David >> _______________________________________________ >> 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 > > > > -- > irc: pnkfelix on irc.mozilla.org > email: {fklock, pnkfelix}@mozilla.com > > > _______________________________________________ > 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 davidb at davidb.org Thu Sep 12 10:16:32 2013 From: davidb at davidb.org (David Brown) Date: Thu, 12 Sep 2013 10:16:32 -0700 Subject: [rust-dev] Compiler assertion and trait impl question In-Reply-To: <5231F1AB.3090605@mozilla.com> References: <20130912151602.GA24598@davidb.org> <5231F1AB.3090605@mozilla.com> Message-ID: 6396 does seem to be the issue with the commented out function, and changing self to another identifier lets that compile. But, yes, my main issue is with the impl of inner. I did get a variant to compile and now I'm getting a runtime failure about 'borrowed' that I'll look into more this evening. David On Sep 12, 2013, at 9:54 AM, "Felix S. Klock II" wrote: > Carl, David (cc'ing rust-dev)_ > > Note that #6396 is about the 'self lifetime. > > That may or may not be related to the rustc assertion failure that David mentions in one of his comments, but I think the bulk of his example does not use lifetimes at all. (So I'm assuming that his main issues about `impl Inner for @Inner` are something else.) > > -Felix > > On 12/09/2013 17:49, Carl Eastlund wrote: >> This looks like bug 6396; function lifetimes don't work when named "self" apparently. Try naming it something else. >> >> https://github.com/mozilla/rust/issues/6396 >> >> Carl Eastlund >> >> >> On Thu, Sep 12, 2013 at 11:16 AM, David Brown wrote: >>> Consider the following code >>> ---------------------------------------------------------------------- >>> pub trait Inner { >>> fn secret(&self); >>> } >>> >>> // This doesn't seem to help. >>> impl Inner for @Inner { >>> fn secret(&self) { self.secret(); } >>> } >>> >>> pub trait Wrapper { >>> fn blort(&self); >>> } >>> >>> impl Wrapper for T { >>> fn blort(&self) { self.secret(); } >>> } >>> >>> // This function causes an assertion failure in rustc: >>> // task failed at 'assertion failed: rp.is_none()', /home/davidb/rust/rust/src/librustc/middle/typeck/collect.rs:1108 >>> // fn blort<'self, T: Inner>(item: &'self @T) { >>> // item.secret(); >>> // } >>> >>> struct Client; >>> >>> impl Inner for Client { >>> fn secret(&self) { } >>> } >>> >>> fn main() { >>> let buf = @Client; >>> buf.secret(); // Works >>> >>> // error: failed to find an implementation of trait Inner for >>> // @Client >>> buf.blort(); >>> } >>> ---------------------------------------------------------------------- >>> >>> This fails to compile: >>> wrap.rs:32:4: 41:5 error: type `Client` does not implement any method in scope named `with_data` >>> >>> I'm modeling this after looking at the code in libstd/io.rs, but I'm >>> not sure what I'm missing. >>> >>> I seem to be able to make it work by using 'impl Inner for @Client', >>> but I'm not sure why that is required. >>> >>> Also, the commented out function causes an assertion failure in the >>> compiler (it was a workaround attempt). >>> >>> Thanks, >>> David >>> _______________________________________________ >>> 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 > > > -- > irc: pnkfelix on irc.mozilla.org > email: {fklock, pnkfelix}@mozilla.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Thu Sep 12 12:22:31 2013 From: vadimcn at gmail.com (Vadim) Date: Thu, 12 Sep 2013 12:22:31 -0700 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: References: Message-ID: Thanks Thad! It feels to me that Windows dev setup is getting overly complicated. Is there still any reason not to upgrade to GCC 4.7? This would remove the need to do all that dance with component downgrades. BTW, this also affects users of official Rust releases (#8598 ). I don't think build bot environment upgrades can be done via a PR, so we'll need help from someone on the core Rust team. Also, a new stage0 compiler snapshot will need to be cranked out because of #5878 . Vadim On Thu, Sep 12, 2013 at 9:06 AM, Thad Guidry wrote: > I have updated and added new steps (Step 5) that correctly install the > needed pthread libraries for Windows users of MinGW. > > Rust now correctly compiles Stage0, Stage1, Stage2 out of the box > following the updated guide here: > https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust > > > The new package details for the pthread libraries provided from 'mingw-get > show' , for those interested are below: > > > Package: mingw32-libpthread-old Subsystem: mingw32 > Components: dll > > POSIX threading library for Win32 > --------------------------------- > > pthreads-w32 seeks to provide a freely available and high-quality > implementation of pthreads for Windows. Pthreads is an API for writing > multithreaded applications following the POSIX standard. > > The mingw32-libpthread-old package provides the MinGW pthreads-w32 > runtime dll associated with MinGW GCC 4.5.2 and older. Due to an > unfortunate naming choice, upgrading to newer GCC will also install the > newer, renamed pthreads-w32 DLLs, removing the old DLL. While the may > not affect the new GCC, threaded applications compiled using the older > compiler will break, as they will miss this runtime library. Therefore, > the old runtime library is provided here using a new package name: > mingw32-libpthread-old, so that it can be (re)installed parallel to the > new pthreads-w32 runtime libraries. > > > Package: mingw32-libpthreadgc Subsystem: mingw32 > Components: dll > > POSIX threading library for Win32 > --------------------------------- > > pthreads-w32 seeks to provide a freely available and high-quality > implementation of pthreads for Windows. Pthreads is an API for writing > multithreaded applications following the POSIX standard. > > There are two mingw32 versions of the pthread-w32 runtime library: the > standard one, provided by this package, is called libpthreadgc but may > also be referred to as 'libpthread'. The non-standard one uses C++ > exception handling, and is called libpthreadgce. (Note that the standard > library may be used successfully with C++ code; indeed, on most *nix > platorms the system pthreads implementation follows the behavior of > mingw32-libpthreadgc, and NOT the behavior of the 'GCE' version). We > recommend that most users rely on mingw32-libpthreadgc ('GC') and not > mingw32-libpthreadgce ('GCE'). > > The mingw32-libpthreadgc and mingw32-libpthreadgce packages provide the > two runtime libraries (most people need not install the 'GCE' one). The > associated mingw32-pthreads-w32 package provides the documentation for > the pthreads-w32 library, as well as the related development files. The > mingw32-libquserex package provides optional support for enhanced > standards conformance of the GCE runtime. > > mingw32-libpthreadgc is a required component of the MinGW Compiler > Suite. > > -- > -Thad > Thad on Freebase.com > 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 thadguidry at gmail.com Thu Sep 12 12:39:49 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 12 Sep 2013 14:39:49 -0500 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: References: Message-ID: Yeah, there should not be a reason anymore, if I am correct, to not have GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try also , and if it works, then we can close out (#8598 ). (I also would like to get rid of the 4.5 downgrade needed).... but that does need more testing from the core Rust team and others. It's something that Brian has been counting on me to help make happen, and Alex is also contributing to some of that effort by fixing various LLVM build issues that affect Windows Rust users as you mention in (#8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878 . On Thu, Sep 12, 2013 at 2:22 PM, Vadim wrote: > Thanks Thad! > > It feels to me that Windows dev setup is getting overly complicated. Is > there still any reason not to upgrade to GCC 4.7? This would remove the > need to do all that dance with component downgrades. BTW, this also > affects users of official Rust releases (#8598 > ). > > I don't think build bot environment upgrades can be done via a PR, so > we'll need help from someone on the core Rust team. Also, a new stage0 > compiler snapshot will need to be cranked out because of #5878 > . > > Vadim > > > > On Thu, Sep 12, 2013 at 9:06 AM, Thad Guidry wrote: > >> I have updated and added new steps (Step 5) that correctly install the >> needed pthread libraries for Windows users of MinGW. >> >> Rust now correctly compiles Stage0, Stage1, Stage2 out of the box >> following the updated guide here: >> https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust >> >> >> The new package details for the pthread libraries provided from >> 'mingw-get show' , for those interested are below: >> >> >> Package: mingw32-libpthread-old Subsystem: mingw32 >> Components: dll >> >> POSIX threading library for Win32 >> --------------------------------- >> >> pthreads-w32 seeks to provide a freely available and high-quality >> implementation of pthreads for Windows. Pthreads is an API for writing >> multithreaded applications following the POSIX standard. >> >> The mingw32-libpthread-old package provides the MinGW pthreads-w32 >> runtime dll associated with MinGW GCC 4.5.2 and older. Due to an >> unfortunate naming choice, upgrading to newer GCC will also install the >> newer, renamed pthreads-w32 DLLs, removing the old DLL. While the may >> not affect the new GCC, threaded applications compiled using the older >> compiler will break, as they will miss this runtime library. Therefore, >> the old runtime library is provided here using a new package name: >> mingw32-libpthread-old, so that it can be (re)installed parallel to the >> new pthreads-w32 runtime libraries. >> >> >> Package: mingw32-libpthreadgc Subsystem: mingw32 >> Components: dll >> >> POSIX threading library for Win32 >> --------------------------------- >> >> pthreads-w32 seeks to provide a freely available and high-quality >> implementation of pthreads for Windows. Pthreads is an API for writing >> multithreaded applications following the POSIX standard. >> >> There are two mingw32 versions of the pthread-w32 runtime library: the >> standard one, provided by this package, is called libpthreadgc but may >> also be referred to as 'libpthread'. The non-standard one uses C++ >> exception handling, and is called libpthreadgce. (Note that the standard >> library may be used successfully with C++ code; indeed, on most *nix >> platorms the system pthreads implementation follows the behavior of >> mingw32-libpthreadgc, and NOT the behavior of the 'GCE' version). We >> recommend that most users rely on mingw32-libpthreadgc ('GC') and not >> mingw32-libpthreadgce ('GCE'). >> >> The mingw32-libpthreadgc and mingw32-libpthreadgce packages provide the >> two runtime libraries (most people need not install the 'GCE' one). The >> associated mingw32-pthreads-w32 package provides the documentation for >> the pthreads-w32 library, as well as the related development files. The >> mingw32-libquserex package provides optional support for enhanced >> standards conformance of the GCE runtime. >> >> mingw32-libpthreadgc is a required component of the MinGW Compiler >> Suite. >> >> -- >> -Thad >> Thad on Freebase.com >> Thad on LinkedIn >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at debethencourt.com Thu Sep 12 13:12:19 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Thu, 12 Sep 2013 16:12:19 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? Message-ID: Hello everyone, I'm interested in helping with some module development. A good way to learn Rust by using it and help Rust at the same time. Of the wanted modules in this page: https://github.com/mozilla/rust/wiki/Libs I'm attracted to datetime: https://github.com/mozilla/rust/wiki/Lib-datetime Just want to make sure there isn't anybody working on this to avoid accidental duplication. Thanks, Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at debethencourt.com Thu Sep 12 13:14:04 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Thu, 12 Sep 2013 16:14:04 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: Forgot to say I'm luisbg in IRC. For all of those who have seen/read me there. :) On 12 September 2013 16:12, Luis de Bethencourt wrote: > Hello everyone, > > I'm interested in helping with some module development. A good way to > learn Rust by using it and help Rust at the same time. > > Of the wanted modules in this page: > https://github.com/mozilla/rust/wiki/Libs > > I'm attracted to datetime: > https://github.com/mozilla/rust/wiki/Lib-datetime > > Just want to make sure there isn't anybody working on this to avoid > accidental duplication. > > Thanks, > Luis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Sep 12 14:10:34 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 12 Sep 2013 14:10:34 -0700 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: References: Message-ID: <52322DCA.8040104@mozilla.com> On 09/12/2013 12:39 PM, Thad Guidry wrote: > Yeah, there should not be a reason anymore, if I am correct, to not > have GCC 4.7 in MinGW for Rust Windows users anymore. I will give > that a try also , and if it works, then we can close out (#8598 > ). (I also would like to > get rid of the 4.5 downgrade needed).... but that does need more > testing from the core Rust team and others. > > It's something that Brian has been counting on me to help make happen, > and Alex is also contributing to some of that effort by fixing various > LLVM build issues that affect Windows Rust users as you mention in > (#8598 ). > > Agreed, if a new stage0 compiler snapshot can be created, then we > should be in the clear to also close out #5878 > . > > Thanks for everybody's amazing contributions to our Windows support. If somebody makes the changes necessary to work with a newer toolchain then we will upgrade the bots. It's unlikely we can do this before 0.8 though, due in two weeks. I gather that some folks would like to switch to the mingw-w64 toolchain as well. Is that in the cards here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Sep 12 14:28:09 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 12 Sep 2013 17:28:09 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Sorry it is late; it has been on my blog and reddit, but I forgot to post it here. Content copied from http://cmr.github.io/blog/2013/09/07/this-week-in-rust/ -- Welcome to another *This Week in Rust*. # What's cooking in master? 65 pull requests were merged this week, and bors has had some idle time when there wasn't anything approved in the queue. ## Breaking changes - `std::os::glob` has been replaced with a [pure Rust version](https://github.com/mozilla/rust/pull/8914), for cross-platform and compatability reasons. - `std::str::from_bytes` has been [renamed](https://github.com/mozilla/rust/pull/8997) to `std::str::from_utf8`, to be explicit about what it accepts. - Casting to bool with `as` is [no longer allowed](https://github.com/mozilla/rust/pull/8980), and surrogate characters are no longer allowed in strings. - char is [no longer](https://github.com/mozilla/rust/pull/8974) treated as an integer type (meaning it can't be casted to/from them), which removes the ability for safe code to create invalid characters. - Opening a listening socket and actually listening on it [have been split](https://github.com/mozilla/rust/pull/8954). If you're jiggy with the jive, listen and accept are now separate operations. (*ed*: this used to say bind and accept wereseparate; thanks to ecr for the correction.) ## Additions - `let` var hygiene has [landed](https://github.com/mozilla/rust/pull/9026). I'm sure this has cool implications, but I don't really know what they are. - An [`export_name` attribute](https://github.com/mozilla/rust/pull/8903) has been added to control what symbol name something is exported as (similar to `no_mangle`). - An `ExactSize` trait [has been added](https://github.com/mozilla/rust/pull/8884) to mark an iterator that always accurately reports its size in the `size_hint` method. - `ToStr` has been [implemented](https://github.com/mozilla/rust/pull/8960) for char and Ascii. - Safe accessors of `MutexArc` [have been implemented](https://github.com/mozilla/rust/pull/8966) - A bytes iterator [has been added](https://github.com/mozilla/rust/pull/8935) for newrt readers. - Stream is [automatically implemented](https://github.com/mozilla/rust/pull/8984) for types which implement Reader and Writer from newrt. - An `unreachable` macro [has been added](https://github.com/mozilla/rust/pull/8992) for better error reporting than a function could do. - newrt [can now do](https://github.com/mozilla/rust/pull/9000) simple DNS resolution. - strptime/strftime [now support](https://github.com/mozilla/rust/pull/9016) fractional seconds, out to tenths of a nanosecond. ## Changes etc - Name mangling [has been improved](https://github.com/mozilla/rust/pull/8875). - `rust_log.cpp` [has been converted](https://github.com/mozilla/rust/pull/8880) into pure Rust. - Debuginfo [now does closure capture](https://github.com/mozilla/rust/pull/8855) and very large structs. - A [bunch](https://github.com/mozilla/rust/pull/8947) [of](https://github.com/mozilla/rust/pull/8927) [repr](https://github.com/mozilla/rust/pull/8928) improvements landed. # Meeting There was no meteting this week listed on the wiki or that I saw. # Projects - [rust-nanomsg](https://github.com/glycerine/rust-nanomsg) - bindings to the nanomsg library. From thadguidry at gmail.com Thu Sep 12 14:57:15 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 12 Sep 2013 16:57:15 -0500 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: <52322DCA.8040104@mozilla.com> References: <52322DCA.8040104@mozilla.com> Message-ID: Yes, that's the game plan I have...and klutzy and Vadim.... getting the mingw-w64 toolchain working. On Thu, Sep 12, 2013 at 4:10 PM, Brian Anderson wrote: > On 09/12/2013 12:39 PM, Thad Guidry wrote: > > Yeah, there should not be a reason anymore, if I am correct, to not have > GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try > also , and if it works, then we can close out (#8598 > ). (I also would like to get rid of the 4.5 downgrade needed).... but > that does need more testing from the core Rust team and others. > > It's something that Brian has been counting on me to help make happen, > and Alex is also contributing to some of that effort by fixing various LLVM > build issues that affect Windows Rust users as you mention in (#8598 > ). > > Agreed, if a new stage0 compiler snapshot can be created, then we should > be in the clear to also close out #5878 > . > > > > Thanks for everybody's amazing contributions to our Windows support. If > somebody makes the changes necessary to work with a newer toolchain then we > will upgrade the bots. It's unlikely we can do this before 0.8 though, due > in two weeks. > > I gather that some folks would like to switch to the mingw-w64 toolchain > as well. Is that in the cards here? > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Thu Sep 12 15:06:16 2013 From: vadimcn at gmail.com (Vadim) Date: Thu, 12 Sep 2013 15:06:16 -0700 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: <52322DCA.8040104@mozilla.com> References: <52322DCA.8040104@mozilla.com> Message-ID: Hi Brian, Actually, I would argue that these changes *should* be made before 0.8 release in order to smoothen the path of people who will install 0.8 to try it out. Regarding the work to be done, as far as I know all you need is: 1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin 2. "mingw-get update" 3. "mingw-get upgrade" 4. run %rust%\configure (not sure if actually needed, but won't hurt) 5. "make clean" 6. "make check", which will fail at building stage1 std crate because step 3 upgraded libgcc and libstdc++ and stage0 compiler needs them. 7. copy dlls saved in step 1 into %rust%\build\i686-pc-mingw32\stage0\bin 8. "make check" again, which should succeed this time Can somebody please verify that this works? Re mingw-w64: sort of works, however its' phtreads implementation seems to be buggy . Also see this thread. I don't think we'll should migrate to it just yet. Vadim On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson wrote: > On 09/12/2013 12:39 PM, Thad Guidry wrote: > > Yeah, there should not be a reason anymore, if I am correct, to not have > GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try > also , and if it works, then we can close out (#8598 > ). (I also would like to get rid of the 4.5 downgrade needed).... but > that does need more testing from the core Rust team and others. > > It's something that Brian has been counting on me to help make happen, > and Alex is also contributing to some of that effort by fixing various LLVM > build issues that affect Windows Rust users as you mention in (#8598 > ). > > Agreed, if a new stage0 compiler snapshot can be created, then we should > be in the clear to also close out #5878 > . > > > > Thanks for everybody's amazing contributions to our Windows support. If > somebody makes the changes necessary to work with a newer toolchain then we > will upgrade the bots. It's unlikely we can do this before 0.8 though, due > in two weeks. > > I gather that some folks would like to switch to the mingw-w64 toolchain > as well. Is that in the cards here? > > _______________________________________________ > 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 Thu Sep 12 18:56:54 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 12 Sep 2013 20:56:54 -0500 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: References: <52322DCA.8040104@mozilla.com> Message-ID: Doesn't work... Errors regarding libuv and mswsock... http://pastebin.mozilla.org/3038909 On Thu, Sep 12, 2013 at 5:06 PM, Vadim wrote: > Hi Brian, > > Actually, I would argue that these changes *should* be made before 0.8 > release in order to smoothen the path of people who will install 0.8 to try > it out. > > Regarding the work to be done, as far as I know all you need is: > 1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin > 2. "mingw-get update" > 3. "mingw-get upgrade" > 4. run %rust%\configure (not sure if actually needed, but won't hurt) > 5. "make clean" > 6. "make check", which will fail at building stage1 std crate because step > 3 upgraded libgcc and libstdc++ and stage0 compiler needs them. > 7. copy dlls saved in step 1 into %rust%\build\i686-pc-mingw32\stage0\bin > 8. "make check" again, which should succeed this time > > Can somebody please verify that this works? > > > Re mingw-w64: sort of works, however its' phtreads implementation seems > to be buggy. > Also see this thread. > I don't think we'll should migrate to it just yet. > > Vadim > > > > On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson wrote: > >> On 09/12/2013 12:39 PM, Thad Guidry wrote: >> >> Yeah, there should not be a reason anymore, if I am correct, to not have >> GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try >> also , and if it works, then we can close out (#8598 >> ). (I also would like to get rid of the 4.5 downgrade needed).... but >> that does need more testing from the core Rust team and others. >> >> It's something that Brian has been counting on me to help make happen, >> and Alex is also contributing to some of that effort by fixing various LLVM >> build issues that affect Windows Rust users as you mention in (#8598 >> ). >> >> Agreed, if a new stage0 compiler snapshot can be created, then we >> should be in the clear to also close out #5878 >> . >> >> >> >> Thanks for everybody's amazing contributions to our Windows support. If >> somebody makes the changes necessary to work with a newer toolchain then we >> will upgrade the bots. It's unlikely we can do this before 0.8 though, due >> in two weeks. >> >> I gather that some folks would like to switch to the mingw-w64 toolchain >> as well. Is that in the cards here? >> >> _______________________________________________ >> 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 Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at debethencourt.com Thu Sep 12 19:52:57 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Thu, 12 Sep 2013 22:52:57 -0400 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: Thanks Corey! This updates are great to keep track of all things Rust. Kudos :) Luis On 12 September 2013 17:28, Corey Richardson wrote: > Sorry it is late; it has been on my blog and reddit, but I forgot to > post it here. Content copied from > http://cmr.github.io/blog/2013/09/07/this-week-in-rust/ > > -- > > Welcome to another *This Week in Rust*. > > # What's cooking in master? > > 65 pull requests were merged this week, and bors has had some idle time > when > there wasn't anything approved in the queue. > > ## Breaking changes > > - `std::os::glob` has been replaced with a [pure Rust > version](https://github.com/mozilla/rust/pull/8914), for cross-platform > and > compatability reasons. > - `std::str::from_bytes` has been > [renamed](https://github.com/mozilla/rust/pull/8997) to > `std::str::from_utf8`, to be explicit about what it accepts. > - Casting to bool with `as` is [no longer > allowed](https://github.com/mozilla/rust/pull/8980), and surrogate > characters are no longer allowed in strings. > - char is [no longer](https://github.com/mozilla/rust/pull/8974) treated > as an > integer type (meaning it can't be casted to/from them), which removes the > ability for safe code to create invalid characters. > - Opening a listening socket and actually listening on it [have been > split](https://github.com/mozilla/rust/pull/8954). If you're jiggy with > the > jive, listen and accept are now separate operations. (*ed*: this used to > say > bind and accept wereseparate; thanks to ecr for the correction.) > > ## Additions > > - `let` var hygiene has [landed](https://github.com/mozilla/rust/pull/9026 > ). > I'm sure this has cool implications, but I don't really know what they > are. > - An [`export_name` attribute](https://github.com/mozilla/rust/pull/8903) > has > been added to control what symbol name something is exported as (similar > to > `no_mangle`). > - An `ExactSize` trait [has been > added](https://github.com/mozilla/rust/pull/8884) to mark an iterator > that > always accurately reports its size in the `size_hint` method. > - `ToStr` has been [implemented](https://github.com/mozilla/rust/pull/8960 > ) > for char and Ascii. > - Safe accessors of `MutexArc` [have been > implemented](https://github.com/mozilla/rust/pull/8966) > - A bytes iterator [has been added]( > https://github.com/mozilla/rust/pull/8935) > for newrt readers. > - Stream is [automatically > implemented](https://github.com/mozilla/rust/pull/8984) for types which > implement Reader and Writer from newrt. > - An `unreachable` macro [has been > added](https://github.com/mozilla/rust/pull/8992) for better error > reporting > than a function could do. > - newrt [can now do](https://github.com/mozilla/rust/pull/9000) simple DNS > resolution. > - strptime/strftime [now support]( > https://github.com/mozilla/rust/pull/9016) > fractional seconds, out to tenths of a nanosecond. > > ## Changes etc > > - Name mangling [has been > improved](https://github.com/mozilla/rust/pull/8875). > - `rust_log.cpp` [has been > converted](https://github.com/mozilla/rust/pull/8880) into pure Rust. > - Debuginfo [now does closure > capture](https://github.com/mozilla/rust/pull/8855) and very large > structs. > - A [bunch](https://github.com/mozilla/rust/pull/8947) > [of](https://github.com/mozilla/rust/pull/8927) > [repr](https://github.com/mozilla/rust/pull/8928) improvements landed. > > # Meeting > > There was no meteting this week listed on the wiki or that I saw. > > # Projects > > - [rust-nanomsg](https://github.com/glycerine/rust-nanomsg) - bindings to > the > nanomsg library. > _______________________________________________ > 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 spam at scientician.net Thu Sep 12 21:57:20 2013 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 13 Sep 2013 06:57:20 +0200 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: On 2013-09-12 22:12, Luis de Bethencourt wrote: > Hello everyone, > > I'm interested in helping with some module development. A good way to learn > Rust by using it and help Rust at the same time. > > Of the wanted modules in this page: > https://github.com/mozilla/rust/wiki/Libs > I see that this page does have a link to design docs for JSR-310 which is probably a good bet as to a usable DateTime API design (for Java at least). I just thought I'd mention that the documentation for the "nearly final" (i.e. barring serious bugs) API has been released at: http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html Even if this is for Java, the design decisions about how the conepts of date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) would apply in any language. They are also all essential concepts when working seriously with date/time even though the distinctions may not appear so at first. (I should mention that the lead on the JSR-310 spec was also the author of JodaTime which gets much deserved credit by Java developers for bringing date/time manipulation on the JVM out of the dark ages of java.util.Date. JSR-310 is a slightly reworked/simplified version of that API, so it's a sort of "what are the essentials?" version of JodaTime.) Regards, From vadimcn at gmail.com Thu Sep 12 23:19:04 2013 From: vadimcn at gmail.com (Vadim) Date: Thu, 12 Sep 2013 23:19:04 -0700 Subject: [rust-dev] Windows Users can build Rust properly again ! In-Reply-To: References: <52322DCA.8040104@mozilla.com> Message-ID: Hmm. Looks like mingw released a new version with gcc 4.8 and that somehow broke mswsock.h (though the file didn't change). On Thu, Sep 12, 2013 at 6:56 PM, Thad Guidry wrote: > Doesn't work... > > Errors regarding libuv and mswsock... > > http://pastebin.mozilla.org/3038909 > > > > On Thu, Sep 12, 2013 at 5:06 PM, Vadim wrote: > >> Hi Brian, >> >> Actually, I would argue that these changes *should* be made before 0.8 >> release in order to smoothen the path of people who will install 0.8 to try >> it out. >> >> Regarding the work to be done, as far as I know all you need is: >> 1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin >> 2. "mingw-get update" >> 3. "mingw-get upgrade" >> 4. run %rust%\configure (not sure if actually needed, but won't hurt) >> 5. "make clean" >> 6. "make check", which will fail at building stage1 std crate because >> step 3 upgraded libgcc and libstdc++ and stage0 compiler needs them. >> 7. copy dlls saved in step 1 into %rust%\build\i686-pc-mingw32\stage0\bin >> 8. "make check" again, which should succeed this time >> >> Can somebody please verify that this works? >> >> >> Re mingw-w64: sort of works, however its' phtreads implementation seems >> to be buggy. >> Also see this thread. >> I don't think we'll should migrate to it just yet. >> >> Vadim >> >> >> >> On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson wrote: >> >>> On 09/12/2013 12:39 PM, Thad Guidry wrote: >>> >>> Yeah, there should not be a reason anymore, if I am correct, to not have >>> GCC 4.7 in MinGW for Rust Windows users anymore. I will give that a try >>> also , and if it works, then we can close out (#8598 >>> ). (I also would like to get rid of the 4.5 downgrade needed).... but >>> that does need more testing from the core Rust team and others. >>> >>> It's something that Brian has been counting on me to help make happen, >>> and Alex is also contributing to some of that effort by fixing various LLVM >>> build issues that affect Windows Rust users as you mention in (#8598 >>> ). >>> >>> Agreed, if a new stage0 compiler snapshot can be created, then we >>> should be in the clear to also close out #5878 >>> . >>> >>> >>> >>> Thanks for everybody's amazing contributions to our Windows support. If >>> somebody makes the changes necessary to work with a newer toolchain then we >>> will upgrade the bots. It's unlikely we can do this before 0.8 though, due >>> in two weeks. >>> >>> I gather that some folks would like to switch to the mingw-w64 toolchain >>> as well. Is that in the cards here? >>> >>> _______________________________________________ >>> 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 > Thad on Freebase.com > Thad on LinkedIn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Fri Sep 13 02:48:41 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 13 Sep 2013 05:48:41 -0400 Subject: [rust-dev] Subtyping in Rust In-Reply-To: References: <20130909133458.GE3459@Mr-Bennet> Message-ID: <20130913094841.GD6242@Mr-Bennet> I see. There is actually some debate about the proper behavior of `as`, but I believe the conversions that it will currently apply are: 1. Between scalar types (e.g., int to i32 and vice versa) 2. Into an object type (from @T into @Trait) 3. Borrowing (@T or ~T into &T) 4. Converting between unsafe pointer types, and I think uint to *T as well It has been proposed to limit `as` to #1 and rely instead on a combination of type ascription (`expr : T`), implicit conversions, and transmute calls for some of the others. In principle we could use library calls or traits for almost everything `as` does, except that we have been resisting the idea of compile-time evaluation of functions, meaning that we wanted to have operators for anything that would be legal as part of a constant definition. I am not sure if this principled stand is worth it, though, since `as` is a troublesome and heavily overloaded operator. Niko On Tue, Sep 10, 2013 at 10:20:02AM +1200, Nick Cameron wrote: > To clarify I meant subtyping in the sense of when are types compatible for > some kind of conversion. As opposed to subsumption or subclassing (or at > least, not limited to these cases). > > If I have |e as U| when does that succeed, and when does it fail. (Actually > from the manual it was unclear how much checking is done statically vs > dynamically, but that is kind of a tangent). Presumably the cast only > succeeds if the dynamic type of e is a subtype of U (or it can be coerced > or converted to U). An example from the manual (sect 8.1.10) shows that an > instance of an impl can be cast to the type of an implemented trait, are > there other relationships where casting is allowed? > > The manual states (sect 7.2.11.5): > > "A numeric value can be cast to any numeric type. A raw pointer value can > be cast to or from any integral type or raw pointer type. Any other cast is > unsupported and will fail to compile." > > But the last sentence is contradicted by the example in section 8.1.10 > > Separately, I remember that the various pointer types can be implicitly > converted. I couldn't find anywhere where these conversions are defined. Is > my memory bad or my search skills? > > Thanks, Nick > > > On Tue, Sep 10, 2013 at 1:34 AM, Niko Matsakis wrote: > > > By subtyping, do you mean defining class hierarchies as in C++ or > > Java? This is currently not supported. Typically such hierarchies > > are modeled either using an `enum` (most common) or using a `trait`. > > > > Enums are perfect for cases where there is a limited set of > > possibilities. Traits are perfect for "open-ended" situations where > > you have an interface and many ways to fulfill it. The two techniques > > *can* be combined for cases that fall between the two extremes. > > > > We have considered adding a limited form of struct inheritance (so > > that one struct can build on another) but afaik this feature is not > > planned in the short term. > > > > > > Niko > > > > On Mon, Sep 09, 2013 at 07:04:07PM +1200, Nick Cameron wrote: > > > Is there somewhere I can look for a description of subtyping in Rust? I > > > don't see any mention of it in the manual or tutorial. > > > > > > Thanks, Nick > > > > > _______________________________________________ > > > 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 niko at alum.mit.edu Fri Sep 13 02:51:13 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 13 Sep 2013 05:51:13 -0400 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: References: <522EC3B7.4040304@proinbox.com> Message-ID: <20130913095113.GE6242@Mr-Bennet> People seem to reimplement C++ compilers, despite there being an enormous amount of complex just parsing it... that said, the trickiest and least specified part of the type checker right now is probably the type inferencing algorithm, which I hope we can overhaul for something that is clearer or more easily specified. Niko On Wed, Sep 11, 2013 at 08:50:39AM -0400, Corey Richardson wrote: > On Wed, Sep 11, 2013 at 3:27 AM, Gregory Maxwell wrote: > > Presumably before rust reaches a point of earth-shaking importance > > there will be an second implementation which can compile the first > > compiler, thus permitting this solution. :) > > I wouldn't be so sure of that. There's a ton of trickiness around the > type and borrow checker and everything else, and I'm not sure anyone > would *want* to reimplement it. What gain would there be? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From robertknight at gmail.com Fri Sep 13 03:27:29 2013 From: robertknight at gmail.com (Robert Knight) Date: Fri, 13 Sep 2013 11:27:29 +0100 Subject: [rust-dev] Rust compiler bootstrapped In-Reply-To: <20130913095113.GE6242@Mr-Bennet> References: <522EC3B7.4040304@proinbox.com> <20130913095113.GE6242@Mr-Bennet> Message-ID: > People seem to reimplement C++ compilers, > despite there being an enormous amount of complex just parsing it Realistically though, how many implementations are libre and complete enough to actually build a C++ compiler? On 13 September 2013 10:51, Niko Matsakis wrote: > People seem to reimplement C++ compilers, despite there being an > enormous amount of complex just parsing it... that said, the trickiest > and least specified part of the type checker right now is probably the > type inferencing algorithm, which I hope we can overhaul for something > that is clearer or more easily specified. > > > Niko > > On Wed, Sep 11, 2013 at 08:50:39AM -0400, Corey Richardson wrote: >> On Wed, Sep 11, 2013 at 3:27 AM, Gregory Maxwell wrote: >> > Presumably before rust reaches a point of earth-shaking importance >> > there will be an second implementation which can compile the first >> > compiler, thus permitting this solution. :) >> >> I wouldn't be so sure of that. There's a ton of trickiness around the >> type and borrow checker and everything else, and I'm not sure anyone >> would *want* to reimplement it. What gain would there be? >> _______________________________________________ >> 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 russel at winder.org.uk Fri Sep 13 11:45:16 2013 From: russel at winder.org.uk (Russel Winder) Date: Fri, 13 Sep 2013 19:45:16 +0100 Subject: [rust-dev] Trouble building Rust Message-ID: <1379097916.4456.22.camel@anglides.winder.org.uk> I am running Debian Unstable, fully up to date. I have a clone of the Rust Git repository, again fully up to date. Everything used to build fine, but sometime recently something has changed, I assume in the Debian set up that means that I am no longer able to build Rust. Well I can'#t make the documentation which causes a build fail. Has anyone seen this and found a way forward? I tried manually running pandoc on rust.md but Make seems to think that hasn't done enough, I guess the problem is a dependency that always causes doc/version_info.html to be rebuilt. Thanks. compile_and_link: x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/librust.so Warning: removing previous 'librust-*.so' libraries: x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib//librust-28ac9d9c3782cf3d-0.8-pre.so version-info: doc/version_info.html sed -e "s/VERSION/0.8-pre/; s/SHORT_HASH/7c8f503a/;\ s/STAMP/7c8f503ac543e0ffe18986b8d6f8548df21cefa3/;" /home/Checkouts/Git/Git/Rust/doc/version_info.html.template >doc/version_info.html pandoc: doc/rust.html pandoc: /usr/share/pandoc/data/templates/default.html: openBinaryFile: does not exist (No such file or directory) events.js:72 throw er; // Unhandled 'error' event ^ Error: write EPIPE at errnoException (net.js:901:11) at Object.afterWrite (net.js:718:19) make: *** [doc/rust.html] Error 1 -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From m at minhdo.org Thu Sep 12 22:17:09 2013 From: m at minhdo.org (Minh Do) Date: Fri, 13 Sep 2013 13:17:09 +0800 Subject: [rust-dev] Working on rusti as final year project In-Reply-To: <521B85C2.8060804@minhdo.org> References: <521B85C2.8060804@minhdo.org> Message-ID: <52329FD5.8090107@minhdo.org> On 08/27/2013 12:43 AM, Minh Do wrote: > My name is Do Nhat Minh, currently a final year Computer Science > student at Nanyang Technological University in Singapore. I have > played with Rust and found the experience to be very pleasant. I think > Rust make sensible trade-offs and managed to stay small, compared to C++. > > I have been granted permission by my university supervisor to work on > rusti as my final year project. I hope with this contribution, Rust > will be even stronger a competitor to Go and D. > > This will be my first time working on something this size and this > long a duration. I would love to hear your advice or experience > implementing rusti. > > Thank you for your time. > > Regards, > Minh Hi, I'm working on figuring out why rusti segfaults. So far, I'm able to extract very little information. Attached is a backtrace from rusti using gdb. SIGSEGV is signaled inside jemalloc's tcache_alloc_easy, line 286. Below is the piece code where it fails. 274 JEMALLOC_ALWAYS_INLINE void * 275 tcache_alloc_easy(tcache_bin_t *tbin) 276 { 277 void *ret; 278 279 if (tbin->ncached == 0) { 280 tbin->low_water = -1; 281 return (NULL); 282 } 283 tbin->ncached--; 284 if ((int)tbin->ncached < tbin->low_water) 285 tbin->low_water = tbin->ncached; 286 ret = tbin->avail[tbin->ncached]; // <- XXX fail here 287 return (ret); 288 } jemalloc is trying to read from tbin->avail at tbin->ncached. tbin->ncached was 1227353920 (or 0x4927ef40) which is too big in my opinion. All the other values in tbin were unusually high or low, which leads me to suspect tbin is uninitialized or there is a memory overrun. I run valgrind on rusti in the hope of catching memory overruns, but it does not help much. Valgrind only prints some warning about conditional jumps depending on uninitialized variables and then reports an invalid read with the identical backtrace. However, at the top, valgrind prints the below text, which I find quite interesting. ==31583== Syscall param read(buf) points to unaddressable byte(s) ==31583== at 0x40170C7: read (in /usr/lib/ld-2.18.so) ==31583== by 0x400586C: open_verify (in /usr/lib/ld-2.18.so) ==31583== by 0x4005CA6: open_path (in /usr/lib/ld-2.18.so) ==31583== by 0x4008495: _dl_map_object (in /usr/lib/ld-2.18.so) ==31583== by 0x400C281: openaux (in /usr/lib/ld-2.18.so) ==31583== by 0x400E773: _dl_catch_error (in /usr/lib/ld-2.18.so) ==31583== by 0x400C4E4: _dl_map_object_deps (in /usr/lib/ld-2.18.so) ==31583== by 0x4002E93: dl_main (in /usr/lib/ld-2.18.so) ==31583== by 0x4015174: _dl_sysdep_start (in /usr/lib/ld-2.18.so) ==31583== by 0x4004AE5: _dl_start (in /usr/lib/ld-2.18.so) ==31583== by 0x4001277: ??? (in /usr/lib/ld-2.18.so) ==31583== Address 0x7fec7f700 is on thread 1's stack I then try linking directly with Rust's libstd (since it's the first thing that's linked with the code being compiled) in rusti's main() before anything is done. Below is the addition. diff --git a/src/librusti/rusti.rs b/src/librusti/rusti.rs index 8d61a97..2f72cfa 100644 --- a/src/librusti/rusti.rs +++ b/src/librusti/rusti.rs @@ -84,6 +84,9 @@ use syntax::print::pprust; use program::Program; use utils::*; +use rustc::lib::llvm::llvm; +use std::unstable::intrinsics; + mod program; pub mod utils; @@ -505,6 +508,17 @@ pub fn main() { pub fn main_args(args: &[~str]) { #[fixed_stack_segment]; #[inline(never)]; + unsafe { + let manager = llvm::LLVMRustPrepareJIT(intrinsics::morestack_addr()); + let path = "/path/to/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1-0.8-pre.so"; + do path.with_c_str |buf_t| { + if !llvm::LLVMRustLoadCrate(manager, buf_t) { + debug!(~"Could not link"); + } + debug!("linked: %s", path); + } + } + let input = io::stdin(); let out = io::stdout(); let mut repl = Repl { Rusti now also fails in the scheduler sometimes if it happens to switch threads while LLVMRustLoadCrate is being executed. Below is the backtrace. #0 rust_thread_start (ptr=0x7ffff1c1f5e0) at src/rt/sync/rust_thread.cpp:36 #1 0x00007ffff548b0a2 in start_thread () from /usr/lib/libpthread.so.0 #2 0x00007ffff3217a2d in clone () from /usr/lib/libc.so.6 The above failure in the scheduler and the curious message by valgrind makes me wonder about the scheduler and the runtime. However, when git grep-ing for rust_thread, I don't see how it is hooked into Rust. Could someone enlighten me on this? More importantly, does anyone have any suggestion about my approach or any leads on this? Regards, Minh -------------- next part -------------- #0 0x00007f43cecc7737 in SignalHandler(int) () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustllvm.so #1 #2 0x00007f43cdb1fd9d in tcache_alloc_easy (tbin=0x7f43ca8062e8) at ../../../../src/rt/jemalloc/include/jemalloc/internal/tcache.h:286 #3 tcache_alloc_small (zero=true, size=1315, tcache=0x7f43ca806000) at ../../../../src/rt/jemalloc/include/jemalloc/internal/tcache.h:300 #4 arena_malloc (try_tcache=true, zero=true, size=1315, arena=0x0) at ../../../../src/rt/jemalloc/include/jemalloc/internal/arena.h:916 #5 icallocx (arena=0x0, try_tcache=true, size=1315) at include/jemalloc/internal/jemalloc_internal.h:803 #6 icalloc (size=1315) at include/jemalloc/internal/jemalloc_internal.h:812 #7 calloc (num=, size=) at ../../../../src/rt/jemalloc/src/jemalloc.c:1079 #8 0x00007f43d1b0f75f in _dl_new_object () from /lib64/ld-linux-x86-64.so.2 #9 0x00007f43d1b0b204 in _dl_map_object_from_fd () from /lib64/ld-linux-x86-64.so.2 #10 0x00007f43d1b0cff5 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #11 0x00007f43d1b17917 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #12 0x00007f43d1b13774 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #13 0x00007f43d1b1732b in _dl_open () from /lib64/ld-linux-x86-64.so.2 #14 0x00007f43cd4dc02b in ?? () from /usr/lib/libdl.so.2 #15 0x00007f43d1b13774 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #16 0x00007f43cd4dc5dd in ?? () from /usr/lib/libdl.so.2 #17 0x00007f43cd4dc0c1 in dlopen () from /usr/lib/libdl.so.2 #18 0x00007f43cecb12e7 in llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::string*) () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustllvm.so #19 0x00007f43cdfdf46c in RustMCJITMemoryManager::loadCrate (this=this at entry=0x7f43ca85e100, file=file at entry=0x7f43c2220020 "/home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1-0.8-pre.so", err=err at entry=0x7f43caa48070) at src/rustllvm/RustWrapper.cpp:132 #20 0x00007f43cdfdfcfb in LLVMRustLoadCrate (mem=0x7f43ca85e100, crate=0x7f43c2220020 "/home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1-0.8-pre.so") at src/rustllvm/RustWrapper.cpp:271 #21 0x00007f43d02c385e in back::link::jit::exec::_c689f4ad2731ee34::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc-d3cb8c2ccd84a7a7-0.8-pre.so #22 0x00007f43d02c5a27 in back::link::write::run_passes::_8982e8a461f435::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc-d3cb8c2ccd84a7a7-0.8-pre.so #23 0x00007f43d0335568 in driver::driver::phase_5_run_llvm_passes::anon::expr_fn_97090 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc-d3cb8c2ccd84a7a7-0.8-pre.so #24 0x00007f43d00538e1 in util::common::time_72396::_c4d0513e54dc658e::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc-d3cb8c2ccd84a7a7-0.8-pre.so #25 0x00007f43d03352d2 in driver::driver::phase_5_run_llvm_passes::_af1696f6788ce06d::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc-d3cb8c2ccd84a7a7-0.8-pre.so #26 0x00007f43cf87f799 in run::_bdca1c883dbff4c::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librusti-53e0ef2ae196aaff-0.8-pre.so #27 0x00007f43cf8a17c5 in run_line::anon::expr_fn_17258 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librusti-53e0ef2ae196aaff-0.8-pre.so #28 0x00007f43cf89ecb1 in task::__extensions__::try_16906::anon::expr_fn_17066 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/librusti-53e0ef2ae196aaff-0.8-pre.so #29 0x00007f43d147b6b0 in task::spawn::spawn_raw::anon::expr_fn_37755 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #30 0x00007f43d14c25c0 in rt::task::__extensions__::build_start_wrapper::anon::anon::expr_fn_44126 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #31 0x00007f43d14c0ab7 in rt::task::__extensions__::run::anon::expr_fn_44054 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #32 0x00007f43cdb12834 in rust_try (f=, fptr=, env=) at src/rt/rust_builtin.cpp:523 #33 0x00007f43d14c09ec in rt::task::Unwinder::try::_199ab8d6eb226980EIaH::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #34 0x00007f43d14c0861 in rt::task::Task::run::_199ab8d6eb22698022aG::v0.8$x2dpre () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #35 0x00007f43d14c21ac in rt::task::__extensions__::build_start_wrapper::anon::expr_fn_44111 () from /home/minh/Documents/Workplace/rust/rust/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-6c65cf4b443341b1-0.8-pre.so #36 0x0000000000000000 in ?? () From catamorphism at gmail.com Fri Sep 13 11:50:03 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri, 13 Sep 2013 11:50:03 -0700 Subject: [rust-dev] Trouble building Rust In-Reply-To: <1379097916.4456.22.camel@anglides.winder.org.uk> References: <1379097916.4456.22.camel@anglides.winder.org.uk> Message-ID: I don't know what the bug with the docs is, but in the meantime, you can build without the docs by doing: ./configure --disable-docs and then rebuilding. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From danielmicay at gmail.com Fri Sep 13 11:57:03 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 13 Sep 2013 14:57:03 -0400 Subject: [rust-dev] Working on rusti as final year project In-Reply-To: <52329FD5.8090107@minhdo.org> References: <521B85C2.8060804@minhdo.org> <52329FD5.8090107@minhdo.org> Message-ID: On Fri, Sep 13, 2013 at 1:17 AM, Minh Do wrote: > On 08/27/2013 12:43 AM, Minh Do wrote: > >> My name is Do Nhat Minh, currently a final year Computer Science student >> at Nanyang Technological University in Singapore. I have played with Rust >> and found the experience to be very pleasant. I think Rust make sensible >> trade-offs and managed to stay small, compared to C++. >> >> I have been granted permission by my university supervisor to work on >> rusti as my final year project. I hope with this contribution, Rust will be >> even stronger a competitor to Go and D. >> >> This will be my first time working on something this size and this long a >> duration. I would love to hear your advice or experience implementing rusti. >> >> Thank you for your time. >> >> Regards, >> Minh >> > Hi, > > I'm working on figuring out why rusti segfaults. So far, I'm able to > extract very little information. > > Attached is a backtrace from rusti using gdb. SIGSEGV is signaled inside > jemalloc's tcache_alloc_easy, line 286. Below is the piece code where it > fails. > > 274 JEMALLOC_ALWAYS_INLINE void * > 275 tcache_alloc_easy(tcache_bin_t *tbin) > 276 { > 277 void *ret; > 278 > 279 if (tbin->ncached == 0) { > 280 tbin->low_water = -1; > 281 return (NULL); > 282 } > 283 tbin->ncached--; > 284 if ((int)tbin->ncached < tbin->low_water) > 285 tbin->low_water = tbin->ncached; > 286 ret = tbin->avail[tbin->ncached]; // <- XXX fail here > 287 return (ret); > 288 } > > jemalloc is trying to read from tbin->avail at tbin->ncached. > tbin->ncached was 1227353920 (or 0x4927ef40) which is too big in my > opinion. All the other values in tbin were unusually high or low, which > leads me to suspect tbin is uninitialized or there is a memory overrun. > > I run valgrind on rusti in the hope of catching memory overruns, but it > does not help much. Valgrind only prints some warning about conditional > jumps depending on uninitialized variables and then reports an invalid read > with the identical backtrace. However, at the top, valgrind prints the > below text, which I find quite interesting. > > ==31583== Syscall param read(buf) points to unaddressable byte(s) > ==31583== at 0x40170C7: read (in /usr/lib/ld-2.18.so) > ==31583== by 0x400586C: open_verify (in /usr/lib/ld-2.18.so) > ==31583== by 0x4005CA6: open_path (in /usr/lib/ld-2.18.so) > ==31583== by 0x4008495: _dl_map_object (in /usr/lib/ld-2.18.so) > ==31583== by 0x400C281: openaux (in /usr/lib/ld-2.18.so) > ==31583== by 0x400E773: _dl_catch_error (in /usr/lib/ld-2.18.so) > ==31583== by 0x400C4E4: _dl_map_object_deps (in /usr/lib/ld-2.18.so) > ==31583== by 0x4002E93: dl_main (in /usr/lib/ld-2.18.so) > ==31583== by 0x4015174: _dl_sysdep_start (in /usr/lib/ld-2.18.so) > ==31583== by 0x4004AE5: _dl_start (in /usr/lib/ld-2.18.so) > ==31583== by 0x4001277: ??? (in /usr/lib/ld-2.18.so) > ==31583== Address 0x7fec7f700 is on thread 1's stack > > I then try linking directly with Rust's libstd (since it's the first thing > that's linked with the code being compiled) in rusti's main() before > anything is done. Below is the addition. > > diff --git a/src/librusti/rusti.rs b/src/librusti/rusti.rs > index 8d61a97..2f72cfa 100644 > --- a/src/librusti/rusti.rs > +++ b/src/librusti/rusti.rs > @@ -84,6 +84,9 @@ use syntax::print::pprust; > use program::Program; > use utils::*; > > +use rustc::lib::llvm::llvm; > +use std::unstable::intrinsics; > + > mod program; > pub mod utils; > > @@ -505,6 +508,17 @@ pub fn main() { > pub fn main_args(args: &[~str]) { > #[fixed_stack_segment]; #[inline(never)]; > > + unsafe { > + let manager = llvm::LLVMRustPrepareJIT(** > intrinsics::morestack_addr()); > + let path = "/path/to/rust/x86_64-unknown-** > linux-gnu/stage2/lib/rustc/**x86_64-unknown-linux-gnu/lib/l** > ibstd-6c65cf4b443341b1-0.8-**pre.so > "; > + do path.with_c_str |buf_t| { > + if !llvm::LLVMRustLoadCrate(**manager, buf_t) { > + debug!(~"Could not link"); > + } > + debug!("linked: %s", path); > + } > + } > + > let input = io::stdin(); > let out = io::stdout(); > let mut repl = Repl { > > Rusti now also fails in the scheduler sometimes if it happens to switch > threads while LLVMRustLoadCrate is being executed. Below is the backtrace. > > #0 rust_thread_start (ptr=0x7ffff1c1f5e0) at > src/rt/sync/rust_thread.cpp:36 > #1 0x00007ffff548b0a2 in start_thread () from /usr/lib/libpthread.so.0 > #2 0x00007ffff3217a2d in clone () from /usr/lib/libc.so.6 > > The above failure in the scheduler and the curious message by valgrind > makes me wonder about the scheduler and the runtime. However, when git > grep-ing for rust_thread, I don't see how it is hooked into Rust. Could > someone enlighten me on this? > > More importantly, does anyone have any suggestion about my approach or any > leads on this? > > Regards, > Minh > Compile jemalloc with --enable-debug (you can add it to rt.mk) and it will check for things like double-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at debethencourt.com Fri Sep 13 12:10:21 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Fri, 13 Sep 2013 15:10:21 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: Hello Bardur, Thank you so much for the reference resource of JSR-310 and its design docs. I looked over it briefly and it is indeed very valuable. It was listed in the wiki page, but the link was to the former home of it. I have updated it. Since nobody has claimed this module, I will start working on this module tomorrow Saturday. Is that OK? Please, please, I would love more comments and ideas. Will start asking for reviews once I have some code to show. Thanks, Luis On 13 September 2013 00:57, Bardur Arantsson wrote: > On 2013-09-12 22:12, Luis de Bethencourt wrote: > > Hello everyone, > > > > I'm interested in helping with some module development. A good way to > learn > > Rust by using it and help Rust at the same time. > > > > Of the wanted modules in this page: > > https://github.com/mozilla/rust/wiki/Libs > > > > I see that this page does have a link to design docs for JSR-310 which > is probably a good bet as to a usable DateTime API design (for Java at > least). I just thought I'd mention that the documentation for the > "nearly final" (i.e. barring serious bugs) API has been released at: > > http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html > > Even if this is for Java, the design decisions about how the conepts of > date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) > would apply in any language. They are also all essential concepts when > working seriously with date/time even though the distinctions may not > appear so at first. > > (I should mention that the lead on the JSR-310 spec was also the author > of JodaTime which gets much deserved credit by Java developers for > bringing date/time manipulation on the JVM out of the dark ages of > java.util.Date. JSR-310 is a slightly reworked/simplified version of > that API, so it's a sort of "what are the essentials?" version of > JodaTime.) > > Regards, > > > _______________________________________________ > 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 garethdanielsmith at gmail.com Fri Sep 13 12:40:55 2013 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Fri, 13 Sep 2013 20:40:55 +0100 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: <52336A47.8040605@gmail.com> I think its great that you are going to be working on this. A comprehensive datetime library is very important. That said I have not got any particular ideas or comments. I have not used Joda time/JSR-310 but the docs look promising and lots of people seem to recommend it. Cheers Gareth On 13/09/13 20:10, Luis de Bethencourt wrote: > Hello Bardur, > > Thank you so much for the reference resource of JSR-310 and its design > docs. > I looked over it briefly and it is indeed very valuable. > > It was listed in the wiki page, but the link was to the former home of it. > I have updated it. > > Since nobody has claimed this module, I will start working on this > module tomorrow Saturday. > Is that OK? > > Please, please, I would love more comments and ideas. Will start > asking for reviews once I have some code to show. > > Thanks, > Luis > > > > > > On 13 September 2013 00:57, Bardur Arantsson > wrote: > > On 2013-09-12 22:12, Luis de Bethencourt wrote: > > Hello everyone, > > > > I'm interested in helping with some module development. A good > way to learn > > Rust by using it and help Rust at the same time. > > > > Of the wanted modules in this page: > > https://github.com/mozilla/rust/wiki/Libs > > > > I see that this page does have a link to design docs for JSR-310 which > is probably a good bet as to a usable DateTime API design (for Java at > least). I just thought I'd mention that the documentation for the > "nearly final" (i.e. barring serious bugs) API has been released at: > > http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html > > Even if this is for Java, the design decisions about how the > conepts of > date/time are modeled (Instant vs. *DateTime, Periods, Durations, > etc.) > would apply in any language. They are also all essential concepts when > working seriously with date/time even though the distinctions may not > appear so at first. > > (I should mention that the lead on the JSR-310 spec was also the > author > of JodaTime which gets much deserved credit by Java developers for > bringing date/time manipulation on the JVM out of the dark ages of > java.util.Date. JSR-310 is a slightly reworked/simplified version of > that API, so it's a sort of "what are the essentials?" version of > JodaTime.) > > Regards, > > > _______________________________________________ > 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 aaron.dandy at live.com Fri Sep 13 12:51:29 2013 From: aaron.dandy at live.com (Aaron Dandy) Date: Fri, 13 Sep 2013 13:51:29 -0600 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: , , Message-ID: I remember reading this article: http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a while back and really appreciating date time & time zone libraries. Also after reading news of the leap second triggering a bug on a bunch of systems I now question all assumptions I make about our representations of time. I can no longer say that a minute is 60 seconds long with a straight face. Next up I guess we programmers have a year 2038 problem to deal with too. This library will be a big deal to write but there thankfully there should be a lot of existing knowledge to learn from. Date: Fri, 13 Sep 2013 15:10:21 -0400 From: luis at debethencourt.com To: spam at scientician.net CC: rust-dev at mozilla.org Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? Hello Bardur, Thank you so much for the reference resource of JSR-310 and its design docs.I looked over it briefly and it is indeed very valuable. It was listed in the wiki page, but the link was to the former home of it. I have updated it. Since nobody has claimed this module, I will start working on this module tomorrow Saturday.Is that OK? Please, please, I would love more comments and ideas. Will start asking for reviews once I have some code to show. Thanks,Luis On 13 September 2013 00:57, Bardur Arantsson wrote: On 2013-09-12 22:12, Luis de Bethencourt wrote: > Hello everyone, > > I'm interested in helping with some module development. A good way to learn > Rust by using it and help Rust at the same time. > > Of the wanted modules in this page: > https://github.com/mozilla/rust/wiki/Libs > I see that this page does have a link to design docs for JSR-310 which is probably a good bet as to a usable DateTime API design (for Java at least). I just thought I'd mention that the documentation for the "nearly final" (i.e. barring serious bugs) API has been released at: http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html Even if this is for Java, the design decisions about how the conepts of date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) would apply in any language. They are also all essential concepts when working seriously with date/time even though the distinctions may not appear so at first. (I should mention that the lead on the JSR-310 spec was also the author of JodaTime which gets much deserved credit by Java developers for bringing date/time manipulation on the JVM out of the dark ages of java.util.Date. JSR-310 is a slightly reworked/simplified version of that API, so it's a sort of "what are the essentials?" version of JodaTime.) Regards, _______________________________________________ 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 dteller at mozilla.com Fri Sep 13 13:05:26 2013 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 13 Sep 2013 22:05:26 +0200 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: <52336A47.8040605@gmail.com> References: <52336A47.8040605@gmail.com> Message-ID: <52337006.2060600@mozilla.com> I believe that it would be a good idea to ensure that the Rust datetime library is a superset of the JS Date object and that it passes a port of the EcmaScript tests. Cheers, David On 9/13/13 9:40 PM, Gareth Smith wrote: > I think its great that you are going to be working on this. A > comprehensive datetime library is very important. That said I have not > got any particular ideas or comments. > > I have not used Joda time/JSR-310 but the docs look promising and lots > of people seem to recommend it. > > Cheers > Gareth -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From thadguidry at gmail.com Fri Sep 13 13:08:44 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Fri, 13 Sep 2013 15:08:44 -0500 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: One idea and use case for Paleontologists and Geologists coming over to Rust in droves... :-) Generically, just be able to handle simple Geologic addition and subtraction against an Epoch itself (reference date) http://en.wikipedia.org/wiki/Epoch_(reference_date) using known abbreviations. And additionally, store, understand, and output them: B.Y.B.P = Billion Years Before Present M.Y.B.P = Million Years Before Present On Fri, Sep 13, 2013 at 2:51 PM, Aaron Dandy wrote: > I remember reading this article: > http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a > while back and really appreciating date time & time zone libraries. Also > after reading news of the leap second triggering a bug on a bunch of > systems I now question all assumptions I make about our representations of > time. I can no longer say that a minute is 60 seconds long with a straight > face. Next up I guess we programmers have a year 2038 problem to deal with > too. This library will be a big deal to write but there thankfully there > should be a lot of existing knowledge to learn from. > > ------------------------------ > Date: Fri, 13 Sep 2013 15:10:21 -0400 > From: luis at debethencourt.com > To: spam at scientician.net > CC: rust-dev at mozilla.org > Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? > > > Hello Bardur, > > Thank you so much for the reference resource of JSR-310 and its design > docs. > I looked over it briefly and it is indeed very valuable. > > It was listed in the wiki page, but the link was to the former home of it. > I have updated it. > > Since nobody has claimed this module, I will start working on this module > tomorrow Saturday. > Is that OK? > > Please, please, I would love more comments and ideas. Will start asking > for reviews once I have some code to show. > > Thanks, > Luis > > > > > > On 13 September 2013 00:57, Bardur Arantsson wrote: > > On 2013-09-12 22:12, Luis de Bethencourt wrote: > > Hello everyone, > > > > I'm interested in helping with some module development. A good way to > learn > > Rust by using it and help Rust at the same time. > > > > Of the wanted modules in this page: > > https://github.com/mozilla/rust/wiki/Libs > > > > I see that this page does have a link to design docs for JSR-310 which > is probably a good bet as to a usable DateTime API design (for Java at > least). I just thought I'd mention that the documentation for the > "nearly final" (i.e. barring serious bugs) API has been released at: > > http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html > > Even if this is for Java, the design decisions about how the conepts of > date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) > would apply in any language. They are also all essential concepts when > working seriously with date/time even though the distinctions may not > appear so at first. > > (I should mention that the lead on the JSR-310 spec was also the author > of JodaTime which gets much deserved credit by Java developers for > bringing date/time manipulation on the JVM out of the dark ages of > java.util.Date. JSR-310 is a slightly reworked/simplified version of > that API, so it's a sort of "what are the essentials?" version of > JodaTime.) > > Regards, > > > _______________________________________________ > 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 Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Sep 13 13:12:07 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 13 Sep 2013 16:12:07 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: On Fri, Sep 13, 2013 at 3:10 PM, Luis de Bethencourt wrote: > Please, please, I would love more comments and ideas. Will start asking for > reviews once I have some code to show. > Joda-Time looks quite nice. My only desire from a datetime lib is "easy to use correctly". From thadguidry at gmail.com Fri Sep 13 13:20:25 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Fri, 13 Sep 2013 15:20:25 -0500 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: Additionally, Be able to convert "bya" to "mya" ? http://en.wikipedia.org/wiki/Bya The short scale is now commonly used, btw... but also need to deal with this for conversions: http://en.wikipedia.org/wiki/Long_and_short_scales There should be a preference boolean for conversion output for short or long scale... especially concerning above a thousand million. That's enough to get you going with some wild ideas that Jodatime does not handle. On Fri, Sep 13, 2013 at 3:08 PM, Thad Guidry wrote: > One idea and use case for Paleontologists and Geologists coming over to > Rust in droves... :-) > > Generically, just be able to handle simple Geologic addition and > subtraction against an Epoch itself (reference date) > http://en.wikipedia.org/wiki/Epoch_(reference_date) using known > abbreviations. > > And additionally, store, understand, and output them: > > B.Y.B.P = Billion Years Before Present > M.Y.B.P = Million Years Before Present > > > > > On Fri, Sep 13, 2013 at 2:51 PM, Aaron Dandy wrote: > >> I remember reading this article: >> http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a >> while back and really appreciating date time & time zone libraries. Also >> after reading news of the leap second triggering a bug on a bunch of >> systems I now question all assumptions I make about our representations of >> time. I can no longer say that a minute is 60 seconds long with a straight >> face. Next up I guess we programmers have a year 2038 problem to deal with >> too. This library will be a big deal to write but there thankfully there >> should be a lot of existing knowledge to learn from. >> >> ------------------------------ >> Date: Fri, 13 Sep 2013 15:10:21 -0400 >> From: luis at debethencourt.com >> To: spam at scientician.net >> CC: rust-dev at mozilla.org >> Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? >> >> >> Hello Bardur, >> >> Thank you so much for the reference resource of JSR-310 and its design >> docs. >> I looked over it briefly and it is indeed very valuable. >> >> It was listed in the wiki page, but the link was to the former home of it. >> I have updated it. >> >> Since nobody has claimed this module, I will start working on this module >> tomorrow Saturday. >> Is that OK? >> >> Please, please, I would love more comments and ideas. Will start asking >> for reviews once I have some code to show. >> >> Thanks, >> Luis >> >> >> >> >> >> On 13 September 2013 00:57, Bardur Arantsson wrote: >> >> On 2013-09-12 22:12, Luis de Bethencourt wrote: >> > Hello everyone, >> > >> > I'm interested in helping with some module development. A good way to >> learn >> > Rust by using it and help Rust at the same time. >> > >> > Of the wanted modules in this page: >> > https://github.com/mozilla/rust/wiki/Libs >> > >> >> I see that this page does have a link to design docs for JSR-310 which >> is probably a good bet as to a usable DateTime API design (for Java at >> least). I just thought I'd mention that the documentation for the >> "nearly final" (i.e. barring serious bugs) API has been released at: >> >> >> http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html >> >> Even if this is for Java, the design decisions about how the conepts of >> date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) >> would apply in any language. They are also all essential concepts when >> working seriously with date/time even though the distinctions may not >> appear so at first. >> >> (I should mention that the lead on the JSR-310 spec was also the author >> of JodaTime which gets much deserved credit by Java developers for >> bringing date/time manipulation on the JVM out of the dark ages of >> java.util.Date. JSR-310 is a slightly reworked/simplified version of >> that API, so it's a sort of "what are the essentials?" version of >> JodaTime.) >> >> Regards, >> >> >> _______________________________________________ >> 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 > Thad on Freebase.com > Thad on LinkedIn > -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at debethencourt.com Fri Sep 13 13:31:22 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Fri, 13 Sep 2013 16:31:22 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: Cool! Great and awesome feedback. The summary is that Joda-Time is what we should aspire to have. My goal is to first cover the "most common use cases", and as Corey says, "easy to use correctly". After that I can start considering the corner cases like bya and mya. Which sound very fun and interesting, but not high priority. Hopefully by then I won't be too consumed by the question of what is Time. Thanks, will keep you guys updated, Luis On 13 September 2013 16:20, Thad Guidry wrote: > Additionally, > > Be able to convert "bya" to "mya" ? http://en.wikipedia.org/wiki/Bya > > The short scale is now commonly used, btw... but also need to deal with > this for conversions: > > http://en.wikipedia.org/wiki/Long_and_short_scales > > There should be a preference boolean for conversion output for short or > long scale... especially concerning above a thousand million. > > That's enough to get you going with some wild ideas that Jodatime does not > handle. > > > > On Fri, Sep 13, 2013 at 3:08 PM, Thad Guidry wrote: > >> One idea and use case for Paleontologists and Geologists coming over to >> Rust in droves... :-) >> >> Generically, just be able to handle simple Geologic addition and >> subtraction against an Epoch itself (reference date) >> http://en.wikipedia.org/wiki/Epoch_(reference_date) using known >> abbreviations. >> >> And additionally, store, understand, and output them: >> >> B.Y.B.P = Billion Years Before Present >> M.Y.B.P = Million Years Before Present >> >> >> >> >> On Fri, Sep 13, 2013 at 2:51 PM, Aaron Dandy wrote: >> >>> I remember reading this article: >>> http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html a >>> while back and really appreciating date time & time zone libraries. Also >>> after reading news of the leap second triggering a bug on a bunch of >>> systems I now question all assumptions I make about our representations of >>> time. I can no longer say that a minute is 60 seconds long with a straight >>> face. Next up I guess we programmers have a year 2038 problem to deal with >>> too. This library will be a big deal to write but there thankfully there >>> should be a lot of existing knowledge to learn from. >>> >>> ------------------------------ >>> Date: Fri, 13 Sep 2013 15:10:21 -0400 >>> From: luis at debethencourt.com >>> To: spam at scientician.net >>> CC: rust-dev at mozilla.org >>> Subject: Re: [rust-dev] lib: Is anybody working on the datetime library? >>> >>> >>> Hello Bardur, >>> >>> Thank you so much for the reference resource of JSR-310 and its design >>> docs. >>> I looked over it briefly and it is indeed very valuable. >>> >>> It was listed in the wiki page, but the link was to the former home of >>> it. >>> I have updated it. >>> >>> Since nobody has claimed this module, I will start working on this >>> module tomorrow Saturday. >>> Is that OK? >>> >>> Please, please, I would love more comments and ideas. Will start asking >>> for reviews once I have some code to show. >>> >>> Thanks, >>> Luis >>> >>> >>> >>> >>> >>> On 13 September 2013 00:57, Bardur Arantsson wrote: >>> >>> On 2013-09-12 22:12, Luis de Bethencourt wrote: >>> > Hello everyone, >>> > >>> > I'm interested in helping with some module development. A good way to >>> learn >>> > Rust by using it and help Rust at the same time. >>> > >>> > Of the wanted modules in this page: >>> > https://github.com/mozilla/rust/wiki/Libs >>> > >>> >>> I see that this page does have a link to design docs for JSR-310 which >>> is probably a good bet as to a usable DateTime API design (for Java at >>> least). I just thought I'd mention that the documentation for the >>> "nearly final" (i.e. barring serious bugs) API has been released at: >>> >>> >>> http://download.java.net/jdk8/docs/technotes/guides/datetime/index.html >>> >>> Even if this is for Java, the design decisions about how the conepts of >>> date/time are modeled (Instant vs. *DateTime, Periods, Durations, etc.) >>> would apply in any language. They are also all essential concepts when >>> working seriously with date/time even though the distinctions may not >>> appear so at first. >>> >>> (I should mention that the lead on the JSR-310 spec was also the author >>> of JodaTime which gets much deserved credit by Java developers for >>> bringing date/time manipulation on the JVM out of the dark ages of >>> java.util.Date. JSR-310 is a slightly reworked/simplified version of >>> that API, so it's a sort of "what are the essentials?" version of >>> JodaTime.) >>> >>> Regards, >>> >>> >>> _______________________________________________ >>> 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 >> Thad on Freebase.com >> Thad on LinkedIn >> > > > > -- > -Thad > Thad on Freebase.com > Thad on LinkedIn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flaper87 at gmail.com Fri Sep 13 14:13:28 2013 From: flaper87 at gmail.com (Flaper87) Date: Fri, 13 Sep 2013 23:13:28 +0200 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: 2013/9/13 Luis de Bethencourt > Cool! > > Great and awesome feedback. The summary is that Joda-Time is what we > should aspire to have. > > My goal is to first cover the "most common use cases", and as Corey says, > "easy to use correctly". > > After that I can start considering the corner cases like bya and mya. > Which sound very fun and interesting, but not high priority. > Hopefully by then I won't be too consumed by the question of what is Time. > Another thing that I'd like to see there is a good handling of TZs. Many datetime libraries got that wrong. Here's a blog post Armin wrote that may be helpful. http://lucumr.pocoo.org/2011/7/15/eppur-si-muove/ Thanks for taking care of this. FF -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Sep 13 14:21:13 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 13 Sep 2013 17:21:13 -0400 Subject: [rust-dev] Windows Help for rustdoc_ng Message-ID: Hi all, I've hit a wall with rustdoc_ng. It fails to build on Windows with http://buildbot.rust-lang.org/builders/auto-win-32-opt/builds/1435/steps/compile/logs/stdio, the error being: note: i686-pc-mingw32\stage1\bin\rustc\i686-pc-mingw32\bin\lib.o:fake:(.text+0x68373): undefined reference to `SetLastError' I find this very strange that it manifests in rustdoc_ng. The only reason I could see it failing is that it would need to link to libstd's dependencies (kernel32 in this case). Does anyone know what's going on here? From luis at debethencourt.com Fri Sep 13 14:27:15 2013 From: luis at debethencourt.com (Luis de Bethencourt) Date: Fri, 13 Sep 2013 17:27:15 -0400 Subject: [rust-dev] lib: Is anybody working on the datetime library? In-Reply-To: References: Message-ID: That is a really good article and a very valid point. Writing down all the feedback for future reference in my development. Thanks FF, Luis On 13 September 2013 17:13, Flaper87 wrote: > > > > 2013/9/13 Luis de Bethencourt > >> Cool! >> >> Great and awesome feedback. The summary is that Joda-Time is what we >> should aspire to have. >> >> My goal is to first cover the "most common use cases", and as Corey says, >> "easy to use correctly". >> >> After that I can start considering the corner cases like bya and mya. >> Which sound very fun and interesting, but not high priority. >> Hopefully by then I won't be too consumed by the question of what is Time. >> > > > Another thing that I'd like to see there is a good handling of TZs. Many > datetime libraries got that wrong. Here's a blog post Armin wrote that may > be helpful. > > http://lucumr.pocoo.org/2011/7/15/eppur-si-muove/ > > Thanks for taking care of this. > FF > > -- > Flavio (@flaper87) Percoco > http://www.flaper87.com > http://github.com/FlaPer87 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Fri Sep 13 15:03:43 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Sat, 14 Sep 2013 00:03:43 +0200 Subject: [rust-dev] Proposed API for character encodings In-Reply-To: <522F3EF7.1000507@exyr.org> References: <522F3EF7.1000507@exyr.org> Message-ID: <52338BBF.4000803@exyr.org> Here is an updated proposal, based on email and IRC feedback. The changes are: * Fix .feed() and .flush() to have the self parameter they need. * Remove the iterator stuff. I don?t find it super useful, and it?s easy enough to build on top of the "push" API. KISS. * Duplicate the "one shot" convenience API in Decoder so that it?s usable without involving trait objects and dynamic dispatch. * Make the output generic in the low-level API by having StringWriter instead of ~str * Add encoding_from_label() * De-emphasize the Encoding trait by moving it to the end. It is only useful together with encoding_from_label() and other dynamic-dispatch scenarios. If the encoding to use is known at compile time, one can use eg. UTF8Decoder directly. Again, this is only decoders. Encoders are basically the same, with [u8] and str swapped. Maybe the output could just be std::rt::io::Writer. /// Each implementation of Encoding has one corresponding implementation /// of Decoder (and one of Encoder). /// /// A new Decoder instance should be used for every input. /// A Decoder instance should be discarded /// after DecodeError was returned. trait Decoder { /// Simple, "one shot" API. /// Decode a single byte string that is entirely in memory. /// May raise the decoding_error condition. fn decode(input: &[u8]) -> Result<~str, DecodeError> { // Implementation left out. // This is a default method, but not meant to be overridden. } fn new() -> Self; /// Call this repeatedly with a chunck of input bytes. /// As much as possible of the decoded text is appended to output. /// May raise the decoding_error condition. fn feed(&self, input: &[u8], output: &mut W) -> Option; /// Call this to indicate the end of the input. /// The Decoder instance should be discarded afterwards. /// Some encodings may append some final output at this point. /// May raise the decoding_error condition. fn flush(&self, output: &mut W) -> Option; } /// Takes the invalid byte sequence. /// Return a replacement string, or None to abort with a DecodeError. condition! { pub decoding_error : ~[u8] -> Option<~str>; } /// Functions to be used with decoding_error::cond.trap mod decoding_error_handlers { fn fatal(_: ~[u8]) -> Option<~str> { None } fn replacement(_: ~[u8]) -> Option<~str> { Some(~"\uFFFD") } } struct DecodeError { input_byte_offset: uint, invalid_byte_sequence: ~[u8], } trait StringWriter { fn write_char(&mut self, c: char); fn write_str(&mut self, s: &str); } /// Only supports the set of labels defined in the spec /// http://encoding.spec.whatwg.org/#encodings /// Such a label can come eg. from an HTTP header: /// Content-Type: text/plain; charset=